小小·装修宝是一款辅助管理装修事务的 App，最近刚刚上线。iTunes 上的链接，小小·装修宝
大概的长相是这样的。
这款 App 大概写了近2年，从我还没有开始装修到住进去3个月，才提交了第一版。中间因为太忙了，曾经短暂的修整。一路下来，虽然最后的成品我不是很满意，但是因为一个 App 涉及到的所有问题都是一个人完成的，所以中间还是有很多决策、工具、一些思考和权衡等可以和大家分享。
为什么要做这个 App
从装修开始，我就在 App Store 找各种装修的 App。 通过搜索 装修 关键字，我搜到的是这些。
图中所有的 App 我都看过，总结下来有3类；一类，装修公司的入口，要么展示软装图片售卖装修材料，要么展示报价提供装修公司的订单入口；二类，单纯的装修业务知识的普及，没有任何定制化的内容，相当于就是个装修知识的字典，需要的时候你自己去查；三类，单独的工具，如记账。缺乏一个将装修所有事务有机管理的软件，一个工具。
初期我们买空调，逛商场时，拿着小本本，记型号记价格记联系方式。逛完一整天，回到家里，再拿出来小本子，或者从手机里拍的照片，两个人综合信息，然后做决策；到开始装修时，我用刚刚做的开发版的 小小·装修宝里记录购买的建材的送货情况。然后建各种待办任务，记录下什么时候需做什么事情；还有记录最近正在联系的设计师、最近购买的门或者瓷砖送货人的联系电话。
当时就这3个大需求，基本能得到满足。后面我在 v2ex 上看到有坛友说自己的装修居然是用 Excel 这样的工作。心里是有点心动，觉得还是有很多人需要这样的工具，其实应该是个共性的需求。
所以在那以后，周末、或者工作日的晚上就是在写代码。
小小·装修宝 起名来源
小小 来自 Dota 2 的英雄。他的经典台词是“小小来了，目标采石场”。 采石场是采集石材的地方，和装修有点关联度。所以就决定用这个名字。 这个决定除了形成了 App 名字外，对 logo 设计、品牌色都有影响，尤其是对于 logo 的演进，后面我会详细讲一下。
技术架构的确定
当时， Swift 也到 3.1 版本，所以面对着用 Swift 、 Objective-C、 React Native 的选择。 React Native 其实不适合做很多交互复杂的应用；Swift 当时的编译的性能不太好。所以就是 Objective-C。 数据库 SQLite 写 SQL 语句太原始了，除了 SQLite 外当比较有名的就是 Realm。新闻里报道过 Realm 有个偷偷上传数据的丑闻，不过看了他们的 API 比较符合我的习惯，所以决定用 Realm。服务器后端，使用了 nodejs + express。服务器是基本版的 腾讯云 （其实之前 有比较过 阿里云，关于这两者的选择，我有另外的文章写过）
架构里有个比较关键的决定——是否要支持多端同步。最后的决定是不做，原因；
- 个人精力有限，写服务端的同步时间不够。当然 Realm 自己是支持 远端的 sync，如果用了 Realm platform 来支持 sync，确定了对 Realm 的强依赖——对我而言这不是我的风格。
- App 自己会有很多的图片，如果要服务器存图片，对我这种个人的 App，流量费用可不是小数目。经过测试，一个 iPhone X 对一些色彩丰富的场景，图片本身到 8M+， 数据一多，经济上也不合适。
业务设计
说设计有点大，我要表达的是，作为一个业务管理软件，如何设计一个事务管理的交互、业务流程，整个 App 应该包含哪些元素，才更合理、快捷，也符合更多人习惯？
所以我在做之前，我参考了很流行很受好评的几款软件，包括 Things 3，todoist，wunderlist，trello 等等。
试用后的效果，作为一个资料收集工具，提醒工具是很合适，但是对于装修这种需要联动很多要素的而言太简单；而且因为他们是做的通用性的软件，没有对装修这个事务做任何优化——寻百 App 而不得，这也给了我很强的冲动要自己做一个。
谈回正题，除了这些比较知名的通用的 App 外，我自己还关注了 appsolution、最美应用、Appso， 这类的软件。接收每日推荐和事务管理相关的推送，我会自己下载了然后看看是不是有可以利用的设计要点。坦白的说在找了这么多软件，有些粗制滥造的软件真是难看、难用的要死，也会被推荐；大部分软件都是大同小异，能够于我借鉴设计，有亮点的 App 并不多，所以现在小小·装修宝的阶段日历设计的那么糟我自己都分不清是确实这部分比较难还是自己的设计能力太差。
从产品到交互到代码的过程
从我构思 App 开始，没有采用所谓的敏捷编程，而是通过交互稿来验证自己的想法。这里涉及到我用什么交互工具的决策过程；
包括Origami、 frames 等在内，通过在知乎、在 quora 上搜索综合所得信息，得知Origami 是对懂 JavaScript 的人很友好，通过写 Origami 得到的效果甚至可以作为实际的代码，在 codebase 里使用。
然而下载完毕之后，仔细看了下文档和 API ，对照 demo 实现的效果。 发现其实不合适我，学的慢，写出来效果不太好，不是可见即可得。最后我找到了有个叫墨刀，（下面这个截图还不是最新的）
截图里已经是3.0 版本，界面和元素比较丰富，但是我刚刚开始用的时候，元素还比较少，制作页面的流程也很简单，没有现在的工作流之类的设计。用墨刀做的交互稿如下图，这里可以看到我早期对 App 的界面设计、功能构想。
。用了一段时间，发现他上手容易，使用习惯也很和我胃口。下载了 Mac App Store 的墨刀，发现他是用浏览器内核做的，所以是跨平台的，能实现这么好的拖拽操作还是很佩服他们的技术能力。
到交互稿做的差不多的时候，这时候开始写代码。 在 GitHub 上购买了会员，每个月费用7美元，就开始写代码，基本上都是晚上9点下班后，吃完饭，洗脚完毕，坐在床边的小桌子上，一般是写到晚上 1 点左右，然后 commit；后期搬家后终于有沙发可以躺着写了，如果不想躺着就在餐桌上写，夏天下代码，挺凉快，不知不觉就到1点多。一遍写功能，一边用，很多需求都是直接在代码里改了，后期很多调整没有反馈到交互稿上。
一个题外话
墨刀本身还有很多问题，包括商业上的运作。记得在写这个分享初稿，也就是半个月前，我登录了墨刀去截图作为文章的配图，发现我原来不知道怎么的，显示我的付费的支持协作的会员资格到期了，而且是对旧的项目不能编辑，只能运行——这个限制有些太极端了。我猜想这是来自商业化压力，而现在我再次登录发现又可以了，已经被自动续费——应该是来自用户的压力。
另外一个题外话
对于少数派文章编辑器里，插入图片的交互方式—— 即由输入光标来触发的方式，我很兴奋，终于有一个比较大的网站有这种高效的编辑方式。因为我曾经在我的工作当中提出过这种方式，希望在 web 页面里使用，来加速用户的选择速度。当然我的场景是不一样的：
当用户触发了一个强制中断用户流的操作，如删除一个文件夹，而这个文件夹里还有很多邮件，这时候需要用户来确认。但绝大部分的设计的场景这样的，在整个页面的左下角触发了删除操作，但是需要用户确认的弹窗，却是在页面的正中间显示，此时需要移动鼠标到中间点击确认，接着去删除下一个文件夹……
所以当时的设想是这个弹窗在触发删除地点附近显示；同样的拥有遮罩、类似红色这样的警示的标题。这种弹窗不同于一些 web 页面上搞的奇奇怪怪的右键菜单系统，也拥有比鼠标的 hover 菜单更重提醒含义的效果。当时流行去申请软件专利，但想想这种交互的一点点改进去申请专利也未必丢人了点，而如今听闻 UC 拿长页面滚动时延迟显示即将被滚动到图片的专利，告了今日头条，索赔1200万的新闻，感慨：有些专利流氓的底线还是低的可怕。
言归正常，少数派文章编辑器里的插入图片的方式，我自己也一直想引用到实际里，下面会讲到我的“最初的梦想”也是来自相同的考虑。我本人想法的受激源可能来自现代电脑系统里快捷方式、桌面的设计，还有一部分来自我的一个亲身经历。
>
有一次我在一个 hr 那里看到她使用的一款 windows xx管理软件，她在每输入一项目的信息后，会优先在整个 form 的 panel 里的任一个空白地方右键，在弹出的右键菜单里点击保存，而不会去使用整个表单下面的保存或者 panel 标题上方的保存按钮。当时我被右键菜单这种巨丑的方式而震惊，我没有考虑到右键菜单的操作方便性，对于他们这些一天要操作成千上百的输入流程而已，这一点点的简化，会带来巨大的便利。而这个反向的经历，让我对快捷方式保持了很强的敏感度。
关于logo
本身我不是视觉出身，自己又不会作图，所以前期包括 App 的视觉风格，线框图的确定，都是我从 sketchappsource.com 这个网站上找到，大概下载了10个左右，做了对比，然后自己做了些调整，确定了最后的线框图。也就是现在你在 App Store 里的 APP 的风格，偏使用 iOS 原生视觉风格构建的。
除了线框图风格外，还有 icon 的素材，前期都是我自己在各个线框图里 到处扣扣。这样的问题很明显，视觉效果不一致，而且很多是图不达意的。直到一天，我发现了 Noun Project - Icons for Everything 这个网站，上面除了收费的可定制颜色配置外，还有 CC 授权的黑白色系的图标。正好我可以拿过来使用。所以解决了 图片素材的问题。
至于整个 App 的 logo，我从开始做到临近提交了，一直在想如何找一个，或者自己画一个，前后经历了3个图片。
第一版本，
这是从 Google 上搜索的图片，关键字， Dota 2，tiny，小小，挑选的时候，剔除了过于暴力，或者图像元素太多的图片，一部分是游戏内的截图，而另外一些剔除的是插画作家的作品，充满了丰富的想象，造型过于妖艳，过于复杂。
第二版本，
主体还是小小，不过是在#hero, #Dota 2, #Dota, #Valve, #Valve Corporation, #Defense of the Ancients, #Tiny | Wallpaper No. 312286 - wallhaven.cc 找到的这个图片，色彩单一，造型简单，暂时可以用来 App 的 ICon，不过缺乏美感，总觉得不是很喜欢。
第三版本，来自临近提交 App Store 时，我终于放弃了小小这个关键字，按照 log 为关键字，搜索到这个；
这个版本，彻底放弃了小小这个主题形象。其实这个决定不是个容易的事情，因为，这个 App 的缘起、具象化就是 tiny 这个形象，如果弃用了小小这个形象就想到与忘本了。不过替换为新的 logo，这个看起来更贴近装修这个主题——形象简单，色彩布局温暖，而且有点小 cute。
还算喜欢，可惜因为是下载别人的 png 文件，导致最后截图出来的像素不是很高，这就是它目前最大的问题。
说完 logo的演化，功能规划的演变也反映我作为一个程序员，多产品感的变化
最开始的产品形态，就如同我在 墨刀里的原型一样。充满了一个程序员思维的设计，主要包含检查项目、待办任务、前置任务等要素。
到装修的后半程，因为太忙了，编码工作搁置了；随着装修的经验积累，我自己对装修设计要有了变化。从一个程序员实现的角度转换为从一个最终用户的方式来思考，整个 App 的信息流和工作流也发生了很多的变化。最典型的差别就是，消除了前置任务和检查任务和待办任务的合并——从用户角度而言这些其实都是一种待办任务。
最后经过几次迭代。形成如今以待办任务为核心的工作流项目。
视觉风格
因为自己不会作图，所以当初确定的色彩配色就是简色，线框，少量圆角。蓝色 为品牌色，因为蓝色是大部分工具类的配色，给人一种稳重安全的情感体验。根据对视觉风格理解，颜色不能太多，主要有以下颜色；
蓝色也是是表示动作的提示色，也是品牌色。
0x4A4A4A 为界面所有字体的颜色，辅助文字如备注信息用字体0xB8C3C8；
错误提示信息的文字用0xD50000；
分割线颜色是0xcccccc。另外一些特殊的颜色，具体情况具体分析。
以上这些简单的规则形成了基本的视觉感知。
功能的演进
最开始的主要模块是商品购买的首选项目比较、前置任务、检查任务等，特别提到是这个快捷方式的设计，一直很满意，叫做“最初的梦想”。
主界面的侧边栏，我把他当做快捷工具栏，初期的定位是在 live tab 常驻，作为信息的汇集地。
到后面实现时，发现页需要增加 预算管理的功能，还有 tag 的创建和删除管理，再延伸下，还需要有对 tag 的统计功能；另外还需要日志，作为对待办项目的包装，这也是很重要的一点。我对于待办事务的分解——5H1W，本质上也是一种流程，是另外一种形式的日志。
因为编码的时间实在不够，你现在 Applestore 上看到的 App 其实是我原先设想中的精简版。按照我的本性，总会想着将所有的功能都完成，有设计多少的功能都想着最后呈现给最终用户多少功能——删功能是个很难的决定。所以在真正在实现时，不得不忍痛割爱。按照 互联网业界的说法，想把它上线，再解决问题。
功能层面的自举
因为时间和精力的原因，直到房子装修完毕，App 一直还没做完，离我交互稿上设计的还差好多，大概只有完成 10% 的样子。
等我今年夏天从新开始写代码后，我已经不能拿来管理装修的事情了，前期测试的时候，我只是来给自己 mock，或者事后补充当时的流程和事情；快到提交 App 的时候，我用来管理上线前的 bugfix 任务。
换言之，即使你不是一个装修用户，通过自己设置 tag ，也可以用 小小·装修宝来管理自己的事情——它变成了一个事务管理工具。
如果说一种语言的编译器是语言本身编写的叫自举的话，那我用即将上线的 App 来管理上线事务，也是一种自举，很有意义。
特点
要写少数派的自荐文章，至少要写下自己觉得做的不错的地方。我想作为一个程序员，从我自身角度看，我觉得在小小·装修宝里，下面的这些是我的得意之处；
- tag 系统。
Tag 系统存在非常非常多的系统里，很强大，我也很喜欢用这个系统；第一是它比较自由；第二有很强的扩展性；所以在小小·装修宝里，我把 tag 系统用在很多的地方，举个例子；记账时候的消费类型，创建阶段的阶段类型，还有图片的分支，这些的背后全是 tag 系统。tag 系统的 tag 分为两类，一类是系统内置为了让有基本的空数据时，让 App 运行，第二种是用户的自定义 tag。你能创建的 tag ，决定了你能将这个 App 利用到什么程度； - 5W1H 的事务模型。“模型”这个说法有点大，其实就是我做事的关注点和思维方式。我本身的记性不好，所以就靠总结一些公式，来辅助自己记东西。而 5W1H 是我认为，要做好装修、甚至是其他所有的事情都需要注意的几个要素点。做好这几点，你做事情就不会差到哪儿去。所以我就将这个理念，实现为待办任务和阶段日历的方式。希望用户能够按照我的思路，来使用这款软件，提升你们的做事效率。当然我知道肯定有很多人说，你的这东西是什么玩意，我完全不会用，我希望这些用户，可以先放下自己的成见，暂时接受我的思路；如果真的无法认同这个方式也无妨，那也是很正常的，毕竟每个人都有自己的路径依赖，做事风格。
- “最初的梦想” 即前文提及的主界面的侧边栏。这个设计的思路来自 电脑上的桌面功能；说的更确切的一点就是 快速启动 + 全局搜索。善用 快速启动 + 全局搜索 可以极大的提示生产效率。用过 Alfred， spotlight ，或者 windows 上 everything 之类的软件的人士，应该深有感触。但是限于实现的难度，目前没有在主界面实现，只有在添加名片时，你可能会使用到这种交互方式——这是我的创新，当然你也可以说是瞎搞。
- 等等，限于篇幅就不写了。
关于爱好和执念
执念在这里特指，小小·装修宝这个名字里的小小。我本身是个资深的 dota2 菜鸟，喜欢但是不擅长。所以在为 App 起码或者为 App 视觉风格定基调，设计虚拟形象时，我第一想到的就是要将小小作为我的住 icon 来做。前文提到的 icon 设计，即得益于我的这个爱好，也被囿于这个执念。 所以在早期，我想到要设计 icon 时，自己不会设计，只能去各个免费的地方去搜索资源，
关于视觉素材的制作
前期要的 icon，可以在 theneuoproject 上搜索得到，等我需要提交到 Apple Store 的时候，遇到了一个比较大的问题，就是制作 screenshot，显示位置就是 Apple Store 里搜索到 App 之后，在下面展示的最多的6的照片。 iTunes connect 里是不接收屏幕截图的，而且需要对多种设备截图。
其实我是知道 fastlane 的 frameit 是做截图的工作流的，但是使用下来，效果太差。一番 Google ，找到了一些在线制作的网站，通过你是上传图片，然后生成图片，可以批量下载最后的成品图片文件夹。然而我使用了3个，发现他们都或多或少有问题；不是模板不够好看，就是速度太慢，或是可定制程度不够高，不满意。不过最后和 logo 的制作方式一样，我找到了 SketchToAppstore.sketch 的一个文件，他通过 symbol 技术，可以实现替换图片和文案，最后批量导出所有设备、所有图片的资源的功能。因为是 sketch，可定制程度很高，就是改文案的时候比较麻烦，总体感觉还是很不错的。
对可能吐槽的回应
我知道我做的时候，很多交流记事的方式其实都是我自己的方式，很多人会吐槽这是啥？为啥是这样的，用不明白。我这里稍微解释一下，做事的方式和人的思维方式有关系，你们吐槽小小·装修宝看不懂，其实我自己对别人的软件也是有相同的问题。举个例子，就像上面的墨刀，在我早期使用的时候，很多概念，我是能理解的，而且作为一个程序员，做过 Dreamweaver 相关工作的人，还是很容易上手的，然后到后面，很多小版本的更新中，加了很多工作流之类的概念，我其实很多真的不是很明白他的使用场景，所以很多时候我都是不用他的。然而根据张合一在teahour里说法，他们自己在迭代过程中加功能其实是个很坚定的决定，所以加‘工作流’一定是个很有必要有用的概念，然而对我产生了很多的困扰——虽然不懂但是保持好奇心，所以希望你们也很保持。
在我收到周围朋友的的少量的反馈中，说交互的思路不符合用户思路的；说视觉太丑的；说程序实现有 突然僵住的 bug的问题的都有，所以这是我自己不满意的作品，如果你有有兴趣的，欢迎你能够提给我，帮助我改进。
谢谢。
