Chapter 7: Adding a Web Interface

The Web has given us a whole new way of looking at software. Not only can you browse web pages, but you can create software that actually puts the Web to use; such software can grab files off the Web, process them, or whatever you want. From a technical perspective, creating software that interacts with the Web is pretty easy, thanks to the abundance of helper libraries. I would argue, however, that creating software that is highly useable is actually much harder. Read on for the details.

Accessing Data over the Web

In this first main section, I talk all about the issues of accessing data that’s out there on the Web. Although I do provide a tiny bit of code here, the focus, of course, is on usability. Let’s get started with a fun anecdote, and then you can move on.

Embedding a Browser (Yawn)

Microsoft made it easy: Want to add a web browser window to your program? Turns out, the center window in Internet Explorer (the part of the window that holds the web page) is an ActiveX component. That means that you can embed a web browser in any application without having to write your own! And because every Windows computer includes Internet Explorer, you can be assured that the users will have the ActiveX component already on their computer. What could be easier! If you want a web interface in your program, all you have to do is embed the Internet Explorer ActiveX component in your window.

But why? What would you gain? Would you like the users to be able to surf the Web right from within your application? What would be the point? Not much.

Now, in all fairness, including a web browser inside your program does have its places and benefits. For example, for the last couple of years, Intuit’s fine product TurboTax has included a web browser inside it for the purpose of allowing you to set up your bank accounts. The assumption, of course, is that your bank provides a website for setting up your accounts, and you can access the site from within TurboTax, without having to switch over to a web browser.

But such examples are few and far between. Instead, the web browser component is useful for displaying data that is encoded in HTML. And more likely, your application can benefit from accessing data over the Web and processing the data, rather than just displaying browser web pages.

Even though to the average user the Web consists of billions of web pages, in reality those web pages are data. Further, the web servers hosting the web pages can have web services, which are, at the most fundamental level, suppliers of more data.

REAL WORLD SCENARIO: Paper Towel Fun

Ahhhhh, paper towels. Gotta love them. They cover the floors of our public restrooms, while allowing us the convenience of drying our hands without the hygiene problems of sharing cloth towels as we do at home.

While paper towels may be a great invention, the real ingenuity comes from the devices that dispense the paper towels. Now I don’t mean to diss any Paper and Pulp Engineers who might be reading this book (yes, that’s a real major; they had it at my university). I’m sure they’re very talented people. But right now I want to talk about the dispensers. These are the works of our friends, the mechanical engineers.

The other day I was at a local franchise of a popular bookstore chain (its name starts with a B), and in the men’s room they had a paper towel dispenser that was simply a tall, thin metal box attached to the wall. The paper towels were all stacked neatly inside the box, and the box was sized such that they fit perfectly. The hole for grabbing the paper towels was on the bottom. And what happened when I pulled out one paper towel? The one came out and stayed in my hand, and a dozen or so over-eager paper towels promptly climbed on out in hopes of joining their comrade but instead ended up on the floor.

But the solution to this remarkable device isn’t straightforward! Suppose the hole were instead on top. Then soon the only people who would be able to reach the paper towels would be those with really long, narrow arms as the stack inside gets lower and lower. The rest of us would have to make do with wet hands. And you certainly couldn’t just leave the front of the device open, for two reasons: First, the towels would probably fall out. And second, this device would qualify too closely as a shelf, and people might not respect it for the original invention that it was.

But a funny thing happened: The young college students who worked at this store seemed to come up with a pretty good solution: They just stacked a few towels on top of the dispenser. Yes, that’s not all that different from the version of the dispenser that has no front. But it works. In fact, here’s an even better solution: Skip the dispenser altogether and just leave a stack of paper towels on the counter.

But wait; that’s not the best either: People with wet hands before me end up getting my paper towels wet. Gross.

What to do? I guess we’ll just have to wait, and as our planet’s culture evolves, maybe some sharp young minds of the 22nd century will come up with the best paper towel dispenser. Until then, I’ll just keep my complaints to myself.

The data that consists of web pages is, of course, in HTML format. The data dished out by web services, however, is in whatever format the developers of the web services choose. (Most likely, the data comes down encoded in XML, and on your end you use the SOAP protocol to decode it.)

This book isn’t a tutorial on web services. Instead, I want to share with you how web services can fit into your application, while providing you with a bit of background on web services, if you’re not familiar with them. And if you are familiar, you might find that my suggestions are a bit unusual and out of the ordinary. That’s okay; I’m not your typical engineer. I myself am a bit unusual and out of the ordinary.

In the sections that follow, I talk about how you can access data that’s in HTML format using the HTTP protocol and how you can access data in other formats using web services. But the goal isn’t to teach you how to code; the goal is to demonstrate how you can do these things while creating the most useable software possible.

Tip

One particularly interesting use of a web browser control is in displaying local files. This is most often done for online help and e-books. Using this method, you can actually create a sophisticated user interface completely in HTML. However, you want to be careful, because if you’re using the Internet Explorer control on Windows, you could inadvertently give your users the ability to surf the Web from your program if you allow them to somehow enter a URL or if your local web pages include a link to a page such as a search engine. That might seem a bit strange to the users.

Requiring an Internet Connection?

These days, you can be pretty sure that the majority of your users will have an Internet connection. Therefore, you’re safe in writing software that expects an Internet connection. However, remember the following:

RULE

Your users might not always be online, so don’t require that they stay online. What if they’re using your software on a laptop on an airplane or on the subway?

And on a similar note:

RULE

Many users still have slow dialup connections. Don’t require them to have high-speed Internet yet.

But on the other hand, don’t write your software strictly for the lowest common denominator, assuming that they don’t have high-speed Internet or any Internet at all. Instead, write your software to have additional features that can support the high-speed Internet, but include features that also allow for a slower connection or no connection at all. In other words:

RULE

Write software that caters to everybody: those with a high-speed Internet connection, those with a slow connection, and those with no connection at all.

Of course, you will find exceptions to these rules. If you’re writing a streaming audio program, then the software can’t really function without an Internet connection.

Tip

However, I can think of a way around that one, too: Let the users download the streams beforehand and listen to them without a connection, provided the copyrights of the audio files allow for downloading. See, there’s always a way, and never say it can’t be done.

How do you make allowances for this varying crowd? Here’s how. For starters, your software can detect the connection speed. If it finds a high-speed connection, then include the extra features. Is your software downloading images? Then the high-speed people can download higher-quality images. If the connection is slower, give the users an option: Would they like to download a poorer image, or would they like to download a higher-quality image? But don’t ask this question every time the program wants to download an image; that would be a major annoyance. Instead, consider asking it only once, and include clear instructions about how to change the preference later on in your Options dialog (which you will have, right?).

If your application is downloading general data, not just images, then if it detects a high-speed connection, it can download larger batches of data more quickly. If it detects a slower connection, it can download only the absolute minimum data and grab more data as it is needed.

Your application can also behave in a hybrid mode: If the user is on a high-speed connection, in the background your application can download large amounts of data very quickly, save it to the hard drive, and then have the data available later if the user is working offline. (This is especially useful when your software runs on a laptop computer.) And again, make this hybrid mode an option.

And what about the people with no connection at all? Some software, of course, requires an Internet connection. But for other software, you might provide default data that the user can work with. Here’s an example: Suppose you’re writing a specialized word processing tool or graphics layout tool that includes templates for helping the users get started. Here are three different things you can include all at once within your program to cater to the different users:

• Default templates that are easy to use

• The option for downloading more templates

• The option for high-speed users to download even more advanced templates, with megabytes of sample images and text

These features would be available in a single software package. And there’s nothing new here; I’m just laying it out in plain human language. Think of an e-mail program. When you’re traveling, you might use Hotmail or Yahoo! Mail to check your e-mail, forgoing the downloading of huge attachments. Once home, you might download all your e-mail to your laptop while on the high-speed connection. But you might not be ready to read all the massive PDF files somebody sent you until you’re back on the airplane, headed for your next destination.

Retrieving Data on the Web

Web servers usually offer their web pages as HTML files and then transfer the files using the HTTP protocol.

Tip

Remember, HTTP is just a protocol, and when you specify a URL, your prefix of http:// is not actually part of the address but rather a directive to the browser to use the HTTP protocol.

Using various libraries, you can retrieve data from the Web using HTTP. For example, I’ve seen some weather programs that download files from The Weather Channel site (http://www.weather.com), process the information to extract the current temperature and forecast, and then render the data in their own format. (I find it hard to believe that this happens with The Weather Channel’s blessing, but to each his own. Be careful if you choose to use this method using data from somebody else’s website.)

Files on a web server, however, don’t have to be in HTML format but can still be accessed via HTTP. The HTTP protocol specifies that in addition to the HTML file (or whatever type of file it is), the client software will first get a list of headers. These headers specify information about the file. This is how your browser knows that a PDF file, for example, is a PDF file even if it doesn’t have a .pdf filename extension. Here’s an example of the headers from my own website:

 HTTP/1.1 200 OK  Date: Mon, 08 Sep 2003 02:17:10 GMT  Server: Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.46  OpenSSL/0.9.6g DAV/2 FrontPage/5.0.2.2634 PHP/4.3.2 mod_gzip/2.0.26.1a  Last-Modified: Sat, 09 Aug 2003 15:50:57 GMT  ETag: "14011503-c32-eb3e1a40"  Accept-Ranges: bytes  Content-Length: 3122  Connection: close  Content-Type: text/html 

This includes a lot of blah-blah information, but the important part is the final header, which says that the content type is text/html. That means the file is text with HTML markups. For a PDF file, you’ll see this header (in addition to others):

 Content-Type: application/pdf 

This data is all used by the browser. However, if you’re using an HTTP library to access data via the HTTP protocol, your own client application is free to ignore all this information. In other words, you don’t have to embed any specific content type header. I recommend that you do, however, in case somebody happens across the link and tries to access it with a browser. For example, suppose you have data on your web server for a popular program you have written, and you save that data at http://www.Sybex.com/mydata.abc. The .abc file format is your own special file format. If you put this file on your server, and you have an Apache web server, for example, Apache will not know what type of file it is, and will, by default, send it down with a basic text header of type text/plain. If web surfers happen across a link pointing to this file, and they type the address into their browser, they’ll see the file rendered in text format.

Tip

For sensitive or secure information, however, I hope you wouldn’t just make it available via nonsecure HTTP; for that I would recommend more security.

By default, Apache uses the filename extension to make an assumption about what type a file is. You can, however, easily configure Apache to do otherwise, or, if you’re not the administrator and can’t modify Apache’s configuration files, then I recommend that you create a CGI script that specifies the headers. Here’s an example in Perl, which sends down four bytes (1, 2, 5, 10):

 #!/usr/bin/perl  print "Content-Length: 4  print "Content-type: custom/abc  $data = pack("CCCC", 1, 2, 5, 10);  print $data; 

Tip

Instead of hard-coding the data into the script, however, you could have the script read the data from a file.

Now your client program can easily access your data via this CGI script. And if somebody tries to access the file via a web browser, the browser won’t display the file as corrupted text, at least in theory . Netscape, in fact, responds by saying it doesn’t recognize the file type and wants to know if it should download the file. Internet Explorer, however, makes a fundamental assumption: If it can’t figure out the file type, then the file must be plain text. Oops! That’s bad, unfortunately.

A slightly modified solution, then, is to cheat. This is nothing more than a hack; I admit it, but it works: Make the content type image/gif. Make sure you include a length header as I did here, and make sure it matches the data size. (Otherwise the browser will hang waiting for more data, although that, I suppose, would also prevent people from looking at it.) Then the browser will display just an icon representing a corrupted image. (Hey, it works; you have to admit it.) You can use this line for the Content-type line:

 print "Content-type: image/gif 

Warning

Now remember, however, I want to reiterate that this is not a secure method. This will not prevent people from gaining access to the data. Instead, it will just stop them from looking at the data in their browser.

REAL WORLD SCENARIO: Talking Cars—Shut Up, I’m Trying to Drive!

Back in Chapter 2, “Modeling the Real World,” I told a story about the car that had the all-digital dashboard and what a disaster that was. I briefly mentioned the fact that the car talked. And now I want to tell you more about that. My dad owned a talking car, and this car had a whole host of usability problems, um, waiting to be complained about.

If the car was running low on fuel, the car would loudly announce, “Your fuel is low!” It would then do so every 10 miles or so. “I know, I know, give me a minute to get to the stupid gas station!” This was the mid-1980s, and if you remember back then and recall seeing a bunch of people driving down the roads, hands tightly clenching their steering wheels, and they seemed to be angry and shouting at nobody, then you know what they were doing: They were yelling at their talking cars!

But it wasn’t just the fuel the car talked about. He (I mean it) had all kinds of things it liked to discuss. If you started up the car while somebody was still climbing in, the car would proudly announce, “A door is ajar.” Now I clearly remember my young cousin Leah, who at the time was maybe six, heard this and said, “Why does the car say a door is ajar?” We all explained that it’s saying so because the door is opened. Then suddenly we realized what she was really asking: “Why does the car say a door is a jar?” Oops, noun trouble. She heard the word jar. And we then had to explain what this new word ajar meant.

Talking Car Usability Rule Number 1: If you’re going to make the car talk, at least use common words!

Then there was the day my poor mother was driving the car home from work when suddenly the car shouted, “Urgent! Severe engine problem occurring! Please get the car in for maintenance immediately!” She managed to drive the rest of the way home (apparently the problem wasn’t that bad), walked into the house stark white, and my poor dad thought she’d had a heart attack. (I think that’s when she took up smoking again, but I’m not sure.)

Talking Car Usability Rule Number 2: DON’T.

Forget the talking cars. And talking software? I turn on my speakers only when I want to listen to a CD. If your software talks, you better have it give me feedback in other ways, too, because otherwise I won’t hear it. Seriously? Make it an option. Low-vision people can benefit from talking software; deaf people would not need the option. People who can both see and hear might want it or might not. Yes, an option is good, unlike the talking car, which wouldn’t let us turn off the sound. (We got rid of it.)

And before I finish this story, while on the topic of annoying sound, don’t even get me started on those websites that have annoying (and often cheesy MIDI-quality) music playing in the background. One editor of this book had a problem where he was shopping for a gift for his wife, and when he got to the website, he got bombarded with sound that gave away what site he was on. As a result, his wife, who was in the other room, couldn’t help but know what he was buying for her!

Once you have your CGI script in place, your client program can easily download the data using any of the widely available HTTP libraries. (And please, don’t write your own HTTP library unless you’re an HTTP expert. Your job is to focus on your client program, not on writing an HTTP library. You want to ship your software on time, right? This is a book about usability, after all, and I want to encourage you to keep your software shipping on time and without bugs.)

Since this book isn’t a coding book, I’ll stop here on the data transfer methods, because you get the idea.