聽起來您有兩項任務：任務1對對象進行分類，對於一系列對象，用戶在多個維度（屬性）的每一個上爲每個對象分配一個類別（值）。任務2：創建和修改維度和類別。
除了數據建模師，面向對象的程序員和數據庫設計師之外，維度和類別的概念是一個非常難以理解的概念。您應該爲不瞭解類別和維度之間差異的用戶做好準備。但是，用戶通常會理解表，其中每列是一個維度（包含多個類別），每行都是一個對象。儘可能使用表格。
第一個關鍵問題是通過用戶研究來弄清楚程度，任務1和2是整合還是分離。
如果這些任務是集成的，用戶通常不需要太多思考就可以流暢地從一個切換到另一個，那麼一個UI設計就是有一個逐維的表格，但提供一個空白列（或「插入」按鈕）允許用戶添加一個尺寸。列標題具有用戶可以編輯的維度名稱。標題下方是列出該維度類別的空間。每個類別名稱都是可編輯的，並且有一個空白行（或插入按鈕）來添加新類別。在下面是要分類的對象，每個對象在維度的每個列中都有一個下拉列表。
在可用性測試，注意用戶試圖通過點擊一個類別在類別列表中，而不是從下拉列表中選擇要設置對象的類別。使分類列表在視覺上分開以防止出現這種情況。
您可能需要一個按鈕來隱藏/顯示類別列表，因爲這可能會（使用滾動條時甚至）採取了很多的空間。即使任務1和2緊密集成，我認爲您會發現用戶可能希望有時候將類別列表排除在外。
如果您發現任務1和2是分開的，很少一起完成（例如，用戶通常設置其維度，然後對一堆對象進行分類），那麼您最好使用單獨的窗口（或頁面）對於每個任務來說，儘管在它們之間來回導航應該很容易。例如，當用戶可能通常會建立自己的尺寸事先然後很少修改它們，有時用戶會意識到人們需要一個維度的新類別而分類，一個不尋常的對象，所以你提供需要的用戶「添加類」菜單項到「管理類別」窗口，爲當前維插入一個新類別，等待用戶提供名稱。
任務1的窗口與以前相同：包含每個維度的下拉列表列，但排除類別列表，編輯維度名稱以及添加新維度的能力的對象表。如果用戶需要掃描需要分類或重新分類的對象，或者通常用戶需要比較一個對象與其他對象（例如，決定如何對對象進行分類），則這是最有效的。但是，如果用戶的任務是真正限於基於外界的信息在每次只分類對象之一（例如，轉錄從紙張的信息），然後再考慮一個形式，而不是一個表格，顯示的列表框的數組，一個爲每個屬性。通過單擊每個列表框來設置每個類別，這比使用下拉列表更快。
爲任務2的窗口可以像任務之一報頭部分。它與用於任務1的表一致，並允許用戶一次查看多個維度的類別，幫助他們找出最佳的分類方案（例如，幫助他們找到基本上同一類別在兩個不同維度中出現的地方）。但是，如果空間是一個問題，那麼請考慮一個維度列表，每個維度都顯示主從關係中的類別列表。
在用戶功率和任務2靈活性最終是樹狀控制。樹的根級包含維度，層次結構中的下一步包括每個維度內的類別。主要優勢在於它支持尺寸爲，依賴於類別上的。例如，可以具有包括類別如汽車，小船，平面等的車輛類型維度。對於汽車類別，可以具有僅適用於該類別的類別的體型類型（Coupe，Hatchback等）。 ）。相關維度通過分類表示在樹中。結果是樹在每個級別的尺寸和類別之間交替。
重要的是要通過不同的圖標在視覺上區分的類別從維度，也許，也許不同的字體，以及-something告訴用戶層次結構中的交替步驟是質的不同（例如，如果您創建一個維度，然後你應該創建至少兩個類別）。即便如此，如果用戶將維度與類別混淆（例如，允許他們將一些「維度」移動到另一維度下，將前者轉換爲類別），提供一種簡單恢復的方法。
我想再次強調人們對尺寸和類別等抽象的困難。即使他們確實瞭解它，人們通常很難自行創建體面的維度和類別。有些複雜的交互可能會導致需要仔細考慮（例如，當類別移動到新維度時，對象分類會發生什麼？）。如果您希望每個用戶真正創造自己的新穎維度，那麼您可能需要認真重新考慮您的整個方法。這是一項固有的複雜任務。
如果在文化，組織或領域（例如我們的汽車）中已經有相關的多維方案，用戶會做得更好。當然，如果已經有了一個方案，那麼你可以研究它並將其作爲你產品中的一組默認尺寸安裝。任務2只需要被支持以允許專家用戶對其進行微調。
我想你知道標籤，想知道具體的用戶界面，不是嗎？就像在哪裏放置圖片一樣，如何查詢標籤，使用哪些容器等等。 – 2008-11-11 16:09:26