axure命令行_Axure完成前端开发可行性探索
目錄
1 序言
2 編程的必要基礎
2.1 變量
2.2 條件判定
2.3 循環
2.4 自定義功能函數
3 命名規范
4 編程過程
4.1 設計過程
4.2 偽代碼編寫
4.3 創建調試環境
4.4 單元測試與集成測試
5 其它事項
曾經有產品經理使用Axure做個人博客,并在線上發布。Axure到底有多少潛力?能否可以挑戰更多的開發項目成為直接上線可用的產品?
筆者正好利用2020年超長的春節假期進行一次探索。為什么會想到要用一款原型工具去做成品?主要原因是所見即所得的編輯過程,讓那些需要一定時間學習編程才能完成的工作,由普通人來做學習成本幾乎可以不計,而且質量的穩定性更加可靠。如輪播只要簡單設置就好,也無需考慮不同瀏覽器之間的代碼兼容性。其次Axure提供了強大的函數庫,給于了無限可能。
本次的挑戰的工具使用Axure8.0版。項目選擇了作者公司中交互較為復雜的移動端商城裝修功能。此功能讓用戶在PC端通過所見即所得的編輯方式,將移動端常見的展示效果,像搭積木一樣,組合設置成為用戶需要的移動端商城的樣式。(如下圖:左邊,裝修組件選擇區。中間,實際效果預覽區。右邊,組件參數設置區。)原型效果圖
本次挑戰的原型已發布到作者的線上空間。網址如下:
探索過程完成的主要功能:
1. 適用于不同屏幕尺寸的自適應布局框架。
2. 裝修組件在預覽區中的實時顯示。
3. 預覽區指定位置插入新的裝修組件。
4. 預覽區中刪除已有的裝修組件。
5. 裝修組件組件在預覽區中位置的上下調整。
6. 裝修組件的設置變更時在預覽區中的同步。
7. 公用圖片選擇控件的單選與多選功能。
8. 公用翻頁控件。
9. 裝修組件“圖片列表”功能。
10. 裝修組件“視頻”功能。
11. 裝修組件“標題”功能。
因時間有限,其它裝修組件的功能暫未提供,但依據筆者的經驗,是可以實現的。如果需要與后臺通訊則要外掛JS文件處理其中的數據。
經過這段時間的探索與試驗,總結下來,Axure可做一些對文件體積不敏感,交互不復雜的項目。如:CMS,個人博客等展示類的產品。如果需要一些復雜的交互,也可以實現,實現的過程中則需要額外注意些事項,有興趣的朋友可以了解后面分享給大家的一些探索中的經驗。
總結一下用Axure做前端開發的優缺點:
優點:
l 所見即所得的編輯效果。
雖然只有一個優點,但這是很多人的痛點,編程學習的東西很多,從HTML,CSS, JS到放棄。而Axure的工作方式讓前端的工作就像畫畫。
缺點:
l 成品文件冗余。
以本次項目為例,HTML文件:482KB。JS腳本:855KB(其中jquery庫162KB),CSS文件62KB,頁面數據文件:1270KB。共計2669KB(不含圖片資源)。如果把項目中所有功能做完,HTML文件和頁面數據文件可能會更大。這也許是Axure為了存儲原型描述相關的內容,生產的冗余。
l 執行效率低。
主要發生在數據集頻繁大量變更時,會導至頁面明顯卡頓。而Axure的數據集機制也導致容易出現大量的數據操作。所以筆者只能控制一些界面元件的數量,降低實時同步頻率,選擇操作間隙更新數據等方法,讓卡頓感盡量減少。
l 調試過程繁瑣。
工具并沒有現成的調試方法,需要規劃一個調試空間。有興趣的朋友可以看后面的單元測試與集成測試介紹。
l 代碼碎片化
Axure中所有的代碼都寫在元件上,這個開始沒太在意,但隨著項目的進展,影響越來越大最后導致后面幾乎進行不下去。最后不得不提出Axure偽代碼規范的解決方案。
經過本次探索,筆者認為如果Axure向可視化編程方向努努力,可能會極大的降低前端的開發門檻或改變開發方式。
如何使用Axure完成一些復雜的交互,下面將本次探索的一些經驗分享給大家。
Axure編程中必備的基礎功能實現
變量
實現變量效果的三種方式
1. Axure全局變量:利用Axure原生的全局變量功能,這種變量所有頁面共用,可用在跨頁面的數據傳遞上。
2. 元件文本記錄:利用元件的文本記錄功能,這種方式保存的變量只在當前頁面有效。
3. 數據集(中繼器):用于存取復雜的數據,可以當作一個小型的數據表用。由于中繼器也是頁面元件,所以只在當前頁面有效。數據集中的數據可以通過文本元件配合篩選獲得或通過篩選配合字符截取完成,筆者推薦前者,因為更直觀簡單易調試。
條件判定
Axure中每一個元件都可以添加條件判定。但用在模擬功能函數上,多選按鈕(checkbox)較為適用,因為選擇狀態可視有利于調試過程。
循環
通過定時切換多選按鈕(checkbox)完成。缺點邏輯嚴謹差一些,需要注意邏輯并行可能的影響。可以使用禁用或鎖定等方式避免影響。
自定義功能函數
通過定時切換多選按鈕(checkbox)完成。由于一個元件上承載的功能有限,所以有時需要多個checkbox組合完成,這種方式我們把他稱為功能函數組。
命名規范
對于復雜的項目,元件多時間命名規范極為重要。否則再次優化,修改無從著手。規范可以幫助我們看名知其意,也有利于在眾多元件中輕松找到需要的元件。
編程過程
設計過程
功能設計圖:折分功能,幫助理解流程及流程中各動作的影響范圍。
功能列表:記錄拆分后的功能列表,幫助你實施時更加有條理,應隨著偽代碼的編寫逐步完善。
功能影響列表:記錄功能可能影響到的范圍或用戶可能的非正常操作列表,并給出對應的解決方案(如有必要可編寫解決方案的偽代碼),應隨著偽代碼的編寫逐步完善。
偽代碼編寫
偽代碼是將各元件的協作,用簡練的文字描述出來的方法。因為Axrue中的功能,都是寫在各各獨立的元件上的,非常碎片化,對于復雜一些的功能,編輯不直觀,思維容易被干擾,后期也不利于梳理和閱讀。本次的項目隨著元件的增加,幾乎到了不可維護的情況。所以需要避免在元件中盲目操作導致越發混亂。同時對于之后的維護,只需要有對應的偽代碼,便可快速了解整個全貌,輕松上手。偽代碼需要與命名規范結合使用。(本次使用的偽代碼規范文檔:http://www.yssycm.com/personal/index.php/2020/03/15/axure-pseudocode-specification/)
創建調試環境
調試即是偽代碼的實施的過程,按偽代碼的內容要求,逐一操作創建對應的元件并賦于對應的功能。
將需要監視的變量,數據集,功能函數組,分類陳列。方便運行中查看錯誤產生在那。必要時可增加額外功能元件,幫助觸發特定的情況。Axure中的等待命令可以模擬編程調試中的斷點功能。完成調試后可以只隱藏不刪除,便于之后再次修改維護(發布上線的可以刪除減少一些冗余)。
單元測試與集成測試
將項目中的功能,依據范圍,目的,拆分為相對獨立的功能模塊,每一個功能模塊在獨立的頁面進行編輯和調試。最后再組裝到一個頁面中。可以快速定位錯誤的位置,同時預覽調試速度也快。
其它相關事項
l 選擇元件的順序會影響執行順序,如果發生難已理解的錯誤,可以仔細查看下順序。
l 如果能有一個大的寬屏(2560*1440)的顯示器將極大提高效率與過程的舒適性。
l Axrue發布后與預覽時的圖片引用位置是不同的。因為在發布時會把項目所有用到的圖片進行總和,無論在項目中引用過幾次是否在同一個界面中,最后都只會輸出一張,大家共用,一般是輸出到第一次引用此圖片的頁面資源文件夾中,如果項目中有依賴圖片路徑的操作,記的處理。
l 引入外部的CSS文件可以擴展Axrue的樣式功能。
l 引入外部的JS文件可以實現更多的交互或實現原型中的數據與外部系統打通。如果計劃要把數據傳送到后臺,偽代碼設計時就應考慮到。
總結
以上是生活随笔為你收集整理的axure命令行_Axure完成前端开发可行性探索的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: catia曲面扫掠命令详解_Catia曲
- 下一篇: 阿尔法蛋机器人tf卡_如父母般陪着你长大