From kragen@dnaco.net Tue Sep 22 10:42:52 1998 Date: Tue, 22 Sep 1998 10:42:51 -0400 (EDT) From: Kragen X-Sender: kragen@pike To: jakob@useit.com Subject: Re: Does Internet = Web? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Keywords: X-UID: 2078 Status: O X-Status: Well, I read your column with interest. You have some good points, but as usual, I disagree with some of your points. Stand-alone applications do have nicer user interfaces than Web pages do. But there are several major downsides to stand-alone applications that you didn't mention. - It's true that some Web applications break the Back button on Web browsers. However, for many applications, it's really quite convenient to have a Back button built in, plus the other things a Web browser provides -- bookmarks, layout, multiple windows, etc. As a result, it's much easier to build many kinds of applications as Web pages than it would be to build them as standalone applications. Sometimes this can determine between whether or not they get implemented at all. - While stand-alone applications can have nicer user interfaces, they all have *different* user interfaces. I *really* don't want to have to learn a brand new UI -- even if it conforms perfectly to, say, the Mac conventions, which is unheard of -- in order to make travel reservations, for goodness' sake! - Stand-alone binary, Javascript, or Java applications are a security risk. As a user, I don't want to download untrusted code if I can help it. HTML is much safer. (Remember the porn viewer that dialed up a country in the former Soviet Union and ran up hundreds of dollars in users' phone bills?) - Stand-alone applications obviously have the potential to store their data on a universally-accessible server. Many don't. For a significant portion of the work I do, I don't care about privacy, but I do care about being able to access my work anywhere, any time. Often I use 'telnet' for this. I could just as well use a Web-based application. - In general, Web-based applications are fairly susceptible to automation. It doesn't take a wizard or a guru to write a Perl script to fetch a couple of Web pages, munge them, and generate an HTTP request. Three examples on my own computer: - Monolith, aka ml.org, provides DNS to many people. When I connect to the Internet, I use a web form at their site to update my IP address in their DNS database. But I don't submit it by hand -- I use Lynx. If they used a proprietary protocol to do the updates, it's quite likely that I'd have to live with whatever automatic-update facilities they built into their client. - Merriam-Webster, www.m-w.com, has an online dictionary. I find their Web-browser interface a little clunky -- in order to look up the word 'positivism', I have to go to www.m-w.com in my Web browser, click in a window, type positivism, hit return, and wait for a response. So I wrote a few simple shell scripts; now I can type 'wwwebster positivism' and hit return, and I get a textual answer. - The RFCs are available via HTTP. I often want to read a particular RFC, or search the RFC-index. I wrote some little shell scripts. Now I can type 'vrfc 821' and see RFC-821. The shell-script caches already-fetched RFCs in a special directory which is never cleaned out. I think what is needed is not a call to implement things as stand-alone applications rather than as sets of Web pages, but rather guidelines on how to keep them usable as sets of Web pages. Here's what *I'd* like to see: - No Java. No JavaScript. No DHTML. Not unless the alternative is writing a standalone client. - Don't use form elements when you can use ordinary links. Links have all kinds of support that form elements don't: "open in new window", breadcrumbs, URL preview, ease of automation. - All the usual advice for any web page: don't enclose the whole web page in a single table, use WIDTH and HEIGHT tags on IMGs, don't use IMGs unless they're important and as small as possible, don't use frames for Pete's sake, don't be wasteful of bandwidth, etc. - Try to make your system as stateless as possible, since the more state you add, the more you decrease usability. Maybe some of the other things you'd like to see in Web browsers, like overview diagrams of navigation history, folding sitemaps, search, paths, tabletops, fat links, parametrized backtrack, visual cache, link inheritance and clustering, and link rating, would impose other constraints on Web-based applications. I don't think they would, though. Kragen -- Kragen Sitaker The sages do not believe that making no mistakes is a blessing. They believe, rather, that the great virtue of man lies in his ability to correct his mistakes and continually make a new man of himself. -- Wang Yang-Ming