Difference between revisions of "Mylyn/UI Design"

From Eclipsepedia

Jump to: navigation, search
(Interaction Desgin)
Line 1: Line 1:
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 [http://www.eclipse.org/mylar/bugs.php discussed on bug reports].
This page is used to collect materials related to the design of the Focused UI, Task List and Task Editor.
= Idioms =
= Idioms =
Line 71: Line 71:
== Task Drag & Drop ==
== Task Drag & Drop ==
To come...
Mylyn supports drag & drop of tasks between the Task List, Task Editor and other applications. The following elements of Mylyn's UI can be dragged:
===== Task List =====
===== Task Editor =====
The following elements of Mylyn's UI allow dropping:
===== Task List =====
====== Categories ======
= Visual Design =
= Visual Design =

Revision as of 18:02, 18 January 2008

This page is used to collect materials related to the design of the Focused UI, Task List and Task Editor.



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.

Task Repositories

  • For the common case the user should only need to enter the repository URL and their crednetials. Additional settings are hidden out of the way (in a foldbale section) and should only be needed by expert users.

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


Using links vs. buttons in UI:

Information Design

Guaranteed Visibility

Query and category visibility

  • Empty queries and categories always show when not in Focused mode.

Working sets

  • No container has visibility when not a part of the working set (TODO: change for Archive?)


  • A completed parent task is visible when a subtask has an incoming change or any subtask is still open
  • Incomings of subtasks are propagated to the parent task

Synchronization States

  • The Task List shows only the current difference between what the user has read and what's accurate on the server. This means that a query will show all new hits that have not been read, but that hits that have disappeared from the query will not show (e.g., these could be show with a Synchronize view style minus). This ensures that queries only show matching elements, and not transitional states.

Interaction Desgin

Task Editor Lifecycle

Editors in Eclipse tend to follow the open-save-close lifecycle model (UI Guideline 6.2). Mylyn's Task Editor differs from editors of workspace resources, because it typically shows content that is stored on a server, and not as a resource in the workspace. In order to support a separation between local save and server submission, the Task Editor follws an open-save-submit-close model:

  • open: The offline copy is opened synchronously. If no offline copy exists the task contents are retrieved from the server.
  • save: If the user has made changes, the changes can be saved and the editor put into an outgoing state.
  • submit: Once changes are ready to be shared with others, the outgoing changes can be submitted to the server. The editor then refresh itself with the latest contents from the serrver. This action cannot be undone.
  • close: The editor can be closed with outgoing changes and reopened. Changes can be discarded. If outgoing changes exist locally and on the server the conflict state arises and the user is given options for merging changes.

Task Scheduling

To come, discussion currently on bug 206566

Time Tracking

Mylyn automatically tracks the time spent working on each task in order to assist with planning activities and to provide input to planning tools. The following time tracking mechanism is provided with Mylyn:

  • Time spent actively interacting with the workbench via mouse and cursor events.

The following time tracking mechanisms are outside of the scope of Mylyn, but can be provided by extensions:

  • Time spent actively interacting with the operating system, out of scope due to OS-specific implementatnoi requirements.
  • Total elapsed time spent on a task independent of activity monitoring, out of scope due to UI overhead imposed by the need to support periods of inactivity logged as activity.

Task Drag & Drop

Mylyn supports drag & drop of tasks between the Task List, Task Editor and other applications. The following elements of Mylyn's UI can be dragged:

Task List
Task Editor

The following elements of Mylyn's UI allow dropping:

Task List

Visual Design

Incoming Indication

  • When Focused mode is enabled, incomings do not need to show on their parent containers because the elements with incomings will show due to the Guaranteed Visibility rules. Showing the indicator on both the container and the item results in visual noise. Since Guaranteed Visibility is not supported when Focused mode is off, the typical Eclipse rule of propagating the decorator to the parent needs to apply.
  • Make it easy to scan vertically for incomings by aligning incoming indicators along the side of the view.
  • Arrows direction is conceptual (e.g. incoming points at the item, outgoing way from the item).


  • From 2007 UI Best Practices Working Group Review: Green is a better color than black for the outgoing arrows because it bares less similarity to the Synchronize view overlays, connotes action (there is something outgoing), is positive (you just did some work on this thing) and is consistent with the other places green is used for outgoing (WTP?).

Task Context

  • Project open/closed state should not be included as part of the task context bug 170232.

Focused Views

  • Filters: when focus is applied to a view, all of the other filters for that view should be removed. Filters that correspond to elements that should not participate in selection (e.g. Java import declarations) can be preserved. To make this explicit, the manual filtering facilities should be disabled when focus is enabled.
  • Linking: if the editor selection always causes an element to become interesting, the Link with Editor property should be automatically enabled when a view is focused. Turning off linking is intended to prevent a large scrolling tree from jumping around. However, when a view is focused the amount of content should be sufficiently small to ensure visual stability of the view without the need to suppress linking.

Open Questions

Task List

  • Can we improve on the icon rendering strategy? Currently we custom draw the incoming and activation icon, overlay priority and create composite descriptors for the repository-specific kind. This still leaves problems of excessive indentation on Windows and custom-draw related limitations on Linux.
  • Should there be more consistency between our incoming/outgoing overlays and those of Platform/Team?
  • If we move the active task and working set switcher out, what do we do with the space to the right of Find?
  • What's the best mechanism for providing discoverability of Ctrl+H when using Find?
  • Is the disparity between Platfrom's use of bold and Mylyn's use of bold a problem? Mylyn uses bold to indicate the most relevant information in a view (e.g. active task, landmark element). The Platform uses bold for showing which editors are not visible in tabs.
  • Is the enforcement of a common task icon background a good idea? We currently encourage but to dont enforce.
  • Can our custom drawing of container separators be improved?
  • Should Presentations become a toolbar radio group? If so what's the maximum we should allow? Frequently switching presentations is cumbersome now, but we need to keep extensibility in mind.
  • Which New actions belong on the view toolbar?

Task Repositories

  • How do we support branding without making the UI overly noisy? Current approach is to not allow more than 7x8 overlays for branding. But we might want to include repository favicons.

Working Sets

  • Should Mylyn's aggregate working sets be supported at the Platform UI level? Single-command selection of working sets is valuable when the are frequently switched.
  • How do we improve aggregate working set switching and awareness of contents? It's not uncommon to switch working sets a dozen times a day, which can makes this action more frequent than perspective switching. The current drop-down selector has friction and cannot be used to show status of what's in another working set.


  • What is the policy for when views should be cloned? One use has expressed interest in Task List cloning. bug 151432
  • Which view state is considered transient and not worth restoring when switching tasks? Currently Go Into is in this category.
  • Is removing all viewer filters and forcing linking the right approach for Focused mode? Currently we do this for all but bridge-specific filters specified via extension point, e.g. the Package Declarations filter.
  • Is there a more obvious icon/metaphor for the Focus action?


  • Should split editor state be restored? The workbench does not restore it on startup.
  • Should we allow a scrollable box within a scrollable pane? This complicates interaction but can increase information density, e.g. for the Bugzilla Description section which can blow up the editor.
  • How should we support expansions of an editable area? Can be manual or dynamic. bug 203670

Content providers and filtering

  • 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


  • If a search result has only one match should it open in an editor instead of showing and focusing the Search view? This is the current beahvior for entering a task key/id on the Task Search page.


  • What's the best mechanism for showing progress in a form-based editor? Mylyn current uses the editor tab's icon and does not use the standard for progress indicator. bug 175592
  • Should all non-content actions on form editors be in the header? If not, should content vs. workflow/lifecycle buttons be differentiated? bug 198166


  • Is the UI Legend a good idea? Should it be view specific or more generic?
  • What's the best approach for documenting complex steps in a dialog? (i.e. the Task Repository Properties dialog) bug 195059


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