Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Mylyn/UI Design"

(Questions)
Line 25: Line 25:
  
 
Uses of FilteredTree
 
Uses of FilteredTree
* Should we include it in the Search view?  Should Platform include it for all searches?  [https://bugs.eclipse.org/bugs/show_bug.cgi?id=200411 bug 200411].
+
* Should we include it in the Search view?  Should Platform include it for all searches?  [https://bugs.eclipse.org/bugs/show_bug.cgi?id=200411 bug 200411]
  
 
Content providers
 
Content providers
* The Task List currently has a content provider that supports guaranteed visibility (e.g. the query containing an overdue task will always show).  The task contenxt model captures guaranteed visibilty for landmarks by maintaining a map.  Platform's FilteredTree has a different, and somewhat expensive, mechanism of computing guaranteed visibility for matches and the viewer/filter level.  Can we improve on this disparity?
+
* The Task List currently has a content provider that supports guaranteed visibility (e.g. the query containing an overdue task will always show).  The task contenxt model captures guaranteed visibilty for landmarks by maintaining a map.  Platform's FilteredTree has a different, and somewhat expensive, mechanism of computing guaranteed visibility for matches and the viewer/filter level.  Can we improve on this disparity?[https://bugs.eclipse.org/bugs/show_bug.cgi?id=200411 bug 200411]
 +
 
 +
Forms
 +
* Should all non-content actions on form editors be in the header?  If not, should content vs. workflow/lifecycle buttons be differentiated? [https://bugs.eclipse.org/bugs/show_bug.cgi?id=198166 bug 198166]

Revision as of 21:15, 23 August 2007


This page will be used to collect materials related to the design of Mylar's Focused UI. Please consider adding a screenshot of how you use Mylar to help inform the UI decisions discussed on bug reports.

Idioms

Avoid Hierarchies

While we are always tempted to add hierarchies to the Task List and there is never a lack of requests to do so, this is something that we have to proceed with very carefully because hiearchies are much dramatically more difficult to interact with and use than monocline lists. In general the Mylyn UI design attempts to follow the simpler monocline grouping metaphor over the hierarchical metaphor.

Avoid Preferences

While there is never a shortage of demand for additional preferences, especially from advanced users, each preference that gets added has a significant cost in terms of UI complexity. Preferneces also mask ways in which the tool should change by providing work arounds particular to very specific use cases. We should strive to evolve the UI in a way that meets the use cases proposed by requested preferences in a way that does not overly clutter or add modalities to the UI. Oftentimes this can mean improving on or changing existing functionality instead of adding a preference to accomodate a specific use case. Since figuring out how to do that can require implementation, preferences can be added more liberally to the Sandbox component for the purpose of experimentation.

See "The Question of Preferences" in the following entry for a good discussion: http://ometer.com/free-software-ui.html

References

Using links vs. buttons in UI:

Questions

Uses of FilteredTree

  • Should we include it in the Search view? Should Platform include it for all searches? bug 200411

Content providers

  • The Task List currently has a content provider that supports guaranteed visibility (e.g. the query containing an overdue task will always show). The task contenxt model captures guaranteed visibilty for landmarks by maintaining a map. Platform's FilteredTree has a different, and somewhat expensive, mechanism of computing guaranteed visibility for matches and the viewer/filter level. Can we improve on this disparity?bug 200411

Forms

  • Should all non-content actions on form editors be in the header? If not, should content vs. workflow/lifecycle buttons be differentiated? bug 198166

Back to the top