Thanks for mentioning this page @vmassol, very interesting read. See below a
Where the two design pages aligns:
- The need of classes description
- The need for categories for classes. Discussed in a separate proposal, the main difference being that I think we need to be able to have several categories per XClass (e.g.,
Development, Internal).
What was missing in my initial proposal:
- Issues with Nested Spaces, broking the alphabetical listing of the classes. Thought it never felt like an issue when using the picker for me, but I’d like other opinions.
- No highlight of the searched word. I indeed think this is interesting in terms of UX.
What’s not clear to me:
- “No preview for the end result” I’m not sure what kind of preview is expected, an XClass can be used in very various ways and picking one and representing it visually feels difficult
- “No consistency in the way we add different entity types”
New concepts we can postpone:
- “No listing for related classes”. While this feels interesting, in don’t have supporting use cases in mind
What I disagree with:
- “No link to the class documentation” In several other discussions we reach the conclusion that UIs needs to be self-contains and self-explainable, and that linking to external documentation is a maintenance burden and does not work for instances with no internal connection.
- The idea of moving to a modal instead of a picker: nesting modals is a pain and the picker is likely to already be integrated in modals. So I’m in favor of staying with the current picker/dropdown UX
- Displaying the count of classes per-categories. I’m not sure if this brings useful information. Also, it raises the same scaling issues as the other counts when we start taking into account user rights.