Preference page usability

1. User doesn't find settings
2. User doesn't know of settings
3. Configuration of a feature is spread out on several pages
4. Settings are not directly accessible from where they apply
5. The number of settings is overwhelming
6. Some pages have become very big (lots of tabs)
7. Gap between preference page / property page

• We can't start from scratch. Backward compatibility must be guaranteed. There will always be pages contributed by old plugins. Existing products might not have the time to invest to completely rewrite or restructure their pages. They must be shown as they are, existing API must work
• We want users to experience Eclipse a single integrated environment and might want to hide the component structure (plugins) in which Eclipse is build.structured. But: achieving that requires a lot of effort: Cross-component work is far more difficult and time consuming that single component work.
  

Examples:

CVS label decorators

• Enabling/Disabling label decorators is on Workbench -> Label Declarators
  
• Actual configuration is on the CVS label decorator page
  
• Color and Font decoration is on the Color & Fonts page
  
  

• Label decorators are contributed to platform.ui. platform.ui decides which decorators to enable/disable and therefore hosts the label decorator page. The page has the advantage to give an overview of showing all label decorators but isn't helpful in saying what such a decoration means
  
• All settings for the CVS decorator are CVS specific. Having them in the CVS category makes sense. The problem is that enablement is on another page
• CVS color/font decorations are on the Color/Font page. CVS wants to be a good citizen and uses the existing infrastructure. The advantage is that having that the user can configure the whole color setup at one place, with the (future) possibility to save a color scheme. The disadvantage is that now the CVS decorator page isn't complete: It shows the color in it's preview, but doesn't allow to configure it.
  

Java editor appearance

• Editor font is on the color and font page
  
• Font styles and color for syntax highlighting are on a Java editor sub page
  
  
• Colors of annotations in the text are on the Text editor
  
• More colors on the Java editor appearance page
  

• The color & fonts page has proved to be too general for the editor settings. In the editor there's only one font but many colors and styles.
• Some of the constructs that have colors (e.g. Annotations) have additional settings associated with them: 'Highlight in text'. Breaking that up for the reason of being a good Color & Font page citizen is also not optimal
• Annotations are configured for all editors and therefor not on the Java editor page

Suggested improvements

• Introduce links in preference pages: Place links on preference pages to navigate to related or more general settings.
• Don't force a setting to be only on one page: For example: contribute a color & fonts but still have a color configuration box on the syntax highlighting page. The settings are of course in sync
  
  
  
  
  
• Don't force the preference tree to be complete: Some pages should be allowed to be only be reachable through links or when opened externally: Hide advanced settings: Certain settings are very technical (various buffer sizes) and should be on advanced pages.
• View preferences: No view settings in the global preferences anymore. The view menu should have a 'Preferences...' menu entry
  
  
• Add a new Filter/Search field
• Add browser history controls to allow to go a link backwards
  
  
• When opening a preference page directly from the workbench, hide the navigation tree initially: