Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/CSS/Visual Design"

< E4‎ | CSS
(Implementation issues/constraints)
(Goals)
Line 9: Line 9:
 
* drive the ability/flexibility of the CSS styling for SWT widgets
 
* drive the ability/flexibility of the CSS styling for SWT widgets
 
* demonstrate the ability to keep a "classic" look and supply alternate designs
 
* demonstrate the ability to keep a "classic" look and supply alternate designs
 +
* identify the major interaction design issues that might block visual design
  
 
== Visual Design Items ==
 
== Visual Design Items ==

Revision as of 16:02, 5 October 2009

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
  • identify the major interaction design issues that might block visual design

Visual Design Items

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

Interaction Design Items

  • 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)

Implementation issues/constraints

  • 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 UI 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

Timetable/approach

  • 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 focus 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/Eric - 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
      • Eric/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

Back to the top