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) |
(→Visual Design Items) |
||
Line 60: | Line 60: | ||
| Shape should be specified in CSS, shouldn't require Java code (ownerdraw). Consider use of sprites/images and prototype the performance. Look for other standards for specifying custom shapes. | | Shape should be specified in CSS, shouldn't require Java code (ownerdraw). Consider use of sprites/images and prototype the performance. Look for other standards for specifying custom shapes. | ||
| High | | High | ||
− | | | + | | [[Image:Progress.gif]] Bogdan investigating SVG as descriptive format for tab shapes. Linda to provide SVG file(s) of previous tab shape designs. |
|- | |- | ||
| Tabs | | Tabs | ||
Line 66: | Line 66: | ||
| An approach using images limits the ability to honor platform themes where the color does not need to be specified. | | An approach using images limits the ability to honor platform themes where the color does not need to be specified. | ||
| High | | High | ||
− | | | + | | [[Image:Progress.gif]] SVG would solve this issue. |
|- | |- | ||
| Tabs | | Tabs | ||
Line 72: | Line 72: | ||
| None - Can be drawn by ETabFolder | | None - Can be drawn by ETabFolder | ||
| High | | High | ||
− | | | + | | [[Image:Ok_green.gif]] |
|- | |- | ||
| Tabs | | Tabs | ||
Line 78: | Line 78: | ||
| None - Can be drawn by ETabFolder | | None - Can be drawn by ETabFolder | ||
| High | | High | ||
− | | | + | | [[Image:Ok_green.gif]] |
|- | |- | ||
| Tabs | | Tabs | ||
Line 84: | Line 84: | ||
| None - Can be drawn by ETabFolder | | None - Can be drawn by ETabFolder | ||
| High | | High | ||
− | | | + | | [[Image:Question.gif]] which borders do we need to control (remove top border without removing tab tops? position of bottom line?) |
|- | |- | ||
| Widget borders | | Widget borders |
Revision as of 15:37, 19 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 (workbench model) that might block visual design
Timetable/approach
- October
- 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
- Investigate/define implementation constraints
- 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
- Visual design explorations
- Dec/Jan/Feb
- Visual design
- 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, etc.)
- Bogdan - implementation/evolution of CSS/SWT styling engine, CTabFolder, etc.
- Interaction design
- Eric/Susan (?) - implementation
- Visual design
- March
- EclipseCon goals
- Show the new design
- Show a "classic" stylesheet based on 3.x
- Show radical alternatives to demonstrate CSS flexibility
- EclipseCon goals
- April
- stabilize design
Interaction Design Ideas
- 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)