Re: Cocoa et al as HCI usability problem
Re: Cocoa et al as HCI usability problem
- Subject: Re: Cocoa et al as HCI usability problem
- From: Graham Cox <email@hidden>
- Date: Thu, 22 May 2008 12:13:00 +1000
I should clarify my reason for that statement, since it has been
somewhat misconstrued. I think we can all see that the software
situation on Windows (let's name names) is undesirable from the point
of view of the average user. It may be desirable from certain other
perspectives but that's not important here - I personally have been
trained over the years to think that a computer's user is the most
important person we should have in mind when developing software. That
attitude is embodied much more in Apple's thinking than in any other
platform at the present time, and is one reason it attracts me (I
can't speak for others) to Mac development.
Some developers feel (quite passionately in some cases) that Microsoft
has better documentation, APIs, tools, languages, what-have-you than
Apple. That may be true for all I know, and there's no doubt about the
dominance of that platform. However, I think the results speak for
themselves - the poor old user is the one left confused and struggling
in a great many cases, with every developer left unchecked to develop
whatever interfaces they want, and do things in whatever way *they*
think best. Now I'm not claiming that all Windows software is bad -
far from it. The problem is the inconsistency, and the inconsistency
is permitted by the APIs and the tools and the fact that there are not
enough developers who care enough guiding those who, through
inexperience, lack of empathy, arrogance or any of a million possible
reasons, think their way is better. Some aspects of the OS design
arguably even seem to encourage this. It may also be the case that the
sheer overwhelming numbers of developers prevents things from being
effectively communicated. But whatever the reason, the culture is
different, and the culture on Windows does not appear to emphasise
quality.
The situation seems to be different on the Mac platform. Mac apps
*are* more consistent with each other and with published guidelines
than Windows apps. There are still poor Mac apps, but the proportion
of the poor to the good seems to be slewed in favour of the good. One
can speculate about why that is, but whatever the reason, I think most
of us who subscribe to this list would prefer to keep it that way. On
the other hand I also think most of us would agree that it would be
healthier for the computing world in general (and for Microsoft too)
if there were a better balance among alternative platforms. My
personal contribution towards that goal is to write Mac apps. Other
might write Linux apps, etc. So there's a slight conflict of interest
here. We definitely *want* more developers on the platform, but we
don't want the quality to be diluted, it's as simple as that. And by
quality I'm talking about the quality of the experience for the user.
Nowadays when there is little difference between platforms in hardware
terms, this is still a very desirable distinguishing feature in my view.
The recent upswing in new developer numbers is great - it's what I and
probably most of us have been waiting for for years! But with that
influx comes the problem of maintaining the quality. The solution is
not to "keep out the riff-raff" (which most definitely was *not* what
I was trying to convey in my original - and admittedly slightly
flippant - post). It's to ensure that each new developer "gets with
the programme" so to speak. Doing that involves learning the Mac way,
including the way its APIs are documented, and possibly unlearning or
setting aside a lot of entrenched culture that goes with other
platforms. The argument isn't that that culture is wrong, it's that
it's probably wrong *here*. Conversely, if a prospective developer
isn't prepared to do that, they can probably look forward to not
getting much help. Here's why:
The user is king - that's who computers are made for, not developers.
We are just the necessary craftsmen needed to bring computing power to
the masses. I sometimes like to think of software development as being
a bit like woodwork (indulge me). It's open to almost any level of
experience (anyone can nail two planks together) but the finest work
takes years to master - think of a Chippendale cabinet for example.
And there are different techniques used in different camps - you may
have learned to use a particular set of chisels to make certain joints
a certain way, but over in China they make beautifully crafted (and
definitely non-English) furniture using completely different tools and
joints, a lot of which seem strange and unfamiliar. Well, you are in
China now. Presumably you are here because something is interesting
you about "the Chinese Way", and you'd like to add that to your stock-
in-trade. It's no use complaining that the Chinese don't use the
English techniques you are so familiar with - they just don't. So
you'll have to start by learning Chinese (Obj-C) to be able to
communicate at all, then take time to learn the appropriate techniques
from those versed in the art to do things their way. The result will
be that you'll be able to turn out beautifully crafted Chinese
furniture that even the Chinese will look at and say "a fine piece".
My view is that the documentation's job is not to teach you the art,
it's to provide a reference guide to what is available (a wall-chart
of possible joints). What remains is the necessity for hard work,
diligence, a little humility, and, to be honest, talent. Would a
Chinese master craftsman thank you for waltzing in, taking a glance
around, denouncing his methods as rubbish, throwing a vaguely Chinese
looking piece of work together using your own approach and calling it
equal to their own? No, and not just because it's disrespectful, but
very much because it devalues his work too.
This allusion to craftsmanship and so forth might seem to be
stretching the point, and maybe it is. But software is a craft,
according to many of its best practitioners. And you'll find that here
(in China) we do tend to want to maintain the quality of our work, for
whatever motive, and aspire to improve it, and become as good as the
best (well, I do anyway). So expect a different culture, new
techniques, and a potentially long apprenticeship. That's how it is.
But like any apprenticeship, the real value is the effort put in by
the apprentice - you can't expect to learn this stuff in a week, or
without effort. Even if you are experienced in some other apparently
similar area, it may not help you - you are free to contrast and
compare, and learn from that, but you are not going to get Apple (or
the Chinese) to change their ways, at least not overnight. Ears open,
mouth shut, as I used to get frequently told at school!
Personally, I have always found the documentation adequate (and I
don't mean that to sound as if I'm damning with faint praise), and it
suits my method of working/learning well. This has been true going
back to the original Inside Macintosh. I do understand that others may
feel differently and that the hardest part is getting orientated.
That's where Hillegass et. al. helped me a great deal, so *if* Apple
are lacking in this area, others are taking up the slack. I'm sure
newbies find the culture here alien (particularly those experienced
with Windows or whatever), the APIs and Obj-C language "weird", but
there's no doubt it works. Mac apps are typically fine pieces of work.
My view is that by the time a newbie has learned enough to match the
quality expected, along the way something will have "clicked" and
they'll stop complaining about it all. Ultimately, the user decides.
Poor Mac apps last nanoseconds in the marketplace, where the
equivalent Windows app might go on for some time, so that should be a
strong incentive to a prospective Cocoa developer to do things right,
because if you don't, your product is likely to fail.
Sorry for the diatribe ;-)
Graham
On 22 May 2008, at 10:01 am, Jeff LaMarche wrote:
Nobody spoke up against those posts because there was nothing
inappropriate about them - they were not targeted at you or any
individual and they are not even remotely how you've characterized
them. Hamish was making a general statement (and stating his
opinion) about what he saw as the likely outcome of lowering the
barriers to entry. Graham was agreeing with that opinion, again,
without targeting any indvidual.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden