RE: [agile-usability] Re: It;s not about UI
- Regarding:>In your experience how have you reconciled the wants of the sponsors to keep the new system exactly like the old system with the desire of the developers to make changes that take advantage of conventions in the new UI paradigm (for instance green screen to Swing GUI). If I change a field where old users knew they had to enter a Y or an N to a check box, am I changing the conceptual model? Or am I thinking about this too much?You are thinking perfectly!This could be a disaster. It's all about the needs of the user... not about new developer widgets to play with to bolster their resume <g>. Make it "exactly like the old system" needs clarification. (Like "Why are we doing this, then?")If the green screen was for a data entry app that they use 6-8 hours of the day, you likely had best match the performance and "comfort" or improve on it... For example, doing a JSP app might get you escorted out the door "modernizing" the stupid green screen @say application to modern, thin client, distributed paradigm.You have to ask what they need, and not let developers invent a solution outside the context of the users...You must also deliver early and frequent results to the users to see if you are marching down the right path.Stay agile! Give the customer's voice a megaphone. Suggest ways to improve, use technology, but keep it arms length. Do not be a slave to technology or you will suffer the consequences of Technical Debt (avoid Y2K the sequel).
-- jon-----Original Message-----This is my first post and so I will make the requisite introduction. My
From: Phil Borlin [mailto:pborlin@...]
Sent: Wednesday, August 04, 2004 10:32 AM
Subject: Re: [agile-usability] Re: It;s not about UI
name is Philip Borlin and I work at CMC Flex as a Java developer with
Jonathan House who is also on this list. I attend the sl-agile
roundtable and so I know Jeff and I am to the point where Alistair only
asks my name 4 out of the 5 times he sees me which I hear is his version
of being on pretty good terms ;). By the way Jon (Kern) if you find a
way to successfully pull a Trump tell me because all of those examples
in your role play were from the project I work on.
> In words,
> designers/developers have only three things they can use in a UI
> (Attractiveness, Information and Navigation) to connect users' Goals
> with Sponsors' criteria for Success. If a UI is not Attractive, users
> will use it only as much as is mandated or required by necessity. If
> Information is not present or difficult to find within the window
> (assuming a GUI), then the system will probably fail. If the Navigation
> among displays (windows and dialog boxes) is not well designed, the
> users' experience will be painful and this also increases the risk of
Exactly! This is everything I have thought about but have not been able
to express. Nice succinct way of describing the UI balancing act.
> How well users transfer to a new system depends on the
> similarity of the conceptual and logical models. The physical model can
> be completely different and the transfer will still be relatively easy.
In your experience how have you reconciled the wants of the sponsors to
keep the new system exactly like the old system with the desire of the
developers to make changes that take advantage of conventions in the new
UI paradigm (for instance green screen to Swing GUI). If I change a
field where old users knew they had to enter a Y or an N to a check box,
am I changing the conceptual model? Or am I thinking about this too much?
> The key
> is to "extract" the conceptual and logical models from the old system
> (can be quickly done if you know how) and then refer to it during design
> of the new system.
Sounds great. Can you point me to some resources that talk about how to