Thursday, May 15, 2008

Gooeys and...Something Clever About Usability

The other day I wandered into my boss's office and she was showing me the new system that showed her how many appointments were scheduled for the testing labs throughout the month. She was complaining that the new system did not have a way for her to view the name of the students who had made the appointments, and overall it looked like the interface was highly confusing and unproductive.

At the risk of not being very descriptive, the screen is basically set up with a toolbar frame to the left hand side where the lab and date could be selected. The rest of the screen was occupied by what resembled a weather radar...a month was shown as a line of days, one on top of the next, and the appointments showed up as colored blocks in each strip. The color indicated the amount of appointments at the moment; ie, white for none, blue for 1 to 3, etc. I was marveling at this, more because it was so overtly unnecessary for the task she needed to do: just see how busy a lab was going to be on a specific day.

Having just finished an excellent GUI class recently (my mind is clear enough to realize how good it actually was), I began thinking quite a bit about, first of all, how would one effectively display information like this in such a way to be easily accessible, understood, and useful to the user and, second of all, what the living hell possessed the programmers to change it the way they did (BSU in-house applications in general is a UI nightmare, but I'll get to that in a moment).

As an exercise, what are the tasks necessary for this kind of application, at its very core? Display data based on reservations made in a lab. How should this be displayed? Would it be easier to do a day by day or have a full month? Or even a year? We would certainly want to accommodate for at least three levels of view: daily, monthly, and weekly. How detailed would the information need to be for each of these views? If you're looking at daily you'll certainly want to see specifics: names, times, etc. This would be easily filtered by lab selection, as well as narrowing down the time span to search. Weekly...less detailed. Just indicate the number of appointments each day, allow for filtering by lab. Monthly...I could see that as just a larger weekly view, but this could arguably be made even less detailed.

In the long run how the month view would completely depend on how the day and week view were formatted. Just having a calender would seem to make sense immediately, but considering it for a second makes the flaws in this obvious; regulating so much information to such a small space would make it quickly unusable. You could also, rather than organizing it by date, organize it by lab. But this again could be difficult because it is less intuitive to navigate by lab than by date. Limiting the view to a specific lab would also be too restrictive in many ways.

Anyway, just food for thought, I'm incapable of designing something like this off the top of my head, but I may sketch up something later just to do it. This all got me thinking about another issue with Computer Science in general however...it's so focused on the theory that, when it comes right down to it, many CS people don't really know how to make USEFUL software for people. I'm sure the codebase is (fairly) solid with these in-house apps, but the fact is usability was obviously not even on their radar. Having to help lab patrons schedule an appointment is a nightmare in more ways than one. I also faced an interesting issue during finals week; when pulling up a patron's list of lab appointments, it went past the end of the tiny window. Not only was there no scroll bar, the window couldn't be resized. Fortunately the Page Down button still worked, but the first time this happened I was completely thrown. What's the point of displaying information like this when you can't easily see ALL the information?

During my GUI class I'll be the first to admit that I was one of those "I just want to code something" people. CS people, and coders in general, are like that a lot of times...they're so busy imagining the back end that the front end is just slapped on at the finish. Even the lab appointment display showed this hastiness and disregard; the coder obviously spent all his time focused on HOW he could make the UI look that way, and didn't stop to consider if it SHOULD look that way.

No comments: