爲何一個 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 怎麼可可以?