说到前端技术，每个框架、js库基本都会提供一些 demo 入门代码，万年不变的例子就是实现一个 todolist。（别笑^-）其中做 todolist 的网站、app 数不尽，比较有名的就是 todoist ，还有微软的 todo，燃鹅~ 实现一个 todolist 真的如此简单吗？

如何打造一款实用的 todo app？

TaskHub 官网截图

image

首先需要回答，我们为什么需要 todolist？

米勒法则： 根据米勒(Miller，1956)的分析，人脑处理信息有一个魔法数字7(正负2)的限制，也就是说，人的大脑最多同时处理5到9个信息(chunks)。原因是短期记忆储存空间的限制，超过9个信息团，将会使得大脑出现错误的概率大大提高。

每个人大脑短时间记录的事情、步骤有限。据分析顶级的围棋高手能够预判未来的12步棋，而这几乎就是人脑的极限了，但日常生活的任务通常超过这个数字，所以我们需要一个 todo 软件来辅助我们记录，避免忘记、错过重要的任务，误了大事。

常见需求

• 简短描述：如：总结会议纪要，输出邮件
• 状态：标记是否完成
• 优先级：方便在任务较多时进行排序
• 时间：用于定时任务提醒等
• 过滤：列表显示过长，用户过滤特定条件，方便筛选

高级需求

• 详细描述：（通常todo的简短描述无法满足复杂需求）
• 图片：对特点任务上传图片描述
• 多维管理：可以对任务进行分组分类
• 附件上传：pdf，word等文件作为todo项目附件说明
• 文字排版（富文本）：详细描述过长时，需要排版功能辅助数据可视化、条理化
• 多端支持：移动端、PC端数据同步，可同时使用

隐性需求

• 用户隐私：个人、团队任务属于隐私数据，需要严格加密存储流程（内部开发人员技术上不可见）
• 平台解耦：用户数据方便进行迁移、可视化，不会因为平台特有数据格式导致难以重复利用
• 知识沉淀：todo app 记录日常工作，需要提炼工作经验、总结知识点、归档，方便团队共享
• 统一平台：多行业通用：程序员bug跟踪、设计师需求对齐、各类行业规则检查，方便工作数据共享
• 可拓展：后续特定行业用户需求可以实现平滑拓展

需求分析

其中常见需求大部分的 todo app 都有实现（也是万年demo），高级需求增大应用复杂度，较少app实现。附件上传、多维管理通常以付费形式提供。

需求痛点、难点

• 附件上传与平台解耦需求矛盾
  平台通常使用自有格式保存用户上传的资料数据，用户难以迁移，文件数据难以管理

• 多维管理与知识归档难以兼得
  任务分组使得工作有条理，但实际工作需求多变，有时项目进行到一半因为各种原因停掉，转移战场。项目较多时关闭的分组与正在进行的分组混合，管理混乱，若删除，项目重启又很麻烦。

• 多维管理：维度不够，或者平台特定
  前面说到任务数量问题，通常项目细化后任务数量多的惊人（按部门、按人员、按项目分组）。大部分app只支持二维分组（付费支持），难以满足需求。分组后的数据更难进行平台迁移。

• 文字排版与平台解耦需求矛盾
  在任务较为复杂时，详细描述提供数据、资料支撑可以方便理清来龙去脉。但现有软件的排版停留在加空格还有换行符上，文字较多时显示混乱。如果支持特定排版功能，保存平台特定数据格式又与平台解耦需求矛盾

• 用户隐私保护需求难以实现
  任务的结构化数据存储在后台数据库中，字段难以全部加密，技术实现困难。若不加密，数据库被脱裤，或者被用于数据挖掘，用户特征分析都是不可接受的。

• 任务优先级难以定义
  如果采用优先级0、1、2...这样的排序方式，只描述了级别差异，而且不同用户不同习惯，有的习惯优先级0是最高优先级，有的习惯数值越大优先级越高。

基于上述原因及团队项目管理需要，开发了一个Markdown网盘，TaskHub 官网，微信小程序版本同名。

image

我们是如何解决这些痛点问题的？

首先联想到平时的文件管理，文件式管理解决了大部分的管理问题，无限维度、用户自定义、容易迁移归档、易使用。如果任务也能像文件一样管理就好了。于是想到了 Markdown 文件，首先 markdown 无侵入性、排版简洁、容易迁移、平台无关。如果每个任务都是一个 Markdown 文件，通过后台实现一个 markdown 网盘，这样就可实现文件式管理，而且Markdown任务文件可以方便总结日常工作经验，形成经验，在团队内部共享，方便通过网络进行传播（网页渲染简单）。于是大体方案就出来了——基于 Markdown 进行管理。

还有一些问题，如何将上述需求的数据结构映射到一个 markdown 文件中呢？

• 简短描述 ==> 映射为markdown的文件名或者标题
  由于文件名有特殊符号限制，很多常见符号不能作为文件名，所以采用标题映射方式。

• 状态 & 优先级 & 时间等信息==> 映射为badge
  首先这些信息要可视化，不是数据库中格式，其次要相对显眼。于是想到了平时代码 README 文件的 badge，状态信息可以映射到 badge 上，用户体验还不错。如下：
  [图片上传失败...(image-32cf3b-1576571794784)]

• 详细描述 ==> 映射为Markdown的正文部分
  效果图：

image

有了Markdown方案，回到上面的痛点问题

• 附件上传：用户图片等文件上传后作为link插入到markdown中解决，而且支持本地图片裁剪，可以隐藏一些敏感信息
  

  image

• 多维管理：文件式管理无限维度，容易归档，增加了wiki文件夹，用于知识归档，文件可直接下载导出

  
  
  image

• 文字排版：使用markdown进行排版，平台无关，软件上实现一个简洁的Markdown编辑器，方便编辑
  

  image

• 用户隐私保护
  每个任务都是一个文件，网盘后端可以很方便进行加密、分割存储、备份（通用网盘加密方式）大大简化后端设计，安全性更高。

• 确定优先级
  如何清晰描述一个优先级确实是个难题，不同行业不一致。后来我们联想到了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.

同类软件对比

写在最后

最后贴上小程序和官网~
欢迎小伙伴使用哦~
(Bug & 特性 同样欢迎~)

TaskHub 官网：文件式的任务管理神器

image