说到前端技术,每个框架、js 库基本都会提供一些 demo 入门代码,万年不变的例子就是实现一个 todolist。(别笑^-^)其中做 todolist 的网站、app 数不尽,比较有名的就是 todoist,还有微软的 todo,燃鹅~ 实现一个 todolist 真的如此简单吗?
首先需要回答,我们为什么需要 todolist ?
米勒法则: 根据米勒(Miller,1956)的分析,人脑处理信息有一个魔法数字 7(正负 2)的限制,也就是说,人的大脑最多同时处理 5 到 9 个信息(chunks)。原因是短期记忆储存空间的限制,超过 9 个信息团,将会使得大脑出现错误的概率大大提高。
每个人大脑短时间记录的事情、步骤有限。据分析顶级的围棋高手能够预判未来的 12 步棋,而这几乎就是人脑的极限了,但日常生活的任务通常超过这个数字,所以我们需要一个 todo 软件来辅助我们记录,避免忘记、错过重要的任务,误了大事。
其中常见需求大部分的 todo app 都有实现(也是万年 demo ),高级需求增大应用复杂度,较少 app 实现。附件上传、多维管理通常以付费形式提供。
附件上传与平台解耦需求矛盾
平台通常使用自有格式保存用户上传的资料数据,用户难以迁移,文件数据难以管理
多维管理与知识归档难以兼得
任务分组使得工作有条理,但实际工作需求多变,有时项目进行到一半因为各种原因停掉,转移战场。项目较多时关闭的分组与正在进行的分组混合,管理混乱,若删除,项目重启又很麻烦。
多维管理:维度不够,或者平台特定
前面说到任务数量问题,通常项目细化后任务数量多的惊人(按部门、按人员、按项目分组)。大部分 app 只支持二维分组(付费支持),难以满足需求。分组后的数据更难进行平台迁移。
文字排版与平台解耦需求矛盾
在任务较为复杂时,详细描述提供数据、资料支撑可以方便理清来龙去脉。但现有软件的排版停留在加空格还有换行符上,文字较多时显示混乱。如果支持特定排版功能,保存平台特定数据格式又与平台解耦需求矛盾
用户隐私保护需求难以实现 任务的结构化数据存储在后台数据库中,字段难以全部加密,技术实现困难。若不加密,数据库被脱裤,或者被用于数据挖掘,用户特征分析都是不可接受的。
任务优先级难以定义
如果采用优先级 0、1、2...这样的排序方式,只描述了级别差异,而且不同用户不同习惯,有的习惯优先级 0 是最高优先级,有的习惯数值越大优先级越高。
基于上述原因及团队项目管理需要,开发了一个 Markdown 网盘,TaskHub 官网,微信小程序版本同名。
首先联想到平时的文件管理,文件式管理解决了大部分的管理问题,无限维度、用户自定义、容易迁移归档、易使用。如果任务也能像文件一样管理就好了。于是想到了 Markdown 文件,首先 markdown 无侵入性、排版简洁、容易迁移、平台无关。如果每个任务都是一个 Markdown 文件,通过后台实现一个 markdown 网盘,这样就可实现文件式管理,而且 Markdown 任务文件可以方便总结日常工作经验,形成经验,在团队内部共享,方便通过网络进行传播(网页渲染简单)。于是大体方案就出来了——基于 Markdown 进行管理。
还有一些问题,如何将上述需求的数据结构映射到一个 markdown 文件中呢?
简短描述 ==> 映射为 markdown 的文件名或者标题
由于文件名有特殊符号限制,很多常见符号不能作为文件名,所以采用标题映射方式。
状态 & 优先级 & 时间等信息==> 映射为 badge
首先这些信息要可视化,不是数据库中格式,其次要相对显眼。于是想到了平时代码 README 文件的 badge,状态信息可以映射到 badge 上,用户体验还不错。如下:
详细描述 ==> 映射为 Markdown 的正文部分 效果图:
有了 Markdown 方案,回到上面的痛点问题
附件上传:用户图片等文件上传后作为 link 插入到 markdown 中解决,而且支持本地图片裁剪,可以隐藏一些敏感信息
多维管理:文件式管理无限维度,容易归档,增加了 wiki 文件夹,用于知识归档,文件可直接下载导出
文字排版:使用 markdown 进行排版,平台无关,软件上实现一个简洁的 Markdown 编辑器,方便编辑
用户隐私保护
每个任务都是一个文件,网盘后端可以很方便进行加密、分割存储、备份(通用网盘加密方式)大大简化后端设计,安全性更高。
确定优先级
如何清晰描述一个优先级确实是个难题,不同行业不一致。后来我们联想到了 IETF 发布备忘录的标记方式,标准细项的描述使用了 requirement level 关键字:Must、Required、Recommended 等,这些关键字用来描述任务的优先级更为准确、清晰,最后被我们采纳。参考 rfc6919
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.
| 软件 | TaskHub | todoist | microsoft todo | | ----------- | ------- | -------- | --------------- | | 简短描述 | √ | √ | √ | | 状态 | √ | √ 状态少 | √ 状态少 | | 优先级 | √ | | | | 时间 | √ | √ 付费 | √ | | 过滤 & 排序 | √ | √ 付费 | √ | | 详细描述 | √ | | √ add note 方式 | | 图片 | √ | | | | 多维管理 | √ | √ | √ | | 附件上传 | 开发中 | | √ | | 文字排版 | √ | | | | 多端支持 | √ | √ | √ | | 用户隐私 | √ | 未知 | 未知 | | 平台解耦 | √ | | | | 知识沉淀 | √ | | | | 统一平台 | √ | | | | 可拓展 | √ | | |
最后贴上小程序和官网~
欢迎小伙伴使用哦~
(Bug & 特性 同样欢迎~)
1
HTSdTt3WygdgQQGe 2019-12-20 11:15:31 +08:00 via Android
说明有点复杂,没看完
|
2
chennqqi 2019-12-20 11:17:31 +08:00
微软的 TODO 挺好用的,免费。
|
3
tangbao 2019-12-20 11:55:00 +08:00
测试了一下,就是支持 Markdown 语法的任务详情?
|
4
zhdsuperm OP @q409640976 哈哈 不好意思啊~ 这个说明还没有更新 不过整个网站是小白式的 随便点点就知道了 和以往的 todo 差别还是特别大,解决痛点比较多,每个任务都是一个 markdown 文件,即使你不会 markdown,网站的 UI 也足够了
|
5
zhdsuperm OP @chennqqi 微软的不能添加复杂的描述,像我们平时讨论的项目任务,通常要记录一些背景信息,或者贴上邮件比较麻烦,微软的 todo 不能添加图片还有详细排版,挺麻烦的。有对比表格: https://juejin.im/post/5df4a870f265da33e57ac2b9 (文末有对比表格,v2ex 不支持 markdown 表格比较麻烦~)
|
6
zhdsuperm OP @tangbao 是的,任务详情还要描述,状态等信息统一在一个 markdown 文件中,网站本身是个 markdown 网盘,做了这样的拓展,有利于文件式管理。平时项目任务,bug 跟踪太多了,普通的 todo 管理不来,或者数据格式平台相关,太痛苦。这是我们团队也在用的,很多项目都用上了,还在持续优化中
|