關於本報

自由軟體鑄造場電子報
報主:中央研究院資創中心
創刊日期:2004-06-03
發報頻率:雙週刊
訂閱人數:3,349
官網:

近期電子報


訂閱便利貼


將貼紙語法置入您的網站或部落格當中, 訪客可以輸入mail取得認證信,並按下確認連結後, 快速訂閱您的報紙。
預覽圖
訂閱自由軟體鑄造場電子報報
自由軟體鑄造場電子報
-----------------------------------------------------------------------------------------------------
Plurk FaceBook Twitter 收進你的MyShare個人書籤 MyShare
  顯示內嵌語法

自由軟體鑄造場電子報
發報時間: 2009-10-13 16:00:00 / 報主:OSSF
[公益聯播]守護獨老,按<讚>助建站
本期目錄
[開放原力] 打造三太子
[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)
[開放原力] 打造三太子
Jedi/文 2009/10/10

「三太子」是一個開放專案,目的是要將 Opera 桌面瀏覽器按照台灣使用者的習慣與偏好,修改成適合台灣人使用的樣子。本文將簡要描述這項專案如何進行,提供給任何企圖發起開放源碼專案的讀者參考。

最近一個月來,我著手進行了一項(目前為止仍然只有一個人維護的)軟體專案,這項專案命名為「三太子」,目的是要把 Opera 桌面瀏覽器按照台灣使用者的習慣與偏好,加以調整。Opera 本身雖然是一套私有軟體,但是其企業文化相當鼓勵使用者社群在不修改 Opera 本身程式碼的前提下加以修改、包裝客製版本;有些客製化版本甚至有機會獲得 Opera 公司的官方支援,並成為正式釋出的版本之一。中國的「朱雀」就是這樣的例子。

像這樣的一個第三方維護專案,也可以是開放源碼專案。事實上,開放源碼社群行之多年的各種技術、慣例、文化,即使拿來跟私有軟體合作,也能夠有很好的搭配;本著拋磚引玉的精神,我決定以本文來記錄這一個月來用於「三太子」專案的各種實務要點,回饋給開放源碼界的各位。

在本文開始之前,還有一件事:日前歐萊禮出版社的新書《The Art of Community》(社群的藝術)已採用創用CC「姓名標示─非商業性─相同方式分享」3.0 授權條款釋出,並可於其網站上下載英文原本及多種語言的譯本,讀者不妨也將此書納入開放源碼社群經營的重要參考。
 

■ 命名

許多開放源碼專案往往始於「我想要做某某事」的想法,由極少數人(例如只有一個人)開始動手進行;接下來隨著專案日趨成熟,參與的人也越來越多,專案也越來越龐大、複雜。不論專案成員有多少人,當專案成為專案的那一刻,就要有個名字,或者是個代號;「名稱」在任何語言當中都有神奇的魔力,可以把一個不存在的、虛幻的、抽象的概念,轉化成一個具體存在的實體,可以讓溝通能夠集中,讓彼此知道在談論的是什麼。

命名本身是一項大學問,甚至有專門以命名謀生的行業,在此便不多論述;不過命名時有個重點,是每個參與專案的人都該牢記在心的:不管命名的背後考慮了多少細節、用了多少暗示或明示,名字就只是個名字而已,世界上沒有十全十美的名字,一定會有人對這個名字有意見──但是請饒了自己吧,名字取好後沒事最好不要更動,精力應該著重在專案的發展上,而不是一直繞著名字打轉。

「三太子」這樣的名字,說實話多少受到了「朱雀」的影響。中國版 Opera 叫「朱雀」,如果跟著叫「玄武」、「青龍」、「白虎」之類的顯然太過沒有創意,而且就沒辦法跟 Opera 的主題色:紅色相稱了。那如果從另一個角度來想,Opera(歌劇)到了中國變京劇(Chinese Opera),到了台灣是不是應該叫「歌仔戲」(Taiwanese Opera)呢?總覺得哪裡怪怪的。後來在跟我一個朋友的閒聊之中,冒出了「哪吒三太子」這樣的想法;哪吒三太子在台灣的民間信仰當中,是很重要的神祇,手上有各種神兵利器,而且腳踏風火輪,行動迅速,似乎可以跟 Opera 的本質巧妙呼應!再說,風火輪就是圓形的,又是紅色的嘛!所以最後就決定這個專案要叫「三太子」了。

有了中文名字後,接著還得有個英文名字,除了可以保留日後「與國際接軌」的可能性外,英文名字也適合用於檔案命名。由於「哪吒」的出處是梵文佛經當中的「Nalakuvara」音譯之略,因此「三太子」的英文名稱就決定採用「Nalakuvara」了。
 

■ 決定基準

許多軟體專案在發展之初並不會先訂好完整的里程碑,或者繪製完整的藍圖(實務上來說,確實不是所有的軟體專案都可能在一開始就做好這些事);不過就算如此,也應該在一開始就先決定好取捨的準則,讓參與開發的協同工作者,或者是專案的使用者,都能夠明確地判斷哪些事項比較有可能會囊括在專案內,哪些則不大可能。

這項工作可以為整個專案奠定起最高指導原則,日後若有功能衝突時,或者需要排定工作項目優先順序時,都該以此最高指導原則為基準。有些專案在初期僅憑著核心成員之間的默契來行事,隨著時間過去,或者是隨著成員變動,這些「默契」就很有可能發生變化或喪失,導致專案走向不明,甚至是無法持續下去,實在是相當可惜。

儘可能地把「默契」轉化成具體的文字,讓各種決策都有明白的依據,這是任何專案健全成長的必要根基之一。

「三太子」的基準相當簡單,跟五洲製藥的理念一樣,是「先講究不傷身體,再講究效果」。因為 Opera 本身的開發理念之一就是希望能兼具簡潔與功能強大,因此這也成為「三太子」的最高指導原則──讓 Opera 更適合台灣使用者的同時,也一定要讓 Opera 保持簡潔、乾淨。

在這樣的前提下,「三太子」必須要盡可能地遵循 Opera 本身的設計,按照 Opera 原本的目錄架構邏輯來放置檔案,致力於維持 Opera 一貫的美感。如果可能的話,盡可能地不要添加第三方應用程式、外掛、使用者 JavaScript,這樣才是符合 Opera 精神的「三太子」。

這樣的決定還有一個好處:理論上各平台的 Opera 的邏輯是一致的,因此在儘可能不添加額外程式的前提下,所有對 Opera 的動作理論上也會是能夠跨平台的。也就是說,遵守這樣的指導原則,可以讓「三太子」更靈活、有彈性,也能更容易地移植到不同的平台上。我們稍後就會看到這樣的實證。

可惜現實世界當中並非事事順心,有些台灣使用者極為渴望的功能,不靠外力難以達成;這種情況下,「三太子」仍盡力保持 Opera 本身的純淨,想辦法把「破壞」減到最少,並且把各種額外添加的東西都做成選項──如果使用者不想要,那麼這些東西就不會進來。
 

■ 版本管理

就算只有一個人的專案,也應該要使用版本管理系統,而且儘可能不要拿本機當做版本管理系統的伺服器端。

使用版本管理系統的好處實在是不遑多論了:便於管理(從基本的版本比對到複雜的版本分支及合併)、便於協同作業、作為備份,每一項都十足重要。就算是只有一個人、沒有分支的專案,也有可能因為一時手殘(或者是任何意外)而毀掉手中的檔案,需要回溯到先前可正常運作的版本,任何開發者這時都會對著版本管理系統發出「哈里路亞!」的讚嘆聲。

版本管理系統的選用會跟專案的本質、專案成員的偏好有關。以「三太子」來說,這個專案會將專案當中的某個目錄直接打包壓縮釋出,因此會產生一堆「.svn」目錄的 svn 在此就不是那麼合適;由於我原本就一直有在使用 Perforce(兩個使用者以內免費,用來開發開放源碼專案的話也可以去申請免費授權金鑰),這套版本管理軟體在各方面表現都不錯,也沒有「.svn」的問題,因此最後「三太子」就決定採用 Perforce 來管理修訂版。

不論使用哪一種版本管理系統,最重要的是要乖乖按照正確的取出、放入流程來使用,並且要養成仔細撰寫修訂版日誌的習慣。「三太子」半個月內就產生了數百次修訂版,如果沒有修訂版日誌,根本不可能在需要的時刻找到正確的版本。
 

■ 源碼語言

每一種語言都有其擅長之處,也有其不擅長之處。軟體專案應該選用能夠滿足需求的語言──不過值得注意之處在於,一個專案不見得就只能使用一種語言。

在「三太子」當中,基本上是按照不同作業系統版本的 Opera 安裝方式不同,來選擇所要搭配的腳本語言。

Windows 版本的 Opera 在安裝時有較多使用者互動,而 Windows 的使用者也比較習慣圖型化使用者介面,因此就要選擇能輕易處理 GUI、能處理 UTF-8 字串、能夠處理檔案及目錄、能夠讀寫登錄、能讀寫 INI 設定檔的腳本語言,最好還要能輕易編譯成執行檔,讓使用者毋須安裝執行環境就可以使用這樣的腳本。在這樣考量之下,最後雀屏中選的是 AutoHotKey。

到了 Linux 及 FreeBSD 上,則完全不一樣了。Linux 及 FreeBSD 版本的 Opera 在安裝時沒什麼需要使用者介入的地方,而且這些作業系統的使用者往往也比較熟悉文字使用者介面,所以選用了 Shell Script 來處理。

Mac OS X 又是另一種情況。由於 Mac OS X 內建了一套叫 Automator 的腳本語言,也支援 GUI,所以屆時「三太子」若要移植到 Mac OS X 上,就會選用 Automator 來實作。

不管選用了何種語言,如果能先撰寫虛擬碼及描述程式邏輯的文件,那麼日後要是不幸得改用不同的語言來實作時,就會比較輕鬆。不過請注意:許多軟體專案隨著時間成長,軟體本身的發展往往會超出虛擬碼及程式邏輯一開始的設定範圍,這時別忘了要跟著更新相關的文件及虛擬碼,以免產生了一堆過時而無法使用的文件,在關鍵的時候反而就幫不上忙了。
 

■ 源碼註解與文件

有了版本管理之後,修訂版日誌可以協助了解每一批修改的用意為何;但是修訂版日誌無論如何也無法取代源碼註解。源碼註解可以幫助明天的你還能看懂今天所寫的東西,也能幫你釐清邏輯上的瑕疵與漏洞──換句話說,詳細的註解其實主要還是幫自己的忙,其次才是幫其他人看懂你都在寫些什麼。

除了源碼當中的註解外,還要另外維護使用者文件跟開發者文件。使用者文件用來讓專案的使用者知道這個專案做了些什麼事、有什麼功能可以使用、有哪些東西可以調整或開關、如果出錯了可能是誰造成的;開發者文件則是讓其他有興趣參與開發的人,可以更迅速地上手,掌握整個專案的結構與步調。

雖然維護這些註解與文件所費不貲(「三太子」專案花在文件上的時間大約是三分之一到一半左右),但是卻會是物超所值的行動,因為藉由這些文件,可以讓整個專案更容易地被檢視,有瑕疵時也能更迅速地補正,因此使用者及開發者之間的關係更透明而直接,信任關係也就越強烈。「信任」正是一切社群的核心,妥善而完整的文件則是開放源碼專案累積信任的重要基礎。

「三太子」對 Opera 所做的一切處理,皆儘可能詳實地公布在網頁上,這樣不但能讓台灣使用者社群更放心地使用三太子,也能讓台灣使用者社群藉此機會更瞭解 Opera,甚至是以此為基礎,打造屬於自己的個人 Opera。
 

■ 訊息管道

任何一個開放源碼專案,有了名字、進行開發、有了文件之後,更重要的是得有個便於公眾取用的入口。在網頁時代,這個入口也就是一個網頁或網站。

但是光有網站還不夠,因為這年頭網站實在太多了,開放源碼專案也如過江之鯽,九成以上的使用者對任何網站都只會看一次──這些使用者可能是看到某些資訊入口網站或媒體的報導而來,但是離開之後就不會再回來。

對於健康的開放源碼專案來說,只有一次的高度關注是沒有用的,細水長流才是生生不息的象徵。如何能夠掌握那唯一一次的使用者來訪呢?在網站上提供源料,或者是利用 twitter 或 plurk 這類可供訂閱/跟隨的媒介,都會是不錯的作法。藉由這類管道,使用者就能源源不絕地獲得最新的更新資訊,誘使他們再度回訪。

有些開放源碼專案總是在新版本釋出的時候玩跟著撰寫釋出聲明,這對於專案發展來說幫助是有限的;正確的作法其實是儘可能頻繁地更新訊息,不論是網頁上的文件有修正,或者是專案源碼有變更,就算還沒有達成階段里程碑而不會釋出新版,也還是可以先放出風聲,一方面可以讓社群感受到專案的活躍,另一方面也能鼓舞社群回應,並避免已修正的問題重複回報。

如果每一則訊息,以及網頁上的每一段資訊,也都能有個靜態鏈結,那麼社群成員就更能把相關的訊息散佈出去,使整個專案能見度更高。
 

■ 多語

任何軟體專案,只要是會有前端使用者介面的部份,就一定要顧及多語的使用情境。這部份可以分成幾個不同的層次,循序漸進:

1. 在不同語言的環境之中,至少要能正確地顯示同一種語言的訊息
2. 在不同語言的環境之中,至少要能正確地處理同一種語言的輸入內容
3. 在不同語言的環境之中,至少要能正確地處理同一種語言、不同編碼(例如 Big5 跟 UTF-8)的輸入內容
4. 在不同語言的環境之中,能夠正確地按照語言環境變數,用不同的語言來表達相關訊息內容
5. 在不同語言的環境之中,能夠正確地處理不同語言、不同編碼的輸入內容
6. 在不同語言的環境當中,能夠處理不同語言及編碼的檔案名稱與路徑名稱

處理輸入內容的時候,重點在於要判斷輸入內容的原始編碼,統一轉換成 UTF-8 等通用編碼格式,再繼續做處理(正好 Opera 的設定檔都必須以 UTF-8 編碼來撰寫)。

處理訊息時,會遇到的問題則是要同時維護多種語言的版本;為了讓程式/腳本本身盡可能單純、簡化,這些訊息字串最好抽出另外處理,而不要嵌入主程式/主腳本之中。開放源碼界的 GNU gettext 是個相當成熟的國際化框架,當專案成長到某個程度時就可以予以採用,如此也便於把不同語系檔交付給不同的社群成員來負責。(當然在專案還很小的時候就率先採用 gettext 也很好,並沒有什麼不妥)

從網頁服務乃至於商業化的獨立遊戲,處處都可見到 gettext 的蹤跡,足見其成熟度。
 

■ 跨平台

軟體專案要如何跨平台呢?最簡單的辦法是使用本身就跨平台的開發框架,並且避開平台特定性的元件或語言模組。很不幸地「三太子」沒有辦法這樣做。因為 Opera 在不同平台上的安裝方式、檔案放置位置都有所不同,所以正如前述一般,「三太子」在不同平台上選用了不同的實作腳本語言。不過「三太子」一開始就決定了靈活與彈性的最高指導原則,儘可能避開平台限定的元件,因此很容易就可以移植到許多不同的平台上。

實務上,「三太子」的開發也是在不同的平台上平行(但是同步)進行,這時候就得說虛擬機器實在是開發者的好朋友了。

VMware 的 VMware Server、VMware Player 及 Sun 的 VirtualBox 都是開放源碼的虛擬化解決方案,另外微軟也有一套免費(但是沒有開放源碼)的 Virtual PC,都可以讓開發者在自己的電腦上準備好多種不同作業環境,用來開發及測試。

「三太子」最先完成的平台是 Windows,並且將多語訊息抽離出來另外處理,主要的腳本保持簡潔,又撰寫了詳細的註解,很快就整理出虛擬碼;在虛擬碼的協助之下,很快地就轉寫成 Shell Script 的版本,於是 Linux 及 FreeBSD 平台很快就處理完一半了,剩下來的部份就是將檔案的換列格式調整成 UNIX 格式,並且重新分配檔案路徑,調整檔案權限,然後就可以打包收工。
 

■ 檔案測試與釋出

不論做的變更有多小,檔案都應該要實際測試過再釋出,因為疏忽跟意外總是在料想不到的地方發生。前述虛擬化的做法還有一個優點,就是可以幫準備好的環境建立快照,日後就可以利用這些快照,迅速還原到用來測試的環境。包括全新的乾淨安裝,以及移除舊版後的再安裝、直接覆蓋的安裝、使用非預設路徑及設定的安裝等,通通都要測試過一遍。

在「三太子」的發展過程當中,最常出現的瑕疵是因為 Big5 衝碼導致腳本執行失敗,以及忘記更改版號,好在多半都有在測試階段發現,及時更正。

隨著專案規模擴大,要測試的流程與變數也會越來越多,如果可能的話,最好分配給社群成員來進行。不過為了要確認測試方式的一致性,應該要準備好測試說明文件,並且準備好檢核清單,方便社群成員回報。

釋出檔案時,除了應有釋出註記、版本沿革文件外,最好在檔名對不同的版本做區分,以免使用者同時下載多種不同版本產生檔名衝突。另外若是自行尋找空間放置檔案,則應該要盡可能尋找多個不同的下載空間,讓使用者能夠選擇對他們來說更為便利、迅速的下載來源。提供檔案的 MD5/SHA1 加總檢核碼是確保檔案下載完整的好方法,但是並非所有的使用者都瞭解如何運用加總檢核碼,所以釋出的檔案本身若能檢查自己的完整性,對於使用者來說將會更為便利。
 

■ 外交

檔案釋出了,對於一個軟體專案來說,才是真正的開始。當你的軟體投入廣大的使用者社群後,會面臨到許多你原本所沒有設想到的情境,也可能會激盪出更多不同的需求與想法,其中有些真的是非常珍貴的回應,但是也有一些會導致專案往奇怪的方向發展。專案一開始設立的基準此時就會是護身符了,理性、禮貌、平和地拿出專案基準,與使用者社群互動,就可以釐清八成的回應是否應該納入開發流程、應該納入哪個里程碑。

但是使用者社群並不是開放源碼專案唯一該接觸的對象。現今的軟體產業很少從上到尾靠自己就能搞定,尤其像「三太子」這樣的專案,除了接觸瀏覽器的使用者外,還有網頁及網頁服務的提供者,以及瀏覽器製造者(也就是 Opera 公司),也會與「三太子」的發展攸關。因此這些「上下游產業」也是「三太子」專案在發展過程當中,不斷聯繫的對象。

說實話,「三太子」專案的最終目標,是讓「三太子」專案可以不需要繼續下去──一旦 Opera 能夠針對台灣的使用者社群提供更好的預設值及功能,而網頁服務提供商也能更完善地支援 Opera,那麼「三太子」就可以下台鞠躬了。促成此事需要仰賴社群的力量,而一個目標明確、透明誠實的專案,則是凝聚社群力量的良好管道。

「三太子」專案首次釋出檔案後半個月內就有超過五千人次的下載數,並且在台灣及中國都掀起了一陣討論;目前已經有台灣的網頁服務提供商表達願意配合「三太子」專案修改產品的意願,而 Opera 的台灣辦公室、中國辦公室、挪威總部也都有相關的人員主動聯繫「三太子」專案,足見「三太子」專案至今的經營與發展方向,大致還算穩健、正確。
 

■ 結語

經營一個開放專案,跟經營一個開放社群,兩者都是相當不容易的工作,更需要相當的熱誠與精力,才有辦法保持日久彌新、穩健成長。「三太子」在這個領域當中,實在是非常年輕的一個專案;它到底會如何發展,沒有人能說得準。

身為計畫的維護者,我能確定的事情只有一樣:秉持著開放的心胸、開放的想法,保持開放的文件與開放的源碼,讓整個專案的內容便於整個社群開放取用,那麼整個社群在此專案上所投注的每一分每一秒,就都能累積下來,成為重要的資產。即便未來這個專案因故告一段落,這些資產也還是會陪伴著整個社群,讓整個社群能以此為基礎,繼續繁衍出其他的計畫。
 

■ 相關連結

「三太子」計畫與文件集
Opera
《The Art of Community》
Perforce 版本管理系統
AutoHotKey 腳本語言
鳥哥的 Linux 私房菜──學習 Shell Scripts
Automator 腳本語言
GNU gettext
VMware Server
VMware Player
Sun VirtualBox
Microsoft Virtual PC

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)
Attila/文 2009/10/10

*圖文整合篇*


圖文的比例

簡報的主題若能選擇能表達其意境的圖片,往往能傳達出比預期還要多的訊息,而且觀眾的印象也比較深刻,所以在投影片內適度地加入圖片,簡報的效果往往會更好。不過圖文之間如何安排?有了圖片之後,文字還可以如何加以精簡,好讓二者合一,發揮更好的效果?這是值得大家研究的大學問。
 

圖和文字的比例應該是多少才是最好呢?這可沒有一定的規則,多數的情形是:圖多於字、圖片所佔的面積大於文字會比較好,畢竟圖片總是比較賞心悅目一些。當然實際製作時還是要視情況而定,不是圖越多、越大就是越好。使用的數量、大小,還得看簡報的內容和版面設計而定。

至於圖片要不要經過特殊處理,如透明、漸層、濾鏡或特效等,一樣還是要根據整體版面的設計、配色和想表達的意境而定,不見得非用不可。而某些影像效果,簡報軟體也會提供,若想節省製作時間,不妨多加利用。

底下所示範的設計方式,是以多張不同的圖來襯托主題的圖片,讓觀眾在欣賞圖片時,就能自行聯想到簡報者想表達的核心概念,最後再以簡短的一句話,讓觀眾更加確認自己所瞭解的主題是什麼,如此可以達到讓觀眾印象深刻的效果。

步驟一:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3) 

增加一張投影片後,版面配置選擇「空白投影片」。


步驟二:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

在繪圖工具列上按「取自檔案」鈕,以便選擇自己準備好的圖片檔案。


步驟三:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

選擇存放圖片的資料夾,點選要加入的圖片後按「開啟」。


步驟四:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

除非事先已經根據投影片的版面設計而把圖片製作成適合的大小,否則加進投影片的圖,通常還得設定一下大小。

這裡我們要把三張圖片排成一列,所以一定得要縮小圖片,因此在圖片上按滑鼠右鍵,點選快顯功能表的「位置和大小」。


步驟五:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

在「位置與大小」標籤內,把「大小」這一區的「調整」勾選起來,然後「寬度」改為9公分。由於已經勾選「調整」,「高度」會跟著「寬度」等比例縮放。(唉!這裡的翻譯讓人更難懂!)

〔補充說明〕

縮放圖片也可以在選取圖片之後,直接拖曳上面的節點。如果同時按住 Shift 鍵,就可按照等比例縮放。只是用拖曳的方法不容易把所有的圖片都設定為同樣的大小,因此改用指定數值的方式來做比較好。至於以拖曳進行縮放的方式並不難,且為了節省篇幅,在此就省略不談。


步驟六:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

接著我們要為圖片加上框線。在圖片仍舊是被選取的狀態下,按「圖片」工具列的「線條」鈕。
 

步驟七:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

在「線條」標籤內,「樣式」選擇「連續」;「顏色」改為「藍灰色」;「寬度」是「0.15」公分;右下角的「角樣式」,則選擇「斜接」。全部設定完畢後,按一下「確定」。


步驟八:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

用相同的方式,把想放進來的圖片全加進來,需要設定外框線者全設成一樣,並調整好圖片的位置。

接著,按一下繪圖工具列的「文字」鈕。


步驟九:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

拖曳出文字框並輸入所需的文字,接著把文字選取起來(或點選文字方框),在文字格式化工具列上,「字型大小」設為 36 級字並加上「粗體」,最後「字型顏色」改為「白色」。


步驟十:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

拖曳綠色的節點調整好文字框的大小,並把它移到最右邊,讓文字框與投影片的右邊界對齊。


步驟十一:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

這樣子的畫面不但賞心悅目,且更能點出主題之所在。

使用圖片時,要特別注意文字與圖片的閱讀動線,如果安排的不好,觀眾就得費心去尋找重點。通常,橫向文字的閱讀動線是「Z」字形,進行圖文的版面安排時,不妨多試試這個原則。

最後要提醒大家,除非圖片是自己生產的,否則使用圖片一定要注意授權問題。如果獲得合法授權,也別忘了和授權人之間的使用協議,該加入的相關資訊,可千萬別忘了。


全版面的圖和文字的搭配

在單一投影片內用多張圖片,也不見得全是好事,這道理和文字用很多一樣,只是投影片的面積有限,產生的問題不像文字那麼嚴重而已。其次,要找到多張合用的圖片,老實說,不是想像中那麼容易的事。

這時可以考慮另一個不錯的方式,就是選用一張能涵蓋整張投影片的圖(也就是標題所說得全版面的圖),文字則直接加在圖上面。不過,想要採用這種方式,圖片不但要經過細心的挑選,有時還得經過適當的影像處理,例如部份採用單色或透明漸層,預留好文字所需的空間,而加入的文字更要注意精簡程度和外觀設定,否則很容易破壞圖片的美感。講究一點的朋友,連文字都是用影像處理軟體特別設計過,好配合圖片的意境。
 

步驟一:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

加入一張完全空白的投影片,然後按繪圖工具列的「取自檔案」鈕。


步驟二:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

選擇存放圖片的資料夾,點選想要加入的圖片後按「開啟」。


步驟三:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

加入圖片後,調整好圖片的位置和大小(範例的圖已經事先以影像處理軟體調整好尺寸,大小和投影片一樣),接著在投影片以外的空白處按一下,取消圖片的選取狀態。然後在繪圖工具列上按一下「圖說文字」旁的下拉式清單按鈕,從出現的顯單中,點選「圓角矩形圖說文字」。


步驟四:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3) 

在投影片上拖曳出一個「圓角矩形圖說文字」的框。


步驟五:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

表示說明來源的尖角上有個黃色的控制點,拖曳它可改變方向和大小。這裡我們讓它指向圖片上的荷花。

〔補充說明〕

這裡使用圖說文字的用意,除了要使用擬人化的效果,也希望加入的文字會比較清楚明顯。其實,大家也可以利用影像處理軟體製作一張便利貼的影像,放置在全版面的圖上面,在其上加入文字,可營造出「備忘」的效果。


步驟六:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

在「圓角矩形圖說文字」框內按二下滑鼠,即可切換到文字編輯狀態,我們就可以輸入需要的文字內容了。

把這裡的文字分為兩個段落,一來方便把部份文字變得特別大,好強調重點之所在;二來不會因內容太長讓「圓角矩形圖說文字」框變得又扁又長,進而破壞圖片整體構圖的平衡和美感。


步驟七:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

把要強調的重點(本例為10%)加以放大(此處為136級字),其他的文字則設為24級字並加上粗體。最後把所有的文字都設為藍色。

要注意的是,設定好文字大小後,「圓角矩形圖說文字」框要調整一下大小和位置,好配合整體版面的配置。


步驟八:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3) 

透過線條和充填工具列,把外框的線條樣式設為「隱入的」,顏色則改為「黃色3」,最後按一下「平面」鈕。


步驟九:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

切換到「陰影」標籤,勾選「使用陰影」,「間隔」改為「0.2」公分,顏色則設為「白色」。設定好了之後按一下「確定」。


步驟十:

[源碼秘技] 淺談簡報設計的技巧~以 Impress 為例(3)

藉由圖片的意境和超大的文字設定,我們就可以達到強調10%這個數據的效果。

〔補充說明〕

某些朋友可能和 Attila 一樣不擅長處理圖片,此時除了可以請朋友幫忙(幫忙後,別忘記獻上自己的感謝),也可以到某些提供免費授權的圖片網站去下載。當然,這一類的網站提供的圖片數量通常有限,必要時也可到專業的網站去購買合法圖片來用。

或者學一下 Attila,平常出門時,隨手用數位相機拍下所有的美麗事和物(拍人物照,還有隱私和肖像權的問題,通常會被 Attila 省略),以備製作作品的不時之需。

簡報設計的技巧其實很多,這裡所介紹的只是滄海之一粟而已。其實 Attila 最想傳達的理念,是簡報設計一定要把重心放在「凸顯主題」這點。畢竟溝通要講求效果,如果講得天花亂墜,投影片也提供了相關資料,但沒辦法讓自己的想法確實傳達給觀眾,那簡報不就白費力氣了?還不如直接提供相關資料,才不會浪費彼此寶貴的時間。

然而投影片做的好,簡報的內容就會好嗎?Attila 的答案傾向肯定。因為製作投影片時,通常也會仔細思考演講的相關內容,也就是說會針對即將要進行的簡報,加以斟酌和取捨。所以製作投影片的過程,不僅僅只是為了製作出一份簡報檔,同時也是在為自己決定簡報時的口頭內容。只要認真的把投影片設計好,簡報的內容通常也不會差到哪裡啦!

當然,二者之間還是有落差,平時還是要多參考各種演講技巧,並且經常演練,有機會上台時千萬不要害怕,而是要把它當作訓練和檢討的寶貴機會,多多累積經驗,以後才能進行更好、更棒的簡報!


(待續)

推薦訂閱
介紹一個免費資訊與網路新知網站@【網頁研習室【網頁製作系列報導】】
【ACTION! 走讀社區開麥拉】 屏東社區深度旅遊體驗暨短片徵選活動開鑼了!@【藍色東港溪保育協會網路通訊】
自由軟體鑄造場電子報
轉寄『第 136 期 打造三太子:台灣版 Opera 瀏覽器』這期電子報

寄信人暱稱  寄信人email
收信人暱稱  收信人email

  • 社群留言
  • 留言報主