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.
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.
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.
- 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:
Query and category visibility
- Empty queries and categories always show when not in Focused mode.
- 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
- 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.
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.
- 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?).
- Project open/closed state should not be included as part of the task context bug 170232.
- 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.
- 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?
- 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.
- 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