什么是好的APP icon

Posted 2023-05-11

参考技术A 一个好的APP图标有利于你的应用在眼花缭乱的众多APP中脱颖而出，吸引用户的眼球，引导用户去点击，那么什么才算是好的APP icon设计呢，icon设计要注意什么？谈一下我的看法

1、icon是干吗用的

任何事物的出现都是为了解决一定的问题，所以我们先叨叨几句，了解下icon是为了解决什么问题而出现的？

这是一个菜市场，王二麻子在这条街上卖了十几年烧饼了，一直也没有其他卖烧饼的，所以人们来了市场，买烧饼必定买他家的，品质又好，大家口口相传。因为市场卖东西的比较多，王二麻子就找了块布，上面画了个圈，挂在门口方便别人找 后来来了个新的卖烧饼的胖嫂，菜市场人渐渐多起来了，为了方便大家找到他家，就做了个招牌，上书《王二麻子烧饼》，这样人们要介绍他的门面，只需说去菜市场找王二麻子烧饼就行，后来王二考虑到人们看字也比较麻烦，就找人画了个大饼的样子，点了几个点，当做是芝麻的样子。又把底色招人弄成烧饼的金黄色，自此王二麻子烧饼的品牌形象定型了，人们口口相传，去买烧饼就找那个圆圈里面有点的那个。

2、ICON的历史

从上面的小故事我们可以了解，王二麻子的招牌也就是王二麻子的icon 的发展经历了四个阶段

1、无标识或弱标示，人即品牌，多在竞争不充分的情况下

2、模糊标识，竞争相对少，只需要区分出自己与他人来即可

3、明确标识，竞争升级，既要区分出与别人的不同，又要体现自己的特色

4、抽象标识，目的是便于区分，易于理解，便于传播。 从1990起，国内兴起了设计企业VI的风潮，大家可以了解下当时的文案，对于icon设计会有帮助。

icon最重要的目的就是标识产品，易于传播

二、ICON该改怎么设计

如无特殊说明，下文中的icon指的是手机APP的icon icon是由色彩，文字和图案构成的。

1、icon怎么选择色彩

色彩：色彩之于icon最重要的作用是吸引人的目光，渲染出设定的氛围，作为产品形象输出的背景。 当人在手机APP上浏览时，翻屏动作是很快的，注意力也是发散的，这个时候，用户能关注到的只有色彩，一个大的色块在眼前划过，跟用户的眼睛造成视觉冲击，一个好的色彩搭配会吸引用户视觉停留，获取宝贵的点开的机会。那么什么样地色彩会让人停留呢。我们应该怎么选择APP对应的色彩呢？

分两种情况考虑：

1）你做的不是一个从零开始的新产品，你的公司之前已经有了在网站，在平媒的展示记录，已经有确定的品牌色，这种情况下就应当延续之前的配色，保证传播形象上的统一，让用户看到这个颜色就能联想到之前用过的产品，让用户产生联想，产生我点进去看看有啥新东西的想法，走到这一步，那么恭喜！！！吸引用户成就达成_。

2）你做的是一个新产品，那么选择色彩时可以从这几个方面考虑。 你的产品是属于什么行业的呢，行业有没有什么相对固定的颜色方案呢？如果有，那么请尽量往上靠，选择相似的颜色有利于用户对产品产生印象。如果没有那么就要从产品功能上考虑，你的产品能给用户提供什么帮助，是信息展示类的应用还是工具类应用，在这里可以参照通用的冷暖色调理论和平面设计的配色方案。 总体来说， 对色彩的要求是区别于其他产品，能烘托产品氛围，吸引人的眼睛，让用户关注到应用。

2、怎么设计icon的图案

图案是用来沟通的，是通过特定的形状，来让人们产生联想，比如红十字的图案就让用户想到医院，想到健康方面的，汽车的图案就让人想到车相关，飞机就让用户想到旅行相关的，利用这些固定行业的固定形状可以直接让用户了解产品的使用场景和功能，进而产生兴趣。

图案大体可以分三种，

一是对实际物体的抽象和引申

比如说摩拜单车的icon上的自行车图案，让人一看就知道这是和自行车相关的应用。苹果原生地图应用的图标也属于这种。

ios操作系统升级到7。0时,还嫌弃了一波平面化图标替代拟物化图标的风潮，其实，不管是拟物化图标还是平面化图标都是对实际物体的抽象和引申。另外平面化替代拟物化是必然的，原因很简单，最开始IPHONE推出的时候，算是新事物，必须使用比较真实的拟物化图标来告诉用户每个应用是干什么的，后来用户越来越多，再进行进一步抽象升级，图标就不需要那么形象的表示事物了只需要让用户看到图标能理解到这个图标代表的是什么就可以了。

二是对行业图标的变形 例如铁道部12306的icon图案就是常见的铁路部门的示意图标，同花顺的图标是一段简单的K线让用户一看就是和故事相关的应用。

三是对文字的变形 这里有两个很牛的应用要推荐下，一个是天猫的icon，图标的上半部分就是天猫俩字，仅在猫字上面做了些许变形，认识字就知道这是干嘛的，而且还特别醒目。相比下京东的icon就有点懵了，一看之下是个狗，如果是个新用户直接一看其实是懵的，表意不明。不过，以京东现在的知名度倒是不需要care这点小事情了。

另外一个是大网易新闻，看人家图标

大红的底色上有大大的两个字网易，下面是小产品标识news。

对文字的变形还有一种情况，那就是文字加一些小修饰，既能看到品牌名，又能大约看出产品是干嘛的来。如下例：

叮当俩字强调品牌名，上面加了个小人，就做成了一个人骑着自行车的形象，用户大约了解这可能是个配送相关的应用。

3、icon上该写什么字

icon上该不该写字，写字的话要写什么字，其实和上面说的图案使用文字的论述有点关系。

图案用来沟通，文字才能精准的信息，如果我们要在icon上加文字，首先要考虑的是我们要传达的信息是什么，这个信息能不能通过我们的图标进行传达。

确定了要不要加字，就要确定加在哪个位置，其实这个一般来说都会是加在整个图标的底部。

写什么字呢，毕竟地方不大，写不了几个字，不同业务选的词和字的组合不一样，没法提出具体的建议了。来直接比较俩图标.

浦发银行信用卡APP你直接放了四个大字你也太蒙事儿了吧，中间一个大花还遮了部分字,low，脑残，无语ing

天猫上面已经夸了一遍，天猫这个icon设计里还有一个小机关，天猫两个字下面和猫头上面还有个空白区，中间还可以塞11.11，如此设计确实牛逼。

最后总结一下，icon设计时需要根据产品阶段（新产品还是已有产品），所属行业（电商、信息、游戏）的不同来选择合适的色彩（夺人眼球）和合适的图案（品牌形象）和精准的文字（信息传递）。

我们在设计ICON是一定要考虑用户浏览使用APP时，目光关注点是从大到小，从上到下来移动的。仔细体会用户的习惯才能设计出优秀的ICON。

最佳实践 | 什么是好的日志记录实践？

作为软件开发人员，我们在使用某些库或框架时都遇到过那些烦人的、不太有用的错误消息：“无法解析配置文件”、“缺少此操作的权限”等。好的，好的，所以显然出了点问题；但究竟是什么？什么配置文件？哪些权限？你应该怎么做？缺少此类信息的错误消息很快就会产生挫败感和无助感。

那么什么是好的错误信息呢？对我来说，它归结为应通过错误消息传达的三条信息：

背景：是什么导致了错误？失败时代码试图做什么？

错误本身：到底是什么失败了？

缓解：为了克服错误需要做什么？

让我们深入探讨一下这些个别方面。在我们开始之前，让我澄清一下这是关于由库或框架代码创建的错误消息，例如以异常消息的形式，或以写入某个日志文件的消息的形式。这意味着这些错误消息的消费者通常是其他软件开发人员（在应用程序开发过程中遇到由 3rd 方依赖项引发的错误），或者是操作人员（在运行应用程序时遇到错误）。

这与面向用户的错误消息形成对比，应该应用其他指导和规则（特别是关于安全问题）。例如，您通常不应在面向用户的消息中公开任何实现细节，而对于此处讨论的错误消息类型来说，这并不是什么大问题——或者相反，它甚至可能是可取的。

语境

在某种程度上，一条错误消息讲述了一个故事。和每一个好故事一样，你需要建立一些关于它的一般背景的背景。对于错误消息，这应该告诉接收者有问题的代码在失败时试图做什么。鉴于此，上面的第一个示例“Couldn\'t parse config file”在某种程度上解决了这个方面（而且只有这个方面），但可能还不够。例如，知道文件的确切名称将非常有用：

无法解析配置文件：/etc/sample-config.properties"

使用Debezium的一个示例，我在日常工作中正在开发的开源变更数据捕获平台，第二条消息可以这样读，并带有一些关于发生了什么的上下文：

回到与处理某些输入或配置文件相关的错误消息，打印绝对路径可能是个好主意。如果文件系统资源以相对路径的形式提供，这有助于识别当前工作目录周围的错误假设，或者任何其他用作解析相对路径的根目录。另一方面，特别是在多租户或 SaaS 场景的情况下，您可能会将文件系统布局视为机密的实现细节，您可能更愿意不将其透露给您运行的未知代码。什么是最好的取决于你的具体情况。

如果某些框架支持不同类型的文件，则有问题的文件的特定类型也应该是消息的一部分：“Couldn\'t parse entity mapping file... ”。如果错误与文件内容的特定部分有关，则显示行号和/或行本身是个好主意。

就如何传达错误的上下文而言，它可以是消息本身的一部分，如上所示。许多日志框架还支持映射诊断上下文(MDC) 的概念，该映射用于将任意键/值对传播到日志消息中。因此，如果您的消息要显示在日志中，那么为 MDC 设置上下文信息会非常有用。例如，在 Debezium 中，这用于传播受影响连接器的名称，允许 Kafka Connect 用户区分源自部署到同一 Connect 集群的不同连接器的日志消息。

就通过日志消息传播上下文信息而言（与 CLI 工具打印的错误消息相反）， 结构化日志记录（通常以 JSON 的形式）简化了任何下游处理。通过将上下文信息放入结构化日志条目的单独属性中，消费者可以轻松过滤消息，根据其内容仅摄取特定的消息子集等。

在异常的情况下，导致根本原因的异常链也是一个重要的上下文信息。因此，我建议始终记录整个异常链，而不是捕获异常并仅记录一些替代消息。

错误本身

然后进入下一部分，描述实际错误本身。这就是您应该以简洁的方式描述确切发生的事情的地方。继续上面的例子，第一条消息，包括上下文和错误描述可以这样写：

无法解析配置文件：/etc/sample-config.properties；给定快照模式“nevr”无效

对于第二个：

未能创建数据的初始快照；数据库用户 \'snapper\' 缺少所需的权限

除此之外，这里没有太多可说的；努力提高效率：使消息尽可能长，尽可能短。一个想法可能是使用不同的消息变体来处理相同类型的错误，一个更短的错误，一个更长的错误。使用哪一个可以通过日志级别或某种“详细”标志来控制。Java 开发人员可能会发现 Cédric Champeau 的jdoctor库对实现这一点很有用。就个人而言，我还没有使用过这种方法，但对于特定情况可能值得付出努力。

减轻

在确定了失败的背景以及究竟出了什么问题之后，最后——通常也是最有趣的——部分是对用户如何克服错误的描述。他们需要采取什么行动来避免它？这可以像在配置文件示例中告诉用户约束和/或有效值一样简单（即类似于测试失败消息，显示预期值和实际值）：

无法解析配置文件：/etc/sample-config.properties；给定快照模式 \'nevr\' 无效（必须是 \'initial\'、\'always\'、\'never\' 之一）

如果出现权限问题，您可以澄清需要哪些权限：

无法拍摄数据库快照：数据库用户“snapper”缺少所需的权限“SELECT”、“REPLICATION”

或者，如果需要更长的缓解策略，您可以在参考文档中指向一个（稳定的！）URL，该 URL 提供了所需的信息：

如果需要进行一些配置更改（例如数据库或 IAM 权限），如果您以“可执行”形式共享该信息，您的用户会更加喜欢您，例如作为他们可以简单复制的 GRANT 语句或特定于供应商的 CLI 调用比如aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/SomePolicy --role-name SomeRole。

说到错误消息中引用的外部资源，最好将唯一的错误代码作为消息的一部分（例如 Oracle 的 ORA 代码，或WildFly 及其组件产生的错误消息）。然后使用您最喜欢的搜索引擎可以轻松找到相应的资源（由您自己提供或外部提供，例如在 StackOverflow 上的答案中）。将对您自己的规范资源的引用添加到错误消息本身的奖励积分：

（这是一个虚构的例子，我们目前没有在 Debezium 中使用这种方法；但我可能应该考虑购买 dbz.codes 域