圖形用戶界面(GUI,或更一般的 UI)重要性的上升不再局限于消費市場。UI 設計正迅速成為整個嵌入式領域產品之間的關鍵差異化因素。只需要 UI 功能而不是引人注目的應用程序正在發展以適應這一趨勢。工業和醫療設備已經將 UI 概念從消費者和移動市場中提取出來,用于下一代設備。
隨著重要性的變化,UI 的開發方式也發生了變化。UI 開發不再是一個只由嵌入式工程師控制的過程;它包括許多不熟悉嵌入式生命周期的利益相關者。協作工作現在包括 UI 設計師和用戶體驗(稱為 UX)設計師以及嵌入式工程師。
團隊中的新角色
這些利益相關者中的每一個不僅帶來了他們自己的專業知識,而且還帶來了通常與嵌入式開發世界不一致的非常不同的開發環境和流程。以下是對每個利益相關者的職責和開發環境的快速回顧:
嵌入式工程師:負責從中間件到嵌入式系統硬件的應用邏輯。嵌入式工程師使用 C/C++ 代碼進行開發,并使用源代碼存儲庫進行協作和保留項目歷史記錄。
UX 設計師:負責定義產品屏幕、UI 流程、高級應用程序邏輯和呈現給用戶的數據。UX 設計師在 Adobe Flash、HTML、Balsamiq Mockups 和類似應用程序中使用草圖、線框、流程圖和 UI 原型。
UI 設計師:定義圖形內容以及屏幕轉換和動畫。UI 設計師通常使用 Adobe Photoshop 和 Illustrator 等工具以及其他圖像編輯器。
除了商定的流程和任務序列化之外,UI 和 UX 設計師都沒有標準的協作方法。UI 和 UX 角色偶爾會結合起來以減少協作挑戰,但這并不能解決缺乏工具來管理開發期間生成的設計工件的問題。
憑借所有這些不同的技能組合和工作環境,協作成為一項艱巨的任務和潛在的生產力殺手。當工程師和平面設計師必須一起工作時,關注點和開發風格的差異可能會導致嚴重的流失。許多公司試圖通過使用單一資源(嵌入式工程師)來管理 UI 來避免這種沖突。此解決方案適用于非常簡單的情況,但不適用于較大的項目,并且如果未滿足時間表,則無法將更多資源應用于 UI 開發。
當一個項目通過單一資源進行序列化時,UI 和 UX 設計師通常在實施階段被邊緣化。設計師為項目貢獻初始圖形內容、圖像和線框,然后在軟件開發人員實施他們的設計時被排除在開發過程之外。這通常會導致所需的用戶體驗與最終產品中交付的內容不匹配。
關注點和工具不同
在 UI 界面的開發和發布過程中,UI/UX 設計人員的關注點可能比嵌入式開發者的關注點更重要,后者往往關注處理器使用、內存占用、代碼架構、可維護性和重用性。UI/UX 設計師更關注可用性、界面一致性、圖形質量和整體用戶體驗。這些擔憂并不總是完全矛盾的。然而,沒有平衡的方法很容易扼殺產品的市場吸引力。
為了平衡這些擔憂,重要的是讓所有利益相關者參與整個開發過程。這說起來容易做起來難,不僅因為不同的技能和關注點,還因為開發環境提供的交叉很少,沒有自然的集成。幾個問題很快就會浮出水面:
使用小部件庫或 C/C++ 開發 GUI 框架會阻止除有經驗的嵌入式工程師之外的任何人進行協作。
UI 和 UX 設計師以及產品營銷人員需要嵌入式工程師的幫助才能對 UI 進行哪怕是微不足道的更改。
使用設計人員熟悉的高級工具會阻止與代碼存儲庫的集成,并且無法提供有關詳細更改或協作和合并能力的有用信息。
在嵌入式項目中,所有開發協作都是通過設計用于處理文本文件的代碼存儲庫完成的,為二進制和專有格式提供最小的回報。
在文本級別查看比較時,將代碼存儲庫與 C 或 XML 文件一起使用并不能展示對 UI 進行微小更改的上下文和后果。
許多非正式工具,如電子郵件、即時消息和 wiki 都被用來嘗試解決這些問題。盡管這些工具提供了某些優勢,但最終它們僅有助于共享有關項目的信息,而不是與項目相關的工件和可交付成果。這些工具無法在 UI 設計和開發級別實現共享和協作,不包括屏幕設計、屏幕轉換、腳本和代碼管理以及測試套件等重要元素。
在規模的另一端,源代碼存儲庫提供了一種正式和結構化的方法來捕獲項目所代表的基本代碼。雖然源代碼存儲庫對于任何大型項目的成功都是必要的,并且已被證明對于軟件工程團隊的協作是成功的,但它們不足以使非軟件開發團隊成員能夠進行協作。作為一個明顯的例子,圖形設計師從源代碼存儲庫中獲得的價值很少。
視覺協作表面
UI 開發與標準嵌入式系統開發有很大不同,因為隨著時間的推移監控 UI 需要一種可視化方法,而不是源代碼差異視圖來完全理解上下文的變化。在編輯器中查看的源代碼更改或 XML 聲明性語言對幫助開發人員完全理解更改的真正后果幾乎沒有幫助(參見圖 1)。當檢查差異的資源不是對源代碼非常了解的嵌入式工程師時,這個問題就會被放大。此外,許多 UI 工具套件涉及代碼生成或關鍵部分的專有二進制組件,因此極難管理。
圖 1:在編輯器中查看源代碼更改或 XML 聲明性語言時,最終用戶幾乎無法完全理解更改的真正后果。
為了解決這個問題,理想的方法是使用一個工具或一組工具,它不僅以可視化的方式公開 UI 特定元素的變化,而且還與嵌入式開發生命周期的主要協作中心、源代碼存儲庫(參見圖 2)。使用可以以任何利益相關者易于理解的級別公開 UI 的每個更改的工具,使所有利益相關者能夠并行工作。允許利益相關者充分協作提供了許多好處,包括及早發現 UI 行為中的問題、縮短產品開發時間以及在最終產品中提供更好的用戶體驗。
圖 2: UI 開發的理想方法是使用一個工具或一組工具,以可視方式公開 UI 特定元素的更改。
Crank Software 的 Storyboard Suite 通過創建一個可供所有利益相關者利用的環境來支持可視化 UI 開發。該工具利用 Eclipse 框架作為 Crank Software 的 Storyboard Designer 的基礎,其中嵌入式工程師可以利用 Eclipse C/C++ 插件。Storyboard 還有助于解決在監控產品內 UI 演變方面的上下文困境。UI 的視覺差異比較編輯器和對文本差異的支持(用于腳本和編程語言)允許所有項目參與者在與他們相關的上下文中查看產品的歷史。使用這樣的工具,UI/UX 開發人員可以通過直接從他們熟悉的工具中導入來快速協作地開發 UI。
審核編輯:郭婷
-
嵌入式
+關注
關注
5082文章
19111瀏覽量
304861 -
C++
+關注
關注
22文章
2108瀏覽量
73627 -
編輯器
+關注
關注
1文章
805瀏覽量
31163
發布評論請先 登錄
相關推薦
評論