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
(Current mockup)
 
(11 intermediate revisions by one other user not shown)
Line 1: Line 1:
This page summarizes the investigations into an updated visual design (default stylesheet) for the e4 workbench.
+
This page summarizes the visual design work done for the Eclipse 4.0 Early Adopter Release.
 +
This is now a historical document.
 +
For information on the current progress on the visual design, please see [[Eclipse4/SDK Visual Design]].
 +
 
 +
Eclipse 4.0 SDK Visual Design
  
 
== Goals ==
 
== Goals ==
Line 9: Line 13:
  
 
== Current mockup  ==
 
== Current mockup  ==
All mockups are posted in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=293481 Bug 293481], please cc: on this bug if you want to be alerted of new mockups.
+
All mockups are posted in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=293481 Bug 293481], please cc: on this bug if you want to be alerted of new mockups. The blocking bugs listed there itemize where the current implementation deviates from the mockup and what work is planned for 1.0.
 +
 
 +
* Current iteration
 +
** tightens up gradient on toolbar
 +
** gradient for selected stack is more similar to toolbar gradient
 +
** background color for window is derived from menu bar colors, with gradients playing off that base
  
* Iteration 2
 
** 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
 
  
 
[[Image:e4vis_mockup_1.png]]
 
[[Image:e4vis_mockup_1.png]]
Line 30: Line 33:
 
* initial design focuses on static visual design
 
* initial design focuses on static visual design
 
** investigate role of animation later
 
** 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=296175 Bug 296175]
 
** Specifying tab shapes and gradients as sprites while still respecting theme hues
 
** Specifying tab shapes using SVG
 
  
 
== Deliverables ==
 
== Deliverables ==
Line 42: Line 39:
 
* process for obtaining alternate styles and polling/vote to determine which will ship with SDK
 
* process for obtaining alternate styles and polling/vote to determine which will ship with SDK
  
== Timetable/approach ==
+
== Milestone plan ==
* M4 - First prototype of new styling
+
* M7/RC0 (6/18/2010)
* M5 - Most design details implemented
+
** Focus on polish, getting closer to mockups.  Blocking bugs on [https://bugs.eclipse.org/bugs/show_bug.cgi?id=293481 Bug 293481] describe specific work.
* M6 - Focusing on end-user story for tweaking styles/editing
+
** Finalize story of user-management of themes
 
+
* M6 (5/21/2010)
{| border="1" cellpadding="2" width="100%"
+
** Implementation work toward mockups
!width="25%"|October 2009
+
* M5 (4/9/2010)
!width="25%"|Nov/Dec 2009
+
** Most major design concepts implemented
!width="25%"|Jan/Feb 2010
+
* M4 (2/26/2010)
!width="25"|Mar/Apr 2010
+
** First prototype of new styling
|-
+
*** Shows direction of new look, not everything is stylable
|
+
*** Post new mockups to compare implementation with intended direction
* Investigate/define implementation constraints  
+
* EclipseCon (3/22/2010)
** Bogdan - explore tab shape definition, border control, Windows 7 implications (if any)
+
** "new look" available to demo apps / some stylability of new look
* Prioritize visual design areas
+
* M2 - M3 (Oct-Dec 2009)
** Susan - work within e4 plat UI team to prioritize focus areas for design exploration
+
** Design project kick-off
|
+
** Investigate/define implementation constraints  
* Visual design explorations
+
** Prioritize visual design areas
** Linda - multiple design explorations with limited constraints
+
** Visual design explorations
** Susan - solicit team response/consensus on alternatives
+
*** Linda - multiple design explorations with limited constraints
** Choose a direction by end of year?  via bug reports, e4 meetings
+
*** Susan - solicit team response/consensus on alternatives
* Interaction design explorations
+
*** Choose a direction by end of year?  via bug reports, e4 meetings
** Susan/Eric - work within e4 team to develop default workbench model [https://bugs.eclipse.org/bugs/show_bug.cgi?id=292789 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 ==
 
== 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.   
+
The following table tracks visual design elements that have been 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.   
  
 
{| border="1" cellpadding="2" width="100%"
 
{| border="1" cellpadding="2" width="100%"
Line 91: Line 73:
 
!width="25%"|Status
 
!width="25%"|Status
 
|-
 
|-
| View stack bar
+
| View stack bar (ie, tab background)
 
| Stylized tab/view stack bar
 
| Stylized tab/view stack bar
| Consider use of gradients across stack bar. 
+
| Custom colors, consider gradients
 
| High
 
| High
| [[Image:Progress.gif]]  
+
| [[Image:Ok_green.gif]]  
 
|-
 
|-
 
| Tabs
 
| Tabs
 
| Custom highlight colors and gradients
 
| Custom highlight colors and gradients
| Need to honor platform hues where the color does not need to be specified.
+
| Still working out what needs to be in platform-specific CSS vs. having a general "platform hue honoring" strategy. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=296175 Bug 296175]
 
| High
 
| High
 
| [[Image:Progress.gif]]  
 
| [[Image:Progress.gif]]  
Line 105: Line 87:
 
| Tabs
 
| Tabs
 
| Specify custom fonts/bolding for normal/selection
 
| Specify custom fonts/bolding for normal/selection
| None - Can be drawn by ETabFolder
+
| None  
 
| High
 
| High
 
| [[Image:Ok_green.gif]]
 
| [[Image:Ok_green.gif]]
 
|-
 
|-
 
| Tabs
 
| Tabs
| Ability to remove keylines or specify their color independently
+
| Ability to remove keylines or specify their shape and color color independently for different states
| None - Can be drawn by ETabFolder
+
| None  
 
| High
 
| High
| [[Image:Question.gif]] can we stylize the tab background area as a whole?
+
| [[Image:Progress.gif]] implemented in e4 renderer, need to define/expose styling capability
 
|-
 
|-
 
| View and editor stacks
 
| View and editor stacks
 
| Visual separation of view stacks without using keylines (drop shadowing?).
 
| Visual separation of view stacks without using keylines (drop shadowing?).
| Need to understand how this is rendered
+
| Rendered by new CTabFolder
 
| High
 
| High
| [[Image:Question.gif]] Requires some hacking/experimentation
+
| [[Image:Ok_green.gif]] implementation complete, may need to expose some styling control
 
|-
 
|-
 
| Toolbar
 
| Toolbar
Line 125: Line 107:
 
| Current assumption: might be limited by platform, can this be rendered efficiently
 
| Current assumption: might be limited by platform, can this be rendered efficiently
 
| High
 
| High
| [[Image:Progress.gif]] Bogdan to investigate rendering vs. images
+
| [[Image:Ok_green.gif]] some refinement of gradient still tbd
 
|-
 
|-
 
| Deemphasize non-active views
 
| Deemphasize non-active views
| Programmatic fades or other reduction of emphasis
+
| Static reduction of emphasis or programmatic fades?
| May instead change drop shadowing or scroll bars, view stack appearance
+
| Visual design complete - focusing on static changes
 
| High
 
| High
| [[Image:Question.gif]] Bogdan to investigate scroll bar removal
+
| [[Image:Ok_green.gif]] Still working implementation details of hover, fonts
 
|-
 
|-
 
| Animation/feedback for view stack manipulation
 
| Animation/feedback for view stack manipulation
| Visuals for stack manipulation are old/outdated.  Can we animate or at least modernize?
+
| Visuals for stack manipulation are old/outdated.  Can we animate or at least modernize?  Do we need new cursor icons?
 
|  
 
|  
 
| Medium
 
| Medium
| [[Image:Question.gif]]  Need to experiment
+
| [[Image:Progress.gif]]  Implementation of full drag in e4 M4, consider refinements and updated icons for cursor
|-
+
| 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
+
| [[Image:Progress.gif]] Ongoing discussion in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=292792 Bug 292792]
+
 
|-
 
|-
 
| Perspective Switcher
 
| Perspective Switcher
Line 149: Line 125:
 
|  
 
|  
 
| Medium
 
| Medium
| [[Image:Progress.gif]] Ongoing discussion in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=292789 Bug 292789]
+
| [[Image:Ok_green.gif]] Needs right alignment.  See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=313775 Bug 313775]
 
|-
 
|-
 
| Shared search bar
 
| Shared search bar
| Should we have a search bar in the platform trim?
+
| Define behavior, then location.
 
| Platform trim supported on Win7, Mac.  Need to position it for XP, GTK
 
| Platform trim supported on Win7, Mac.  Need to position it for XP, GTK
 
| Medium
 
| Medium
| [[Image:Question.gif]]
+
| [[Image:Progress.gif]] Ongoing discussion in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=304440 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
 +
| [[Image:Error.gif]] Not for 1.0 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=292792 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
 +
| [[Image:Ok_green.gif]] Complete
 
|-
 
|-
 
| Widget borders
 
| Widget borders
 
| reducing key lines within tab content, etc.
 
| reducing key lines within tab content, etc.
|
+
| requires changes to client code so we can't assume it would happen
| Medium
+
| Low
| [[Image:Progress.gif]] Bogdan to provide summary of OS limitations
+
| [[Image:Error.gif]] Not for 1.0, no changes to 3.6 parts specific to 4.0 look
 
|-
 
|-
 
| Workbench background
 
| Workbench background
Line 167: Line 155:
 
| ?
 
| ?
 
| Low
 
| Low
| [[Image:Question.gif]]
+
| [[Image:Error.gif]] Not for 1.0 
 
|-
 
|-
 
| Menubar
 
| Menubar
Line 173: Line 161:
 
| Current assumption:  limited by platform
 
| Current assumption:  limited by platform
 
| Low
 
| Low
| [[Image:Progress.gif]]  
+
| [[Image:Error.gif]] Not for 1.0
 
|-
 
|-
 
| Decorations
 
| Decorations
 
| Don't show decorators for 90% case
 
| Don't show decorators for 90% case
 
| would need new graphics for "exception case"
 
| would need new graphics for "exception case"
| ?
+
| Low
| [[Image:Question.gif]]
+
| [[Image:Error.gif]] Not for 1.0
 
|-
 
|-
 
| UI Forms
 
| UI Forms

Latest revision as of 13:44, 11 August 2010

This page summarizes the visual design work done for the Eclipse 4.0 Early Adopter Release. This is now a historical document. For information on the current progress on the visual design, please see Eclipse4/SDK Visual Design.

Eclipse 4.0 SDK Visual Design

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. The blocking bugs listed there itemize where the current implementation deviates from the mockup and what work is planned for 1.0.

  • Current iteration
    • tightens up gradient on toolbar
    • gradient for selected stack is more similar to toolbar gradient
    • background color for window is derived from menu bar colors, with gradients playing off that base


E4vis mockup 1.png

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

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

Milestone plan

  • M7/RC0 (6/18/2010)
    • Focus on polish, getting closer to mockups. Blocking bugs on Bug 293481 describe specific work.
    • Finalize story of user-management of themes
  • M6 (5/21/2010)
    • Implementation work toward mockups
  • M5 (4/9/2010)
    • Most major design concepts implemented
  • 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
  • M2 - M3 (Oct-Dec 2009)
    • Design project kick-off
    • Investigate/define implementation constraints
    • Prioritize visual design areas
    • 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

Visual Design Items

The following table tracks visual design elements that have been 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 Ok green.gif
Tabs Custom highlight colors and gradients Still working out what needs to be in platform-specific CSS vs. having a general "platform hue honoring" strategy. Bug 296175 High Progress.gif
Tabs Specify custom fonts/bolding for normal/selection None High Ok green.gif
Tabs Ability to remove keylines or specify their shape and color color independently for different states None High Progress.gif 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 Ok green.gif 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 Ok green.gif some refinement of gradient still tbd
Deemphasize non-active views Static reduction of emphasis or programmatic fades? Visual design complete - focusing on static changes High Ok green.gif Still working implementation details of hover, fonts
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 Progress.gif 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 Ok green.gif Needs right alignment. See Bug 313775
Shared search bar Define behavior, then location. Platform trim supported on Win7, Mac. Need to position it for XP, GTK Medium Progress.gif 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 Error.gif Not for 1.0 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 Ok green.gif Complete
Widget borders reducing key lines within tab content, etc. requires changes to client code so we can't assume it would happen Low Error.gif Not for 1.0, no changes to 3.6 parts specific to 4.0 look
Workbench background Specify an image as the background for the workbench  ? Low Error.gif Not for 1.0
Menubar Specify transparency or customizable background Current assumption: limited by platform Low Error.gif Not for 1.0
Decorations Don't show decorators for 90% case would need new graphics for "exception case" Low Error.gif Not for 1.0
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 Ok green.gif No work to be done

Back to the top