制作電子內容，最困難的是內容輸入和顯示。傳統的書籍由於媒介(書頁)有固定的大小，只要按“所見即所得”的方式排版和輸入文字便可以了。你想第三十頁有一張圖片，也就在那裡插入即可。電子圖書，卻要照顧不同顯示裝置的屏幕大小，不可能在iPhone和iPad上，第三十頁的內容都相同。iPhone的螢幕小，如要清晰顯示，每一頁可顯示的字數一定不及iPad多，因而影響分頁和內容位置。
因此，合理的電子圖書制作方法，應先用結構化的方式輸入內容(也就是不以頁數作為內容組織單位，而是根據章節等結構)，然後再利用一個排版的程式，自動根據顯示裝置的大小調整內容和圖片的位置和大小。可惜，管理層做事一向缺乏長遠考慮，將電子書當一般文件般去處理，結果同事需要為每一個顯示裝置制作全新的排版，無日無之，費時失事。所以每次問候負責有關工作的同事，她們都顯得很無助。
其實早於2008年，已經提出過手動排版不是辦法，系統設計應該預留自動排版機制。由於當事者不關心長遠問題，當然也是不了了之。現在的問題，三年前已經知道...
今天，發現某個項目終於采用結構化的方式輸入內容(一些練習問題)，但系統的設計竟要同事白手編寫以下這個東西(這已經是最簡單的一個例子)：
<Question type="FITB" lv="1" zone="0" bonus="1" keyword="F1_VOC_EE">
<Span type="text">Apple is ___</Span>
<Span type="input" answer="red">3</Span>
<Span type="text">in color.</Span>
</Question>
這段文字稱為XML。簡單說，就是告訴電腦紅色文字的功用是什麼的一種語言。由於檔案需要由電腦處理，所以格式要很准確，不能有誤。同事只可修改紅色的部分，其余部分則不能碰。做這項工作，等於要你在數百個相連的字母中，只修改其中數個，但不能碰到其他的字母。
如果輸入的題目數量少，還可以接受。但同事的工作量是每天四百條，也就是四百段以上的語句。那有什麼可能不錯不累呢？這樣精細的工作，絕對應該由機器去代勞，而不是浪費一個有血有肉的人的生命，即使你付了他錢。
我問這位累得駝背的同事：“為什麼Programmer不弄一個輸入題目的程式，讓後自動輸出XML呢？”。同事無奈回答因為他們沒有時間。然後我覺得更加無奈，與其讓四五個人慢慢輸入和核對，何不投資幾個小時去做個工具，免卻無謂的付出呢？用編輯的工資請資料輸入員，又是何等愚蠢呢？其實，從2006年我進入公司以來，從沒有聽過一天是“有時間”的，重要的事都是不斷給緊急的事排擠...
“小喇星！！！咩都話無時間！！！今日我唔做自己野，我寫呢個程式比你！” 結果，用了半天的時間便完成了那個Programmer一生人都說沒時間做的東西。
程式功能其實很簡單，只要輸入文字內容，就能根據問題類型，輸出適合的XML語句。此外，還可以一次輸出多條題目的XML。由於界面已經將要輸入的內容表格化，所以能杜絕輸入錯漏，也不需要用肉眼去判斷有沒有不小心碰到那些可惡的符號。
作出這個行動，其實只想表達兩個信念：
- 先建好地基，才蓋房子，而不是先建房子，待就要塌下來的時候才去整個樓房拆掉，改善地基。那時已經太遲。
- 不是沒時間，而是不肯去想，急功近利。
訂閱錄音室
沒有留言:
發佈留言