Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] UI refactoring vs Code refactoring

Expand Messages
  • Lynn Miller
    ... Sometimes it is good to refactor a part of the UI. Let s take the opening metaphor as in Jared Spool s article on Designing Embraceable Change
    Message 1 of 9 , Jun 28, 2005
      Desilets, Alain wrote:
      > I'm really interested in hearing what other Ux practitionners have to say bout UI refactoring. In particular:
      > * How do you decide how big your baby steps can be (i.e. just how much UI changes users can deal with in a new release).
      > * How do you decide if you should still support the old way of doing things?
      > * How do you go about supporting both the new and old way of doing things without the system turning into an incoherent mish mash (both at the level of the UI and the code).
      > * Do you keep supporting the old way of doing things forever and if not, how do you decide when is the right time to drop the old way?
      > * Is the allowable speed of change different for different levels of the system. I would imagine that kite level things are harder to refactor than clam level ones right? What is the factor between those speeds. Can one be changed twice as fast as the other, or 10 tiems faster, or 100?
      > * Typically, what percentage of the original UI gets refactored and over what period of time?

      Sometimes it is good to 'refactor' a part of the UI.

      Let's take the opening metaphor as in Jared Spool's article on
      "Designing Embraceable Change"

      and change it around a little bit.

      Let's say every day you wake up, go downstairs to the kitchen to have
      breakfast and think "If only I could get the guy who designed this
      #@!**@ kitchen alone for 10 minutes" as you jiggle the fridge out a
      little to be able to plug the coffee maker in. (The frig then blocks the
      door so you have to jiggle it back to be able to leave.) Then you stand
      (because there isn't any room for a table) and drink your coffee and
      look around and think about how much you loath your kitchen and whether
      you should buy a new house that has a better kitchen.

      If, upon waking the next morning and going downstairs, you found a
      renovated kitchen that was bigger, had all the functionality it had
      before and then some, and was properly organized for best usage - my
      guess is that you would't complain too much that you had to search for
      the coffee spoons.

      This is how we have had success refactoring pieces of the UI in legacy
      products. I stress 'pieces'. It's not changing everything at once - it
      is spot fixing a problem area.

      The key points are:
      - the users have to have identified it as a problem area (i.e. If it
      ain't broke, don't fix it.)
      - it has to be a descrete chunk (e.g. The kitchen, not the floor)
      - the functionality that was there must be maintained (what you can do,
      but not how you do it)
      - the new design must be significantly better to the user (they can do
      more, have less frustration, make fewer errors, are more efficient, etc)

      In cases like this we do not support the old method because the new
      model is better. Of course we do extensive usability tests and design
      iterations to make sure that not only do existing users think it is
      better, but that they can also transition from the existing method
      fairly easily.

      Lynn Miller
    Your message has been successfully submitted and would be delivered to recipients shortly.