Re: AW: [platform-ui-dev] RE: UI Status followup

[Michael Van Meekeren <Michael_Van_Meekeren@xxxxxxxxxx>]

Gunnar, 

Good comments, may I suggest you have
a look at the link provided below (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/dynamic_teams/dynamic_teams.html#preferences)
, many of the items you suggest are on our "idea" list.

/michael

"Gunnar Wagenknecht" <G.Wagenknecht@xxxxxxxxxxxxxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

11/19/2004 12:49 AM

Please respond to
platform-ui-dev

To	<platform-ui-dev@xxxxxxxxxxx>
cc
Subject	AW: [platform-ui-dev] RE: UI Status followup

Full ACK. 
 
Currently a lot pages out in the wild are just copy & paste of existing
pages. There are a lot similar concepts available (FieldEditors, DialogFields
etc.) which should bring a red light flashing. The TabFolders used on a
lot pages were just a better way to "group" the preferences.
I also like the preferences dialog of Firefox. Advanced/expert settings
(like connection settings) are swapped out to a pop up dialog. But the
dialogs do have a similar UI.
 
Having preferences defined in a meta model allows a better mixture of preferences.
Someome could easily create a preference dialog showing only the preferences
that apply to a specific component which might be a subset of different
pages.
 
Another problem is the "inheritance". A lot components still
have their own preferences and even in 3.0 I need to configure multiple
preferences just for getting the line numbers correctly displayed in every
text editor.
 
When I saw the "categories" on the top my first thoughts were
the following in the given order:
- "images are cool"
- "can I add more/other"
- "editing and development overlap"
- "looks heavy and complicated"
 
A power feature would probably be a quick search bar. It could perform
a quick search through localizable preference lables and preverence descriptions
and display the results in the same UI. Complicated settings (like key
bindings) should get their own dialogs and a button in the common preference
UI. IMHO also the "Apply" button is confusing and blowing up
the UI. There are a lot uses which click "Apply" before clicking
"OK" (two clicks where one is suitable). They are arguing that
preferences arn't apply sometimes if you only click on "OK"...
 
Anyway we shouldn't be afraid of the migration issue. It's much more simple
to define prefrences in the PDE editor if the scheme is set up than coding
preference pages. It should be even easier to define dependencies to other
preferences (enabled only if auto-building is on).
 
IMHO it's worth decoupling preferences from their fixed and inflexible
preference pages. I'm volunteering in prototyping :)
 
Cu, Gunnar

                
-----Ursprüngliche Nachricht----- 
                
Von: Ed Burnette [mailto:Ed.Burnette@xxxxxxx] 
                
Gesendet: Do 18.11.2004 21:53 
                
An: platform-ui-dev@xxxxxxxxxxx 
                
Cc: 
                
Betreff: [platform-ui-dev] RE: UI Status followup
                
                

                
Michael suggested I follow up here. The prototype looks pretty busy to
me with navigation across the top, down the left side, and in the content
area in the form of tabs.
                
                
It's always struck me as a usability problem that some preferences pages
are heavily into tabs and some aren't and some use a combination of tab
pages and tree nodes on the left. I know that different components have
different numbers of preferences but this is pretty confusing to even experienced
users. If the preferences dynamic team can straighten all that out it would
be very welcome.
                
                
Two interesting models that I think demonstrate some fresh, good ideas
for preferences UI are the Options dialog in Firefox (http://www.mozilla.org/firefox)
and both the main interface and options dialog of the MySQL Administrator
(http://dev.mysql.com/downloads/administrator).
                
                
I suggest a data-driven approach. You already have the concept of field
editors and preference categories. Go a bit further, and instead of having
preference page designers painstakingly build up an SWT composite by hand,
let us give the preferences UI engine enough info so it could generate
the whole interface on the fly
                
                
For example, look at the Workbench > Search preferences. You have some
boolean options, you have a color option, you have a text option that can
be disabled, and you have an option that takes a value out of a list. This
could all be described in some simple XML. With a few exceptions I'll bet
almost all the preferences could be handled that way.
                
                
You list height/width problems as an issue - dynamically generating the
pages would help address that wouldn't it? There's a bugzilla open for
filtering/searching, and having metadata for all the preferences would
help that too. It would help capabilities as individual options could be
visible or hidden based on the capabilities, not just whole preference
pages. It would help making the presentation of the preferences common
across all plug-ins (rather than everybody doing their own rendering as
currently). It would eventually allow alternate UI presentations for the
preferences (future versions could render it differently, and some RCP
apps might prefer tree representions, some might want to do the whole thing
in Swing, and some might want a long scrollable list, etc.).
                
                
Also it would reduce developer time trying to squeeze in an option in a
preference page here or there, and reduce the opportunities for error cutting
and pasting all the boilerplate get/set/default code that's currently needed.
That's probably why many preferences that exist in the code aren't surfaced
in the UI; it's too much of a pain.
                
                
________________________________
                
                
        From: eclipse-dev-admin@xxxxxxxxxxx [mailto:eclipse-dev-admin@xxxxxxxxxxx]
On Behalf Of Michael Van Meekeren
                
        Sent: Thursday, November 18, 2004 10:50 AM
                
        To: eclipse-dev@xxxxxxxxxxx
                
        Subject: [eclipse-dev] UI Status followup
                
       
                
       
                
                
       
                
        As a followup to the status note about preferences,
a sample image has been linked to the Preferences Dynamic team page.
                
        http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/dynamic_teams/dynamic_teams.html#preferences
                
       
                
        click here to go directly to it, note that
it is just a prototype:
                
        http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/dynamic_teams/pref_snapshot.PNG
                
       
                
       
                
        /michael
                
                
_______________________________________________
                
platform-ui-dev mailing list
                
platform-ui-dev@xxxxxxxxxxx
                
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
                
                
                
                

[attachment "winmail.dat" deleted by Michael Van Meekeren/Ottawa/IBM]