This page is based on a discussion of the UI experts and collects a number of suggestions for changing UI development in order to improve quality and meet specifications.
Goals
- make implementing the visual design of the UI less dependent on other development work
- ensure that we can properly plan and track changes requested as a result of larger UI design reviews
- ensure that the UI meets visual and UX design specifications
- ensure that the UI quality increases and avoid that we have to invest into focused efforts in order to achieve that
- ensure that the UI works on all supported browsers and devices
What is missing
Reviews
The following concepts and designs have to be reviewed on a regular basis.
= we already do this;
= we don't (consequently) do this currently
Conceptual design
Feature concepts
- the goals of a new feature or set of functions; the theoretical concept behind the feature; what a user can and cannot do when using a feature
- reviewed by Boris, Philipp and Pascal
- published as concept pages in the UX wiki space
UI designs for new features
- sketches, mockups and interface flows based on the feature concepts that mainly Andreas designs
- reviewed by Boris, Philipp and Pascal
- published as UI design pages on the UX wiki space
Visual designs
- visual designs for new UI elements from the graphics designers
- reviewed by Andreas and Pascal
- published as screens pages in the UX wiki space
Applied design
UI and visual design of missing elements
- The conceptual foundation is clear and defined, but not all interfaces have been designed, e.g. there might be a missing form or even UI element.
UI and visual design implementations
- actual implementations of UI and visual designs by the development team
Testing on platforms
We currently lack regular testing on a number of devices and platforms. In particular, we should test for:
- Support for multiple browsers on desktop systems
- Correctness on tablet devices on the default browser
- Support for right-left locales
How could this be added
= suggested improvements;
= should be changed;
= open questions
Reviews
Conceptual design
While the reviews of the more conceptual work are mostly done, we can still improve them.
- UX design process
How can prevent that we only start discussing it once the first implementation appears? Do we need a one or more formal approval steps here, so that we actually think about and discuss the feature?
Does Andreas have to seek more and earlier reviews and discussions?
We could introduce s separate Kanban board for UX design.
We could even track major UX design initiatives using JIRA and Greenhopper (a JIRA UX project with issues already exists, but I'm hardly using it).
- Feature concepts
-
In the product management team, we should also determine some main stories for the next sprint, so that UX design can start develop the feature concept early enough to trigger a proper discussion. Design teams have to be slightly ahead of development teams in agile development to make sure that development doesn't stall.
-
Applied design
We don't do regular reviews here currently, but they should become regular steps in the development process.
- UI and visual design of missing elements
sketches or mockups are proposed in SPECIFICATION/concept state by a developer or UI expert
published together with the technical concept on a concept page in the DEV wiki space
reviewed in SPECIFICATION/review state by a (different) UI expert
- UI and visual design implementation
reviewed in DEVELOPMENT/review state by the UI experts after implementation
Testing on platforms
In order to not slow down development too much, we should distinguish between testing done during the implementation and proper testing against all required platforms before releases.
Testing during development
We should invest into automated integration testingusing e.g. Selenium.
- TestBench from Vaadin could be another option (it actually uses Selenium).
Mandatory manual testing before integration
- done by the developer
- testing of story implementations on the desktop on a small set of core browser versions
- a current Firefox version
- a current Safari or Chrome version
- an iPad running iOS 6.x
Regular testing before a sprint release
- done by one developer per team of all story implementations of the team on
- IE 9 on Windows 7
- Firefox on Mac OS X 10.8
- Safari on Mac OS X 10.8
- iPad 3 on iOS 6.1
do we also have to test with a set of smoke tests covering various typical flows through the UI?
- done by one developer per team of all story implementations of the team on
System testing for performance problems
- done by team who is responsible for the task
- IE 8 on Windows 7
- iPad 3 on iOS 5.1
- testing with a set of smoke tests
- done by team who is responsible for the task
Testing before a final release
- Systematic testing of a release candidate
- conducted after the sprint leading to a release candidate
- Windows 7
- IE 8
- IE 9
- IE 10
- Firefox 18.0.2
- Chrome 24
- Mac OS X 10.8.2
- Firefox 18.0.2
- Chrome 24
- Safari 6.0.2
- iPad 3
- Safari mobile of iOS 5.1
- Safari mobile of iOS 6.1
- iPad 4
- Safari mobile of iOS 5.1
- Safari mobile of iOS 6.1
- Windows 7
by whom? the support team?
done where? We have VMs for testing on multiple OS (Mironet).
how do we test different language versions?
- conducted after the sprint leading to a release candidate
What should also be improved
= suggested improvements;
= should be changed;
= open questions
Here are a couple of changes the UI developers would like to see in order to make implementing the visual design more flexible and less dependent on the development work going on in parallel.
- Decouple visual design implementation
add a separate new swim lane for visual design implementation in the Kanban board
create a new project containing the widget sets and style sheets
- Invest now in style sheets and the theme
clean up CSS; they are quite a mess currently. They are also in the wrong project.
properly modularize CSS files (bundle them with widgets?) so that apps/views/... can be properly extended
verify, if the current way to style desktop vs. tablet UI make sense
could we ask Samuli to do this (Andreas: I consider this more important than supporting DAM links in the rich text editor - his current story).
- No concept pages for visual design implementation
a formal concept page for visual design changes was a paper tiger and didn't make sense
we have specifications from the design reviews instead: http://wiki.magnolia-cms.com/display/UX/UI+meetings
we also compile a change log of what has changes so far compared to the initial design: http://wiki.magnolia-cms.com/display/UX/Change+log+for+visual+design