|
| Programmer Dude wrote:
> Ilja Preuß writes:
>
>
> No, because they don't want to have to keep learning new features all
> the time.
Right - that's why usability is less than Agile. Refactoring GUIs is
absurdly easy, and refactoring users is very hard.
This is why GUIs need aggressive tests to constrain their appearance, so
mistakes don't cause changes in usability. Agile GUI development depends on
_restraining_ the high flexibility that GUI toolkits provide.
> The update--from their point of view--is painless. We use a "Zero
> Client" (really, really, REALLY thin :-), so there is no deployment,
> per se, to the customers' "desktop". But for big changes, they may
> have to learn new things or unlearn old things.
I bet Web sites like Google change elements of their back-end constantly,
and change their complete infrastructure more often than they change their
GUI. (With the obvious exception of the goofy graphics on their logo during
each holiday...)
> THAT'S what they hate. (-:
I would never expect a customer to relearn a single keystroke. A usability
expert who knows the market could order me to change one, but I won't just
change it myself.
> For us, the update IS painful (due to the system's nature). We
> have four environments: Development, QA, Stage and Production.
> When a development cycle is complete, we migrate to QA for our
> test team to beat on it. Once we believe it works right, we
> migrate the changes into Stage (which has a copy of the user data
> from Production). If the migration works right, we repeat that
> process with Production. (All similar to what Nick described
> his customers doing.)
Everyone needs a pipeline like that. However, how many aspects of those
people's behaviors could go away if the team writing the code made any small
adjustments to their workflow?
I don't know the answer; I suspect cramming them all in one programming pit
would cause such efficiencies to arrise spontaneously.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
>
|
|