Speaking of user experience (see below), what do you think of this article on Microsoft's "inductive" user interface guidelines? Essentially, it argues that a good UI helps the user answer two fundamental questions when looking at a screen: "What am I supposed to do now?" and, "Where do I go from here to accomplish my next task?" The UI helps answer these questions by focusing each screen on a single task, and by providing clear links in consistent locations to secondary tasks.
I've tried to apply these guidelines in the design of my current project (a browser-based content management system), but I wonder if the principles apply primarily to infrequently-used apps? Will frequent/experienced users become annoyed at the "one screen per task" hand-holding approach of the inductive user interface? Joel Spolsky makes an interesting point about the difference between learnability and usability. I'm having a difficult time finding the right balance between the two.
Amazon.com rocks! OK, I'll admit that it's a little weird that a single site sells books, CDs, electronics, power tools and clothing. But, its product catalog notwithstanding, if I were creating an e-commerce site, I would imitate as much about Amazon.com as I thought I could get away with. I love its personalization features, and it simply makes online shopping a breeze. GoodExperience.com features an interview with Maryam Mohit, Amazon.com's V.P. of Site Development, with responsibility for the online customer experience. Want your e-commerce site to rock? Check it out.
The Design: In my ASP.NET content management system, I wanted to use a tab control to allow an author to edit individual pages of an article. I also decided to use ActiveUp's HtmlTextBox control to enable rich-text editing: it's a full-featured control at a very reasonable price.
The Problem: I quickly discovered, however, that changes to the text box weren't being saved when I switched to a different tab. After another marathon session of cursing and semi-random code-tweaking (I tried changing viewstate settings, attaching code to various page and control events, etc.), I finally concluded that the postback triggered by a change of tabs was circumventing the text box's onblur event, which is where it persists its contents. (I should mention that in my desperation, I took advantage of ActiveUp's live chat tech support feature. Pierre, the control's author, was extremely cordial and helpful. Since he's in Belgium and I tend to work in the middle of the night, the arrangement proved to be convenient for both of us!)
The Solution: Now that I understood the source of the problem, the question was: How do I force the text box to persist its data before a postback? I tried a few things, and eventually found a solution by Googling for "intercept __doPostBack": The trick was to create my own function that does whatever I need to do before a postback, and then create a function pointer that redirects the default __doPostBack function to my custom function (JavaScript is awesome, by the way). Problem solved!
Footnote: Another problem I had with the HtmlTextBox was that I couldn't get a second control on the page to work correctly. Pierre assured me that this is supported, so I took a closer look at my code. Turns out that the ID I was assigning to the second control contained a space (I create the controls dynamically based on an XML form definition -- that's a subject for another article -- and I was assigning an ID equal to the name of the data field). Replacing the space with an underscore solved that problem.
OK, here's a nugget that could have saved me several hours: XML is case-sensitive!
I'm working on a content management system which saves content objects as XML in a SQL Server database. A typical content object might look something like this:
<?xml version="1.0"?>
<Content>
<Items>
<Item Name="Title">Document Title</Item>
<Item Name="Author">Phil Weber</Item>
<Item Name="Publication">Visual Studio Magazine</Item>
<Item Name="Issue">December, 2002</Item>
<Item Name="Body">Document Body</Item>
...etc.
</Items>
</Content>
So, I wrote some code (in VB.NET, which is not case-sensitive) to extract individual content elements, and it wouldn't work -- kept returning empty strings! I spent hours poring over the code, tweaking the XML, banging my head against my desk... Turns out I was looking for an Item whose Name attribute was equal to title instead of Title. GRRRR!
Go ahead and laugh, but if you ever make a similar mistake, you'll thank me!
Welcome to philweber.net! I currently work as a software developer for FTPOnline. For most of the past year, I've been developing applications in ASP.NET; I decided to start this weblog to share my ever-growing collection of tips, techniques and stupid mistakes. I've learned this stuff the hard way; hopefully you won't have to!
