做者|陸堯javascript
做爲一名風光攝影師,會拍攝一場壯麗的日出日落是基本功。精力充沛一點的,在日落以後便會繼續守候,期待能有漫天繁星。在這看似簡單的拍攝計劃背後,實踐起來,必定會遇到幾個問題:前端
應該去哪裏拍攝?何時日落?太陽會在哪一個方向落下?星空會在幾點出現?銀河在哪?
這些問題都是初入風光攝影時必然會踩到的坑。java
我是一名風光攝影師,同時又是一名我的開發者,既瞭解攝影師的需求,也能經過技術知足攝影師的需求,「龜斯的風光攝影助手」即是爲了解決這些問題而誕生。git
「龜斯的風光攝影助手」提供了日月時間、月相、銀河起落等信息,還提供了曝光計算、光繪筆、天氣預報和潮汐查詢等實用功能,幫助風光攝影愛好者輕鬆安排拍攝計劃。npm
小程序初版的開發,在知曉雲平臺的支持下,只用了 5 天時間。上線後徹底靠口碑傳播的狀況下,已服務了萬餘名風光攝影師,同時也得到了 2020 年知曉雲最佳創意獎。json
雖然數據上看並不起眼,但對於我來講,確實是不小的鼓勵。那麼這一切是怎麼作到的?小程序
要作到「友好+高效」這一點,須要從功能展示和用戶體驗出發。segmentfault
首先,在設計之初,就要求絕大部分功能在點擊三下之內完成,頁面層級必定不能超過五頁。做爲一個功能聚合的小程序,在剛打開的首頁,便要清晰的展示功能分類,用戶點擊一下便可看到最重要的信息,而不是一股腦把全部東西都扔給用戶,形成屏幕上全是重點以致於用戶不知道哪一個是重點。另外,考慮到戶外拍攝用戶多是戴了手套的,因此功能面板的觸摸區域也設置的很是大,方便操做。後端
第二,有明確的導航。絕大部分小程序都會使用自定義導航欄,此時微信會保留右上角的菜單按鈕可是不會提供統一的返回按鈕,而返回功能剛好又是很是不起眼且容易忘記作的功能。雖然微信官方是支持屏幕右滑退出的,可是這個功能在屏幕上不能漏掉,由於他的滑動交互可能會和頁面操做衝突。好比地圖頁,滑動退出時其實也觸發了地圖的滑動操做,從避免誤操做的角度來講,最好仍是直接將返回鍵放置在屏幕上。api
第三,對於一些相對複雜、須要一點學習成本的功能,直接給出可參閱的簡易教程,而不是採用全屏彈窗、或是步驟教學強迫用戶一步步點擊才能使用。
穩定可靠的服務。這一點不只須要在交互上,也須要從先後端開發的角度來解決問題。做爲一名前端開發者,在幾乎沒有後端支持的狀況下,如何爲用戶提供一個在線服務屬實是個大問題。
首先遇到的困難就是內置圖片太多致使小程序包超過容量限制。若是壓制圖片,畫質損失又很大,所以必須把圖片資源放到了線上。好在知曉雲提供了靜態資源的功能,還能經過 URL 做圖來直接快速獲取想要的圖片尺寸。
第二個困難是在線服務的穩定性。對我來講一整套完整可用的後臺系統搭建以及維護是須要耗費很是大的精力的,而且爲了使服務可以更加快速穩定,每一年購置雲主機的費用也不低,最麻煩的(其實就是懶)是須要本身寫接口。好在知曉雲就提供了一攬子 serverless 解決方案,從前端就可以直接獲取設計好的數據結構,大大節省工做量。
以「機位收藏夾」爲例, 這個功能設計用來給攝影師對機位進行記錄與分享。在這個功能中,包含了數據的新增、刪除、修改、查詢四個基本操做。在頁面結構的搭建時,咱們能夠從用戶的操做順序依次開始。
首先分析咱們的產品操做流程:用戶建立一個地點,即一條數據。建立者能夠本身對這個地點進行編輯或刪除,也能夠將這個地點分享出去。當別人經過分享打開時,點擊收藏這個地點,那麼這條數據就被複制了一份到收藏者的名下,收藏者就能夠在本身的收藏夾看到並修改本身的這條記錄。
明確流程以後,咱們在知曉雲後臺建立一個數據表,並設置好用戶權限。咱們的地點能夠由建立者編輯,可是其餘人只能看(複製這條記錄後才能編輯),因此按照下圖設置好 ACL 權限:
而後咱們根據每條記錄的內容設計好表字段:標題(Title,字符串類型)、多張圖片(Img,數組類型)、地點(Location,geojson 地理座標類型)、出處(Source,字符串類型)、星級(Level,Integer 類型)、其餘信息(Info,字符串類型)、全部者(Owner,number 類型),而後還能根據將來功能的規劃,增長標籤、評論等預留字段。這裏在建立字段時必定要想好,一旦建立好,要更改他的某些屬性就很麻煩了(好比變動數據類型)。
而後咱們開始根據設想來畫頁面、接接口。根據原型圖對頁面的搭建很是簡單,這裏很少展開。在最後的保存按鈕中,對於標題、星級、其餘信息這些普通的字符串、數字字段就能夠直接保存到數據表中,其中有三個字段須要單獨作處理。
一是圖片上傳。咱們須要在知曉雲後臺的「文件」模塊下,新增一個分類「機位」,後續用戶上傳的圖片將會存儲在這裏。
而後根據文檔,只須要幾行核心代碼就能夠封裝好一個批量上傳圖片的公共方法,上傳完成後咱們在數據表中保存圖片的 id 或是 url(使用 uniapp 框架):
第二個就是地理位置。首先咱們要知道國際標準爲 wgs84,而我國的國測局標準爲 gcj02,這兩個座標系在使用時有一個轉換的過程。在小程序中,爲了保證日出日落這種涉及座標的計算的準確性,統一使用了 wgs84 標準,而騰訊地圖的地理座標選擇是 gcj02 的,因此用戶在選擇地點並點擊肯定時,須要轉換成 wgs84(這裏我使用了 coordtransform2 的 npm 包)。能夠在 app.onLaunch 中將這個包直接設爲全局方法,直接經過 this.coordtransform.gcj02towgs84(latitude, longitude) 這種形式使用:
最後,在保存數據時,因爲要存儲的是 geojson 類型,而 javascript 自己沒有這個類型,所以要記得經過知曉雲提供的建立地理位置對象方法進行轉換:
保存成功後咱們在知曉雲後臺就能看到這樣的地理位置數據:
第三就是 Owner 字段。這個字段和建立者 Created_by 字段的區別就在於,當用戶收藏別人的地點後,這個 Owner 就指向看用戶本身,這樣就能區分出這條數據是用戶本身建立的,仍是從別人那邊收藏來的。
有了數據以後,剩下的就很是簡單了,用戶在查看時直接根據 Owner 字段等於當前用戶的 id 查詢他能看到的地點:
在點擊收藏時將這條數據複製,Owner 換成本身的 id 並保存到當前用戶名下便可:
一來二去,經過少許的代碼完成了對一個裂變功能的實現。這中間,咱們利用了知曉雲現成的文件上傳 api、wx.BaaS 方法來訪問和操做數據表,經過對 ACL 的權限設置來保證對數據的權限的控制,徹底不須要任何後端的支持就能作到,把有限的精力更多的放在產品邏輯的實現上,對像我這樣的我的開發者來講是很是友好的。
個人分享就是這些啦,但願思路對你有幫助;也但願你們可以嘗試 serverless 開發這種形式,創造更多極具創意的產品,更好的服務用戶。
做者做爲一名開發者,同時也是一名使用者,能夠更好地站在用戶角度,將「龜斯的風光攝影助手」的功能與用戶體驗作到極致。小程序有很好的視覺效果、功能齊全、操做簡單明瞭,能夠成爲攝影愛好者隨時隨地便能使用的工具。
若是你以爲做者的分享和開發的小程序對你有用,請轉發文章併爲小程序點個贊,給做者更多鼓勵~
知曉雲的初衷,即是經過提供的 Serverless 無服務架構,讓開發者無需掌握繁瑣的後端開發,不用去搭建服務器、完成域名備案,只需專一於業務邏輯的實現,從而又快又省地上線小程序。很榮幸可以在「龜斯的風光攝影助手」開發中提供支持,但願知曉云云服務能持續幫助更多開發者快速將創意落地。
若是你有任何建議和想法,歡迎你在文末留言或向小曉雲私信,咱們將會第一時間向做者傳達你的信息,也歡迎你一塊兒分享「你開發的小程序背後的故事」。