E4/CSS/Visual Design

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

Goals

The goals of this work are:

design a compelling visual style for e4
- reduce visual noise, focus on the data
- investigate additional breathing space, lessons learned from publishing and web
- sleek/modern
drive the ability/flexibility of the CSS styling for SWT widgets
demonstrate the ability to keep a "classic" look and supply alternate designs

This is currently just a list of ideas (not prioritized or committed).

tabs
- ability to define custom shapes
- custom highlight colors and gradients for tabs
- ability to express a background color for area behind tabs (ie, blank space on right)
- custom fonts/bolding for selection
- ability to remove keylines or specify their color independently
  - remove or color top border without removing tab tops
  - remove, color, or set position of the bottom tab line
reducing key lines between tabs and their content, and within the content
- ability to style separately the color/presence of borders on widgets (per side)
view and editor toolbars
- consider a local editor toolbar (appears in location of current breadcrumb bar)
- appearance of local view toolbars in consistent location below
- appearance/location of min/max view controls
view/editor visuals
- visual separation of view stacks without using keylines (coloring?)
- visual distinction of editor area
perspective switcher
status area
toolbar with customizable background/transparency
ability to specify an image as a workbench background
reduce visual clutter - no need to decorate for the 90% case

Activity based layouts vs. perspectives (default workbench model)
Is there still a single editor area now that we can be more flexible?
"Split editor" interactions
- Today creating a split is same feedback as stack manipulation but it's a different thing
- Toolbar icons for managing split/unsplit (might be useful in "compare" also)

menubar is native
we must assume view/editor content is limited in ability to style
- selection colors are native
- table headings are native
- what control do we have over borders
- different approaches to content
  - native content (explorer, etc.)
  - PDE forms-style content
  - web implementation of content
CTabFolder/ETabFolder
- limited ability to specify shapes in current implementation (anti-aliasing/blending issues)
- ownerdraw model would require Java code to manage custom tab shapes
- can we style it by supplying bitmaps for corners and top/bottom, stretch to fit text content
Programmatic simplication? (revisiting individual icons is costly)
- diminish icons when views lose focus
- compute decorator 90% case and show the exceptions instead
- subtle fades of non-active views

October
- Investigate/define implementation constraints
  - Bogdan - explore tab shape definition, look at state of the art in web toolkits, experimental implementation
- Prioritize visual design areas
  - Susan - work within e4 plat UI team to prioritize visual design areas for design exploration
November
- Visual design explorations
  - Linda - multiple design explorations with limited constraints
  - Susan - solicit team response/consensus on alternatives
  - Choose a direction by end of November
- Interaction design explorations
  - Susan - work within e4 team to develop default workbench assumptions wrt perspectives, activity-based layouts, role of the editor area
Dec/Jan/Feb
- Visual design
  - Linda/Susan/Bogdan - Iterate (push/pull) on default design
  - Susan - project team consensus, communicate to community
  - Bogdan - implementation in styling engine, CTabFolder
- Interaction design
  - Susan - create milestone plan for changes
  - Susan (?) - implementation
March
- EclipseCon goals
  - Show the new design
  - Show a "classic" stylesheet based on 3.x
  - Show radical alternatives to demonstrate CSS flexibility
April
- stabilize design