I cannot disagree with you more. And here are several paragraphs to
There is a HUMONGOUS difference between product quality and product
usability. Unfortunately, misunderstandings about *usability* result in
a negative view about *quality* no matter how unrelated they are.
The performance of a Porsche 911 is related to the car's engineering
prowess. A software's quality is equally contingent on whether it was
architectured and developed with the Best Of Breed objective in mind.
The usability of a Porsche 911 (say, 2000 model) was not up-to-par for a
standard user's experience. That is because of USABILITY and where the
knobs for the radio were positioned. That discrepency should not affect
a car's performance or quality.
The same goes for software. If you do not agree with the way a software
USER INTERFACE was designed, then you will not believe the software is
USABLE; however, the USER-FRIENDLINESS has *nothing* to do with the
actual quality of the software.
Unfortunately, a correlation of software UI and QA are made. "The user
is always right" is one of service and support because the user may
personally be correct! The button would be more *usable* for them if it
was located elsewhere on a form; however, a software that does not meet
certain user objectives is not related to a flaw in architecture or
execution -- but only to a potential flaw in usability.
Alas, as many have shared, Subversion is making improvements both in
executing the intended software architecture and in improving usability.
Requesting that an architecture change because of less-than-expected
usability is ludicrous. The two aspects should never touch each other;
and in the full architecture of Subversion, they ideally do not. That
is why tools like TortoiseSVN were developed; TSVN is aimed increasing
usability and not modifying architecture.
Lastly, if TortoiseSVN modified their GUI to accommodate your desired
objectives, then that certainly is a discussion for another list. As a
software architecture, I believe Subversion is clearly attaining their
My apologies if anyone was offended by this email's content or length
Sr. Technical Programmer
From: matthew ford [mailto:firstname.lastname@example.org]
Sent: Monday, January 24, 2005 3:47 PM
To: Dassi, Nasser
Subject: User is always right (was Re: Merger not Merging -- What I
would like a merge process to do.)
GUI design and usability is a pet hobby horse of mine (the follow
are not directed at subversion in particular but software in general
no offense was taken)).
> As I said befor the 'User is always right' There are at least
> two users out here who don't think "the subversion" way. And since my
> background is different from my boss', I suppect we are not the only
> With all due respect, Mr Ford, the adage of the "User is always right"
> is one of customer service and support; *not* usability and proper
I dissagree that the "User is always right" does not apply to usability
mode of operation. It is a common failing, that software tries to force
user to think in a particular way which is not the way they would
think. Software is both a service and a tool and as such needs to 'fit'
user's grip. Software developers are so atypical (highly intelligent
logical) that it is very difficult for them to comprehend how a real
might think. Developers are also too close to the software and know it
will, so it is difficult for them to understand that the user may not
the 'logic' of process.
Finally software should not put the user down. 'Users never make
they just change their mind' If the user does something the
developer/software thinks is wrong then it is because the developer did
guard against it and/or did not explain it to the users understanding.
You will allow me to take a some what extreme view point here. This is
ideal to aim for.
However for too long computer uses have been burdened with software that
un-intutitive and too hard to learn/remember. (Like selecting the START
button to shutdown your computer.) There may have been some excuse in
DOS age when memory and computer processing power where scarse
but this is no longer an excuse.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jan 26 03:17:43 2005