为什么一个 Todolist 是不够的

界面是思维的一部分

我是那种思考很快, 但是记忆力很差的人, 有个笔记工具特别重要
极端地说, 我需要把笔记当作硬盘挂载到我的大脑
数据从界面解析传送到大脑, 从大脑持久化到计算机, 都应该尽量快
具备这样的方便, 我还可以借助图形界面更好地排序和评估任务
...或者你仅仅可以理解好记性不如烂笔头, 事情写下来就记牢了

这就像有时人们爱把思路画出来, 加上箭头, 让别人还有自己更清楚
或者到了下雨天, 你出门就会去看伞架, 因为雨伞存储在那儿
或者是当你需要什么东西, 就下意识去兜里去包包里翻看取出
或者是过马路时你下意识去看红绿灯, 再决定能不能走
思考不仅仅需要脑海里已有的数据, 界面也是思维的一部分

我需要 Todolist

我想要一个 Todolist, 而且我每天都会用到, 因而需要满足这样的要求:

• 能随时记东西, 不管什么情况, 回车, 输入, 搞定. 一定要能快
• 我可以拖拽修改顺序, 决定哪个任务是目前关注的
• 任务可以被完成
• 任务可以被延期, 不能同时看到太多任务, 会干扰情绪的
• 界面要干净. 我在思考的时候比一般人都容易分心, 尽量干净
• 背景颜色挺容易带给我压力, 要找轻松的壁纸

了解我的同学大概知道我在的公司就是做团队任务管理的
不过公司的产品功能大而全, 我过分的要求仅仅术语小众产品
而这渐渐也成了我学编程最大的动力, 没有看上的, 自己做
GitHub 上有个团队叫做 Memkits, 顾名思义, 思维的小工具
我经常用到的一些小工具的代码就托管在上边

React Todolist

首先我想要解决 Todolist 的问题, 我用过 Wunderlist, 养不成习惯
接触 Ractive 和 Vue 之后, 渐渐我能轻松实现 Todolist 了
我不仅要实现, 还需要能根据自己的需要定制, 加功能改样式
后来掌握了 React, 渐渐自己的想法比较容易实现, 有了第一个工具

我选择了在浏览器 localStorage 存储 Todolist 的数据
而且页面用本地的 Nginx 托管, 所以不会受到网速影响
我还花了不少时间选择图片, 以及稍微调了一下动画
我强制去掉了很多元素, 避免导致我分心, 同时, 谢天谢地, 代码量少了

试用 http://repo.tiye.me/react-todolist/
代码 https://github.com/Memkits/react-todolist

实际使用一段时间, 小修小改, 我注意到一些问题:

• localStorage 并不靠谱, 同时打开多份页面, 保存会相互覆盖
• 我有很多小任务, 相互之间还有关系的, 需要有分组
• 想到文章思路的时候会记一下, 这时一行可不够用

localStorage 问题, 属于技术问题, 正确的方案是写一套后端
一套后端, 意味着服务器和数据库, 这还算简单, CURD 嘛
然而 WebSocket 也要, 万一两个标签在编辑, 不同步怎么办?
实际上问题到现在也没有解决掉, 我还是存储在标签缓存里的

Pudica Schedule

分组的问题倒是可以解决, 而且场景也很明确很常见,
写程序时候, 先做什么后做什么顺序非常明确, 而且需要不断调整
于是我做了个简单的列表, 可以拖拽, 可以编辑, 可以上下添加
后来还调整完成的任务显示在列表中间, 方便对比
有次看上夏天的绿色的枫叶, 干脆壁纸也换成了翠绿

试用 http://repo.tiye.me/pudica-schedule/
代码 https://github.com/Memkits/pudica-schedule

写组件头绪繁多的时候, 我常把步骤先整理好, 照做, 勾掉
原本完成的任务归档右侧的, 现在的缩进是随着使用调整的
当然, 这个界面依然在使用当中遇到解决不好的场景:

• 事情多我有两组任务要进行怎么办, 我需要更多个组
• 我的任务和同事一起做, 需要共享进度, 可这个页面没有同步功能

我考虑了下, 似乎场景不那么多, 而且那种程度就算有工具大概也用不上
而关于同步, 我也有打算建立新的项目, 不过技术栈有点高
我大概要花好长时间才能把同步的逻辑写到好用而且没 bug 吧
最近...忙, 所以 monilaria-schedule 项目无限期搁置吧
居然要写后端吗, 写完后端还有考虑部署, 维护数据库? 天呐...

Manuscript

看下另一个问题, 写文章的思路, 怎么方便快速地记录下来?
单单考虑需求的话, 有个侧边栏, 有个输入框, 能创建删除和切换就好了
我做了一个版本, 用久了发现按钮挺碍眼, 干脆按钮也去掉吧
侧边栏在创建删除时一闪一闪挺干扰的, 加动画, 用来做过渡以及提示

试用 http://repo.tiye.me/manuscript/
代码 https://github.com/Memkits/manuscript

我经常有想了个开头的文章, 就在 Manuscript 当中记录一下
等到整体结构定下了, 就贴到豆瓣或者 SF 上边继续编辑
看效果勉强还行. 也会遇到一些问题影响使用的:

• Markdown, 喂, 不能查看页面上的效果啊, 只有一部分能脑补出来
• 思源黑体已经是很赞的字体, 但中英文搭配成了棘手的字体问题
• 我经常需要贴代码, textarea 可不能同时呈现不等宽和等宽两种样式
• 左边右边是两份文档, 查看和编辑手动滚动跟定位, 挺麻烦

动画和字体除了技术还有设计方面的难度, 我只能尽量调整了
一方面要更好的效果, 一方面要避免过渡而影响到使用时的注意力
引导和提示视觉的交互当然不是简单的事情, 字体也是, 暂且容忍吧
滚动的问题在实现上就难了, 程序要分析到字符做精确定位才行

Marked React Editor

富文本编辑器是个头疼的问题, Markdown 只是个程序员式的方案
对我而言写东西时考虑点击按钮会出现什么效果, 真是干扰
富文本编辑器是比较容易出问题的, 我还是先坚持用 Markdown
我需要能预览, 还能全屏预览文章, 那就用双击切换模式好了
因为 Air 屏幕小, 那一定要尽可能利用屏幕的空间才行
另外按自己的喜好增加一些样式, 字体, 顺手就可以了

试用 http://repo.tiye.me/marked-react-editor/
代码 https://github.com/jiyinyiyong/marked-react-editor

基本功能算是有了, 而且 Atom 编辑器也大概是这样的效果
SF 的 Markdown 编辑器就做得更全, 只是有时候细节太过
而我这个从细节上缺失功能太多了, 只不过我用不到而已. 不胜枚举

用代码构造你需要的

Bret Victor 曾经感慨设计师难以将灵光一现化为真实的物体:

A "user interface" is simply one type of dynamic picture. I spent a few years hanging around various UI design groups at Apple, and I met brilliant designers, and these brilliant designers could not make real things. They could only suggest. They would draw mockups in Photoshop, maybe animate them in Keynote, maybe add simple interactivity in Director or Quartz Composer. But the designers could not produce anything that they could ship as-is. Instead, they were dependent on engineers to translate their ideas into lines of text. Even at Apple, a designer aristocracy like no other, there was always a subtle undercurrent of helplessness, and the timidity and hesitation that come from not being self-reliant.

It's fashionable to rationalize this helplessness with talk of "complementary skillsets" and other such bullshit. But the truth is: An author can write a book. A musician can compose a song, an animator can compose a short, a painter can compose a painting. But most dynamic artists cannot realize their own creations, and this breaks my heart.

我当时听他视频很受触动, 因为我就是想做东西, 才开始自学编程
也因此我将强烈地追寻新技术, 而不愿消耗时间在编译器底层技术中
这可以说是我的指路明灯和前进动力, 也可以说是我技术生涯的限制
我希望技术能更快把想法变成现实, 这是真真切切的效率和生活的提升

然而某天突然意识到前端的工作, 越来越限制, 是去填补前面说到的缺失
做前端要关心框架, 关心后端数据, 关心可维护性, 关心项目进展
而且要尽可能满足设计的意图, 这样设计师才能精确地洞察设计的效果
作为团队磨合, 这无可厚非, 值得改进. 但想到个人发展, 经常感到烦闷
公司越大, 效率对分工的要求越高, 越需要职位智能精准

而这样的烦恼让我更加认为编程和设计是每个人应具备的技能
跨过一个人, 跨过一个职业, 一层层累积着的沟通成本, 难以被抵消
你看到问题, 你动手解决, 你绕过目前的障碍, 你不再被困扰
就像对于 Linux 用户来说, 不能定制桌面吗? 这操作系统怎么做的?

技术的瓶颈

最后作为程序员讨论下技术实现的问题, 这几乎就是每天的生活状态
实时同步的应用? 什么前端框架? 什么编程语言? 什么通信协议?
什么数据库抽象? 什么编程模式? 什么布局问题? 什么原因导致的 bug?
今天晚上我又看到一款产品, 叫做 Atomic, 可以拖拽生成手机交互

未来的人们真幸福啊, 拖拽几下就能把界面做出来了
等等, 我们要用 Emacs? Vim? Atom? nano? Sublime? Visual Studio?
好像现在出了 Bracket? LightTable? Nuclide? Polymer Design Tool?
前端框架用了吗? 是 MVC, MVP, MVVM, Flux, 或者只能说是 MV*
大能十多种主流前端框架, 大概十多种主流 Web 开发语言, 还可以更多

在外人看来, 做程序的人是不是都疯了, 凭空造出那么多术语来?
这些概念放在二十年前, 那时候 JavaScript 刚刚出现, 微软也还年轻
最近几十年技术疯狂地发展, 现在巨头们常常开发布会介绍新产品
这么多年, 可以想象会有很多聪明人, 大量资金投入在 IT 这个领域
技术发展到什么程度了? 为什么 Dribbble 上一个图实现起来很难吗?

我记得人们经常在意, 为什么世界上有那么多编程语言? 然后回答说:

People take ideas from different languages and combine them into a new languages. Some features are improved (inheritance mechanisms, type systems), some are added (garbage collection, exception handling), some are removed (goto statements, low-level pointer manipulations).

Programmers start using a language in a particular way that is not supported by any language constructs. Language designers identify such usage patterns and introduce new abstractions/language constructs to support such usage patterns.

人们多半没意识到问题的每个细节不断深入会有那么多细节
随着不断的改进, 功能不断组合, 新领域不断混入, 交织出更多的细节来
编程语言就这样疯长了, 其他的方面看来也是, 一切都难逃其命运
即便是说不清楚, 从编程领域繁多的工具分类也可见一斑了

总结

如果扎进技术当中, 会发现存在数不尽的问题, 心情恐怕更烦闷了
抛开技术来说, 当我尝试做出了一个自己想要的 Todolist 问题随之而来
我发现现实生活中种种的需求接踵而来, 我不断改进应用, 却难以追上
仅仅是针对个人习惯做改进或许好一点, 但一套 Todolist 往往不够

技术社区的历史常常更多的互联网用户身上发生的事情的缩影
比如 * 的问答和积分系统, 渐渐在更多社交网站上发生
比如代码版本控制, 渐渐演变到文章, 法律, 设计的版本控制
技术社区因为每个人有能力提出问题解决问题, 进入到无止境的分类
大概当每个人都有能力去改变他想要应用, 会发现永无止境
有那么多种任务需要有记录, 一个 Todolist 怎么可能够?