E4/CSS/Visual Design

This page summarizes the investigations into an updated visual design (default stylesheet) for the e4 workbench.

Goals

• design a modern visual style for e4 that is clearly different than the 3.x design
• reduce visual clutter, more focus on the data, less on the container elements
• investigate design lessons learned from publishing and web
• drive the ability/flexibility of the CSS styling for SWT widgets
• identify the major interaction design issues (workbench model) that might block visual design

Assumptions

• the default design will still honor platform themes with respect to colors and fonts
  • end users still control common fonts and colors through Eclipse preferences and platform theme settings
  • we continue to respect high contrast themes (accessibility)
  • end users may completely reskin the SDK using CSS but should not have to do so for existing preferences
• the design will focus on space, colors, and gradients to help reduce the visual noise
  • tab colors and backgrounds, view backgrounds, reduction of borders
  • investigate overlays to fade non-focus areas
• initial design focuses on static visual design
  • investigate role of animation later

Issues Identified

• How to remain "platform respecting" with respect to theme colors and fonts while still able to style shades and gradients
  • Specifying hue-neutral colors and gradients for backgrounds and borders Bug 296175
  • Specifying tab shapes and gradients as sprites while still respecting theme hues
  • Specifying tab shapes using SVG

Deliverables

• default CSS styling for the Eclipse 4.0 workbench
• demonstrate ability to retain the "classic" look

Timetable/approach

October 2009	Nov/Dec 2009	Jan/Feb 2010	Mar/Apr 2010
Investigate/define implementation constraints Bogdan - explore tab shape definition, border control, Windows 7 implications (if any) Prioritize visual design areas Susan - work within e4 plat UI team to prioritize focus areas for design exploration	Visual design explorations Linda - multiple design explorations with limited constraints Susan - solicit team response/consensus on alternatives Choose a direction by end of year? via bug reports, e4 meetings Interaction design explorations Susan/Eric - work within e4 team to develop default workbench model Bug 292789	Linda/Susan/Bogdan - Iterate (push/pull) on default design Susan - project team consensus, communicate to community Susan/Bogdan - investigate programmatic reduction of clutter (fades, decorator removal, scroll bar removal, etc.) Bogdan - implementation/evolution of CSS/SWT styling engine, CTabFolder, etc. Eric/Susan (?) - working toward default workbench model and other interaction design issues Need to assign an e4 milestone for this	EclipseCon goals Show the new design Show a "classic" stylesheet based on 3.x Show radical alternatives to demonstrate CSS flexibility stabilize design in M5/M6 timeframe

Visual Design Items

The following table tracks visual design elements that are being considered and any constraints that the implementation imposes on the design. Note that the priority listed in the table is related to its impact on the overall visual design. High priority items must have their constraints defined first, while lower priority items can be defined later in the design process without affecting the overall design approach.

Design element	Requirement	Implementation constraints	Priority	Status
View stack bar	Stylized tab/view stack bar	Consider use of gradients across stack bar.	High
Tabs	Custom highlight colors and gradients	Need to honor platform hues where the color does not need to be specified.	High
Tabs	Specify custom fonts/bolding for normal/selection	None - Can be drawn by ETabFolder	High
Tabs	Ability to remove keylines or specify their color independently	None - Can be drawn by ETabFolder	High	can we stylize the tab background area as a whole?
View and editor stacks	Visual separation of view stacks without using keylines (drop shadowing?).	Need to understand how this is rendered	High	Requires some hacking/experimentation
Toolbar	Specify transparency, customizable background, or shadowing to transition between platform themed elements and Eclipse content	Current assumption: might be limited by platform, can this be rendered efficiently	High	Bogdan to investigate rendering vs. images
Deemphasize non-active views	Programmatic fades or other reduction of emphasis	May instead change drop shadowing or scroll bars, view stack appearance	High	Bogdan to investigate scroll bar removal
View and editor toolbars	Consistent location of view and editor toolbars. Consider a local editor toolbar. Consider a static position for view toolbar (always below?). Location of min max controls		Medium	Ongoing discussion in Bug 292792
Perspective Switcher	Look and feel of switcher in e4, location of switcher		Medium	Ongoing discussion in Bug 292789
Shared search bar	Should we have a search bar in the platform trim?	Platform trim supported on Win7, Mac. Need to position it for XP, GTK	Medium
Widget borders	reducing key lines within tab content, etc.		Medium	Bogdan to provide summary of OS limitations
Workbench background	Specify an image as the background for the workbench	?	Low
Menubar	Specify transparency or customizable background	Current assumption: limited by platform	Low
Decorations	Don't show decorators for 90% case	would need new graphics for "exception case"	?
UI Forms	Are there additional requirements for styling ui forms components?	Apps desiring styling control over forms should be encouraged to use web UI technology to achieve this. There will be no more effort applied to styling ui forms.	Low	No work to be done