Ticket #364 (closed Enhancement: fixed)
Improve usability for editing a topic type's View Configuration
Reported by: | JuergeN | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | |
Component: | DeepaMehta Standard Distribution | Version: | 4.0.12 |
Keywords: | Cc: | dgf, Malte, joern, tsc | |
Complexity: | 8 | Area: | GUI / Usability |
Module: |
Description
When creating a new new TopicType? 5 options should be available in DetailsPanel?:
- Name (present)
- URI (present)
- Data Type (present)
- Icon (path to icon - missing)
- Show in Menu (checkbox -missing)
Change History
comment:2 Changed 12 years ago by jri
The topic type's "Icon" and "Add to Create menu" settings *are* editable in the detail panel.
Just reveal the View Configuration topic that is associated to the type. All settings are provided there.
If you need further usage info (in particular for custom icons) please drop a note.
Indeed, that View Configuration thing is not obvious and usability could be improved here.
Do you need further usage info, or aims your request solely at usability?
Thanks for reporting!
comment:3 Changed 12 years ago by JuergeN
Ok, thanks. I did not know that. But indeed I think it would be much better to include all these settings in the details panel of the new TopicType?. I think this is mainly a usability aspect, but if it was easy to solve, it would reduce complexity and hidden aspects a lot.
comment:4 Changed 12 years ago by jri
Yes, usability must be improved here.
But it's not a straight-forward thing, I suppose.
In case of a composite type the detail panel (in Edit mode) is already occupied by the association definition editors. If you look e.g. at the Person type you see a lot of information to edit. Adding the view config settings here would overload the panel.
Some background about the View Configuration concept: DM separates the type definitions (the application's data model and attached logic) from the view configuration. The idea is to encourage the development of a variety of DM clients with their idiosyncratic presentation paradigms. Thus, each client can run the same DM applications but look completely different. One presentation model (= view config type) might rely e.g. on an icon path to render a topic, another one would use shape-name plus color plus size, and yet another text-only client would need no extra presentation model at all. In other words, one DM type can be associated with a number of view config topics (of different types), one for each presentation paradigm.
The view config concept is embodied in DM's Core Service and REST API, e.g. when a client requests a type definition it will receive the corresponding view config data as well.
Regarding the usability aspect it *might* be reasonable to express both aspects in the user interface as well: 1) the separation of model and view, and 2) each type has multiple view config (topics)s. So, from my point of view, it's not too bad to have type topics on one hand, and view config topics on the other, each one with its individual settings panel. Navigation between these two is completely natural within the DM paradigm.
However, you're completely right. For the moment the view config feature is too hidden to be useful (as proven by your original post :-)
I'm wondering if 2 little changes would make a big usability improvement here:
- When a type is in Edit mode: the detail panel could show the links to all associated view topics. Clicking a link would reveal the view config topic (as always) and would enter Edit mode automatically. This would allow for a seemless jump between the type editor and the view config editor.
Currently the view config topic links are displayed generically, that is when the type's detail panel is *not* in Edit mode. This way a cross-topic edit experience is hindered.
- The view config topic links should have a reasonable label, e.g. "View Configuration (DM4 Webclient)". Currently the view config topic's label is rather arbitrary (e.g. sometimes empty, sometimes the icon path).
What do you think?
comment:5 Changed 12 years ago by JuergeN
In short: anything that can improve usability at this point should be done. If you could implement your suggestions in the next release, it would be very helpful to further distribute DM4. Besides all bachground activities on the core and various plugins, UX is still one of the main issues we are not really good at.
comment:6 Changed 12 years ago by jri
Yes, our UX ambition is still higher than the manifestation ;-)
OK, lets realize items 1) and 2) as described above in the upcoming 4.0.13 then.
DM 4.0.13 is scheduled for Dec 4, 2012.
comment:7 Changed 12 years ago by jri
- Complexity changed from 3 to 8
- Summary changed from Options for new TopicType to Improve usability for editing a topic type's View Configuration
After discussion with JuergeN we decided to postpone the View Config usability issue. Instead we want realize the graphical Association Type Editor (#48) for the 4.0.13 release.
comment:9 Changed 12 years ago by JuergeN
At least the labeling of the view config must be changed from "nothing" to something more reasonable for the 4.1 release.
comment:10 Changed 12 years ago by jri
OK, lets improve the view config labeling for 4.1
I intend to provide plugin developers with an additional hook to calculate the label programmatically. If used, this hook will override the normal (user-configurable) labeling rules then.
comment:11 Changed 12 years ago by Jörg Richter
Webclient: labeling of view config topics (#364).
View Configuration topics are labeled "View Configuration".
See ticket 364.
comment:12 Changed 12 years ago by jri
Oh, I just saw the fix is not complete: view config topics created through migrations (e.g. of the standard types) might still have no proper "View Configuration" label.
comment:13 Changed 12 years ago by Jörg Richter
Webclient: fix view config topic labels (#364).
View Configuration topics created through migrations (e.g. of the standard types) have proper label "View Configuration" label.
See ticket 364.
comment:17 Changed 8 years ago by jri
See follow-up #1071