Resser

Resser 閱見

基於微信小程式的RSS閱讀器開源、美觀、完整

直接拿給微信開放社群寫的稿子來用了涉及娛樂、資訊板塊微信不讓上線，所以只能以這種形式跟大家見面了

延伸閱讀：一場比賽，一窺小程式的有限與無限

What-——-我們開發的是什麼？

我們開發的「Resser 閱見」（以下簡稱「閱見」）是一款基於RSS/ATOM的資訊聚合閱讀小程序，其特點是門檻低，姿態新，聚合度高。

說得太拗口？看圖就懂了?

「閱見」小程式頁面截圖

接觸過RSS的朋友可能會說，「哦，不就是RSS閱讀器嘛，RSS不是已經半死不活了嗎」。的確，「閱見」就是一款基於微信小程式平台的RSS的閱讀器。不過，我們降低了RSS的使用門檻，讓一般用戶能像關注微信公眾號一樣簡單的關注自己喜歡的幾乎所有內容（從微信公眾號、B站到微博等），而高級用戶也能延續RSS的使用習慣玩出各種高階功能。

由於小程序尚在參賽階段，為了評審能第一時間用上最新版本的小程序，我們還未將小程序正式上線，因此很遺憾大家暫時無法體驗到小程序的功能了。

How-——-我們是怎麼從入門到不入土的？

作為在校生，要從繁忙的課程和考試中抽出時間來開發一個完整的小程序，著實不易。能在ddl之前完成這個項目，主要歸功於我們團隊良好的時間規劃和任務安排。身為隊長，我將比賽過程分為備賽、開發、精修三大過程。

備賽過程

對上屆得獎作品分析

既然開發這個小程式的目的是為了參賽，那麼當然要奔著獲獎為終極目標。因此，團隊在4月體驗了去年獲獎的30個小程序，從小程序的介面、操作、新穎程度等方面進行分析。在體驗這些優秀作品的同時，我們也獲益良多。產品中讓我們驚喜的點可以作為之後開發的參考和靈感，產品中使用不暢的地方也為我們提前敲響警鐘。

上屆得獎作品分析（部分）

初步入門

在參賽之前，我們團隊中無一人有小程式開發經驗，但是憑著初生牛犢不怕虎的精神和魄力，我們照著學做小程序-學堂在線-精品中文慕課(mooc)平台上的課程和官方開發文件實現了小程式的初步入門。
當然，學習小程式的發展並不是一個單向的吸收知識的過程，邊學邊做是最好的入門方式。

開發流程

前期規劃

考慮到我們開發小程式的過程也是學習小程式的過程，我們並不清楚某個提出的功能是否能實現。因此，我們先確定了小程式的大體架構，也就是頁面的佈局，每個頁面要實現怎樣的功能，透過什麼方式去實現。透過經驗的累積，再逐步往這個框架中填沙子，這樣便不至於出現「走一步看一步」的窘況。

頁面框架規劃

協同工具

由於團隊規模很小，只由兩人構成，因此使用各種todo工具就顯得殺雞用牛刀了，我們選擇的團隊協作工具是非常質樸而接地氣的——QQ群。

使用QQ群文件佈置任務並儲存資料

在每週我會給團隊佈置任務並要求組員提交任務報告，這種半強迫性質的ddl一定程度上能有效防止組員划水並且增加團隊成員的參與感。
而我身為主開發手，將各種功能分為基礎型、進階型、配置型、魅力型四種類型，使用Markdown編輯器Bear記錄功能的完成進度。

Bear中對各個功能進度的標記

當然，如果是較大型的團隊，則需要更專業的協同工具，這裡推薦Slack和Teambition。

開發工具

雖然在備賽學習過程中看到許多開發者都使用VS Code和JetBrains系列軟體，但我們依舊採用了官方的微信開發者工具，因為微信開發者工具畢竟是微信官方專門為小程式開發的IDE，體驗上來說更原生，也方便從IDE的更新日誌中了解到小程式的最新動向。

更新日誌

但由於微信開發者工具還不夠完善，實際使用過程中出現過幾次問題，這裡一個小技巧就是－－穩定版出問題換Beta版，Beta版出問題換穩定版。

填坑與技巧

1. 微信小程式合法網域校驗：可以使用雲端函數進行反向代理
2. 常用API介面：BAT都有在做NLP的介面、以及url2io的正文擷取介面等等、更多介面提供者如易來源資料等
3. 雲端開發雲端儲存圖片可以直接調用，但載入速度比較慢，建議還是用七牛雲CDN
4. SVG圖片的體積小而且向量圖更清晰

精修過程

這裡的精修，一方面是指對小程式的操作流程中可能存在的Bug進行排查和修復，另一方面是對使用者介面和互動邏輯進行更細緻地精調。

內測排查Bug

在這過程中，我們在校園內開放了內測活動，聆聽不同的聲音，也從這些內測使用者口中得到寶貴的意見和建議。在獲得用戶回饋這一過程中，我們發現用戶特別懶於前往我們提供的回饋網址提交回饋，因此我們在小程式中加入了客服功能，用戶在體驗小程式的過程中遇到任何Bug或是有任何建議都可以不需要離開小程式就能夠回饋給我們。

UI設計

我們也在比賽ddl前一週完成了對小程式Icon的繪製、UI的精調。

圖示

必須先說一下Icon的設計理念，因為完成了Icon的設計後，UI的設計也完成了一半。何出此言呢？因為小程式的介面配色要和Icon呼應，配色確定好了，可不就是完成了一半的設計嘛。

圖示背景色使用Brandeis Blue（布蘭迪斯大學藍，蔚藍色）和Solitude（孤獨藍，淺藍色）。布蘭迪斯大學被稱為全美最年輕的主要研究大學，而布蘭迪斯大學藍也被寄予「年輕」、「實踐」、「應用」的美好寓意。正如同「閱見」這款小程式一樣，年輕又實用。孤獨藍則對應「閱見」小程式的Slogan－看見開放網路未經過濾的樣子，「閱見」希望每個人能作為一個獨立的個體，去客觀看待這個世界。

外形上，圖示由中文漢字和圓弧形背景組成。蔚藍色的圓弧象徵地球（舒適圈內），另一半的淺藍色象徵大氣（舒適區外），「閱見」二字分別位於兩種顏色上，寄予「閱見」能打破回音壁，讓使用者看到更全局的世界的美好願景。

發布之前的收尾工作

對於小程式來說，除了使用者用的了看得到的功能，還有隱藏在功能和介面之下的東西，例如小程式的體積、打開的速度、邊界條件的設定等等，這些是用戶不容易感知的，但無形中又影響著使用者體驗的點。

1. 減少小程式的體積：移除不需要的console.log等測試程式碼、程式碼檔案壓縮、圖片盡量使用SVG格式。
2. 加快小程式的開啟速度：其實在減少小程式的體積的操作裡，就能加快程式的運作速度了，還有就是可以將引用的圖片CDN加速。
3. 邊界條件的設定：所有需要使用者輸入的地方，都需要邊界條件的設定，例如使用者輸入RSS訂閱連結時不小心輸錯成了標題，如果不做邊界條件設定的話，小程式就會request一個不合法的網址，就可能造成小程式崩潰

One-More-Thing-——-上線之後的規劃

說實話，在做這個小程式之前，我一直沒有找到稱心如意的跨平台RSS閱讀器，然後碰巧看到有這麼一場比賽，就想著自己開發一個好用的RSS閱讀器。開發過程中，也研究了許多國內外的類似產品，例如國內的輕芒閱讀、國外的紅板報、Feedly、Inoreader等等。資料查得越多，心就越涼，因為幾乎都是RSS已死的論調。但既然選擇了這個主題，一條路也要走到黑。所以我又去探究RSS沒落的原因，歸納成如下幾點：

1. 訂閱源規格不統一：目前存在的Feed規格有RSS 0.91、1.0、2.0和ATOM等，不同來源輸出的XML格式不同，導致解析困難。
2. 正文獲取困難：越來越多網站為了廣告和引流停止輸出RSS或不輸出正文，傳統的RSS 閱讀器無法正常顯示。
3. 使用門檻高：傳統RSS閱讀器手動輸入連結新增RSS操作麻煩。
4. 無參與感：RSS相當於提供了單向的服務，使用者只能作為資訊的被動接受者，沒有參與感。
5. 平台和內容提供者獲利困難：RSS Feed無法為內容提供者帶來流量和效益，提供者放棄RSS內容輸出，也導致內容平台流失用戶。

說穿了，就是沒有獲利去維持RSS的生態，所以我想，如果能夠解決內容平台和內容提供者的獲利問題，是不是可以給RSS續一秒。

我們計劃採用獲利補貼、競價排名、數據回饋三種方式打通和內容提供者之間的壁壘，實現內容平台與內容提供者互利共贏。

• 獲利補貼：我們計劃在小程式上線並累積一定用戶後，在首頁資訊流和文章內投放廣告。文章內廣告的營收將以一定比例作為該文章內容提供者的補助。即：優質的文章帶來大量流量，廣告投放將流量變現，變現的一部分作為對內容提供者的補貼。
• 競價排名：並且，對於知名度不高的內容提供方，「閱見」可以作為除微信公眾號、網站、今日頭條外另一個平台幫助其推廣。發現頁面每個分類下展示的訂閱源以及搜尋建議將採用競價排名形式，即前3個訂閱源根據用戶訂閱熱度排名，往後的4-10個訂閱源採用競價排名形式，一方面為“閱見”提供營收，一方面也可以增加內容提供方的曝光率。
• 數據回饋：由於「表態」功能的引入，「閱見」可以獲得用戶對特定文章的回饋，我們不希望這些回饋只是作為一個擺設，而希望用戶的回饋能夠達到內容提供方，幫助其提升內容質量，了解使用者的心理。