Read Apple's Deep Insight Into User Interface Design online
or reprint it at:
Apple Jumped the Shark long ago.
It's not just me: many other developers say so as well.
It doesn't have to be that way. It wasn't when I worked in Cupertino.
The reason that you guys all think that I'm a crappy web designer, when in reality I am an incredibly effective web designer, is that while I learned basic markup from the National Center for Supercomputing Applications original HTML tutorial - which I Shit You Not came right out and said that the very purpose of HTML was to encourage experimentation by browser designers, in that tags and attributes they did not support were simply not rendered - I actually learned web design from Jakob Nielsen.
Yes, the crackpot who thinks The Internet is a Cube.
Apple's User Interface - who in HELL came up with "UX"? - has totally Jumped the Shark in recent years; it's not just me saying so - just go have a gander at all the hatred that Apple's own developers are posting to Apple's own developer lists.
It doesn't have to be that way. It certainly wasn't that way either of the times I myself worked in Cupertino.
Try this yourself sometime, with early user interface prototypes of your own code or websites:
Apple at least at one time had two user interface testing rooms that were little other than private offices each equipped with a desk, a chair, and a Macintosh.
When Apple's UI people wanted to try out a proposed new design - not just for software, but also for hardware designs such as new mice - they'd hire some random Joe right off the street then pay them to while away a few hours in their UI lab.
"This is a mouse. You can see that as you move the mouse around on the desk, the 'Pointer' on the screen moves with it."
"Clicking twice in rapid succession is referred to as 'Double-Clicking'. If you Double-Click the icon for an Application, the Application 'Launches'. If you Double-Click the icon for a 'Document', the Application responsible for that Document launches, then the Document is 'Opened' by the Application."
"Do you see that icon right there in the middle of the 'Desktop'?"
"The one called iTunes?" asks Joe.
"Yeah. Try Double-Clicking it."
"What's it supposed to do?" asks Joe.
"That's what we are paying you to figure out on your own."
The Apple employee then splits completely, while several video cameras record the proceedings: one pointed at Joe's face, so Apple's people can watch for expressions of interest, joy, frustration or anger. One pointed downward at the keyboard. One pointed at the screen, one pointed at the mouse.
They let Joe screw around with the Mac until he gets tired of it and wants to leave. They then hand him a big fat check then make him promise never to tell anyone what he saw, because were that User Interface design to actually succeed in all these tests, the company that laid off four thousand of its own employees BOTH of the times that I worked there - I even once knew where my new cube was going to be before the poor fuck I was to inherit it from had the first clue he was about to get a Pink Slip - might go on to have more cash in its checking account than the entire United States government.
Do you remember WAP? Wireless Application Protocol?
WAP was much like the World Wide Web but optimized for low-bandwidth connections, very minimal user interface and inexpensive electronics that drew very little electrical power.
Someone clearly dropped the ball when they got the bright idea that ALL the WAP sites ought to be subdomains of ".mobi". Why not just ".m"? Do you know what a Pain In The Ass it was to type ".mobi" into the cell phones of ten years ago?
But there were many positive benefits to WAP:
WAP markup was strictly required to be Valid SGML - NOT XML! - so they didn't have the Browser Wars problem caused by "Tag Soup".
WAP is SGML and neither HTML nor XML because closing tags don't have letters in them, like this:
<a href="http://goatse.ch">You Have Been Selected For a Customer Survey!</>
You can see that if you have strict rules about your market, and the software that generates that markup is reasonably well-debugged, there is no reason to put the name of the opening tag into the closing tag as well. You only require that all tags that get opened also get closed. In that respect, both XML and XHTML are incredibly wasteful of all manner of resources.
Strangely though, WAP failed to cath on. In my entire life I have only heard of one really successful WAP software product; Regan was once a manager at a WAP firm that provided a live traffic reporting application that looked just like the iOS Maps App but would let you know if there was gridlock ahead so you could take an alternate route or maybe hang at the 'bucks before driving home.
Jakob Nielsen made a metric fuckton of moeny when he lent tenty London residents each a WAP phone for a week, then at the end of the week asked them to discuss their experiences with his people:
In the fall of 2000, we ran a field study of WAP users in London. After a week's experience using WAP, study participants had one resounding conclusion:
70% of them said that they would not be using WAP in a year. For the study, we gave 20 users a WAP phone and asked them to use it for a week and record their impressions in a diary. We also performed traditional usability tests with users at the beginning and end of the field study. We gave half of the users an Ericsson R320s and the other half a Nokia 7110e. (WAP = Wireless Application Protocol; a way of accessing the Internet through a cellular telephone.)
We ran this study in London because of the advanced state of the United Kingdom's mobile phone market relative to the United States. The U.K.'s WAP services have been under development longer than those in the U.S. and were also more widely deployed at the time of our study.
It is important to notice that users provided their negative review of WAP after a full week of hands-on experience with the technology. It is irrelevant to ask people in a focus group to predict whether they would like something they have not tried, so the only way to get valid data is to let users experience the technology before you ask them for their opinions.
WAP Doesn't Work
Of course, we didn't just collect opinions. We ran timed task-performance studies as well, since observations are the best source of data. We asked users to accomplish simple tasks with their WAP phones, both at the beginning of the week and at the end. Here are some of the findings:
Time in Minutes
Read world headlines 1.3 1.1
Check local weather forecast 2.7 1.9
Read TV program listing 2.6 1.6
In the above table, the first number indicates the mean number of minutes users needed to perform the task in the beginning of our study and the second number indicates the mean measurement at the end of the study.
As the table shows, our basic conclusion is that WAP usability fails miserably; accomplishing even the simplest of tasks takes much too long to provide any user satisfaction. It simply should not take two minutes to find the current weather forecast or what will be showing on BBC1 at 8 p.m.
I asked a group of Internet experts how long they thought these tasks should take (before showing them our data), and most estimated a task time of less than 30 seconds. Considering that WAP users pay for airtime by the minute, one of our users calculated that it would have been cheaper for her to buy a newspaper and throw away everything but the TV listings than to look up that evening's BBC programs on her WAP phone.
Where Jakob made all those boatloads of money is that the full ninety-nine page report - which is what mobile phone developers really needed to clue into - was for many years a $38.00 download.
Just imagine I could convince every last one of you sorry lot to kick me thirty eight bucks every time you asked me why you could never get the bugs out of your C++ code.
But Jakob, despite being just as I an afficionado of The Special Treament really does have a heart of gold:
His firm's ninety-nine page PDF report on his WAP usability field study is now a free download.
Nielsen's thesis is that the Focus Groups that the politicians, public relations firms and advertising agencies are so enamored of are a complete waste of time.
The Nielsen Norman Groups's approach to User Interface Design is much like the approach to Direct Mail Marketing that I learned from Dave Johnson when I was at Working Software in Santa Cruz in the early 90s. I was WSI's only full-time coder; while Dave was a far-more experienced programmer than I, he had to focus on business management, sales and marketing, for the most part composing Direct Mail "Pieces" - the offer, cover letter and - importantly - what was priinted on the outside of the envelope - slection of mailing list to rent - mailing lists are only very rarely sold - as well as marketing our own list to other Direct Mail firms.
Someone must be clueing in, as neither Android nor iOS support WAP, yet they both sell like hotcakes.
Android and iOS web browsing are able to work at all in large part because bandwidth is so much cheaper, there are so many more cell towers, that so many more people own mobile devices than was the case during the year 2000 WAP field study that economies of scale are enabled, more-sophisticated logical and electromagnetic protocols have been developed to enable EDGE, then 3G, then 4G, but what most people really use, pervasive 802.11x, with the electronics required to support all this being so much smaller, drawing so much less power, and being so much less expensive that the iPhone 4 I've got in my pocket right now is actually quite a lot more powerful than the $2000 desktop Windows NT box I paid a St. John's screwdriver shop to build for me in the fall of 2000.
Which NT box now runs Windows 2000 and Debian, and which box still works fine, and which is really all I require to operate my business, were it not for the fact that I'd Rather Drink Herpes-Ridden Ejaculate than stare all day long at either a Microsoft or Linux user interface.
If you think I develop for Apple products because I think Steve Jobs is such a great guy, Guess Again. In reality, I hate Apple with a passion, and have ever since I hired on as Product Development Manager at Working Software in November of 1990.
Most will readily agree that Apple suffers the Deadly Sin of Greed . It does, but I regard that as the far less significant problem.
Far more serious is that Apple suffers the Deadly Sin of Sloth.
I first clued into that when I got my first look at the source code for strm_echo, a TCP/IP test tool for the Classic Mac OS MacTCP stack that ran as a command-line tool under the Macintosh Programmers workshop.
Yes, the Mac really did have a shell; while MPW eventually became a free download, it was at first quite expensive so lots of tools developers like Symantec and Metrowork made tidy profits through the sale of GUI development environments. In many respects, the MPW to this very day blows away the shell tools one can find for any *NIX box.
For example, for years before the Mac ever gained a hardware memory management unit, or software support for backing store - what most people incorrectly refer to as "virtual memory", which is quite a diffrerent thing - the MPW text editor was perfectly capable of opening and editing any text file that would physically fit in your filesystem, without regard for how little memory your box had.
To be specific: on a two megabyte mac plus with no MMU, running System 6, which had no backing store software even on hardware equipped with MMU, MPW had no problem at all with quickly opening, scrolling right into the middle of, editing and saving a one-hunderd megabyte text file.
It's not rocket science folks: just don't read the whole fucking ball of wax into the G-d Forsaken Heap. Open the file, seek to whereever they user wants to be, then read in only the parts that the user actually wants to display on screen.
That's actually quite a lot harder than reading the whole file into a buffer, because the user might delete text from or add text into the middle. Like a seven year old child couldn't write the code required to close or open a hole in a file. For Fucks Sake!
I myself wrote a rather more sophisticated version of that kind of thing in the Spring of 1993 for The Total Heart, a Multimedia CD-ROM that Medior of San Mateo developed under contract for some medical software publisher.
The original CD-ROM format could hold about 650 MB. Through the use of sophisticated text compression, The Total Heart held about 3.5 Gigabytes of SGML - again, not HTML, while HTML was already in use it had not yet caught on.
My contributions were to decode and display that SGML, with hyperlinks that were small buttons rather thank colored underlines, and to do a full text search.
Suppose you searched 3.5 GB of SGML full of clinical cardiac information for the word "heart" or "blood". You'd get a lot of hits, now wouldn't you?
My search results box enabled the user to clickly and effortlessly scroll through all the millions of hits, yet that CD-ROM worked just fine on - to support System 7 - a four Megabyte mac plus with no virtual memory, and I think an 8 Megahertz 68000 CPU with a 24-bit address bus and a 16-bit data bus.
While the 68k was a true 32-bit instruction set architecture, to make the chip cheaper to design, manufacture, and to integrate into a motherboard, it only had 24 address pins, with 32-bit data accesses requiring two fetches or stores. Thus those in the know used two-byte integers when four-byte integers were not really required.
I contributed to The Total Heart as a consultant, but my success with the effort later resulted in a salaried position with benefits and stock options. I wrote vast quantities of Multimedia CD-ROM as a Medior Employee; they were eventually acquired by AOL then renamed AOL Productions.
Unfortunately I accepted Apple's offer to hire on as a Debug Meister well before my options vested. Pete Burning of Central Coast Software, who formed Medior by partnering with some old friends, got three million bucks out of his Medior equity and now devotes his remaining days to Surfing Photography. Our CEO Barry Schuler is now a top exec at AOL. And Michael David Crawford is not homeless tonight, but only because an old friend has a couch he can surf on while he waxes eloquent about software usability.
Get To The Point, Why Don't You?
While Apple's magnetic MagSafe Power Adapter, which first saw the light of day with my own Early 2006 MacBook Pro - Model Identifier MacBookPro1,1 - should not have been granted a patent, as magnetic power cords were already in use by deep fryers, in general it is a good idea.
With wireless networking, one does need need Ethernet, but if someone trips over your power cord, your expensive Notebook Comnputer gets tossed like a Frisbee.
That's why it took me quite a long time for me to clue in to the fact that if I myself knocked the cord off, which happens quite a lot when I use my mac while lying in bed, I need to reattach is right away as my MacBook Pro's hundred-dollar battery is so totally shot that it holds less than one minute of charge.
The saving grace is that it does hold at least that minute, so I can almost but not quite always get it plugged back in just in the nick of time.
But why oh why, when my MagSafe Pro Power Adapter comes loose, does my Mac OS X Snow Leopard MacBook Pro display the following alert - and only when the power adapter has come loose:
Your startup disk is almost full.
You need to make more space available by deleting files.
Read Apple's Deep Insight Into User Interface Design online
or reprint it at: