为何一个 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 每每不够

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