Wednesday, 9 November 2011

Review: Ubuntu Developer Summit - Designing and Creating Ubuntu Experiences

Presenting the notes from the Community track at UDS-P, this was the first of a series of 3 sessions:
- "Designing and creating Ubuntu Experiences"
- "Meet with the Ubuntu Desktop Designers"
- "Community Participation in User Experience"

The difficulty of not being in the is that the notes come across as a bit trite, with some marvelous examples of "statin' the bleedin' obvious" (Monty Python). I'm thinking particularly of "... define roles for design, implementation, testing, integration and documentation."

I'd hope, this being 2011 and Open Source notwithstanding, we've all got this by now and this is merely a stake in the ground for every team to formalise a structure and not leave all the 'dull' jobs to a the one volunteer willing to be ground down as the general dog's body.

If I'm interpreting correctly, the emphasis on thinking wider than Unity as the user experience is welcome news; considering the excellent modular framework that is Linux, building those connections between available components really must be the way to go. Looking forward to the examples and proofs-of-concept promised at the end. RC

Session Notes:
  • design != Unity only (as in launcher, dash, lenses)
  • think broader, envision user-experiences that go beyond the shell/unity
    (e.g. how to stream your music to your TV)
  • focus on personal experiences (not on shell, middle-ware, kernel), this is where design needs to happen, the end-user does not care about OS-components, but rather home-entertainment, personal media (music, photos, movies), security/privacy
  • potential focus-areas are content, services, applications, hardware, peripherals ... that makes up home-entertainment
  • delivering a "user-experience" very often means connecting the dots, because there are already many building-blocks in Ubuntu's repositories
  • wrap a nice experience around the knowledge of how to connect these dots (e.g. playing music via remote speakers)
  • designing a good user-experience requires very high-bandwidth communication (talking face-to-face if possible, gather in front of whiteboards...), smaller teams of people will have an easier time to achieve this
  • form a team to work a specific user-experience story
  • ... define roles for design, implementation, testing, integration and documentation
  • ... also create a culture of standardizing on processes to pass information between these roles to make this consistent, reproducible and scalable
  • Canonical should share their own experience in key-areas to help formulate processes that can be applied to small task-teams in order to help them create an efficient high-bandwidth work-group
  • define one experience for this cycle (stream music via remote speakers) as a role-model example for creating and test-driving the needed skill-set/processes.