48-Hour Days

A few weeks back the CWSA held a roundtable discussion about form design and development. You were there, weren’t you?

One of the topics brought up was how to enter in dates. Date pickers can be clumsy and ugly, with a host of browser compatibility issues. Providing a blank text field is confusing for the user. Several comboboxes can work, but they get long and there’s lots of mousing involved.

Someone asked about the possibility of a field that would be able to take a value such as “yesterday” or “last monday” and get the right date. There seemed to be some general agreement that this was a great way to go. Let me tell you about my experiences with that.

NSDateFormatter

In Cocoa, we have this really cool object called NSDateFormatter. This object has the sole purpose of taking user-entered date strings and converting them into NSDate objects. It can also take an NSDate object and present a string representation in the format you choose. Cool, right? Wait, it gets better.

With the allowNaturalLanguage option, your fancy-schmancy formatter will also take strings such as “yesterday” and “last monday”, parse it out, and provide the correct date in an NSDate object! We use this functionality all the time in our GUI applications. It really does work quite well.

Since we use an antique version of WebObjects to build our web applications, we are writing them in Objective-C, which means that we have NSDateFormatter available for our date fields on our web forms.

From the beginning, NSDateFormatters have been used to allow our users to enter dates in just about any way they wanted to. We thought it was so cool that a member could type in “today” and get the correct date. It would be great not to require a specific format and allow the user to enter the dates in whatever way came naturally to them. There would be no training required, no questions about how to enter the data. Users would love it!

User Understanding

Our users are constantly confused about how to enter dates. When they ask and we reply, “You can enter the date in any format you wish” they still don’t get it.

“Do I have to use dashes?”

“Yes, you can enter them that way. Or you can just type ‘today’ and it will get the right date.”

“What, the word ‘today’?”

“Yes, or ‘last week’ or ‘next monday’. However you want to enter the date, you can.”

“Okay, so dashes will work, right?”

“Yes, dashes will work.”

I’ve had that conversation over and over, and I know a few others I work with have, too.

Caveat

I do have a caveat to this. Our site was not designed for usability. It was created, written, and designed by developers. Admittedly, the site is complex and hardly user-friendly. Date entry is certainly not the only thing that confuses our users.

Going Forward

We have a port coming up of all of our web applications. Chances are, they won’t be written in Objective-C anymore, which means no more NSDateFormatter. I will not mourn its loss.

The next iteration of our site should be much more user-friendly, as it will be designed with usability in mind. Even so, I will provide a text field with a strictly enforced format. I have learned my lesson. For our users, at least, more choices = more confusion. While parsing out normal English, providing a text field with a strict format requirement will remove all questions about how to enter data.

Take aways

For me, I have more than the concrete takeaway of a strict date-entry format. It is a huge reminder to keep focused on the users and not on what I think is really cool. I’m a geek, my users are not. My users tend to be quite computer illiterate. I see this slowly changing as our oldest members retire and new, Internet-savvy members come in, but it will be a long process.

Lesson for others? Perhaps it is just to remember that even the coolest features might not be the most user-friendly features. Yes, they are a ton of fun for us to implement and they make our fellow developers “ooh” and “aahh”, but stay focused on your users. After all, they are the reason you’re building that site in the first place.

With all the problems with Permalinks lately, you might be wondering if I’ve lost my fabulous theme as well. Nope. I’m naked today.

April 9^th is CSS Naked Day this year. Today web developers and designers all around the world will be showing off their mastery of web standards in two ways:

First, our design is separate from our content. Content is marked up using (X)HTML and does not contain <font> or (gulp) <marquee> tags. All colors, fonts, sizes, backgrounds, etc. are defined in external CSS files that are organized and easy to update (they are organized, right?). These CSS files are site-wide (as much as possible) and are cached by browsers, making our pages faster to load.

Second, our content is marked up semantically and can easily be used without all the fancy styling. Part of my development process is to review the pages I’m working on with CSS turned off. The fabulous Web Developer Toolbar for FireFox makes this extremely easy and no web developer/designer has an excuse for not taking this step.

Disclaimer

Now, this site is actually a bit of a cop-out. I don’t have any static pages at the moment, I’m running WordPress. I didn’t even write my own templates. All I had to do was install a plug-in.

BUT I do use web standards in my everyday work. I inherited quite a large and complex site built using software that generates HTML 1.0 and full of table-based design. It started out as two web applications and has doubled since I became responsible. Slowly, old pages are worked on and brought up to date. But mostly I’ve been adding new pages or replacing old parts of the app with new parts, etc. These are all written using XHTML and CSS.

So, even though I didn’t code this site, I am participating in CSS Naked Day to show that I do use web standards.

With all the problems with Permalinks lately, you might be wondering if I’ve lost my fabulous theme as well. Nope. I’m naked today.

April 9^th is CSS Naked Day this year. Today web developers and designers all around the world will be showing off their mastery of web standards in two ways:

First, our design is separate from our content. Content is marked up using (X)HTML and does not contain <font> or (gulp) <marquee> tags. All colors, fonts, sizes, backgrounds, etc. are defined in external CSS files that are organized and easy to update (they are organized, right?). These CSS files are site-wide (as much as possible) and are cached by browsers, making our pages faster to load.

Second, our content is marked up semantically and can easily be used without all the fancy styling. Part of my development process is to review the pages I’m working on with CSS turned off. The fabulous Web Developer Toolbar for Firefox makes this extremely easy and no web developer/designer has an excuse for not taking this step.

Disclaimer

Now, this site is actually a bit of a cop-out. I don’t have any static pages at the moment, I’m running WordPress. I didn’t even write my own templates. All I had to do was install a plug-in.

BUT I do use web standards in my everyday work. I inherited quite a large and complex site built using software that generates HTML 1.0 and full of table-based design. It started out as two web applications and has doubled since I became responsible. Slowly, old pages are worked on and brought up to date. But mostly I’ve been adding new pages or replacing old parts of the app with new parts, etc. These are all written using XHTML and CSS.

So, even though I didn’t code this site, I am participating in CSS Naked Day to show that I do use web standards.

A List Apart always has great stuff, but I found this issue’s articles even more relevant to my current projects.

First up, A Preview of HTML gives a great tease about what is coming. I love the idea of actual structural elements for the page itself instead of using divs all the time. I also loved seeing the benefits of both HTML and XHTML and how HTML5 will support both. It echoed some of the thoughts that have been expressed in a recent discussion on the CWSA message board.

The second article, Designing For Flow is about designing complex sites so that they get out of the way and let the user get things done. This is the whole problem with my company’s web site and exactly what I hope to focus on improving. Some really great tips in there and I’m really glad to see someone talking about complexity instead of simplicity. Some sites are necessarily complex and all those articles out there about simplifying your design don’t help me much.

Great stuff. Go read.