|Perspective UI Design best practices [message #1398067]
||Thu, 10 July 2014 15:00
| David Wynter
Registered: July 2009
I have a RCP based product that has a few perspectives. All of the current perspectives have the typical tree view of objects on the left side, navigation view for canvases under that, using about 25% of the width and the section to the right is tab accessible editors associated with the objects in the tree view on the left. There is also a properties sheet under the editor area.|
Unfortunately the guy who wrote this is now gone and I am a relative novice with RCP.
Now I have to add a new perspective with several forms to be filled in and am unsure how this fits in visually with the typical editor based perspectives. Can someone suggest a UI best practice resource or advice on how these might work together? This doesn't really help https://wiki.eclipse.org/Eclipse4/RCP/Modeled_UI/Best_Practices
And this http://www.modumind.com/eclipse-rcp-best-practices/
is great for structural details but I cannot find best design practices.
A few specific question come to mind.
Here is the context: Current perspectives support editing technical rules, workflows and ETL mapping. These have a tree view of data assets and a separate tree with product assets, where the later are collection of workflows, ETL and rules that manipulate the data assets. The new perspective will support entering data about licencing restrictions associated with the data assets output to particular consumers and billing units associated with data assets that are output to specific consumers.
1. The end users of the new perspective will be different to the current users of the editors etc. They are more likely to expect forms like interfaces to create and update data about billing, licencing etc. Where I currently have the tab based view of open editors should I hide all of these when I switch to the new perspective and have tab based selection for the 5 or 6 forms I need? These are singletons.
2. What is good practice for selecting current objects in the form? A combo to select only and a text field under it to modify the selected object name? Or in-place editing of the name in the combo used to select, with the associated problems of when to save the new value?
3. Should I allow DnD from the current Data Asset tree view onto the forms where the associations between the object being added/updated in the form is to be defined? Or should I use drop down lists to display the Data Asset names for selection?
4. Should I scrap the forms approach and create a tree navigator view for each of my new classes ( billing, licencing, customer etc.) and stick to property sheets for value manipulation to be consistent with the current Perspectives?
Powered by FUDForum
. Page generated in 0.01767 seconds