Slashdot Mirror

Most speakers at last week's NetMedia'2000 conference in London proclaimed WAP a temporary aberration that delivers substandard services.

British and continental newspapers are full of stories about WAP phones that don't work and services that are difficult to use.

Many commentators point out the simple fact that since you have a phone in your hand, most tasks are faster to perform by simply placing a voice telephone call than by using WAP.

Things have changed greatly: October 1999:

I was a rather lonely voice when I called WAP the Wrong Approach to Portability in my October 1999 Alertbox.

Most other commentators were very keen on WAP during 1999 when the hype was in full gear. April 2000: As recent as during my last trip to Europe in April 2000, most people had great expectations for WAP. Cooler heads who had conducted initial usability studies of the first WAP phones did raise a few concerns in April 2000, but the received wisdom was still in favor of WAP just a few months ago. May-June 2000: The picture started changing and the first negative reviews were published in European newspapers that had tried WAP services and pronounced them useless. July 2000: A new consensus has now been reached: nobody predicts great things for WAP any more. The excitement has shifted to:

Future mobile services with bigger screens and faster, always-on connections (except for the British telecom company Orange which cluelessly supports a technology called HSCSD with an unpleasant need to dial up every time anything is downloaded).

The Japanese I-mode system which is superior to WAP as a current-generation service.

Most speakers at last week's NetMedia'2000 conference in London proclaimed WAP a temporary aberration that delivers substandard services.

British and continental newspapers are full of stories about WAP phones that don't work and services that are difficult to use.

Many commentators point out the simple fact that since you have a phone in your hand, most tasks are faster to perform by simply placing a voice telephone call than by using WAP.

Things have changed greatly: October 1999:

I was a rather lonely voice when I called WAP the Wrong Approach to Portability in my October 1999 Alertbox.

Most other commentators were very keen on WAP during 1999 when the hype was in full gear. April 2000: As recent as during my last trip to Europe in April 2000, most people had great expectations for WAP. Cooler heads who had conducted initial usability studies of the first WAP phones did raise a few concerns in April 2000, but the received wisdom was still in favor of WAP just a few months ago. May-June 2000: The picture started changing and the first negative reviews were published in European newspapers that had tried WAP services and pronounced them useless. July 2000: A new consensus has now been reached: nobody predicts great things for WAP any more. The excitement has shifted to:

Future mobile services with bigger screens and faster, always-on connections (except for the British telecom company Orange which cluelessly supports a technology called HSCSD with an unpleasant need to dial up every time anything is downloaded).

The Japanese I-mode system which is superior to WAP as a current-generation service.

Seems like WAP was already doomed last year. The Brits and euro web developers were already shunning WAP last year.

I can still remember the system architects at work drumming up white papers to convice an outpouring of cash into R&D for WAP but it never quite got anywhere. Who has the time to drive (late) to work and do their makeup and hair much less key 4445533111229955 on their cell for the favorite stock quote?

Jakob Nielsen thinks it's a useful feature and he says so on his homepage.

Okay, this link describes usability tests on web-sites but but the basic principle outlined here would also apply to applications - and it would tie nicely into the "release often" paradigm.

MS execs try to create a general attitude about Free Software, Open Source, and/or Linux that is negative. This is obvious because of things like Ballmer's comments and other recent MS exec's comments.

The interesting thing is not what that attitude means right now, but rather, what it will enable in the future. This is like a chess game. Here is what I mean. If you read this article from Jakob Nielsen (http://www.useit.com/alertbox/20000625_hailstorm. html) in the last paragraph, you will see that a very "intelligent" Microsoft strategy is being birthed. Where the .Net platform locks Internet-based services into Microsoft technology and logic. Hence, PAYing customers will have to use/continue using Microsoft products to get these services.

This duplicates Microsoft's current usefulness to any company developing for a software platform. If a little company makes their product/service available through Microsoft's technologies the little company instantly has access to the largest pool of potential customers. That probably makes sense if you want to make a lot of money.

The thing is, how does Microsoft get such a huge base of people using and implementing (critical mass?) its payment (and other) services first? That is the challenge for Microsoft. They *need* to get businesses and the public feeling generally negative toward free and open source types of philosophies. Hence the inappropriate "cancer" and "intellectual property" notions MS execs spout. With that kind of feeling in the business environment, MS gains an important advantage in convincing everyone to deploy MS technology. Thus, MS locks businesses, organizations, governements, individuals, etc. into a new era of MS monopoly through the Internet and in the form of MS-based payment systems/intellectual property bottleneckers, etc.

The Web is very different from television: it is mainly a cognitive medium, whereas TV is mainly an emotional medium. This makes TV much more suited for the traditional type of advertising which is flashy and promotes superficial qualities of products. While watching TV, people approach a vegetable state and the main goal of a commercial is to minimize interaction by keeping the user's hand off the remote control. As long as the user watches, you can keep them engaged by high production values and a message that says very little besides "we are good."

Where TV is warm, the Web is cold. It is a user-driven experience, where the user is actively engaged in determining where to go next. The user is usually on the Web for a purpose and is not likely to be distracted from the goal by an advertisement (one of the main reasons click-through is so low). This active user engagement makes the Web more cognitive, since the user has to think about what hypertext links to click and how to navigate. This again makes the Web less suited for purely emotional advertising. The user is not on the Web to "get an experience" but to get something done. The Web is not simply a "customer-oriented" medium; it's a customer-dominated medium. The user owns the Back button. Get over it: there is no way of trapping users in an ad if they don't want it.

http://www.useit.com/alertbox/9709a.html

Another problem Google and Robot Wisdom both face is that they are too well designed and consistent... But I'd hate to see either Robot Wisdom or Google damage their functionality in order to improve the effectiveness of advertising.

For a more in-depth analysis (and a better test program) I recommend reading Jakob Nielsen's columns on web usability, starting with one specifically about web-based advertising.

Here's the URLs:

http://www.useit.com/alertbox/
http://www.useit.com/alertbox/9709a.html

Another problem Google and Robot Wisdom both face is that they are too well designed and consistent... But I'd hate to see either Robot Wisdom or Google damage their functionality in order to improve the effectiveness of advertising.

For a more in-depth analysis (and a better test program) I recommend reading Jakob Nielsen's columns on web usability, starting with one specifically about web-based advertising.

Here's the URLs:

http://www.useit.com/alertbox/
http://www.useit.com/alertbox/9709a.html

I have a friend who does a lot of hardcore Flash work. (He's apparently enough of an expert that some folks asked him to narrate an instructional video on the subject.) He's convinced that Flash can do what client-side Java was once pushed for: Highly specialized UIs for specialized goals, using more fine-grained control than you can get through HTML.

I would be unconvinced, except I had seen something he had done: It was a site that let users design their own Nokia cellphone faceplate. It was a basic painting program using a faceplate-shaped painting surface, and then you could save your design and order it. The Flash app was integrated with an industrial painting machine, which would actually spray out a copy of your faceplate, and then you'd get it in the mail in a few weeks.

Flash is so commonly misused that it's easy to assume it's an entirely worthless technology. But in the right hands, it seems like it can be very useful.

• Vince Flanders
• Jakob Nielson
• Interface hall of shame

A final recommendation is to use a server that supports HTTP keep-alive: saving the overhead of establishing a new TCP/IP connection for every "hit" cuts latency dramatically. The experienced response time to load a page often drops to about half by using keep-alive.

Yet most dynamic content systems don't do keep-alive. What have we learned since 1997?

Why should everyone have to know how their computers work?

If not, why are crazy parents putting children in the age of four in front of their mast^H^H^H^Hcomputers then?

Working in the field of human factors, I fully agree with you in that it is the machines', or better the designers' and developers', fault if people encounter difficulties. Every careful reader of Don Norman's The Design of Everyday Things oder Jakob Nielsen's Alertbox column knows that.

The interesting thing is, most people don't. They surely notice when getting confused by some software, web site, or gadget, but they are drawing the wrong conclusion that they had to learn how to use it, or that their children should learn it as early as possible, and things like that. Just a few hours ago I encountered a colleague who complained about usability of some web site. It took me a while to assure her there really are incompetent "web designers" who do not care about users and do not really understand the concepts behind web technology. And this happens over and over.

And things are getting worse. The Internet not only brought to us a lot of incompetence in user interface design, but also a tendency to make three steps backwards unnecessarily. We are told the web browser will be the user interface for everything in the future, because "everyone can use a browser" (how about the application inside the browser?), our personal computers get replaced by "thin clients", and typing on a mobile phone's tiny keypad is considered an adequate way of making payments. In short, we are going back to terminals and transactions, and beyond.

Even cool sites like /. are affected. I would prefer to type into a real text editor instead of this text entry box. I would like an auto-save function for everything I write built into my /. client, like the one in my favourite Usenet newsreader. I would really appreciate a more flexible, i.e. not page oriented, presentation of comments, which my favourite Usenet newsreader provides as well. Don't get me wrong; /. is quite usable if one considers the limited capabilities of a web browser. But those capabilities are not sufficient for most interactive applications.

Recommended reading:
C. Fellenz, J. Parkkinen, H. Shubin: Resolving conflicts between the desktop and the Web

Paul

Not to sound rebellious against the article, but looking at things from an outside perspective this isn't so called "Extreme Programming" to me, its more like custom programming. Not all customers need the same features in a program so who will be the thinktank customer to help with the foundations of it all?

Excellent question! Beck's book covers this in more detail.

The theory here is that you want the developers to have complete control over the "how" and the customer to have control over the "what". And that "when" emerges from this process. The goal is to avoid the nightmare where a manager says "build X features in Y time for Z dollars" by pulling the numbers out of his ass.

In the case where you are making a product for a large, diverse body of customers, you get a proxy for them. Typically, this is is somebody from marketing. This person then is the one to say "of these 323 features that we think would be cool, these five are the most important ones." The developers then give estimates on how long those features will take, and the developers and the proxy customer go back and forth until they all agree on the things to tackle next.

In this case, though, I strongly recommend doing frequent user tests with real users. As Jakob Nielsen is happy to tell you, the difference between what we think people want and what they actually want is often miles apart.

But to a large extent, the developers will have to trust that the marketing person knows what he is doing, in the same way that the marketing person has to trust that the developers know what they're doing. Normally this is pretty scary for both sides, but the short release cycles and continuous feedback make it work out pretty well in practice.

I don't understand why more sites don't use Yahoo!'s navigation interface design. If only Progeny and User friendly would read some Alertbox...
--
mrBlond

1. Learn to manipulate the slashdot editors.
   
2. Jakob Nielsen just wrote a column about
   making sure that journalists know how to
   use your web site: www.useit.com.
   
3. Do your best to annoy the hell out of the
   RIAA and MPAA. You can't buy the kind of publicity
   that Napster got.
   

Whaddya mean, Apache doesn't run on a tea kettle?

Slackers.

This is absolutely hilarious. If it actually runs Apache I'm going to have to get one for the office.

Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine.

Raven is an SSL plugin. I work for the company that makes it (but I don't speak for them, #include stddisclaimer.h), so that's probably why it's not very exotic to me. Raven is a closed source module. Otherwise, if you have the source code of your current version, you can do a diff against the present code base to see what the differences are. If you're really in the dark, you should approach the web server like a black box and (re)define a set of functional requirements, collect and integrate the software and keep record of what you have been doing on file. That's a sound business practice anyway: what if your present webserver irrepairably crashes?

Oh, have you considered making soft links for the most frequently occuring 404's with the misspel(l)ed names? This may be a bit more maintenance intensive but you don't need mod_speling.

Slackers.

:)

Anyway, as for the extent of the patches, I'm not entirely sure. It was built quite a while before I came to the company, and the modules that are running are all statically built in. Much to my annoyance, dynamic linking was disabled in the built version, meaning that the only way to add things like mod_speling (which would eliminate about 90% of our 404 errors, particularly people looking for INDEX.HTML etc & Apache being too case-sensitive for its own good) is by one way or the other rebuilding the server from scratch. Dammit.

Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine. When time allows it, I'll start migrating things over to a new version I guess....

Of course, when people say that "design" will save the world, they usually mean their idea of design, which might not jibe with yours or mine.

No timothy, when they say "design", I beleive they are referring to things like usability testing. In other words, taking a software package to groups of users, and designing statistically sound experiments to see what users find easy and fast to use. In other words, users ideas of good design - not yours, not mine.

If you're interested, maybe read some sites on design.

Moreover, I think they are also saying that VC's should at least be aware of what theoreticians are thinking about so they make better use of their investor's dollars

Here is Nielsen's actual commentary on this topic. As he points out, "Hypertext should not be used to segment a long linear story into multiple pages...Proper hypertext structure is not a single flow 'continued on page 2'."

Try using a line break or paragraph tag; it makes things so much easier to read. I read the first line and my eyes went out of focus. Check out this UseIt.com article for more info and reasons why.

Try using a line break or paragraph tag; it makes things so much easier to read. I read the first line and my eyes went out of focus. Check out this UseIt.com article for more info and reasons why.

Flexible online payment methods make it easier for small players to operate on the marketplace - whether your talking about content providers asking for tips, or super specialized vendors providing better service than their mammoth competitors.

Involuntary micropayments are NOT the way to go, we need something like PayPal, but with universal access and ease-of-use that is comparable/superior to live cash money.

Transaction costs keep mankind down!

I agree this is a problem, but I disagree that it's a fatal flaw. People could, for example set up local automated scripts(or download bots from TUCOWS) to take care of the pop ups behind the scenes (e.g. they authorize sites X Y and Z automatically). They still have to deal with new sites, but there are still schemes yet to be discovered to deal with these situations with a minimal amount of hassle.

Don't you think that would be highly annoying? I doubt techincally illiterate people will be willing to do this. So, maybe it'll get integrated into MSIE 7. But just like with cookies, the default will probably be "Yes, to everything", and that leaves annoying pop-up window attacks still possible (also, consider the attack of hidden frames: have half the website devoted to frames that look like background, yet charge the user seperately. This is less obivous than popping up windows all over the place.)

And let's look at what we get in return, quality websites. The days of great sites like this arrising from ad revenue are numbered.

This is probably true. Ads are clearly not the way to make money on the internet. They don't work, as Jakob Neilsein is fond of pointing out. I'm just saying that micropayments, at least in their current form are also not the way to do it. Personally, I don't mind this. There are very few "content" sites that I actually like. Salon.com is about the only one. The rest...well, I'd be happy to see them go, and see the internet move back into a more person-to-person communication medium. Yet, as you point out, even this has costs. Maybe FreeNet will help with this, because it distributes the bandwidth across the whole network. We'll see. In the meantime, Clay Shirky suggests three options in his article:

1. Aggregation -- bundle a large number of low-value things together
2. Subscription -- pay for the site. I'm not sure if this will work (see: Slate.com), but maybe it would for a network of related sites (see: pr0n)
3. Subsidy -- Shirky points out that most real-world art centers (museums, operas, etc) are funded this way. This is what Amazon's Honor System is (not a micropayment as is often claimed). Goats and Penny Arcade are now trying this with PayPal and Amazon. Online comics are well suited for this type of system, I think, because they take a lot of work and skill to do right, and have a strong network of fans. It will be interesting to see if it works.

As for flat fees, your point only applies to the United States. I've heard that in other countries Internet access fees are generally per hour. As much as we like to think we're the only part of the world that matters, we're not :)

But remember that Europeans HATE this!

Last year, the Poynter Institute did an eyetracking study of how people read news on the web. They found that graphics were largely ignored. It probably doesn't matter what size they are, they'll still be ignored.
--

His arguments are that current web models for raising revenue don't work. In this case I think he's talking about web pages that don't sell a product, and have just content. Most people have a blind eye to banner ads, and I don't know anyone who doesn't close popups before they even finish loading.

He's been saying for years (completely incorrect every time) that micropayments are coming, probably for those very special sites like Yahoo, that fulfill a functions that few have matched. Probably something like a dollar or two a month.

Most recent article on the topic

Personally I don't agree with him, and if it weren't for that fact that I respect so many of his other predictions and theories, I'd probably ignore it. I think that some people want micropayments to happen because they want the web to thrive, and this is the only way they can think of for it to continue to function economically. They might be right in that it's the best way (I don't know), but I don't think that means that it'll happen.

His arguments are that current web models for raising revenue don't work. In this case I think he's talking about web pages that don't sell a product, and have just content. Most people have a blind eye to banner ads, and I don't know anyone who doesn't close popups before they even finish loading.

He's been saying for years (completely incorrect every time) that micropayments are coming, probably for those very special sites like Yahoo, that fulfill a functions that few have matched. Probably something like a dollar or two a month.

Most recent article on the topic

Personally I don't agree with him, and if it weren't for that fact that I respect so many of his other predictions and theories, I'd probably ignore it. I think that some people want micropayments to happen because they want the web to thrive, and this is the only way they can think of for it to continue to function economically. They might be right in that it's the best way (I don't know), but I don't think that means that it'll happen.

Kudos to zephc for giving the print friendly link. It's not quite Alertbox, but much better than the default crap page "design" we've become accustomed to. "The vast majority of web 'designers' should be shot." - JatTDB
--
mrBlond

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

Just ask Jacob Neilsen, one of the world's foremost usability experts.

"This is radical," said Zeldman, "and not every site can participate. Yahoo and Amazon, for instance, can't afford to risk alienating a single visitor. We recognize that many sites are in that position. Our hope is that if enough sites are willing to take the plunge, the typical 18-month user upgrade cycle will be drastically shortened, and a Web that works for all will no longer be something we just talk about: it will be every web user's experience."

"This is radical," said Zeldman, "and not every site can participate. Yahoo and Amazon, for instance, can't afford to risk alienating a single visitor. We recognize that many sites are in that position. Our hope is that if enough sites are willing to take the plunge, the typical 18-month user upgrade cycle will be drastically shortened, and a Web that works for all will no longer be something we just talk about: it will be every web user's experience."

Add the possibility for participants to decide whether they will accept promotional material, preferably as an opt-in choice. See also Jakob Nielsen's column on "Request Marketing".

Amazon does have a couple of things going for it in the micropayments business: Their huge list of credit card numbers, and the trust and name recognition that they have built.

A share in an almost profitable dot.com company: $14.
Cost of supporting a really excellent web site: $2
Seeing your name emblazoned on weird websites: priceless.

However, if you are using the Internet Explorer 5.5 Advanced Security Beta (formerly available at http://www.microsoft.com/windows/ie/download/previ ew/privacy.htm but now seemingly removed) you can disable 3rd party cookies and block amazon.com from identifying you (unless you decide to donate), of course.

However, some care should be taken, it's easy to fall asleep and think we're so good it does comes without effort. Jakob Nielsen has a thing or two to say.

COMMENTARY
Nielsen on Usability: The Seven Sins of Copy Protection Tools

By Jakob Nielsen and Susan Farrell

Copy protection always fails, sometimes even before a product is released, but it keeps coming back in new forms. From lost passwords to broken dongles, the user always feels the pain.

The latest scheme, Content Protection for Recordable Media (CPRM), puts ID numbers on disks and drives. IBM is working to make sure CPRM will be part of every new hard disk by next summer. The 4C Entity owns CPRM, the same group that brought us CSS2, a DVD audio protection scheme that was immediately cracked and has since been withdrawn.

After the first wave of protest, hardware manufacturers agreed to let users turn off hard drive protection. But the average user can't install software using written instructions, so opting out might not be realistic for most people. Anything that makes computers harder to use should be rejected on the drawing board, because if it ever goes to market, it will be rejected by the users, who already have more complexity than they can deal with on their desktops now.

Here's what is wrong with copy protection:

1) It creates more incompatibilities. It creates problems between compliant and noncomplaint media and drives. On the user side, products that worked before will stop working, and new purchases might never work.

2) Data will be lost. Copyright protection interferes with backup and restore operations, for example when a hard drive fails and a new disk must use backed-up data. Backup, a critical task that is difficult for most users, will become even more onerous, and thus less frequently done.

3) It costs more. Any business with more than a few machines tends to install the same software on multiple computers, to save time and effort. Unique installations for each machine cause delay and extra work. Businesses will have to pay for new hardware, more system administration time, and more user support.

4) It stifles innovation that consumers want. It threatens some of the newest and most popular business models such as those used by TiVo and ReplayTV (which save TV content for later play) and Napster-like peer-to-peer networks.

5) It threatens fair use and the ability to quote material within the limits that are well permitted by law.

6) It doesn't work. Every popular copy-protected program ever released has been cracked, so it will penalize home users and businesses for no good reason. Treating users as if they were data pirates just makes them mad. Real data pirates get excited about new copy-protection schemes, because they present a new challenge.

7) It could slow down the Net. Internet improvements often involve more caching, proxies, and content negotiation for multiple devices -- in other words: copying. Even if only trusted systems are used, those systems would be under tight control, the opposite of the kind of open Internet we know today.

Copy protection makes things harder to use, and people hate it. Early phonograph records had printed licenses that forbade their resale. People believe, no matter what the fine print says, that if they buy a thing, it's theirs. Books can be given away after use. Software can be used on both desktop and laptop. A CD can be taped and played in the car. A magazine can be read for free in the library. People need to share data among the many devices they own. Any content payment scheme that doesn't allow for the time-honored ways people actually use information is doomed and should be rejected.

(Dr. Jakob Nielsen is principal of Nielsen Norman Group ( http://www.nngroup.com/ ) and author of "Designing Web Usability: The Practice of Simplicity." E-mail: jakob@useit.com. Susan Farrell is a user experience specialist at Nielsen Norman Group. Nielsen on Usability appears in this newsletter every Monday.)

----

If your application is very simple, you can probably just get away with doubling everything.
But if you're writing something even moderately complicated, you should look at doing custom interfaces for both. Why? A number of reasons.

The big one is that interaction styles in desktop and touchscreen environments are generally pretty different. Early touchscreen proponents ignored this, resulting in a lot of problems, including gorilla arm. Fingers are also much bigger and less precise than mouse pointers. This suggests that touchscreens should work hard to make common choices much bigger, to give more macro-ish buttons that perform common sequences, and generally make frequent activities very easy.

Another important reason is that people sitting at a desk are generally in a very different frame of mind then people at a kiosk or running a big piece of machinery. At a desk, you are generally physically comfortable and familiar with your environment; you're also likely to have fewer distractions and be more familiar with the software. In common touchscreen environments, though, people are usually standing or just stopping for a moment, and they're much more likely to be inexpert users. So with a touchscreen, you should probably make the basic interface much simpler: enlarge or emphasize more important information; shrink or remove less important information; relegate rarely used options to other pages; make on-line help more simple and direct; and so on.

Also, a number of the standard GUI widgets don't work as well in touch-screen environments. You'll note that most kiosks only have buttons, with the occasional radio button or checkbox set; there are no pull-down menus (and especially no hierarchical menus), few pop-up lists, scrolling lists, or tabs. And any text or number entry field has to provide a pop-up keyboard.

But if you really can't afford to develop two UIs, then there's a very simple solution: use the touchscreen monitor at a low resolution. An interface that works pretty well at 640x480 on a 15" touchscreen should be adequate on a 1280x1024 17" desktop. But if you do a combined desktop+touchscreen interface, you must do some user testing. Jakob Nielsen's site useit.com has many good hints, including an articles on doing budget user testing plus boss-friendly explanations of why spending a little money on user testing has big payoffs in the long run.

If your application is very simple, you can probably just get away with doubling everything.
But if you're writing something even moderately complicated, you should look at doing custom interfaces for both. Why? A number of reasons.

The big one is that interaction styles in desktop and touchscreen environments are generally pretty different. Early touchscreen proponents ignored this, resulting in a lot of problems, including gorilla arm. Fingers are also much bigger and less precise than mouse pointers. This suggests that touchscreens should work hard to make common choices much bigger, to give more macro-ish buttons that perform common sequences, and generally make frequent activities very easy.

Another important reason is that people sitting at a desk are generally in a very different frame of mind then people at a kiosk or running a big piece of machinery. At a desk, you are generally physically comfortable and familiar with your environment; you're also likely to have fewer distractions and be more familiar with the software. In common touchscreen environments, though, people are usually standing or just stopping for a moment, and they're much more likely to be inexpert users. So with a touchscreen, you should probably make the basic interface much simpler: enlarge or emphasize more important information; shrink or remove less important information; relegate rarely used options to other pages; make on-line help more simple and direct; and so on.

Also, a number of the standard GUI widgets don't work as well in touch-screen environments. You'll note that most kiosks only have buttons, with the occasional radio button or checkbox set; there are no pull-down menus (and especially no hierarchical menus), few pop-up lists, scrolling lists, or tabs. And any text or number entry field has to provide a pop-up keyboard.

But if you really can't afford to develop two UIs, then there's a very simple solution: use the touchscreen monitor at a low resolution. An interface that works pretty well at 640x480 on a 15" touchscreen should be adequate on a 1280x1024 17" desktop. But if you do a combined desktop+touchscreen interface, you must do some user testing. Jakob Nielsen's site useit.com has many good hints, including an articles on doing budget user testing plus boss-friendly explanations of why spending a little money on user testing has big payoffs in the long run.

If your application is very simple, you can probably just get away with doubling everything.
But if you're writing something even moderately complicated, you should look at doing custom interfaces for both. Why? A number of reasons.

The big one is that interaction styles in desktop and touchscreen environments are generally pretty different. Early touchscreen proponents ignored this, resulting in a lot of problems, including gorilla arm. Fingers are also much bigger and less precise than mouse pointers. This suggests that touchscreens should work hard to make common choices much bigger, to give more macro-ish buttons that perform common sequences, and generally make frequent activities very easy.

Another important reason is that people sitting at a desk are generally in a very different frame of mind then people at a kiosk or running a big piece of machinery. At a desk, you are generally physically comfortable and familiar with your environment; you're also likely to have fewer distractions and be more familiar with the software. In common touchscreen environments, though, people are usually standing or just stopping for a moment, and they're much more likely to be inexpert users. So with a touchscreen, you should probably make the basic interface much simpler: enlarge or emphasize more important information; shrink or remove less important information; relegate rarely used options to other pages; make on-line help more simple and direct; and so on.

Also, a number of the standard GUI widgets don't work as well in touch-screen environments. You'll note that most kiosks only have buttons, with the occasional radio button or checkbox set; there are no pull-down menus (and especially no hierarchical menus), few pop-up lists, scrolling lists, or tabs. And any text or number entry field has to provide a pop-up keyboard.

But if you really can't afford to develop two UIs, then there's a very simple solution: use the touchscreen monitor at a low resolution. An interface that works pretty well at 640x480 on a 15" touchscreen should be adequate on a 1280x1024 17" desktop. But if you do a combined desktop+touchscreen interface, you must do some user testing. Jakob Nielsen's site useit.com has many good hints, including an articles on doing budget user testing plus boss-friendly explanations of why spending a little money on user testing has big payoffs in the long run.

For the first article (big fight), the most grevious error was to say that "WML is a subset of XML" and thus rides the wave of XML as a future standard. While I do see XML becoming very popular indeed, the trouble is that WML is a language defined to be XML compliant, and is not a subset! Furthermore, though I've done no programming in it I have attended a few classes at conferences and done a lot of reading on programming WML, and it is not well thought out or easy to use.

Another part I found rather humorous was this paragraph:

One reason why people feel WAP phones are a big let down is that they expect their Internet experience on the WAP phone to be similar (if not better) to that on a PC. This expectation on the part of the users is really not surprising largely because the hype surrounding WAP is so high that it is made out to be something that it?s really not. And, with this kind of unrealistic expectations, the service was bound to fall short.


Only in the computer industry do we have the hubris to assume that because users do not like and cannot understand the service, the solution is to upgrade the users! I think almost by definition, what a customer wants from wireless is realistic. If you can't give it to them (or figure out soemthing they will find useful instead of being told it's useful), then you are not done working yet!

In the second article (Canvas Dreams), I take exception with saying that WAP has "100% industry acceptance". Personally, since DoCoMo is going to start offering service in Europe I think you should consider the "industry" anyone that will be providing service. That means DoCoMo is part of the industry, and thus WAP does not have "100% industry acceptance".

The other facet of that is that while WAP might have a "high" industry acceptance, how high is the customer acceptance? There are plenty of examples where "industries" decided what is best for the customers and the customers all went and did something else, or just ignored the industries altogether.

They also mention the point about land lines being very expensive in Japan - true, but isn't wireless access REALLY popular in Europe, and isn't bandwidth really expesnive there still? Perhaps similar but somewhat different market forces will spread iMode just as wide there as in Japan.

The last article (which is better?) paints a bleaker picture for iMode. But I don't see things that way. Look at the need to create special sites, and the lock in to browsing at sites offered by your service provider, vs. iModes ability to go to any site. Also of course WAP is circuit switched, and iMode is packet based. it seems to me that iMode is going to be able to support more customers using the same bandwith than WAP.

A few last telling points. Go to UseIt and read some of the artciles about usability tests of WAP devices in London. The conclusion he comes to (and one I agree with) is that screen size matters for internet browsing, and that a keypad is not enough of an interface to work with the web. Consider that it took users about 1 - 2 minutes to look up a weather report. One user reported that they could have bought a paper and spent less money to get the information faster!

I like WAP/WML being an industry standard. It's just a shame the industry made such horrible choices. Hopefully for their own sakes the "industry" is flexible enough to switch to a packet based network that works with HTML to some degree.

Controlling DNS' is like telling you what street you can stand on to give your speech.... If all the good streets (recognized and traveled by most people) are owned by major corporations then your right to speech is effectively denied.

It is critically important to be able to register your own domain name. Even if every web visitor finds your page from a search engine, if your speach offends someone with clout, all they have to do is threaten whomever is nice enough to host your pages under their domain name. You get censored very easily.

In the present example, you are unhappy with GM and create a GM-sucks page, and of course being a free-speech example, someone (probably with GM) doesn't like the page. You're not going to be an easy target, but whoever has been nice enough to host your page under their domain name probably is. Afterall, they're a business (in the theoritical world of corporate-only well-known TLDs), and your page isn't in their mission, and even one cease-and-desist letter with words like "confusingly similar to our regsitered trademark" is going to make the decision to stop helping you a no-brainer.

If you don't have your own domain name, you're screwed. All those links and bookmarks to your old URL now dead. Eventually the serach engines will index your page at the new site, but old links continue to propagate for a damn long time. My site was once hosted at a university web site, for about 3-4 years, and hundreds of links were made and all the search engines indexed it. Now, nearly 2 years after the move, still about 2000 hits/month (about 10-15% of my traffic) comes from a redirect that the old site was nice enough to leave in place, despite many all-night sessions resubmitting to all the major search engines and emailing to hundreds of web masters (often times taking considerable time to find out who's responsible for a page with the link). It is very important to have your own domain name.

It will take quite some time before your speech is as effective as before, and in a world where the only well-known domain names pander to corporate interests, you'll have to choose between registering a domain name that labels your page as having no valuable content, or hosting on someone else's site.

Jay, while your domain name is a .cx, it appears that you effectively control this domain name, which is a very different scenario that using "someisp.com/~you/gmsucks", where the ISP is an easy target for a trademark complain or other attempt at censorship, leaving the disgruntled consumer without the option to change the hosting to another ISP that will not be as easily pushed around.

Now, honestly, I'm not sure if this whole ICANN/ALCU thing really is a problem that will turn into corporate control of domain names.... the reason I posted this, and I hope it was clear, is that if you're going to publish anything significant on the web, you need to be able to register your own domain name. Suggesting that others will find your site from search engines and not by remembering your name is only significant until the hosting under someone else's name ends and many links, bookmarks and stored search engine result all stop working.

There are some very exciting ideas in Jakon Nielsen's Request Marketing-piece. If you can get this stuff working, it is truly different.

> they'll just switch and try again.

No, they'll just go to some other site that doesn't insist you use IE, and you've just lost a customer.

I suggest checking out Jakob Neilson's useit.com site for some tips on building web sites.

Who would run Gnome or KDE when they can have Aqua - a professionally designed UI which has undergone professional usability testing?

Not a chance.

Seen any ads (ever) touting professional usability testing as a reason to buy a Mac or Windows or Solaris? I haven't. I used to sell Macs (and PCs...and the NeXT -- the original OSX machine) with Businessland while I was in college. Not _once_ did I ever have 'professional usability testing' arise as a consideration -- or as a passing comment. And I was selling to the corporate IT departmenmts of national banks, etc. NO ONE CARES!

I mean, come on, Mr. Usability himself worked for Sun -- well known for ease of use, right?

• networks can't provide user demographics
• advertisers don't know how to use the medium

• Why Advertising Doesn't Work on the Web
• The Web in 2001: Paying Customers
• The case for micro-payments

• networks can't provide user demographics
• advertisers don't know how to use the medium

• Why Advertising Doesn't Work on the Web
• The Web in 2001: Paying Customers
• The case for micro-payments

• networks can't provide user demographics
• advertisers don't know how to use the medium

• Why Advertising Doesn't Work on the Web
• The Web in 2001: Paying Customers
• The case for micro-payments

• networks can't provide user demographics
• advertisers don't know how to use the medium

• Why Advertising Doesn't Work on the Web
• The Web in 2001: Paying Customers
• The case for micro-payments