|
ow that this column has been running for a while, fueled mainly by technical questions and answers from the Microsoft internal customer support archives, it seems like a good time to add a personal touch on a topic we've all come to know and fear—usability. It's that elusive quality that even the slickest and most professional of Web sites often pay little attention to. Starting this month, I'll be adding my own take on usability issues. Some will undoubtedly be long-held pet peeves dating back to my years as Web Producer here, while others will chronicle the newest and most advanced techniques designed to aggravate users. Most issues will concern Web applications, but I'll leave the door open.
A Case for Usability
OK, you've heard it all before—even the coolest bell or whistle is useless if a user can't figure it out. When the Internet was young (really young) everybody gravitated to coolness. The more a site blinked, the better it was. It was a novelty. Now everyone uses the Internet for serious research, even if it's only to find the best deal on a stereo system, and users don't have even seconds to waste on confusing features. As the Internet matures, what will be the difference between two retailers who, for instance, offer the exact same products at the exact same prices and provide the same customer service? I'll put my money on usability. When Expedia television ads focus solely on a new back-button feature—not on prices or destinations—you know usability has earned its place in the Internet issues Hall of Fame.
When looking at usability, it's very important that you observe the habits of real users, or at least people who would really be interested in your site or your products. It's practically guaranteed that precisely the user you want to get as a customer, the user who planned to buy from your site, is the user you really aggravate. It's not the casual surfer who happened upon your site with no intention of buying. Don't believe it? Try this simple experiment. Next time someone tells you about a really frustrating Web site they tried to use that focuses on something you're not very interested in, let's say a site that sells Victorian-inspired wallpaper, try to use it yourself. I'll bet you don't find it nearly as frustrating. Why? Because you don't care. You never planned to order anything, so if you can't find the order page, it won't raise your blood pressure. That's right. The person who walks away from your site in frustration is exactly the user who would have been a customer if the site were more intuitive. Chalk up one for the competition.
Search What?
The first issue may not be deadly, but it bears inclusion. How many Web sites do you see that, when you navigate to their search page, give you the option of searching the entire Web? Why would you want to search the Web when you have your own favorite search engines that you use all the time?
On the subject of search, any site whose content is navigated overwhelmingly through the search page, let's say an auction site or bookseller, should offer a search box on every single page. It's time-consuming and frustrating for the user to have to navigate back to a search page every couple of seconds. And it doesn't make sense from a server resource perspective either. Why would you want to force a round-trip to the server in between every single search? If people search your site a lot, put a search box on every page. Period.
Text, Text, and More Text
I often read long articles online. Frequently there's nothing in the frame with the article but text. Not a graphic in site. Yet many site designers have decided to feed the audience only a couple of paragraphs of text at a time, leaving the user to click the Next button 10 times to get through the article. Why? Text is the smallest, fastest thing you can download from the Internet. At home, my connection sometimes times out between paragraphs of some important article I'm reading. It's tremendously frustrating knowing that I could have downloaded the entire article in just seconds the first time I accessed the page. And once again, this approach forces many round-trips to the server. It's a lose-lose proposition. It only seems to make sense when an article is a news story following the inverted pyramid structure. Then it's safe to assume that as the article gets into less important details, more people will just stop reading. But this rule does not apply to all types of presentations, which goes to show what happens when you follow the rules!
Homeward Bound
This next issue is so obvious that I suppose that's the reason it's all too frequently overlooked. It's the need to have a link back to the home page or some other orienting mechanism on every page. Site Design 101, right? Well, then let me say that there are quite a few site builders out there who were absent from class that day. With the use of search engines as a navigational tool running rampant, you know that many users will get to your site through some lower-level page, and it looks like a black box. Who knows what's in there. This leaves them confused and disoriented.
The MSDN® Library has found a good solution to this problem with the navigational tree that appears on every page. If a user happens to get to a page without the nav tree on the left, they get a link that allows them to sync the table of contents. This turns out to be a great idea in more ways than one. Not only does it show the user where they are, the tree also serves as a graphical representation of that information relative to similar information. In addition, it offers quick and easy access to other similar information without the need for searching or aimless wandering. And it supplies information about the information. In other words, you can tell from the tree that Web Forms, for example, are part of Microsoft® .NET since they are found in the .NET branch of the tree. Looking at the tree even serves to remind users of content (or products) they would have searched for had they remembered, and even lists pages they wouldn't have thought of themselves. This is a good place to put related product categories. It's a pretty good idea all around if you can get your information into a logical, hierarchical structure.
Use and Usability
If I could name this part of the column, that's the name I'd give it, all allusions to Jane Austen aside. And believe it or not, there are some great uses out there on the Web. There are sites whose architects and designers have learned that not all users are alike. These sites offer the same merchandise to all customers, but they package the process in a number of different ways in order to appeal to a variety of customer types.
Next month I'll take a look at some of these approaches, and some of the things that are going right out there in the ether, along with the blunders I'll be bringing you each month. Right now, for the code-hungry Web warriors among us, let's move on to this month's questions and answers.
Q Within our application, we are investigating the possibility of utilizing SQL Server™ 2000 support for XML via HTTP as a method of database communications. Please tell me how this compares to other alternatives.
A SQLISAPI perf should be faster than doing the equivalent from ASP and ADO. You can scale wide by putting the SQLISAPI on middle-tier servers. If you want to get maximum flexibility (and potentially greater scalability through things like middle-tier caching that you code yourself) you need to use ASP and ADO.
In addition, you should use the SQLISAPI instead of ASP/ADO if you communicate mainly with one database and mainly through XML and stored procedures (only XML to HTML transformation logic on the middle tier). If you need complex business logic on the Web server (including many heterogeneous data sources), you still should use ASP/ADO (note that you can also use the XML features via ADO).
Q When calling into a COM object from VBScript, is there any advantage in calling a method as though it returns a value (like a function), even if, in fact, it is a sub that does not return anything? For example, if the bar method does not return a value, I would call it like so:
foo.bar arg1, arg2
My customer calls the same method as though it returns a value:
snafu = foo.bar(arg1, arg2)
In my tests, when bar returns, snafu is set to type VT_EMPTY, even if it had a different type before the call.
A There is no difference. The distinction between sub and function is one of stylistic convenience. A sub is a function that always returns VT_EMPTY; end of story.
This happens often in programming languages—two things which are very similar under the covers get different names because they represent different concepts. The designers of Visual Basic® decided that there was a sufficient semantic difference between a procedure that returns a value and one that does not to justify giving them different names. Similarly, Stroustrup made class and struct do essentially the exact same thing in C++ as far as the generated code goes, but stylistically they're quite different.
Q Is there a function in VBScript like InputBox that I can use that will let users enter data using a dialog box, but mask what they're typing. I need to be able to ask the user for their password, but not echo back what they are typing.
A In VBScript, no. If you want this functionality provided through a graphical dialog, you'll have to create your own.
For what it's worth, Windows® XP and the .NET Framework include a new component, scriptpw.dll, which provides this capability via the command line. I'm not aware of any documentation for scriptpw.dll. Here's how it works:
Set pw = CreateObject("ScriptPW.Password")
WScript.StdOut.Write "What's the magic word? "
strMagicWord = pw.GetPassword()
MsgBox strMagicWord
Q Is there a way to do a wildcard search using XSL patterns? For example, consider the following:
<rows>
<row fname="John" />
<row fname="Jenny"/>
<row fname="Scott"/>
</rows>
I would like to write a pattern search that would return "John" and "Jenny" when I search for "J*". Basically, I want the functionality of "LIKE" in SQL.
SELECT fname FROM employees WHERE fname LIKE 'J%'.
Can I do this? Also, I am still using the older 1998 XSL transform. Any suggestions?
A Old XSL doesn't have any string manipulation functions. You might try this, though it looks somewhat funny:
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="https://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<xsl:apply-templates select="//row[@fname $ige$ 'J' and
@fname $ilt$ 'K']"/>
</xsl:template>
<xsl:template match="row">
<xsl:value-of select="@fname" />,
</xsl:template>
</xsl:stylesheet>
The and @fname $ilt$ 'K' part does the trick here. $ige$ performs a case-insensitive comparison and gives all the rows whose attribute fname begins with either J , j, or greater. Restricting the resultset to be less than K or k, which is done by $ilt$, gives you what you want.
Send your questions and comments to webqa@microsoft.com. |
.gif)
.gif){kind=small}