書本電子化是必然的趨勢，但取代不了紙本也是事實。電子書只是提供出版商另一個呈現的管道，而不是零成本的到來，如果是用書本電子化來看這塊市場，也沒什麼未來可言了。筆者為國內某大集團開發 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
熱門指數: 15% [?]
您好，我在大陸工作八年其中有五年是在書業，我最近有個項目需要尋找有經驗的電子書App開發商，不知貴公司的業務範圍是否有承接委外項目開發？我將於9／29返台，如果方便希望能約個時間碰個面，看彼此是否有合作的機會。
我認為您說的大部份都是技術問題，最大的核心沒有講到，就是在電子書平台上，紙本的暢銷書沒有上電子書，原因：授權，如果可以解決電子書APP上有暢銷書，那會吸引大ＤＥＱ