Micro Design Improvements/Watchlist UI
This page is currently a draft.
The top-level navigation of the watchlist includes many options for filtering and editing the watchlist. However, these features are not well organized from a user interaction perspective.
There is no clear information hierarchy. The view changes/view and edit watchlist/edit raw watchlist links are much smaller than the rest of the navigation text and float outside of the main "Watchlist options and notices" box. Within that box, all elements are more or less the same size and are positioned within a very small area of the screen, making it difficult to scan or process.
Toggles and filtersEdit
Watchlist editing/viewing toggles are not called out as such but simply appear as bare links. The view changes/view and edit watchlist/edit raw watchlist links are confusingly named and replicate functionality (both view and edit watchlist and edit raw watchlist essentially serve the same purpose). The purpose of the check boxes next to the namespace filter drop-down is not clear, and it is not obvious that the user needs to click the go button in order for the page to reload with the new filters in place. Filtering by time does not make it clear which units (hour, day all) apply to which link. It is not clear which use-cases each of the hide X edits filters is meant to serve, which are more common, and which are redundant. Many of these options are also replicated in the watchlist tab of user preferences.
There is a mix of different methods of input—links, check boxes, drop-down selection, and button—with no clear rationale for any of these choices. This inconsistency makes the choices presented difficult to process.
Data should be gathered on the usage of the filters and options in the watchlist navigation, to determine what functionality is more important for current watchlist users, and what functionality is not being used. A tentative schema for logging this data can be found here: Schema:WatchlistUsage.
Based on this data, the most heavily used features should be given more visual prominence, and less important features should be de-emphasized, hidden, or removed.
Toggles and filtersEdit
The concept of toggling between the view and edit modes of the watchlist should be more clearly instrumented. Filters should be clearly called out as such and should behave consistently (e.g., either filter the list immediately upon input, or show a clear last step for the user to take to enact the changes).
Consistent input methodsEdit
Consistent input methods should be used, preferably no more than two (e.g., drop-down and toggle).