Axure完成前端開發可行性探索

曾經有產品經理使用Axure做個人博客,併發布上線。Axure到底有多少潛力?能否可以挑戰更多的開發項目成為直接上線可用的產品?

Axure完成前端开发可行性探索

筆者正好利用2020年超長的春節假期進行一次探索。為什麼會想到要用一款原型工具去做成品?

主要原因是所見即所得的編輯過程,讓那些需要一定時間學習編程才能完成的工作,由普通人來做學習成本幾乎可以不計,而且質量的穩定性更加可靠。如輪播只要簡單設置就好,也無需考慮不同瀏覽器之間的代碼兼容性。其次Axure提供了強大的函數庫,給於了無限可能。

本次的挑戰的工具使用Axure8.0版,項目選擇了作者公司中交互較為複雜的移動端商城裝修功能。此功能讓用戶在PC端通過所見即所得的編輯方式,將移動端常見的展示效果,像搭積木一樣,組合設置成為用戶需要的移動端商城的樣式。(如下圖:左邊,裝修組件選擇區。中間,實際效果預覽區。右邊,組件參數設置區。)

Axure完成前端开发可行性探索

本次挑戰的原型已發佈到作者的線上空間,網址如下:

  • 不帶Axure導航欄原型地址:http://yssycm.com/fituppage/fituppage.html
  • 帶Axure導航欄原型地址:http://yssycm.com/fituppage

探索過程完成的主要功能:

  1. 適用於不同屏幕尺寸的自適應佈局框架。
  2. 裝修組件在預覽區中的實時顯示。
  3. 預覽區指定位置插入新的裝修組件。
  4. 預覽區中刪除已有的裝修組件。
  5. 裝修組件組件在預覽區中位置的上下調整。
  6. 裝修組件的設置變更時在預覽區中的同步。
  7. 公用圖片選擇控件的單選與多選功能。
  8. 公用翻頁控件。
  9. 裝修組件“圖片列表”功能。
  10. 裝修組件“視頻”功能。
  11. 裝修組件“標題”功能。

因時間有限,其它裝修組件的功能暫未提供,但依據筆者的經驗,是可以實現的。如果需要與後臺通訊則要外掛JS文件處理其中的數據。

經過這段時間的探索與試驗,總結下來,Axure可做一些對文件體積不敏感,交互不復雜的項目。如:CMS,個人博客等展示類的產品。如果需要一些複雜的交互,也可以實現,實現的過程中則需要額外注意些事項,有興趣的朋友可以瞭解後面分享給大家的一些探索中的經驗。

Axure做前端開發的優缺點

優點

所見即所得的編輯效果:雖然只有一個優點,但這是很多人的痛點,編程學習的東西很多,從HTML,CSS,JS到放棄,而Axure的工作方式讓前端的工作就像畫畫。

缺點

成品文件冗餘:

以本次項目為例,HTML文件:482KB。JS腳本:855KB(其中jquery庫162KB),CSS文件62KB,頁面數據文件:1270KB。共計2669KB(不含圖片資源)。如果把項目中所有功能做完,HTML文件和頁面數據文件可能會更大,這也許是Axure為了存儲原型描述相關的內容,生產的冗餘。

執行效率低:

主要發生在數據集頻繁大量變更時,會導至頁面明顯卡頓,而Axure的數據集機制也導致容易出現大量的數據操作。所以筆者只能控制一些界面元件的數量,降低實時同步頻率,選擇操作間隙更新數據等方法,讓卡頓感儘量減少。

調試過程繁瑣:

Axure並沒有現成的較好的調試方法,需要規劃一個調試空間,有興趣的朋友可以看後面的單元測試與集成測試介紹。

代碼碎片化:

Axure中所有的代碼都寫在元件上,這個開始沒太在意,但隨著項目的進展,影響越來越大最後導致後面幾乎進行不下去,最後不得不提出Axure偽代碼規範的解決方案。

經過本次探索,筆者認為如果Axure向可視化編程方向努努力,可能會極大的降低前端的開發門檻或改變開發方式。

如何使用Axure完成一些複雜的交互,下面將本次探索的一些經驗分享給大家。

Axure編程中必備的基礎功能實現

變量

實現變量效果的三種方式:

  1. Axure全局變量:利用Axure原生的全局變量功能,這種變量所有頁面共用,可用在跨頁面的數據傳遞上。
  2. 元件文本記錄:利用元件的文本記錄功能,這種方式保存的變量只在當前頁面有效。
  3. 數據集(中繼器):用於存取複雜的數據,可以當作一個小型的數據表用。由於中繼器也是頁面元件,所以只在當前頁面有效。數據集中的數據可以通過文本元件配合篩選獲得或通過篩選配合字符截取完成,筆者推薦前者,因為更直觀簡單易調試。

條件判定

Axure中每一個元件都可以添加條件判定。但用在模擬功能函數上,多選按鈕(checkbox)較為適用,因為選擇狀態可視有利於調試過程。

循環

通過定時切換多選按鈕(checkbox)完成。缺點邏輯嚴謹差一些,需要注意邏輯並行可能的影響。可以使用禁用或鎖定等方式避免影響。

自定義功能函數

通過定時切換多選按鈕(checkbox)完成。由於一個元件上承載的功能有限,所以有時需要多個checkbox組合完成,這種方式我們把他稱為功能函數組。

命名規範

對於複雜的項目,元件多時間命名規範極為重要。否則再次優化,修改無從著手。規範可以幫助我們看名知其意,也有利於在眾多元件中輕鬆找到需要的元件。

編程過程

設計過程

功能設計圖:折分功能,幫助理解流程及流程中各動作的影響範圍。

功能列表:記錄拆分後的功能列表,幫助你實施時更加有條理,應隨著偽代碼的編寫逐步完善。

功能影響列表:記錄功能可能影響到的範圍或用戶可能的非正常操作列表,並給出對應的解決方案(如有必要可編寫解決方案的偽代碼),應隨著偽代碼的編寫逐步完善。

偽代碼編寫

偽代碼是將各元件的協作,用簡練的文字描述出來的方法。因為Axrue中的功能,都是寫在各各獨立的元件上的,非常碎片化,對於複雜一些的功能,編輯不直觀,思維容易被幹擾,後期也不利於梳理和閱讀。本次的項目隨著元件的增加,幾乎到了不可維護的情況。

所以需要避免在元件中盲目操作導致越發混亂,同時對於之後的維護,只需要有對應的偽代碼,便可快速瞭解整個全貌,輕鬆上手,偽代碼需要與命名規範結合使用。(本次使用的Axure偽代碼規範文檔:http://www.yssycm.com/personal/index.php/2020/03/15/axure-pseudocode-specification/)

創建調試環境

調試即是偽代碼的實施的過程,按偽代碼的內容要求,逐一操作創建對應的元件並賦於對應的功能。將需要監視的變量,數據集,功能函數組,分類陳列,方便運行中查看錯誤產生在那。必要時可增加額外功能元件,幫助觸發特定的情況。Axure中的等待命令可以模擬編程調試中的斷點功能,完成調試後可以只隱藏不刪除,便於之後再次修改維護(發佈上線的可以刪除減少一些冗餘)。

單元測試與集成測試

將項目中的功能,依據範圍,目的,拆分為相對獨立的功能模塊,每一個功能模塊在獨立的頁面進行編輯和調試。最後再組裝到一個頁面中。可以快速定位錯誤的位置,同時預覽調試速度也快。

其它相關事項

  • 選擇元件的順序會影響執行順序,如果發生難已理解的錯誤,可以仔細查看下順序。
  • 如果能有一個大的寬屏(2560*1440)的顯示器將極大提高效率與過程的舒適性。
  • Axrue發佈後與預覽時的圖片引用位置是不同的。因為在發佈時會把項目所有用到的圖片進行總和,無論在項目中引用過幾次是否在同一個界面中,最後都只會輸出一張,大家共用,一般是輸出到第一次引用此圖片的頁面資源文件夾中,如果項目中有依賴圖片路徑的操作,記的處理。
  • 引入外部的CSS文件可以擴展Axrue的樣式功能。
  • 引入外部的JS文件可以實現更多的交互或實現原型中的數據與外部系統打通。如果計劃要把數據傳送到後臺,偽代碼設計時就應考慮到。

題圖來自Unsplash,基於CC0協議


分享到:


相關文章: