Product Development

Page tree
Skip to end of metadata
  • Created on 2013-02-08, last edited by Andreas Weder on 2013-02-13
Go to start of metadata

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.

(tick) = we already do this; (error) = we don't (consequently) do this currently

Conceptual design

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

Applied design

  • (error) 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.
  • (error) 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

(plus) = suggested improvements; (minus) = should be changed; (question) = open questions

Reviews

Conceptual design

While the reviews of the more conceptual work are mostly done, we can still improve them.

  • UX design process
    • (question) (warning) 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?
    • (question) Does Andreas have to seek more and earlier reviews and discussions?
    • (plus) We could introduce s separate Kanban board for UX design.
    • (question) 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
    • (plus) 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
    • (plus) sketches or mockups are proposed in SPECIFICATION/concept state by a developer or UI expert
    • (plus) published together with the technical concept on a concept page in the DEV wiki space
    • (plus) reviewed in SPECIFICATION/review state by a (different) UI expert
  • UI and visual design implementation
    • (plus) 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

  • (plus) We should invest into automated integration testingusing e.g. Selenium.
    • TestBench from Vaadin could be another option (it actually uses Selenium).
  • (plus) 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
  • (plus) 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
    • (question) do we also have to test with a set of smoke tests covering various typical flows through the UI?
  • (plus) 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

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
    • (question) by whom? the support team?
    • (question) done where? We have VMs for testing on multiple OS (Mironet).
    • (question) how do we test different language versions?

 

What should also be improved

(plus) = suggested improvements; (minus) = should be changed; (question) = 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
    • (plus) add a separate new swim lane for visual design implementation in the Kanban board
    • (plus) create a new project containing the widget sets and style sheets
  • Invest now in style sheets and the theme
    • (warning) clean up CSS; they are quite a mess currently. They are also in the wrong project.
    • (warning) properly modularize CSS files (bundle them with widgets?) so that apps/views/... can be properly extended
    • (plus) verify, if the current way to style desktop vs. tablet UI make sense
    • (question) 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 labels