說到前端技術(shù)靡砌，每個框架已脓、js庫基本都會提供一些 demo 入門代碼，萬年不變的例子就是實現(xiàn)一個 todolist通殃。（別笑^-）其中做 todolist 的網(wǎng)站度液、app 數(shù)不盡，比較有名的就是 todoist 画舌，還有微軟的 todo堕担，燃鵝~ 實現(xiàn)一個 todolist 真的如此簡單嗎？

如何打造一款實用的 todo app曲聂？

TaskHub 官網(wǎng)截圖

image

首先需要回答霹购，我們?yōu)槭裁葱枰?todolist？

米勒法則： 根據(jù)米勒(Miller朋腋，1956)的分析齐疙，人腦處理信息有一個魔法數(shù)字7(正負2)的限制，也就是說旭咽，人的大腦最多同時處理5到9個信息(chunks)贞奋。原因是短期記憶儲存空間的限制，超過9個信息團穷绵，將會使得大腦出現(xiàn)錯誤的概率大大提高轿塔。

每個人大腦短時間記錄的事情、步驟有限。據(jù)分析頂級的圍棋高手能夠預(yù)判未來的12步棋勾缭，而這幾乎就是人腦的極限了洽议，但日常生活的任務(wù)通常超過這個數(shù)字，所以我們需要一個 todo 軟件來輔助我們記錄漫拭，避免忘記亚兄、錯過重要的任務(wù)，誤了大事采驻。

常見需求

• 簡短描述：如：總結(jié)會議紀要审胚，輸出郵件
• 狀態(tài)：標記是否完成
• 優(yōu)先級：方便在任務(wù)較多時進行排序
• 時間：用于定時任務(wù)提醒等
• 過濾：列表顯示過長，用戶過濾特定條件礼旅，方便篩選

高級需求

• 詳細描述：（通常todo的簡短描述無法滿足復(fù)雜需求）
• 圖片：對特點任務(wù)上傳圖片描述
• 多維管理：可以對任務(wù)進行分組分類
• 附件上傳：pdf膳叨，word等文件作為todo項目附件說明
• 文字排版（富文本）：詳細描述過長時，需要排版功能輔助數(shù)據(jù)可視化痘系、條理化
• 多端支持：移動端菲嘴、PC端數(shù)據(jù)同步，可同時使用

隱性需求

• 用戶隱私：個人汰翠、團隊任務(wù)屬于隱私數(shù)據(jù)龄坪，需要嚴格加密存儲流程（內(nèi)部開發(fā)人員技術(shù)上不可見）
• 平臺解耦：用戶數(shù)據(jù)方便進行遷移、可視化复唤，不會因為平臺特有數(shù)據(jù)格式導(dǎo)致難以重復(fù)利用
• 知識沉淀：todo app 記錄日常工作健田，需要提煉工作經(jīng)驗、總結(jié)知識點佛纫、歸檔妓局，方便團隊共享
• 統(tǒng)一平臺：多行業(yè)通用：程序員bug跟蹤、設(shè)計師需求對齊呈宇、各類行業(yè)規(guī)則檢查好爬，方便工作數(shù)據(jù)共享
• 可拓展：后續(xù)特定行業(yè)用戶需求可以實現(xiàn)平滑拓展

需求分析

其中常見需求大部分的 todo app 都有實現(xiàn)（也是萬年demo），高級需求增大應(yīng)用復(fù)雜度甥啄，較少app實現(xiàn)存炮。附件上傳、多維管理通常以付費形式提供型豁。

需求痛點僵蛛、難點

• 附件上傳與平臺解耦需求矛盾
  平臺通常使用自有格式保存用戶上傳的資料數(shù)據(jù)，用戶難以遷移迎变，文件數(shù)據(jù)難以管理

• 多維管理與知識歸檔難以兼得
  任務(wù)分組使得工作有條理充尉，但實際工作需求多變，有時項目進行到一半因為各種原因停掉衣形，轉(zhuǎn)移戰(zhàn)場驼侠。項目較多時關(guān)閉的分組與正在進行的分組混合姿鸿，管理混亂，若刪除倒源，項目重啟又很麻煩苛预。

• 多維管理：維度不夠，或者平臺特定
  前面說到任務(wù)數(shù)量問題笋熬，通常項目細化后任務(wù)數(shù)量多的驚人（按部門热某、按人員、按項目分組）胳螟。大部分app只支持二維分組（付費支持）昔馋，難以滿足需求。分組后的數(shù)據(jù)更難進行平臺遷移糖耸。

• 文字排版與平臺解耦需求矛盾
  在任務(wù)較為復(fù)雜時秘遏，詳細描述提供數(shù)據(jù)、資料支撐可以方便理清來龍去脈嘉竟。但現(xiàn)有軟件的排版停留在加空格還有換行符上邦危，文字較多時顯示混亂。如果支持特定排版功能舍扰，保存平臺特定數(shù)據(jù)格式又與平臺解耦需求矛盾

• 用戶隱私保護需求難以實現(xiàn)
  任務(wù)的結(jié)構(gòu)化數(shù)據(jù)存儲在后臺數(shù)據(jù)庫中倦蚪，字段難以全部加密，技術(shù)實現(xiàn)困難妥粟。若不加密审丘，數(shù)據(jù)庫被脫褲吏够，或者被用于數(shù)據(jù)挖掘勾给，用戶特征分析都是不可接受的。

• 任務(wù)優(yōu)先級難以定義
  如果采用優(yōu)先級0锅知、1播急、2...這樣的排序方式，只描述了級別差異售睹，而且不同用戶不同習(xí)慣桩警，有的習(xí)慣優(yōu)先級0是最高優(yōu)先級，有的習(xí)慣數(shù)值越大優(yōu)先級越高昌妹。

基于上述原因及團隊項目管理需要捶枢，開發(fā)了一個Markdown網(wǎng)盤，TaskHub 官網(wǎng)飞崖，微信小程序版本同名烂叔。

image

我們是如何解決這些痛點問題的？

首先聯(lián)想到平時的文件管理固歪，文件式管理解決了大部分的管理問題蒜鸡，無限維度胯努、用戶自定義、容易遷移歸檔逢防、易使用叶沛。如果任務(wù)也能像文件一樣管理就好了。于是想到了 Markdown 文件忘朝，首先 markdown 無侵入性灰署、排版簡潔、容易遷移局嘁、平臺無關(guān)氓侧。如果每個任務(wù)都是一個 Markdown 文件，通過后臺實現(xiàn)一個 markdown 網(wǎng)盤导狡，這樣就可實現(xiàn)文件式管理约巷，而且Markdown任務(wù)文件可以方便總結(jié)日常工作經(jīng)驗，形成經(jīng)驗旱捧，在團隊內(nèi)部共享独郎，方便通過網(wǎng)絡(luò)進行傳播（網(wǎng)頁渲染簡單）。于是大體方案就出來了——基于 Markdown 進行管理枚赡。

還有一些問題氓癌，如何將上述需求的數(shù)據(jù)結(jié)構(gòu)映射到一個 markdown 文件中呢？

• 簡短描述 ==> 映射為markdown的文件名或者標題
  由于文件名有特殊符號限制，很多常見符號不能作為文件名，所以采用標題映射方式瑰枫。

• 狀態(tài) & 優(yōu)先級 & 時間等信息==> 映射為badge
  首先這些信息要可視化荠割，不是數(shù)據(jù)庫中格式，其次要相對顯眼凯亮。于是想到了平時代碼 README 文件的 badge，狀態(tài)信息可以映射到 badge 上，用戶體驗還不錯尤蒿。如下：
  [圖片上傳失敗...(image-32cf3b-1576571794784)]

• 詳細描述 ==> 映射為Markdown的正文部分
  效果圖：

image

有了Markdown方案，回到上面的痛點問題

• 附件上傳：用戶圖片等文件上傳后作為link插入到markdown中解決幅垮，而且支持本地圖片裁剪腰池，可以隱藏一些敏感信息
  

  image

• 多維管理：文件式管理無限維度，容易歸檔忙芒，增加了wiki文件夾示弓，用于知識歸檔，文件可直接下載導(dǎo)出

  
  
  image

• 文字排版：使用markdown進行排版呵萨，平臺無關(guān)奏属，軟件上實現(xiàn)一個簡潔的Markdown編輯器，方便編輯
  

  image

• 用戶隱私保護
  每個任務(wù)都是一個文件甘桑，網(wǎng)盤后端可以很方便進行加密拍皮、分割存儲歹叮、備份（通用網(wǎng)盤加密方式）大大簡化后端設(shè)計，安全性更高铆帽。

• 確定優(yōu)先級
  如何清晰描述一個優(yōu)先級確實是個難題咆耿，不同行業(yè)不一致。后來我們聯(lián)想到了IETF發(fā)布備忘錄的標記方式爹橱，標準細項的描述使用了requirement level關(guān)鍵字：Must萨螺、Required、Recommended等愧驱，這些關(guān)鍵字用來描述任務(wù)的優(yōu)先級更為準確慰技、清晰，最后被我們采納组砚。參考 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.

同類軟件對比

寫在最后

最后貼上小程序和官網(wǎng)~
歡迎小伙伴使用哦~
(Bug & 特性 同樣歡迎~)

TaskHub 官網(wǎng)：文件式的任務(wù)管理神器

image