I am continuously amazed by how I am thought to be ignorant of the knowledge required to perform my profession, and how I manage to take comments to that effect in stride.
You hear the phrase "think outside the box" often. People don't seem to realize that there are occasions where thinking inside the box can be much more beneficial. One of these cases is software user interface development.
One of the main problems with developers for Apple and Linux is that they don't seem to care that their interfaces look nothing like anything anyone has ever seen before. Take a moment and digest that. They have designed their application with an interface that you can't look at and use without reading directions.
I guess these folks assume that their interface is so intuitive (and this is a word I'm so sick of these days that I feel ill typing it) that people will just push and pull their interface knobs exactly as expected to acheive perfect results. A prime candidate for usability and interface construction "don't dos" is the former MetaCreations line of software.
Every window of any MetaCreations tool tries to wow you with graphical design superiority. And I guess when you first see their interfaces (particularly any of the Kai lines) you think to yourself, "Man, this tool is going to kick butt!" Of course, then you try to use it. Sure, after a while you get the hang of it, but it's an effort in trial and error, grabbing unlabelled knobs and twisting them until you understand what the intention was. There may be many features that go unused because you didn't realize that that little silver dial actually moved.
Software packages that originate on Apple computers are major offenders in this area. See Adobe and Macromedia products if you need examples. They have gotten better over time, but mostly because they're moving more toward Windows and the real market share. Linux software is the worst, though.
Linux software, when it has what you can even call a GUI (graphic user interface), doesn't look anything like any other program on Linux. There is no uniformity. You can have learned how to use one program in Linux and then use that knowledge to get a jumpstart on how to use a different program. The interfaces are that different. It's a two-fold problem.
First, there are a billion different developers writing a billion different little projects, and all of them think that they know the best way to do it. They aren't consciously thinking, "I'm the supreme commander of the UI," but they really think they know how people are going to want to operate their software without actually asking anyone.
Second, the toolkit used for building those applications doesn't foster a unified interface between applications. The GTK or API in KDE (all tools for UI building in Linux) don't provide more than a bunch of tools to get things going. No one ever suggested that they be used to create a unified look. The thought was more like, "Programs might need some common UI elements, so we'll toss in a few." This is in opposition to how Microsoft has designed Windows.
In Windows development the thought is more like, "Programs should all have a standard look, so we'll provide UI elements that developes can use to make their software look standard." As a result, most of the programs you use day to day - and I'm talking about business programs now, not games - have the same look to them.
People may say it's bland, but if you show someone how to use notepad (menus, title bar, task bar, copy, paste, etc.) then they pretty much know how to use Word. The stuff that they don't know is all in one place, rather than organized in an interface that only makes sense to the developers of that one piece of software.
I can't emphasize this enough. People simply don't realize how much easier computers are to learn and use when everything looks the same. I can't fathom folks who admit to liking the weird interfaces. I don't understand why a developer would want to hinder their users in this way. This brings me to my work dilemma.
Our new product for work is a web based application that provides an interface to documents for students and teachers. These details are important because as with writing, software developers have to be fundamentally aware of the capabilities of their users. If a user of your program can't use your advanced features, then those features need to be made more obvious or excised.
I have endeavored to develop an interface that is mostly bland so that our users (computer novices, especially in the case of teachers) aren't overwhelmed by options. I have tried to create a standard to which the entire program can conform.
For example, since our interface uses buttons to cause actions, I proposed that the entire interface should use buttons rather than links, as would otherwise be common on a web page. Why? Because it would be weird if you've been using buttons to navigate and process data for 20 minutes, and then when you look for the next function it's in the form of a link. In fact, it's the only link in the whole application. So why shouldn't that be a button instead?
I've also tried to approach the interface design from a viewpoint of a student or teacher attempting to access it. What would a student most want to get from the software, and how can I make that most available to them? In doing this, I have designed a home page that displays all of a student's current required work, creating a valuable summary.
So far, my comments back from test users amount to things like:
"The buttons are too small." - Maybe the buttons are small. But they are no smaller than standard interface elements that one must use to operate Windows. I can't account for your inability to target a button with the mouse. It's also funny how you can know everything about a child's computer use - whether they would be able to aim and click on something so small. Just because you're epileptic and can't click your desktop wallpaper doesn't mean that a kid can't do it. Why not stick it in front of a kid and let them try to click it?
"This screen is too busy." - This in my mind is just a testament to the amount of work that students must perform these days. Even after I've done as much as I can to unclutter the homework list, the students still have that much homework. I think this is a problem you really need to take up with the teachers.
"We need an in-between screen here." - What information would this screen contain? Will it provide any summary information to the user? Nothing? No? I'll tell you what purpose this in-between screen serves - none.
"The backgrounds should be more colorful." - Yes, thank you for focusing on functionality and usability and not cluttering my simplified interface with intense school logos and intrinsically high-contrast backgrounds.
"We don't need any of that descriptive information." - I'm trying to provide a way for a student to differentiate Mr. Smith's class from Mr. Jones'. If I don't put whos class it is in the class information, then how do they know? And so what if it appears every time? After it's there, it's pretty easy to ignore. The things that are under it on the page are not suffering for being so low down. Unlike a sales page, where it's important to get most of your message to appear "above the fold", these pages have the information the students need, and they already know it's there. Besides, you're the one who told me to put that stuff in there in the first place!
I'm willing to concede when I've done something wrong. I'm not so proud. But I have been doing this for a long time. I have had a chance to study it in the real word for a long time. I've been using computers in a programming capacity for 22 years. Professionally for 10. Even these statements are taken with incredulity.
"Because you're so involved in it," they say, "you don't know when something is easy or hard because everything is easy for you." What?! That's like saying that because I'm a professional, I know nothing about my profession. It's ridiculous.
My knowledge has been gained from years of creating my own interfaces, studying the user response to them, studying and critiquing the interfaces of others, and rebuilding those interfaces for improvement all with the eye of a developer who writes software for users other than himself. I have attempted throughout my career to hone all of that knowledge into a marketable skill. I should be able to tell you whether an interface is effective or cumbersome without spending more than a few minutes using it. ...without spending any time using it.
Clearly, I put none of that thought into the creation of this product.
I will freely admit that there are pieces of this software that didn't turn out like I had hoped due to the nature in which is was developed. But there were time constraints. Concessions were made in certain areas to get a living prototype online quickly. The bothersome part of it all is that the things that I see as clear problems that slipped through due to these consessions have not even been mentioned in the reports I get about usability.
Instead, they want to fluff the interface. It may not be less usable as a result, but it will certainly become wide. It's like the irritation of reading the newspaper. Why is the thing so darn big? Even if you fold it, it's still inconvenient, isn't it? Maybe it's just me, but I believe we would all be better off if the paper was 9x12.
So there's nothing left to do but give in. I have held to my principals from the very beginning of the design of this project, and I can only press it so many times to have it met with impassable resistance before I just don't care. Hopefully I'll be able to throw out all of the tenets of usability that I've managed to instill in this project in a way that will let me recall them when they later come to realize their error.
What you don't know about interface design can kill your project. Making it look flashy up front can get people in the door, but if the UI doesn't sail when it's running, you're dead in the water.
