今天有位某雜誌社的朋友,問我他們家的雜誌好不好看、數位版又如何。他們家的雜誌內容非常紮實,這一點不在話下,小缺點是翻譯稍嫌生硬;但我的答覆是「不好看」,詳細的解釋就是這本文。 一直在做紙本雜誌的人,往往很難跨過跟數位媒體之間的鴻溝。當然,反之也是如此。 雖然兩者都是媒體、甚至是一樣的內容(往往問題就出在這裡),但閱讀方式、體例、節奏、以及延伸思考的方式都不一樣;編輯必須針對這些差異來調整內容,而不是拷貝貼上就行。 隨便舉一個簡單的例子:紙本上經常會出現一段長達十幾行的段落,甚至有書上出現超過一頁的段落。雖然這樣並不是不行,但如果作者(或譯者)掌握段落結構的功力不到家,就會讓讀者因為失去閱讀節奏、或是無法跟上內容邏輯而「讀不下去」。 以這個例子來說,問題有兩個: 1. 段落結構問題 當文字段落很長的時候,通常是因為作者試圖解釋一個道理,而這個道理比較複雜、或是需要用比較多的文字說明;而在「講理」的時候,邏輯是很重要的。 而所謂邏輯,在文字上常用的結構是「因為……,所以……」或是「這樣的原因有三個,第一,……,其次……,最後……」之類的;而在大多數情況下,邏輯結構是可以拆解、或是複合運用的,例如「第一,因為……所以……」。 但這些結構通常都不會太長,在兩三行的篇幅裡就可以解釋完一個小邏輯,然後再由幾個小邏輯組成一個大邏輯;而幾個(個人經驗是三個左右)小邏輯、或是一個大邏輯結構,就可以自成一個段落。 而文字上的邏輯結構,是可以用標點符號、以及句子的長度來控制的。如果作者(包括譯者和編輯,以下同)不擅長這個技巧、或是在處理文字的過程中自己就已經失控,就很容易出現非常冗長的段落。 註:本文中所說的這些問題和技巧,都不是絕對的規則;尤其文學作品有時候為了營造效果或意境,會刻意用引導閱讀、甚至讓讀者迷惑失控的寫法來寫。這類寫作就不在「講理」的範圍之中了。 用我自己的一段文章來舉例。同樣的內容,不同的分段和標點運用方式: 範例1: 舉例來說,有些列為「時間最短」的路線可能要先往反方向搭個幾站,換車之後再走(行車速度較快的?)主要路線,從地圖上看就是明顯的繞一大圈,此外有些app則忽略了換車時的站內行走距離、或是等待時間之類的因素。因為它們計算實用的資料都來自官方、而且也不妨假設計算方法沒錯,所以或許技術上來說算出來的都是最快路線,但在「視覺上一看就是繞遠路」和「懶得走那麼遠」的人性因素影響下,一般人直覺上並不會選這類的路線。但有些app推薦的看起來就比較像是經過人工調校,有些直接剔除了人腦邏輯覺得不太合理的路線,有些則會先推薦「對嘛,應該這樣搭才對」(但技術上或許不是最理想)的路線。 範例2: 舉例來說,有些列為「時間最短」的路線,可能要先往反方向搭個幾站,換車之後再走(行車速度較快的?)主要路線,從地圖上看就是明顯的繞一大圈;此外,有些app則忽略了換車時的站內行走距離、或是等待時間之類的因素。 因為它們計算實用的資料都來自官方、而且也不妨假設計算方法沒錯,所以或許技術上來說,算出來的都是最快路線;但在「視覺上一看就是繞遠路」和「懶得走那麼遠」的人性因素影響下,一般人直覺上並不會選這類的路線。 但有些app推薦的,看起來就比較像是經過人工調校;有些直接剔除了人腦邏輯覺得不太合理的路線,有些則會先推薦「對嘛,應該這樣搭才對」(但技術上或許不是最理想)的路線。 上面兩個範例的文字都一樣,差異只在標點和分段。範例2當然是實際刊登的案例、也是我個人習慣的寫法;您可以用前面說的「大小邏輯」結構來比對一下內容。 另外,有一個非常重要的工具叫做「分號」(;)。 依據我自己的觀察,無論中文或英文的寫作者,會善用分號的人並不多;大多數人都會用逗號(,)和句號(。),沒有問題;技巧再好一點的人會用頓號(、)和冒號(:),但能熟練使用分號的人就不多見了。 分號的地位介於逗號和句號之間,主要功用是(我自己的用法解釋)是: 邏輯還沒講完,但將節奏暫停一下; 作為兩個小邏輯之間的區隔,讓之後的句號結束整個中邏輯;由幾個句號結尾的中邏輯組成一個段落,也就是大邏輯。 圖解一下好了: 《【(因為xxx,所以xxx);(也就是說xxx,由此可知xxx)】。【(然而xxx,假設xxx);(當時xxx,現在xxx)】。》 有點像數學式子了(笑),但大概結構就是這樣: () 包起來的是小邏輯; 【】 包起來的是中邏輯; 《》 包起來的是大邏輯;如果這裡的敘述架構已經完整,就可以自成一個段落。 事實上,包括本文在內,我寫的文章(至少比較後期的)大多都是這種結構的實際案例,您不妨隨意參考幾篇看看。 不過要理解的是,用這種結構來寫文章並不會讓文章內容更好,究竟內容好壞跟結構沒有絕對的關係;但是這會有兩個好處: 同樣的內容會變得比較容易理解;讀者不見得能一眼看出你用了這個架構,但可能會覺得文章變得比較好讀了。 在寫作的過程中,可以時時用來檢討自己的思路、說理是否清楚、推論過程是否缺了哪些東西、在講某一件事情時是不是用了太多廢話、以及講A和B兩件事情的時候,是否有份量不均衡的問題等等。 2. 閱讀載具問題 會分段之所以很重要,除了作者本身頭腦的邏輯訓練、以及表達技巧之外,跟文章載具的改變也有些關係。 在紙本的時代,載具的尺寸(雜誌或書的大小,像是菊八或25K等等)是已知固定的、排版版型是固定的、每行字數是固定的,印出來就不會再動;而且一頁上可以容納的字數也不少,所以長段落在技術上問題不太大。 但到了網路時代,我們很難預測文章會出現在什麼樣的閱讀載具上;可能是不同尺寸的紙本、電腦螢幕、平板、手機上,而且周遭可能還圍著一堆色塊、按鈕、廣告之類無關內容的分心工具。 即使不談前面的邏輯架構問題,一個在書上印出來七八行的段落,或許在紙本讀起來還好,但在電腦螢幕上會變成一大塊,跟旁邊的色塊爭奇鬥艷搶眼球;而在螢幕較小的手機上更糟,可能滑了三個畫面還看不完。 在這種狀況下(而且可能是通勤時站在車上看),能充分閱讀、理解、吸收文字內容的讀者,都是很值得敬佩的。 超長的文字段落(示意圖,與本文提到的刊物無關)。 這並不是說紙本編輯、或是他們原本的方式不好或不對;但在這個跨媒體刊登已經是常態的環境下,光剪貼紙本內容到網站上,可能會是導致「不好看」的原因之一。 而且,由於讀者的閱讀習慣已經改變,現在拿「一段剛好就一頁」的書來讀,恐怕讀到第五行就已經有點迷路了;用功一點的就從頭再來、努力跟上作者的思路,沒那麼用功的人就放一邊表示「我讀過了」、或是大手一揮連掃三個畫面直達結尾收工。 所以,同一份內容要從紙本轉到網路上(或是反過來),還是需要重新編輯、整理、分段嗎? 我認為是的,但或許因為時間成本的關係,很少看到紙媒編輯做這樣的後製處理、知道這些差異的編輯似乎也不太多。 反之,如果是從網路原生文章變成紙本,也會有一些重新編輯的工要做;舉兩個簡單的例子: 段落的整理 以紙本編輯的標準來說,網路文章的段落長度和下標方式難免會有些瑣碎,需要依照文意脈絡重新整理(當然不是看到短段落就併起來)。 在這一點上,日文書(或譯自日文的書)的標準會寬鬆一點,因為日文書原本就會有很多的短段落;如果不是大幅改寫,可以保留的短段落會比較多。 網路和紙本專屬的敘述方式 很多網路原生文章(尤其是早期的部落格)經常會有類似這樣的寫法: ……關於這一點的深入說明,請點按這邊。 萬一有一天這篇文章要印在紙上,連結就不見了,讀者用手指把紙戳到爛也連不出去(如果是電子書可能還可以);此時就得改成像這樣: ……關於這一點的深入說明,請參閱〈蘋果真好吃〉一文(註)。 (註:http://apple.com) 或許現在有些文章還會附個QR Code,讓讀者用手機掃瞄之類的。 如果紙本編輯處理到這類寫法的文章,作者又剛好很佛心,一篇文章用了二三十個「請點按這邊」來補充資料,編輯應該會很想跳樓;不過一來佛心作者不是那麼多、二來有概念的網站編輯也會改寫一下這個,所以現在應該比早期好多了。 (廣告一下:我在做〈程天縱的經營學〉這本書的網站原生文章編輯時,就已經預期之後會出書,所以在編輯時就是以紙本的方式改寫;所以後來的編輯應該沒有跳樓。) 反過來說,有些媒體在將紙本文章轉到電子載具上時,也沒有(或是懶得、或是不知道怎麼做)做這些工作,只是把原稿轉上網頁,導致讀者會看到這樣的編排: ……關於這一點的深入說明,請參閱〈蘋果真好吃〉一文(註1)。但我們知道(註2)……所以(註3)……,於是假柏斯認為(註4)……(註5)……(註6)……。 (中間相隔15個畫面,而且註解都沒有連結) (註1)…… (註2)…… (註3)…… (註4)…… (註5)…… (註6)…… …………………… 這在紙本上是理所當然的事情,但在電子載具上就非常不理想。 但因為這種改編作業非常繁瑣(我自己曾經花超過8個小時,處理某本書上超過400條這種註釋連結),而且大部分讀者不會注意到(紙本書會認真看註解的讀者也不多了),所以會實際去做的編輯很少。 回到一開頭的地方。 朋友家的這份雜誌(也包括許多從紙媒移植到網路上的內容),或許因為編輯本身的工作時間限制、對於「是否值得花這個心思」的權衡、或者對紙本和數位編輯差異的理解,所以在段落結構和網路體例轉換上,並沒有花明顯的心思。 所以,即使內容是紮實的,但對於目標讀者來說(至少對我這個目標讀者來說)是「不好看」的。或者換個方式說,菜是好吃的,但擺盤有問題;用商品的角度來形容,就是「presentation」(展示/展現方式)可能有待改進。 但這些細節,編輯一般來說是不太會注意到的;對於原本就好的內容,這一點會有點可惜。所以也希望本文對於這些編輯們能有些幫助。 附記 我一直記得自己好像寫過類似這個題材的文章,但找不到了;所以就再寫一次吧,應該沒人會在意才是。 我給這位朋友的建議,也提到了針對目標讀者的字體大小和版型設定等等;不過這個部分太過「常識」,也不一定適用於其他人,所以這邊就不提了。