制作電子內容,最困難的是內容輸入和顯示。傳統的書籍由於媒介(書頁)有固定的大小,只要按“所見即所得”的方式排版和輸入文字便可以了。你想第三十頁有一張圖片,也就在那裡插入即可。電子圖書,卻要照顧不同顯示裝置的屏幕大小,不可能在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年我進入公司以來,從沒有聽過一天是“有時間”的,重要的事都是不斷給緊急的事排擠...
程式功能其實很簡單,只要輸入文字內容,就能根據問題類型,輸出適合的XML語句。此外,還可以一次輸出多條題目的XML。由於界面已經將要輸入的內容表格化,所以能杜絕輸入錯漏,也不需要用肉眼去判斷有沒有不小心碰到那些可惡的符號。
作出這個行動,其實只想表達兩個信念:
- 先建好地基,才蓋房子,而不是先建房子,待就要塌下來的時候才去整個樓房拆掉,改善地基。那時已經太遲。
- 不是沒時間,而是不肯去想,急功近利。
訂閱錄音室
沒有留言:
發佈留言