雖然說身為唸 software engineering 的人, 覺得責任也不全在我身上, 編輯軟體的 user interface design 應該是很典型的, 遵守 "讓使用者專心在他該花心思的事" 去設計, 而不是當使用者想要什麼效果時, 還需要抱著一兩本厚厚的書在翻找, 或是找有深厚使用經驗的 "高手" 求救 (通常這情形發生的越多, 表示這 software 的 user interface 設計越有改進的空間). 過去 Word / Office 每次出新版, 市面上的相關書籍就琳琅滿目, 該說 M$ 跟這些書的作者也算是某種共犯結構嗎 ?
回到 OOo 的自訂頁碼起始值好了, 如何插入頁碼在 OOo 的基本操作手冊文件裡已經有說明, 但是當我要自訂文件的頁碼起始值, 也就是希望頁碼不見得要從 1 開始, 可以從 15, 43, 或是任何數字開始呢 ?
(以下方法適用於 OOo 2.1, 也就是我現在使用的版本.)
有兩個方法, 第一個是在頁碼上按滑鼠右鍵進入欄位設定,
在欄位設定的格式選項下方, 有一個叫做修改的可修改欄位. 但問題是, "修改" 是什麼意思 ? 要修改什麼 ?
實際試了之後才會發現, 這裡的修改意思是對於目前頁碼的修改, 而且是加減的修改, 而不是直接替換掉原本的頁碼. 舉例來說, 如果把這裡填 10,
確定之後就可以看到原本頁碼是 32, 變成了 42, 同時上下相連的頁面, 其頁碼也會跟著改變. 換句話說, 原本的 32 + 修改的 10 = 最後的 42.
第二種方法就更神奇了, 你必須要把游標移到要改頁碼的該頁, 比如說剛剛的 page 32, 頁面內容的第一段上, 然後右鍵進入段落設定中. 請注意要是第一段, 否則改變的頁碼會從下一頁開始產生影響.
進入段落設定中, 在中間的位置有換行與分頁的設定, 需要把插入以及使用頁面樣式都勾選, 然後才能對右邊的頁碼進行調整, 一樣把他改到 42.
按下確定之後, 一樣可以看到 page 32 變成了 page 42. 但是請注意, 這種方法所造成的頁碼改變, 僅限於 page 32 及其以下的頁面, 換句話說 page 33 會變成 page 42, 但是 page 31 仍舊只會是 page 31, 跟第一種方法的影響不同.
Well, 回過頭來說 user interface design, 像是這種 design, 一來在使用者想要某項功能時, 很難以選擇施行(因為根本不知道可以這樣改阿), 二來對於究竟會造成什麼效果 (post-conditions), 也難以掌握. 今天只是改個頁碼就可能出現兩種不同的結果, 要是改其他的東西, 使用者如何放心文件的其他不相關部分不會被偷偷的進行什麼變動 ? 如果每次作設定的改變都需要使用者重新檢查文件一次, 這未免太累人了 :(從這個 case 其實可以深入探討三個議題,
1. use case consistency : 如果上述兩個方法其實是同一個 use case, 或是相似的 use cases, 那麼他們的 post-conditions 是否應該保持一致 ?
2. use case understandability : 如何讓使用者事先意識到在他所使用的 use cases 中, 最終會對文件帶來什麼改變, 而不是等到 use cases 執行完了, 才讓使用者去找尋造成了什麼改變. 畢竟 use case 在 forward engineering 中本來就是給 customer 看的東西, 沒道理在真正使用 software 時反而不能從 use case 裡得到應該知道的訊息.
3. document-preserving activity : 這是從 refactoring 的 behavior-preserving 借用過來的, 以編輯軟體來說, 是否部分 activity 應該可以視為對 document 作了 refactoring, 同時這些 activity 也必須具備某種 document-preserving 的特性. 舉例來說, 上述的兩種頁碼變更方式, 第一種會維持頁碼的連續性, 第二種則是會打斷頁碼的連續性, 這可能是兩種不同的編輯功能, 但是顯然地他們造成的效果是不一樣的, 換句話說這兩個 activity 對於 document 的改變事實上就是具有不同的特性.
阿...越扯越遠了, 就此打住, 有機會再深入討論這些想法吧 :)
沒有留言:
張貼留言