Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/CSS/Visual Design"
(→Visual Design Items) |
(→Goals) |
||
Line 7: | Line 7: | ||
* drive the ability/flexibility of the CSS styling for SWT widgets | * drive the ability/flexibility of the CSS styling for SWT widgets | ||
* identify the major interaction design issues (workbench model) that might block visual design | * identify the major interaction design issues (workbench model) that might block visual design | ||
+ | |||
+ | == Current mockup (Iteration 1) == | ||
+ | |||
+ | [[Image:e4vis_mockup_1.png]] | ||
== Assumptions == | == Assumptions == |
Revision as of 10:44, 13 January 2010
This page summarizes the investigations into an updated visual design (default stylesheet) for the e4 workbench.
Contents
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
Current mockup (Iteration 1)
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 |
---|---|---|---|
|
|
|
|
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 |
Animation/feedback for view stack manipulation | Visuals for stack manipulation are old/outdated. Can we animate or at least modernize? | Medium | Need to experiment | |
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 |