Annotations Visual Design View

The purpose of this design view is to establish a coherent visual look and feel to "annotations in the IDE". This document concerns only annotation colors and glyph styles, and is designed to support the Annotations proposal by Miloslav Metelka and the User View on annotations proposal by David Konecny and Gabriel Tichy.

Background

Annotations consist of a background color applied to lines in the source editor of NetBeans accompanied by a glyph or icon in the gutter area of the source editor. Many decisions have already been made about the functionality of the glyphs and annotations.

Goals

System should be simple and robust

Perceptual ability to distinguish colors is limited, especially in light of existing colors of text, so the system needs to stay simple, functioning coherently and not presenting the user with too many choices. A hundred colors is the same as none, because none of them will mean anything.

Legibility and readability

System should maintain legibility and readability, allowing users to read text in the source editor easily.

System should be passive and coherent

Families of colors for annotations should be consistent, sharing characteristics which allow them to stay in the background (passive), and be available as added data, additionally not drawing too much attention to themselves.

Data should not be lost

Whatever additional data is provided by the annotations, there cannot be a loss of existing data. Users need to be able to distinguish between the colors that already exist, and text colors should not change when the background color is applied. Note: colors will appear to shift against a colored background in any case. Care should be taken to minimize perceptual color shift.

Extensibility

System must accommodate growth. Module writers may submit an unlimited number of modules to be included in NetBeans. System must accommodate a reasonable amount of growth, and must be flexible enough not to fall apart as a system when new modules present new colors.

Accessibility

Accessibility is a secondary goal, but an important one. The IDE already supports blind and disabled users through other means, but an attempt should be made in the choices of colors to support color-blind users.

Constraints/ existing conditions

Users can currently change size and style of text
Users can change default colors
Some annotation colors exist in the IDE already. See below.

	Blue background color for a guarded block of code
	Blue text color for indicating Java keywords
	Magenta text color for indicating strings
	Aqua color for source editor bookmarks
	Yellow color for highlight search
	Yellow-orange (or ochre) color for
	Gray text for comments

Table 1. Existing Source Editor colors.

Assumptions

Adequate color space. For the purposes of this design, it is assumed that users have a color monitor, and that monitor is capable of displaying at least 256 colors. Optimum performance will be from a 24 bit color display, making millions of colors available.
Ability to distinguish colors. It is assumed that users will be able to distinguish some colors for this enhancement to be useful. Color blind users will not be able to distinguish the actual hue of some colors.

Methodology

Choices for the palette were made based on the goals listed above. Because readability and legibility of text is dependant on maximum contrast, background colors need to be as light as possible to enhance the difference between text and background color and to make reading possible. Since most of the text is dark (low value) already, some text colors were chosen for change, to enhance that contrast. Since there is a huge amount of value difference in highly saturated colors, colors in the palette were chosen to match each other as closely as possible in value and saturation. This is essential to maintain legibility.

Project specific Proposals:

Create color palette

Use high brightness, low saturation colors. For an explanation of hue, saturation and brightness, and to see test palettes see Color Theory document. The Color Theory document is still under development, and will be available later. Even with this palette, distinguishing between the two yellow colors and the blue colors may still be difficult, but this range had to be maintained to be able to see the "comments" text.

Figure 1. Limited color palette and default multiple annotation color.

Change the default existing colors

Change some existing colors in the Source Editor to make color choices work. The basic color hues have not been changed. Instead, existing text colors have been made darker in value to increase contrast, and the existing highlight colors have been made lighter.

Figure 2. Existing and new colors in the Source Editor.

Provide a means for users to select colors by:

Providing an interface where pre-chosen colors are presented, or
Creating a system of rules and instructions where users can choose colors from existing color palettes. I've created an example of this in the separate document, Choosing Colors.

I favor presenting a limited palette at first, and allowing a number of color choices in a special color chooser. This interface would allow users to mix their own colors if they wish, but will first present a number of safe choices that are available.

Control color proliferation by

Limiting the number of colors available to modules and recycle them when they are used up. This means some colors will be used twice. Not optimum
Create categories of color, and put modules into under a dozen categories

This is not yet worked out, since there is no determination about categories. In a way, having categories share the same colors

Create a default color for multiple annotations

In cases where multiple annotations are present, a default gray color should be used. This avoids disagreement about which color should be used, the most important, or the most recent. Additional information will be available through the glyph.

Choosing colors for annotations.

See separate document, Choosing Colors.

Creating icons for annotations

Icons for annotations should fit within the 16x16 standard of NetBeans explorer icons. However, all attempts should be made to keep the icons within the 13x13 size recommended by the Java Look and Feel Design Guidelines. Icons should have a dominant color in the same hue as the annotation background color used for the annotation. Glyphs should be composed of symbolic shapes, rather than reduced pictures of things. The eye wants to make out differences quickly, and a complicated glyph does not serve this task. This will be especially useful if a module has an abstract or difficult to describe function. A simple circle or square can be learned by the user more easily than a complex shape. The glyph is also accompanied by the highlight color, so there is visual redundancy that doesn't require the design of the icon to carry all the information.

		Blue background color for a guarded block of code, no change.
		New blue text color for indicating Java keywords
		New text color for indicating strings
		New color for source editor bookmarks
		Yellow color for highlight search
		Yellow-orange (or ochre) color for
		Gray text for comments