在 App 里，遇到告警或者提示用户，「确定」按钮应该放在左边还是右边？
下面我将详细解释原因，并探讨一些特殊情况和设计考虑：
核心原则：用户习惯与阅读方向
1. 从左往右的阅读习惯 (LTR LefttoRight):
在大多数西方文化和使用拉丁字母的语言中，用户习惯于从左到右阅读。这意味着用户的视线会首先落在屏幕的左侧。
当一个对话框出现时，用户会自然地从左扫描信息，然后寻找操作按钮。
将“确定”放在右边，符合用户完成动作的心理流程：先理解信息，再进行确认（完成）。而“取消”放在左边，则可以看作是“回退”或“忽略”的起始点。
2. 心理上的“下一步”和“完成”:
从左到右的阅读顺序，也意味着右侧通常与“继续”、“下一步”、“完成”等积极的、向前推进的操作相关联。
“确定”按钮代表着用户接受并希望执行某个操作，是一种积极的反馈。将它放在用户视线和操作流程的“终点”或“结尾”位置（右边），更符合这种“完成”的心理预期。
为什么“确定”放在右边更常见和推荐？
最常见的对话框模式: 许多操作系统（如 Windows, macOS, iOS, Android）以及主流应用的设计都遵循了“取消”在左，“确定”在右的模式。用户早已对此形成了一种潜移默化的习惯。突然改变这种习惯，可能会让用户感到困惑和不适。
减少误操作: 对于一些关键性的操作，例如删除、支付、提交等，用户需要仔细确认。如果用户不小心点到“确定”按钮，而它又在左边，可能导致用户以为是“取消”而误操作。将“确定”放在右边，用户在阅读完提示信息后，视线自然会移到右边进行确认，从而减少了因为急于关闭弹窗而误触“确定”的风险。
与链接和按钮的默认状态一致: 在很多网页和App中，链接通常是蓝色的下划线文本，它们也倾向于出现在左侧（描述性信息）或居中。而需要触发动作的按钮，尤其是主操作按钮，则常出现在右侧。
场景分析与细节考量：
虽然“确定”在右边是主流，但也有一些细微的考虑因素：
1. 按钮的数量和类型：
只有“确定”按钮： 如果弹窗只有一个“确定”按钮，那么它的位置相对不那么关键，但放在右边仍然符合“下一步”的直觉。
“确定”和“取消”： 这是最经典的情况，强烈建议“取消”左，“确定”右。
“确定”、“取消”和其他操作： 当存在多个按钮时，例如“确定”、“取消”、“稍后提醒”、“重新加载”等，按钮的布局会更复杂。此时需要遵循一定的优先级和分组原则。
负面或取消性操作（如“取消”、“否”、“关闭”、“稍后”）倾向于放在左侧。
正面或执行性操作（如“确定”、“保存”、“发送”、“继续”）倾向于放在右侧。
最关键或最常用的操作，往往被设计成突出显示的主按钮，通常放在右边。
2. 语境和操作的性质：
危险操作（如“删除”、“退出”、“格式化”）： 在这些情况下，“确定”按钮（有时会改名为“删除”、“退出”）仍然可以放在右边，但“取消”按钮的作用就更加重要。有时，“确定”按钮会使用警示性的颜色（如红色），以引起用户注意。
信息性提示 (非交互)： 如果一个提示只是通知用户某件事情，并没有需要用户“确定”去执行的操作，那么可能根本不需要按钮，或者只有一个“关闭”或“知道了”的按钮，其位置可以居中或左边。
用户主导的流程： 在一些引导用户完成设置或任务的流程中，如果一个按钮代表了“完成”这个任务的步骤，那么它通常会被放在右边。
3. 按钮的视觉样式：
主操作按钮（Primary Button）vs. 次操作按钮（Secondary Button）：
主操作按钮通常是视觉上最突出的（例如，有填充背景色、颜色更鲜艳），代表用户最可能选择的操作。它常常被设计成“确定”或“下一步”。
次操作按钮通常视觉样式较弱（例如，只有边框或文字样式），代表次要的操作，如“取消”或“返回”。
推荐： 将视觉上更突出的“确定”按钮放在右边，将视觉上较弱的“取消”按钮放在左边，这形成了一种清晰的操作层级。
4. 国际化和本地化 (i18n/l10n)：
从右往左的阅读方向 (RTL RighttoLeft): 在阿拉伯语、希伯来语等语言的环境下，用户习惯于从右往左阅读。在这种情况下，按钮的布局应该镜像翻转。“确定”按钮应该放在左边，“取消”按钮应该放在右边。
如果你的App需要支持多语言，务必为RTL语言环境进行相应的按钮布局调整。
举例说明：
App 提示： “您确定要删除这条消息吗？”
按钮布局： `[ 取消 ] [ 确定 ]` (左为取消，右为确定)
App 设置： “您想保存这些更改吗？”
按钮布局： `[ 暂不保存 ] [ 保存 ]` (左为暂不保存，右为保存)
App 支付： “您确定支付 ￥100 吗？”
按钮布局： `[ 取消支付 ] [ 确认支付 ]` (左为取消，右为确认支付)
App 操作失败： “加载失败，是否重试？”
按钮布局： `[ 取消 ] [ 重试 ]` (左为取消，右为重试)
总结与最佳实践：
1. 默认情况： 在绝大多数情况下，将“确定”按钮放在右边，将“取消”或否定性选项放在左边。这是最符合用户习惯的设计。
2. 视觉突出： 将“确定”按钮设计成主操作按钮，使其在视觉上更突出，更能吸引用户的注意力。
3. 语境优先： 仔细分析弹窗或提示的语境和用户想要达成的目标，确保按钮的文字和位置都传达清晰的操作意图。
4. 测试： 如果不确定，可以进行 A/B 测试，观察用户在不同按钮布局下的操作行为和反馈。
5. 国际化： 确保你的App能够正确处理RTL语言环境下的按钮布局。
简而言之，请优先考虑用户习惯和阅读方向，将“确定”按钮放在右边，这通常是最佳的选择。
网友意见
iOS说，「 I'm always right 」，于是「确定」就在了右边。
Android倔强的说，「要在左边」，于是「确定」就在了左边。
接着，iOS把Android胖揍了一顿，「 stay foolish ，foolish......都TM要在右边」，Android被硬拗到了右边。
这是个老话题了，只是时间流转，各平台都在更新，我们也要与时俱进，有必要再拿出来提一提。
移动端三大主要平台，Android、iOS、Windows Phone，咱们逐个说。
1. 先从WP开始吧，WP平台内的弹出提示称之为「raw notifications」，延续Win桌面平台的设计原则。
图1
如图1所示，dialog内操作按键称之为「Commit button」，肯定性操作位于左边，否定性操作位于最右边。Win平台定义了具体的用法与顺序：Yes/No, Yes/No/Cancel, [Do it]/Cancel, [Do it]/[Don't do it], [Do it]/[Don't do it]/Cancel。传送门：http://msdn.microsoft.com/en-us/library/aa511268.aspx#commitButtons ps.注意OK键没有在此间出没，后面具体说明。
图2
WP平台及Win8平台dialog内操作按键的左右顺序也是一致的（图2）。
2. iOS平台，它的出身与历史注定了与OS X在设计上的传承。与Win相反（或者说Win有意与OS X相反，这里面又要翻出一堆历史遗留问题了 ^_^）肯定性操作位于右边，否定性操作位于左边。（大多数情况下）ps. iOS需要注意按键高亮的状态。
图3
OS X用户预期所有的按键位于dialog的右底部，启动一个操作的按键总是位于最右侧。该按键称之为「Action button」，以确认当前dialog最重要的操作。取消按键位于「Action button」的左侧（图3左）。 OS X Interface Guidelines，传送门（参见Dialog章节）： http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Windows/Windows.html#//apple_ref/doc/uid/20000961-TP10
iOS继承了OS X的设计原则（图3右），只是稍稍有些不一样，体现在对于Cancel的理解上：
- 当操作涉及潜在的风险时，两个按键中「Cancel」按键应位于右侧，并高亮提示。
- 当需要引导人们进行所期望的操作时，两个按键中的「Cancel」按应位于左侧，相对应的操作按键高亮提示。
iOS中「Cancel」可能位于左侧，也可能位于右侧，这取决于所执行的操作是否具有破坏性。 iOS平台更看中的是按键的高亮状态（iOS高亮状态始终在右侧，OS X则不然）。同时在dialog弹出的情况下按下Home键，应当是等同于点击了「Cancel」按键，并不执行任何操作。iOS Human Interface Guidelines，传送门(参见alert的描述)： http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW39
3. Android平台，这才是最头痛的家伙，大多数的坑都在这里。刚出道时，可能是因为当时设计规范执行力度、Android系统的碎片化等原因，导致dialog内的操作按键顺序随着各应用开发者喜好而定，大多数与Win平台保持一致。更新至Android 4.x后，官方终于对此有了一个很明确的态度，并在Android Design里有了标准的定义。
图4
Dialog操作按钮通常是「取消」/「确定」，确定键同时也是首选操作以及最可能执行的操作。但是，如果涉及特殊操作例如关闭或等待，那么所有的按钮都应该使用动词。同是，dialog中肯定性的操作总是安排在右侧，而否定性的操作放在左侧。与iOS理念上统一，但也有所保留！^_^ ps.就算是到现在还是能看到大量的Android应用与该原则相悖，或许是惯性，或许是迁就低版本系统... -_-'
Android Design，传送门（参见Dialog章节）：http://developer.android.com/design/building-blocks/dialogs.html
聊完了各平台的设计规范，对各平台dialog内操作按键的顺序有所了解，大家知道怎么去进行设计了，但是身为设计者需要更进一步的思考，有兴趣的请越过下面华丽的切糕线。
-----------切糕线-----------
-----------切糕线-----------
如果你是一个苦逼的设计者，在完全没有设计原则指导的情况下，将如何安排Dialog内操作按键的顺序呢？...... 想个五分钟吧。
以下仅为个人观点！！欢迎打脸 ^_^
我倾向于肯定性操作位于右边，否定性操作位于左边，也就是「取消」/「确定」。ps.所说皆错
「确定」/「取消」，采用这种顺序最大的理由是符合自然的阅读顺序，也就是大部分从左起语言的顺序。用户在执行某操作弹出dialog后，视线最先接触的是需要执行的「Action」，因为设计者认为「Action」重要程度比「Cancel」要高，需要着重强调（这里涉及认知领域的首因效应，以后有机会再讲吧。）ps.由于是Win平台所采用的顺序，就简称为Win顺序吧。
「取消」/「确定」，由于主要是水果平台采用，以下简称为 OS X顺序，或者iOS顺序。说说具体为什么倾向它的几个理由：
- 阅读视线流
- 扫视时的阅读顺序
- 逻辑顺序
1. 阅读视线流，Win顺序虽然能够用户视线更早接触到「Action」，但不可否认一个事实，用户会阅读完所有可操作的选项，这意味着用户的视线不会停留在「Action」上，它将继续向后进行扫描，在查看完所有可选项后，再返回之前的的「Action」执行相应操作。采用iOS顺序，用户的视线流将会更平滑，视线最终停留的位置也是「Action」所处的位置。通过图5对比，可以得知「确定」放置于左侧，将导致用户的视线流发生改变，用户视线流无意识的回跳，而放于右侧将保持视线流在一个方向，减少视线曲折搜索的过程。
图5
2. 扫视时的阅读顺序，有人可能会问了这与第1条理由有什么区别？阅读是由扫视（saccades）和凝视（fixation）两个动作连续组合、切换的过程。第1条的理由基于凝视（fixation）运动过程。
为什么在dialog弹出时会出现扫视？因为，用户对于dialog里的内容只是快速的浏览，或者说是没有人会认真阅读dialog里的内容。由此也引申出dialog设计时的一个重要原则：不要在dialog相关的action按键里写上「好」或「确定」等，应该用实际会发生的动作来命名。这也是为什么建议使用动词的原因。如：你需要执行一个「保存」操作，那你的dialog里出现的相关Action应该是「取消」和「保存」。
说回扫视，用户的在进行扫视时顺序往往如图6，最终视觉的落点是在视觉界面的右下角（Terminal Area），扫视终点往往就在「Action」区域上，该区域能够获得更多的视觉关注。这也是为什么Win及OS X桌面系统内的dialog按键均非居中显示，而是位于右下角的原因。Gutenberg Diagram（古藤堡图表）也是用以描述扫视顺序的模型（传送门：http://www.studiodino.com/info/news47.htm）。。ps.注意图6标识出的区域1，iOS在右侧「Action」键上加了高亮效果，这对视觉搜索有益。
图6
3. 逻辑顺序，首先让我们来对dialog内按键定义一下，「确定」按键是用户以执行相关操作的按键，点击后将对现有状态发生根本性的改变。「取消」按键是使用户返回到原来状态，取消当前dialog。
这意味着，用户点击「Action」后将进入下一步操作，点击「Cancel」将执行返回操作。想想我们常见的：浏览器上的导航按键、kindle上的左右翻页按键、安装软件过程当中的「上一步」「下一步」......等等！
如图7，用户在dialog内所看到的视觉顺序与逻辑顺序是一致的。
图7
另外，桌面平台上还考虑到用户左右手使用习惯，这其实与dialog内的逻辑顺序也有所关联。我们知道大部分的人主要是右手用户，当dialog内的「Action」位于右侧时，用户在操作时能够更为顺应他们自身的使用习惯。 这一点还体现在Win和OS X桌面文件排布顺序方面，OS X为了大部分的右手用户将桌面文件分布在屏幕的右侧。
图8
最后来个Ending，其实视觉顺序在设计时，或系统设计时是一条很重要的原则，需要设计师重视这条原则，举例说明（图9），从下图中将Win和OS X的窗口控制按键抽离出来，并将「关闭」替换成「取消」，如果将这些操作放置在一个dialog中，有没有发现它们还是符合这两个系统分别坚持的设计原则呢？
图9
BTW. 有同学建议采用上下结构解决左右顺序问题，这其实，与本文讨论的标的稍微有点偏差。-_-'
iOS及其它移动平台内有这样的结构，只是将其做了区分！iOS设计指导内将类似本文内描述的dialog称之为「Alert」，上下结构的dialog称之为「Action Sheet」，如图10及图11。两者之前的应用场景和交互方式均有所不同，在遭遇实际问题时，需要设计者考虑使用哪种方式。ps.之前我对iOS官方进行「Alert」及「Action Sheet」的区分也有点想不太透，在写完本文并
@ArtS同学提出该问题后，终于有所明晰... ^_^
- Action sheet为当前任务提供一系列的操作，即多操作选项。
- Action sheet在执行涉及潜在风险操作时，让用户进行确认，并将潜在风险操作按键设置为红色，图11。
- Action sheet在iPhone设备（小屏设备），从屏幕底部弹出，并提供「Cancel」操作。ps. iPad无视这条。
图10
图11
休假后的第一篇，略长...略长....... 囧
类似的话题
-
在 App 设计中，“确定”按钮的摆放位置（左边还是右边）是一个看似简单但非常重要的问题，它直接影响到用户体验和操作的直观性。虽然没有绝对的规定说“左”或“右”是唯一的正确答案，但根据用户习惯、上下文以及设计原则，通常情况下，“确定”按钮应该放在右边，而“取消”或“否”按钮应该放在左边。下面我将详细............. -
.......
-
在App Store上卖App，想实现月入四千元，这绝对是许多独立开发者或小型团队的目标，也是一个比较实在的数字。究竟有多少人能达到这个水平？这个数字很难精确统计，因为苹果不会公开这类具体数据。但我们可以从几个方面来推测和分析，并聊聊那些能达到这个目标的人，他们是怎么做到的。首先，我们需要理解“月入.............
-
微软 Office 套件在 App Store 上的评分普遍偏低，这背后其实涉及不少用户在使用体验上的痛点。 很多用户反馈，即使是 Mac 版本的 Office，与 Mac 本土应用相比，总感觉有些“水土不服”。 这不仅仅是界面设计的问题，更多是操作逻辑和性能表现上的一些差异，让习惯了 macO.............
-
咱们聊聊这事儿，就是说，有些人宁愿去捣鼓那些不是从正规渠道来的软件，也不愿意在苹果的App Store里掏钱买。这事儿怎么看，得从好几个角度来瞅瞅。首先，咱们得承认，这背后有现实的考量。 经济压力是个硬道理。 别说大家都是富得流油，很多年轻人或者学生，手头可能确实不宽裕。想买的正版软件动辄几十块.............
-
.......
-
在开发一款App时，使用开源类库如同搭建高楼使用了预制的砖块和钢筋，极大地提高了效率和功能性。那么，当这些“预制件”被嵌入到你的App中后，是否需要在App里明确地展示出来呢？答案是肯定的，而且这不仅仅是一个简单的“写不写”的问题，更关乎着合规性、透明度和开发者社区的健康发展。首先，最直接的原因是许.............
-
子弹短信在10月9日从App Store下架，这件事可不是小事，背后牵扯出的问题，可以从好几个角度来剖析，而且每一个角度都挺值得说道说道的。首先，最直接的一个问题，就是合规性问题。我们都知道，应用商店对上架的应用有着严格的审核标准，尤其是在涉及用户数据、隐私保护、内容审核等方面。子弹短信作为一个即时.............
-
在国内的互联网生态里，积分商城几乎无处不在，从电商平台到生活服务类App，再到运营商和银行，几乎所有能产生用户粘性、鼓励用户活跃的平台，都少不了积分商城这个概念。然而，放眼海外，特别是在一些发达国家，同类型的App或平台，用户积分的存在感却要弱很多，积分商城更是鲜有提及。这其中的差异，并非偶然，而是.............
-
当你在苹果 App Store 看中了一款心仪的应用，并决定付费下载时，你指尖的每一次点击，都触动着背后一套复杂但流畅的支付流程。其中，银联支付作为一种深受用户信赖的支付方式，它的介入更是为整个过程增添了安全和便捷。一切的起点，是你做出购买决定的那一刻。你在应用详情页点击“购买”按钮，iOS 设备上.............
-
在设计一款企业应用时，我们需要深入理解它存在的根本目的——赋能员工、提升效率、优化业务流程。这绝非一次简单的“美化”工作，而是一个系统工程，需要我们从用户的视角出发，层层剥茧，直至打磨出真正实用的产品。首先，理解并尊重用户是设计的基石。 企业应用的使用者是企业内部的员工，他们肩负着各自的职责，可能是.............
-
.......
-
.......
-
交友App相亲“坑”事：花3000元被拉黑，平台到底有没有责任？网络相亲靠不靠谱？最近在网上看到一个挺让人咋舌的事儿：有网友在某个交友App上，仅仅和一个“对象”聊了不到一个小时，就心甘情愿地掏出了3000块钱，结果对方立马消失，还顺手给拉黑了。这事儿要是搁在以前，估计得被当成笑话听，但现在嘛，在虚.............
-
豆瓣App近期在各大应用商店遭遇了大规模的“一星差评潮”，这无疑是近期科技和文化圈里一个绕不开的话题。作为一个长期使用豆瓣的用户，我对此既感到惊讶，又觉得有些复杂，甚至可以说是有些荒谬。表面现象与直接原因：首先，从技术层面和表面上看，用户给出差评的原因通常是因为对App本身的功能、用户体验、bug或.............
-
在中国对印度的一系列应用程序实施禁令的消息传出后，中国的科技行业正面临着严峻的挑战，尤其是在全球扩张方面。这次禁令涵盖了 59 款应用程序，其中许多应用程序由中国科技巨头开发，包括腾讯、字节跳动和阿里巴巴等，这些公司在中国市场已经取得了巨大的成功。此次禁令对中国互联网公司最直接的影响是其在印度这个庞.............
-
这问题问得很有意思，不少人都会好奇，当一个应用被系统“禁止”了访问摄像头和通讯录，它究竟会看到什么？首先说摄像头。如果一个手机系统，比如锤子手机，严格执行了禁止某个应用访问摄像头权限的指令，那么这个应用在尝试调用摄像头功能时，看到的画面绝对不会是你正在进行的任何操作，更不会是你熟悉的摄像头界面。系统.............
-
朋友圈里突然被Zao刷屏，那会儿感觉像是一夜之间，大家都在玩“换脸”这个新玩意儿。我记得当时朋友圈里各种明星脸、古装扮相的视频层出不穷，好多平时不怎么发朋友圈的朋友都加入了这场狂欢。要说Zao为什么能这么火？我觉得有几个点挺重要的。首先，技术上的新奇感。它那个换脸效果，说实话，刚出来的时候，真的挺让.............
-
视频类APP上架应用市场：你想知道的都在这儿想让你的视频APP在各大应用市场（比如华为应用市场、小米应用商店、OPPO软件商店、vivo应用商店、应用宝，当然还有Google Play）崭露头角？那可不是件简单的事，它背后涉及到不少“硬指标”和“软实力”。今天，咱们就来聊聊视频类APP上架那些事儿，.............
-
这个问题很有意思，也确实是很多在网络棋牌app上玩游戏的人会困惑的地方。简单来说，你在网络棋牌app上玩，实际上是在和“app平台”进行交易，而这个平台又将你与形形色色的其他玩家匹配起来。但从根本的“输赢”和“钱”的流转来看，你更多时候是在和平台进行博弈。让我详细给你掰扯掰扯。第一层：你和平台的关系.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有