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 (whitespace, etc.)
• drive the ability/flexibility of the CSS styling for SWT widgets
• identify the major interaction design issues (workbench model) that might block visual design

Current mockup

All mockups are posted in Bug 293481, please cc: on this bug if you want to be alerted of new mockups.

• Iteration 2
  • always shows view and editor icons, but in faded state when not active
  • maintains the overall direction for rounded stacks with shadows, but tightens up corners and shadows
  • simplifies selected tab rendering on active part stack
  • introduces "selection color highlight" to active part stack
  • maintains a stylized toolbar treatment to provide transition from platform trim to custom look, but reduces the shadowing
  • introduces subtle selected tab emphasis in non-active stacks

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
• process for obtaining alternate styles and polling/vote to determine which will ship with SDK

Timetable/approach

• M2 - M3 (Oct-Dec 2009)
  • Design project kick-off
  • 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
    • Eric working on drag/animation for stack moving
    • Susan/Eric - discussion of default workbench model Bug 292789
• M4 (2/26/2010)
  • First prototype of new styling
    • Shows direction of new look, not everything is stylable
    • Post new mockups to compare implementation with intended direction
• EclipseCon (3/22/2010)
  • "new look" available to demo apps / some stylability of new look
  • Show classic look
  • Radical alternative styling?? What will be possible?
• M5 (4/9/2010)
  • Most design details implemented
• M6 (5/21/2010)
  • Focusing on end-user story for tweaking styles/editing

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 (ie, tab background)	Stylized tab/view stack bar	Custom colors, consider gradients	High	Default visual design is complete, implementation in e4 renderer, consider what is exposed through CSS
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	High	previous control in ETabFolder moving into CTabFolder/e4 renderer structure
Tabs	Ability to remove keylines or specify their shape and color color independently for different states	None	High	implemented in e4 renderer, need to define/expose styling capability
View and editor stacks	Visual separation of view stacks without using keylines (drop shadowing?).	Rendered by new CTabFolder	High	implementation complete, may need to expose some styling control
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	Static reduction of emphasis or programmatic fades?	Visual design complete - focusing on static changes	High	Current mockups moving into implementation
Animation/feedback for view stack manipulation	Visuals for stack manipulation are old/outdated. Can we animate or at least modernize? Do we need new cursor icons?		Medium	Implementation of full drag in e4 M4, consider refinements and updated icons for cursor
Perspective Switcher	Look and feel of switcher in e4, location of switcher		Medium	Ongoing discussion in Bug 292789
Shared search bar	Define behavior, then location.	Platform trim supported on Win7, Mac. Need to position it for XP, GTK	Medium	Ongoing discussion in Bug 304440
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	Probably need user control over this. Not everyone wants to give up the real estate to a view toolbar.	Medium	Ongoing discussion in Bug 292792
Multi page editor tab styling	Tab styling for multi-page editors appearing at bottom of e4 editor stack	Rendering should be simpler than main tab case.	Medium	Need mockup
Widget borders	reducing key lines within tab content, etc.	requires changes to client code so we can't assume it would happen	Low	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