書本電子化是必然的趨勢,但取代不了紙本也是事實。電子書只是提供出版商另一個呈現的管道,而不是零成本的到來,如果是用書本電子化來看這塊市場,也沒什麼未來可言了。筆者為國內某大集團開發 iPad 電子書已好一陣子 (也為不少公司開發過數位化產品),既然電子書的好壞講到快爛掉,筆者就實際一點,提供要 (想) 開發電子書的公司 (Programmer) 一些建議與想法,以下內容僅為筆者對這一塊領域的想法和一些 idea,並不代表該集團已做或想做的產品。
公司應該研發何種 iPad 數位化內容
- 伸觸角用簡易電子書:航空公司旅遊手冊、百貨公司線上型錄、旅行社
- 當公司具有許多線上目錄或線上手冊時,可以考慮將其內容數位化提供使用者免費下載,一般而言,這些手冊沒有版權問題,而檔案內容原本就提供在網路上供人下載,只需開發一個 iPad app 並可達到此目的。通常這類程式具有以下功能:
- PDF viewer:可執行 pdf 檔
- 簡易書本管理:已下載書本排列方式
- 書本自動更新
- 書本可下載清單:根據書本的分類複雜度,Server 必須提供不同程度的修改來配合
- 建議:如果不 care 整個運作的流暢度和閱讀 PDF 的效能,隨便找間有 Objective-C 經驗的工作室外包即可,
- 當公司具有許多線上目錄或線上手冊時,可以考慮將其內容數位化提供使用者免費下載,一般而言,這些手冊沒有版權問題,而檔案內容原本就提供在網路上供人下載,只需開發一個 iPad app 並可達到此目的。通常這類程式具有以下功能:
- 有誠意的簡易電子書:同上
- 伸觸角用的簡易電子書,美其名就是為公司提供另一個行銷或打知名度的管道;但根據筆者的經驗,更多公司願意投入更多的成本來開發一款有誠意的簡易電子書,唯一的目的就是希望使用者能夠享用過程,正所謂燈光美氣氛好質感佳,才容易讓使用者漸入佳境,並帶來實際上的獲利 (or 行銷)。
- 流暢的 PDF viewer:何謂流暢,很難去定義,最簡單的方式就是比下一頁載入的速度,正確呈現 pdf 的 layout,閱讀過程的手勢支援 (單擊、滑動、橫向閱讀),與其它的附屬功能 (閱讀明暗度調整、縮圖、跳頁)。以上功能要做不困難,要做得好就要有點本領了,例如:在有限的記憶體下如何管理 cache 讓頁面載入速度流暢。
- 書本管理:對使用者而言,真正的書本管理,是可以讓他自己建立資料夾或標籤來對這些書本做分類。
- 提醒功能:可以是任何的提醒,利用 Apple Push Notification Service 機制,提供者使用者有書本已更新,或者有新進書籍。
- 支援續傳:在網路微弱的環境下載書本,沒有續傳是一件很痛苦的事,很可惜的是不少 app 不支援續傳功能,這個部分其實只要注意好不要影響過多的效能與 Thread 同步問題,再稍微設計一下用何種方法記錄檔案下載進度,其實不難;也許是客戶(老闆)未主動提起,所以也沒特別花心思去處理這一塊。
- 建議:tune 效能不是一件簡單的事,還是交給專業的來吧,既然都這麼有誠意了就找個可長久合作的夥伴,並且有相關開發經驗的團隊,如此一來可以省下不少冤枉路,也才能真正解決問題。
- 伸觸角用的簡易電子書,美其名就是為公司提供另一個行銷或打知名度的管道;但根據筆者的經驗,更多公司願意投入更多的成本來開發一款有誠意的簡易電子書,唯一的目的就是希望使用者能夠享用過程,正所謂燈光美氣氛好質感佳,才容易讓使用者漸入佳境,並帶來實際上的獲利 (or 行銷)。
- 出版社用的單本電子書:出版社、書商
- 出版社靠賣書吃飯,功能陽春無所謂,但至少閱讀的流暢度要夠。
- 流暢的 PDF viewer:出版社在印刷前通常會有印刷前的 pdf 檔,因為只有單本書,使用者所有的焦點都在閱讀這件事上,基本上閱讀速度要 tune 好,閱讀的整個過程要直觀。
- 進階的附屬功能:keyword 搜尋、橫向雙頁閱讀、bookmark。
- ePub:ePub 最貴重的就是如何排版的 SDK,通常會開發這一塊都是已有現成產品,從頭開始倒也不是不可以,只是這代表不同出版社要是用不同 ePub 格式就代表要重來一次,因此也有些客戶直接捨棄這一塊,一方面省錢,一方面對使用者而言只要可以看就好了。
- 很不想講的 DRM:筆者不覺得 DRM 能有效降低盜版,或提升讀者的購買率,如果今天出版社的雜誌很快就被用暴力法 copy,放在網路上給人下載,我認為大可不必特地搞個 DRM 來降低效能和增加開發時程。DRM 在開發上是一項技術,每家數位出版都有自己的一套,porting 到 iOS 平台需要一些時間,在記憶體有限的情形下不可以暴力硬解 DRM,在閱讀過程中動態解 DRM 會造成一定程度的效能低落,這些問題要克服必須從 DRM decoder 與 PDF Render 下手。這一項目同時也要付出與 PDF viewer 不相上下的成本。
- 建議:通常這一類型的電子書底層是同一個閱讀平台,所以每本電子書基本上會有同樣的閱讀行為,最累的鎖事就是不停的上架每一本書,也許每本書上架成本看似不多,但由於閱讀平台統一,通常不會提供太大彈性的客製化,唯一的缺點就是閱讀平台一但改版,書本就得全部更新 (或者選擇性更新)。
- 出版社靠賣書吃飯,功能陽春無所謂,但至少閱讀的流暢度要夠。
- 出版社用的多本電子書:網路書店平台、出版社、書商
- 很少出版社針對自己的書籍規劃這類型的 app,但我卻認為這個可以做,理由是只要付出開發成本,不用給中介平台抽一層皮,若你是網路書店平台,我則認為更沒有理由不自己開發了。通常書商欲大量投入電子書平台的第一個動作就是找現成的,是因為相較於先花錢再來慢慢回收,與有賺錢再播一些利潤給中介商,寧願選擇後者。
- 功能同出版社用的單本電子書。
- 網路商店 or In App Purchase:不管是何種方式,都必須提供 Server 給使用者完成購買的行為,除非內容為單一產品且一次購買永久服務。
- 書本管理:有付費的 app 功能不能太陽春,否則只會引起一陣咒罵,如不提供自動分類的話,至少也要讓使用者可以手動分類書籍。
- 提醒功能
- 支援續傳
- 建議:
- 客戶:相較於中介商來講,通常願意付出的開發成本較低,只能保祐找到有開發經驗且願意開發的團隊,也許會帶來不少的額外收入。
- 開發團隊:如果沒有相關經驗,通常吃力不討好,只要管理&閱讀、網路商店整合這兩大問題解決就沒啥大問題了。
- 很少出版社針對自己的書籍規劃這類型的 app,但我卻認為這個可以做,理由是只要付出開發成本,不用給中介平台抽一層皮,若你是網路書店平台,我則認為更沒有理由不自己開發了。通常書商欲大量投入電子書平台的第一個動作就是找現成的,是因為相較於先花錢再來慢慢回收,與有賺錢再播一些利潤給中介商,寧願選擇後者。
- 一般雜誌、一般報紙:雜誌出版社、報社
- 這部分有兩種做法,一種是有網路才能用,另一種是整個檔案抓下來看,雜誌和報紙圖文並茂,單檔往往很大,最常見的做法就是每翻下一頁的時候從網路上重新下載,但對使用者而言,其實更喜歡下載一次一勞永逸。
- 雜誌:
- 雜誌分類 & 篩選:至少要根據不同種的雜誌與年份做分類。
- 圖片或 PDF:Online 與 Offline 各有不同做法,Online 必須處理分頁閱讀,Offline 必須處理執行效能。
- 報紙:
- 報紙分類 & 篩選:通勤族最常看報紙,不同族群喜好的版面也不一樣,娛樂版、社會新聞版、政治版,更進一步需要能與內容做結合。
- 圖片或 PDF:基本上我很難想像這是多麼吃記憶體與效能的選項,如果只是想先投入市場再求改善,是可以這麼做,但為求效能,還是先把 PDF 或圖檔的 Content 先做壓縮吧,iPad 不過是一個1024*768解析度、9.7 吋大小的螢幕,圖片畫質不需那麼高。
- 兩者:
- 支援續傳:這點很重要,因為這類型的書籍內容豐富,檔案通常不小,要是不支援大檔續傳,可能客訴電話接不完。
- 單本購買 or 月付制 or 年付制:除了吃喝玩樂相關,或者有重大八掛精彩光碟,我想是不會有人想要單本購買。月付制適合報紙類。年付制適合雜誌,若年付制的雜誌賣得比實體雜誌還貴其實也沒什麼意思。
- 雜誌:
- 建議:雜誌部分通常都找中介平台提供,報社通常都自己找人開發。
- 這部分有兩種做法,一種是有網路才能用,另一種是整個檔案抓下來看,雜誌和報紙圖文並茂,單檔往往很大,最常見的做法就是每翻下一頁的時候從網路上重新下載,但對使用者而言,其實更喜歡下載一次一勞永逸。
- 多媒體互動性內容:內容出版、報社、專業部落客、科技網誌、旅遊網誌、美食網誌
- 這一部分比較難界定,原因是各行各業都有可能踏入這個圈子,只要是 Content Provider,基本上都可以利用這一類型的方式來擴展市場或知名度。
- 為了多媒體:圖片預覽、影片播放、版面 layout。
- 豐富的互動版面:請參考 Wired Magazine on iPad 和 Flipboard for iPad
- 客製化的操作模式:因為不同內容提供者往往希望其操作模式或閱讀模式是有特色的,這樣才有差異化
- 為了品牌:如果不是為了品牌,實在是沒必要踏入這一塊,一個好的 RSS Reader 就能提供很好的閱讀,
- 建議:今天你是內容出版、雜誌出版社、報社,自己有所謂的品牌,所以必須客製化提供讀書一個美好的閱讀經驗(多媒體播放),或者你是為了收費所以提供了這樣的 app 給使用者。否則像是網誌相關其實真的是沒必要自己打造一個這樣的東西,直接交給 app store 上華麗的 RSS Reader 就可以了。
- 這一部分比較難界定,原因是各行各業都有可能踏入這個圈子,只要是 Content Provider,基本上都可以利用這一類型的方式來擴展市場或知名度。
- 基本電子書平台:負責跟出版社抽成的中介商
- 大家都想做電子書,可是真正投入的其實是這一塊,所有的技術中心大概也都集中在這裡。
- 流暢的 PDF viewer:除了前述的功能之外,還需提供額外的附屬功能,例如左右翻頁的設定、不同的檔案格式支援,metadata 管理,不同的翻頁動畫
- 其它功能:bookmark、annotate
- ePub 支援
- 進階書本管理:不同的書本排列與呈現方式,目錄管理 (刪除移動新增),標籤管理,自動分類,搜尋功能
- 必要的 DRM
- 會員管理:為了購買書籍、DRM、Apple Push Notification Service 等功能
- 購書平台:提供與出版社串接
- 建議:找專業團隊開發。
- 大家都想做電子書,可是真正投入的其實是這一塊,所有的技術中心大概也都集中在這裡。
- 購物網站內容數位化
- 不知道各大購物網站是1秒幾十萬上下還是怎樣,都沒人想理這一塊,如果有幸購物網站的主管看到這段文章,請將你們的觸腳伸進 iOS 平台吧。
- 其實這個跟電子書沒什麼關係,只是預告一下近期打算推出的 app,話說好久好久以前的某個下午,一直找不到一個逛購物網站的實用軟體,所以就動手寫了一個 (只是要維護不同網站還滿累人的),後來發現不少朋友都有這個需求,於是和團隊成員討論過後,打算下個階段大家比較有空時,把它改個版上架,我想應該是一個實用又超值的 app : )
開發 iPad 電子書需要哪些能力 (for programmer)
筆者這裡假設開發的是完整電子書平台,不是一般的陽春電子書,針對每種技術提供一個大方向,讓感興趣的人有個依循方向。如果對如果在 iPad 上開發電子書沒興趣的人可直接跳至下一個段落。
- PDF viewer:一個好的閱讀經驗必須經過許多步驟,速度快,每一頁都看得到,再來就是直覺操作。
- iPad 的解析度比較高,而一般電子書的像素沒那麼大,除了 PDF render 之外,還必須做的一件事就是將頁寬(高)縮放至適當比例,才不會留下醜醜的白邊。App Store 上有一部分軟體就是這一部分沒做好,所以有醜醜的白邊。
- PDF 格式有不同的 page box (media box, crop box, bleed box, trim box, art box),media box 是最好處理的,如果只處理 media box,會發現還是有不少的書籍會有醜醜的白邊,或者露出裝訂邊,這就是因為沒有正確 crop box 的緣故 (kCGPDFCropBox)。App Store 上免費的 pdf 軟體僅有少數有處理 crop box,實際上也有少數的付費軟體沒有處理。
- PDF 載入效能:這裡提供一種最常用的方法,Cache 機制,預先載入下一頁內容,並且處理好它們之間的 swap,特別需注意 PDF 在 render 時必須花費很長一段時間 (CGPDFPageGetDrawingTransform) 。App Store 上較多人使用的幾乎都有 cache 機制,但只有少部分有處理好頁面間的切換,最好的測試方式就是快速翻頁
- 支援放大縮小:三種作法,1. 使用UIWebView (比較肥)。2. 使用 UIScrollView (需處理 CATiledLayer)。3. 繼承自UIView,自行處理 scroll。三種作法都有人採用,趕時間用第一種,有一點時間 Tune 效能用第二種,將來有時間改第三種。
- 各式手勢支援:有開發經驗的人都知道手勢支援的愈多,彼此間的衝突就愈大,如果 PDF render 的 View 不是自己實作,而是架構在 UIWebView 或 UIScrollView 上的話,這部分更是明顯,但只要處理的好,其實不會有什麼大問題,如果沒有足夠的經驗,建議還是從最基本的手勢慢慢加。
- 明暗度調整:由於我們無法取用 private api,只好在最上面疊一層 layer 調整 alpha 值。
- thumbnail 支援:絕大部分的電子書都沒有 thumbnail 的 metadata,只要 thread 的 priority 不要調太高,佔用太多 cpu time,動態產生的效能也不會太差。
- 雙頁閱讀:兩種做法,1. 同一個 View 畫兩個 page。2. 兩個 view 分別畫兩個 page。各有其實作上的好處與壞處,通常比較建議選後者。
- 其它功能:搜尋、bookmark、annotate,視階段加入,才不會在效能還沒有 tune 好前,又增加一個瓶頸。
- ePub 支援:
- 不同的出版社會有不同的需求,所以支援 ePub 也是合情合理的,不過這部分通常也是從現有的產品 porting 過來。
- 書本管理:
- 目錄管理:善用原本的目錄結構去管理會比較輕鬆,新增、刪除、移動、重新命名都可以實作一個 Manager 來管理,GoodReader 就是一個很好的範例。App Store 上絕大部分都沒有管理功能。
- 標籤分類:個人認為這是一個很好的功能,簡單設計一下 database 和檔案對應的關係就可以實作,可惜支援的 app 通常其它功能欠缺,而好的 app 通常又不支援。
- 書名搜尋:利用 NSString 的 rangeOfString 最簡單。
- DRM:
- 只要加上 DRM 就會某種程度上降低效能,DRM 通常都是跨平台的 code,但是 porting 到 Objective-C 還是需要點時間,僅記一件事,不要用太多記憶體。
- 如果沒有完整的 DRM 方案,另外一個做法就是弄個 Social DRM (DRM-free)。
- 購書平台:
- 每一家的做法都不一樣,只要能讓出版社在上面賣書就沒什麼問題了,通常這不是我們所該負責的,以筆者的經驗,會接觸到的部分頂多是會員登出登入,一些 API 的 query (抓書單或串流),檔案下載等。
- In App Purchase:如果不想讓使用者跳到網頁進行購買,再回到 app 下載的話,可以選擇讓 Apple 抽三成,所有動作在 app 裡完成。
- 提醒功能:
- 任何你想得到的功能:新書上架,新雜誌上架,會員廣播,優惠訊息,都可以透過 Apple Push Notification Service 提醒使用者。
以上功能是一個電子書平台所需具備的基本功能,大家都大同小異,頂多在畫面的呈現上有不同風格。
筆者理想的 iPad 電子書平台
雖然筆者開發電子書 & 數位內容平台,但還是比較喜歡紙本的感覺,如果說電子書有未來,真正決勝負的是其附加價值。接下來是我的一些想法,好的電子書平台所需具備的功能。
- 流暢的閱讀經驗:
- 支援 pdf、cbz、cbr、epub
- 左翻右翻設定
- 單頁模式、符合頁寬&頁高模式、雙頁模式
- 縮圖、bookmark、annotate、明暗度、快速跳頁、自定手勢翻頁、直行閱讀、頁尾接下一本書(漫畫)
- 支援書本管理、標籤管理
- 支援各式 Server 下載檔案
- annotate 分享功能:同一本書你下的 annotate 會儲存在 server 上,其他讀者可以在同一本書看到你所下的 annotate (kindle 2.5 有提供類似的機制)
- 支援各式微網誌:twitter、facebook、plurk,可以將圈選的片段貼至微網誌上。
- 書評社群:如同 douban anobii 一般,可以透過 ISBN 快速的看到書評,進一步的對書籍的某頁內容做評論
- No DRM
您好,我在大陸工作八年其中有五年是在書業,我最近有個項目需要尋找有經驗的電子書App開發商,不知貴公司的業務範圍是否有承接委外項目開發?我將於9/29返台,如果方便希望能約個時間碰個面,看彼此是否有合作的機會。
我認為您說的大部份都是技術問題,最大的核心沒有講到,就是在電子書平台上,紙本的暢銷書沒有上電子書,原因:授權,如果可以解決電子書APP上有暢銷書,那會吸引大DEQ