2005Offsite/UI Design

From MozillaWiki
Jump to: navigation, search

< back to offsite schedule

An open brainstorming session where we can all talk about how UI design is currently done in our projects and what sort of things can be done to improve that process to result in less wasted time and a more consistent user experience.

Please add topics!

Topics for discussion

  • Should we have a ui-design-review flag?
  • "Skeleton" UI design?
  • Does Firefox/Mozilla need a HIG?
    • What makes a HIG useful?
  • Advantages and disadvantages of a design spec
  • When should new UI get checked into code?
  • How/when/for what issues should user testing be brought into the process?

Notes from the Meeting

  • beltzner: what about a design-review flag?
    • doron: who would get +/-/? a design
      • beltzner: initially mconnor, beltzner, beng
    • kengert: how do you know when to use the flag?
      • beltzner: only design that changes UI or adds new UI? not bugfixes? is that bar too low?
      • kengert: that might make too big a pile, could we make this a triage issue?
      • doron: suggest that it's for any new UI as opposed to fixing old UI?
      • gavin: worried about abuse and that people will misinterpret it as a "this feature should be added or not"
  • myk: do we think that having a flag would help people who aren't comfortable with Bugzilla get into that system? is it simply a matter of them not finding what they're looking for or is it that they don't understand the tool?
  • dvedtiz: might be harder to seperate signal from noise in a more subjective area like UI design; the suite suffered somewhat from this because the default decision was to add prefs if we couldn't decide. Firefox got around this by having a tighter control over the UI design
  • beltzner: guidelines that try to specify too much fail; guidlines should be
  • kai: incremental change is the nature of the project, would the UI flag get +'d for increments or would each request get a full redesign. We need to be pragmatic in many cases.
    • dmose: we see the same thing in code reviews as well, though, so I'd hope we'd get the same thing there
  • myk: there are three cases of bugs; 1. code changes with a UI impact, 2. bugs specifically about UI, 3. new feature requests that require usability analysis.
  • list of topics for design guidelines
    • modal dialogs vs not?
    • lexicon
  • user testing can take a long time, depending on the method that you're looking to use; when you're developing UI, when do you find you hit up against the question "it would be nice to have user testing"
    • kengert: I rarely am blessed with the time to be able to compare and conrast
    • myk: my biggest mistakes in UI design are hit when I make poor assumptions about how someone will end up using the product
    • unknown: I'm with myk
    • schrep: would it be helpful to have additional folks available on staff to do design iteration and prototyping? or is it quicker to do it yourself?
      • unknown: yeah, that'd be great
      • kengert: usually by the time I explain what I want I can do it myself
      • dmose: it depends on the complexity of the UI
      • beltzner: maybe this is a good spot for a keyword?

Comments from the Web

  • callek: a design-review flag in bugzilla would be great, and allow for design review without also requiring code review which means that designs could be expressed in ascii art, specs, etc.