User Interfaces – How should you design them ?
This is a good question, since the programming community one deals with may set “standards” of what “they” view as the proper way the user interface should look. It is not uncommon for programmers to simply copy what ever Microsoft does, since it may be felt that since they created the operating system (Windows), they should set the standards.
While it is true that it makes sense to copy standards in some areas where most people are familiar with (ie. most menus have the Files menu to the far left), this in my opinion only applies to the smaller aspects of the user interface (ie. menu layout, keyboard short cuts, etc.). The more critical aspects of the user interface should not be based simply on what everyone else is doing. Why ?
First, just because everyone else is doing it one way does not make it the best way to do something, nor does it mean it is the only way to do something. For example, Microsoft added the new interface called “Ribbons” to some of their software and now some programmers feel they have to have a ribbon in their application. Interestingly I was reading an article recently that said a survey indicated that IT managers were having a difficult time training people how to use the Ribbon interface and it was one of their bigger problems in training. Doesn’t sound like Ribbons were the best solution does it ?
Second, if we always copy how others design their interfaces, then what happens to creativity ? Some of the greatest inventions were things where the designer decided to do something totally differently. Let me for example, take something from the natural world which demonstrates why some times one must do it differently than everything else. In nature when materials get colder they always contract and get denser (more weight per volume and lesser volume). Its nice to know that all things appear to work the same. It provides consistancy. But …
There is one material that “breaks” this rule for some reason and we should be happy it does. That material is WATER (H2O) ! Why is this important ? If water contracted and got heavier (per volume) when it froze (at 32 degrees), then in very cold places, lakes would freeze solid. The ice would sink (because it was heavier) and the exposed top layer would freeze and if this occurs over and over again, eventually a lake could freeze solid. But this is not how it works in nature. Water breaks the rule and when it freezes is actually gets lighter (less dense) and this makes it float on top of the water. As the ices thickens, it stays on top of the lakes and oceans and provides a barrier which protects the water underneath so it stays warmer and does not freeze. This is why a winter fisherman can go out onto a lake, cut a hole in the ice and still catch fish. (Note: Now this is one good example of evidence of a creator).
When designing software, one needs to have that same mind set. Don’t simply copy what others do, simply thinking it always best. Consider the needs of the situation and design a user interface that accomplishs its purpose in the simplest and easiest way you can find, even if it is not the same as everyone elses. I use to design custom software for local businesses years ago (DOS based) and one rule I had was, when designing the user interface examine how the customer currently did things on paper and try to emulate this, rather than design it based on common programming practices. This made it easier for the customer to learn how to use the software, since it wasn’t all that different than what they currently were doing on paper. Now this actually required a good bit of creativity, since a computer screen is not the same as something on paper, so I had to customize every user interface to make the most out of the limited area of the screen. I created all sorts of popup overlays, scrolling screens, etc. to make it possible to get more out of the limited 80 (width) x 25 (height) screen size (in characters). In the end I had user interfaces that were unique, but to the end user they were simple and familiar. Sure I did copy something, but I copied what the end user did on paper, rather than what other programmers did on the screen. My software was so easy to learn, that I rarely had to write a manual for them and I could teach people who had little or no experience with computers how to use it in a matter of a few short hours. Amazingly some of those DOS applications designed in the mid 90’s are still in use by those customers today (2010/2011). They are just running it on Windows (but still DOS apps).
When designing the user interface, one must consider the end user. One must stop being a programmer for a bit and start thinking like the end user. It also helps to be willing to be a little creative. Don’t be afraid to try something different. Also don’t be afraid to be a little simple at times. Sometimes the best interface is one which doesn’t do anything fancy at all. Maybe a menu or some buttons is all that is needed. One problem with some interfaces is what I would call “screen clutter”. If the interface has too many choices provided at one time, then it can cause a great deal of confusion. Also try not to depend upon keyboard shortcuts for key tasks. Use keyboard shortcuts as an alternative to a task which can be done with the mouse, but make sure it still can be done with the mouse if possible. As an example of screen clutter, I recently started using the open source Blender software which is an amazing 3D animation development tool. While it is very powerful, it suffers from a number of problems with its user interface. Because it was written to be cross platform (Linux and Windows) it does a number things in ways which almost seem unnatural on Windows (ie. selecting files). This is one of the problems with cross platform software, since they tend to not fully utilize each operating systems features to the full. The second problem with Blender is that it has screen clutter. I am a programmer, so you would thing that it would be easy for me to figure out how to use an application. Not so with Blender! I found it very difficult to find things I was looking for. Sure they were there, but I could not find them. If it wasn’t for all the free tutorials on Blender on the internet, I would have been lost.
The old rule of “keep it simple” really does apply to designing user interfaces. For example, with my softwares (EZGUI )Visual Designer I at times hear complaints from new users about how it doesn’t work like everyone elses Visual Designer. OK, I admit that it does things a bit differently. But it is designed to be simple to use and you can find things organized with a minimal amount of screen clutter. Actually when I look at it, I find the interface to be very simple with little clutter on the screen, almost to the point of being too simple. This is because I like to provide interface options in “steps” rather than all at once. True, this does require a few more mouse clicks at times, but is also keeps screen clutter down and you can deal with one task at a time which makes it easier to find what you are looking for. This is not to say that it can’t be improved upon. There have been big changes made from the version 4.0 to 5.0 in the designer. I am learning myself and I am willing to make changes. Now the first reaction I could have, from the complaints from new users such as “it doesn’t work like other designers” could be to simply redesign it so it works exactly like other Designers. That is not the solution though. Maybe there are some real advantages to the way my designer works, which would be lost. Maybe the solution is to simply keep reworking the designer to find ways to make things easier for the user, while offering even more options. Take a lesson from Thomas Edison. He went through over a 1000 failures when trying to find the right material for the wire in light bulbs, but eventually he hit on the right one. He wasn’t afraid to fail a few times until he got it right, but when he got it right, he had an invention that would change the world. So to with sofware. Just because your first attempt with the user interface didn’t come out perfect, doesn’t mean you have failed. Likely you got some things right, while some other things you got wrong. Don’t give up now! View it as a learning experience. Keep what works and then find ways to improve what didn’t. Feedback from end users is important. Now don’t take it personally when a few complain that it does not work exactly like “so and so’s software”. Everybody has their opinion and you can’t please everyone. So instead of giving up or rewriting your software to look just like “so and so’s”, first ask your end users what specifically do they find difficult to do with your software. Find out what really is the problem (ie. it takes too many steps to do such and such or you simply can’t do it at all). View things as “tasks”. Find what tasks the end users need to do and offer solutions to solve their problems.
Lastly, don’t give up on your unique vision of what you want to accomplish with your software. The truth is that the end users don’t dictate everything. Some times you have to stick to your vision of the software, even if initially end users may not understand. I don’t know how many times I added a feature to EZGUI, not because it was requested by end users, but because I personally saw the value of it. As I used my own software, I would often say, “now this would be really cool if I could do this or that”. I didn’t get bogged down on whether I could market the feature or whether enough end users were requesting it. I simply asked myself, “will this solve a problem which is mportant to solve”. Often it was only after end users started playing with the new feature that they would turn around and say “I really love this feature”, even though they never thought of it before. Some times its the simple stuff that makes a difference. For example recently a customer who is working with the PreRelease version of EZGUI 5.0 commented about a very simple little feature I threw in. No one requested it. I didn’t copy it from what others were doing. Just one day, I had a brainstorm and thought, it would be nice to allow controls to have their own private timer events. That customer still keeps commenting about how much he loves this little feature and uses it all the time. It was a small thing, but it is very useful and I knew that, which is why I added the feature.
When it comes to user interfaces, one needs to have the same “inventor” spirit and to be willing to try something different even if no one asks for it. Have a vision in your mind of what you want to accomplish and like Thomas Edison, don’t be afraid of a few failures. You learn from each mistake, but that does not mean the vision itself was wrong. Thomas Edison knew the light bulb would revolutize the world and it did. He was willing to learn from a lot of failures before he got his final vision, but the world thanks him for it (I surely wouldn’t want to be still using old fashioned oil lamps today). In the software industry today, everybody wants to follow the leaders so there are less inventors and artists today like Edison. True there are many talented programmers today, but maybe we need to be a little more like Edison. I am not afraid to admit that my own software EZGUI has had its own weaknesses in the past. Yet it also had many strengths with features not found in others and I built upon that vision. Each new version of EZGUI grows and develops as I see ways to tap into those strengths, while removing the weaknesses. One time someone (not a customer) called my EZGUI’s visual designer “substandard” and “ugly”. Sure that hurts, but like Edison one must realize that some weaknesses in ones invention does not mean it is a total failure. Also what some may view as “ugly” may simply be because it is overly simple and that is not always bad. I have made signficant changes in EZGUI 5.0’s designer, but not simply to make it more “pretty”, but to make it more useful and powerful and easier to use. I do find it interesting that while my designers interface on the surface was viewed as ugly by some, my customers have often commented about how it generates such rock solid and readable source code. I have also tried to listen to my customers and make changes when possible. The problem with my Visual Designer (which is only a small part of the product) is that I do things differently and that is the first thing people notice. “Its not like everyone elses software” so it is assumed it is weak.
But a case in point is the kind of software some of my customers are developing with the tool. My Designer is a programming tool and it should be weighed by what end users accomplish with it. For example the early versions of EZGUI’s designers (1.0, 2.0 and 3.0) were very rudimentary in my opinion and I developed them. They were simple and not “pretty”. But yet customers did a lot with them. Why ? Because the purpose was not to be an all enclusive visual designer, but simply to be a code generator for what was really important in my product which was the GUI engine. Customers would often comment about how they (those rudimentary designers) generated such clean and readable code which ran flawlessly when compiled. You see, my “vision” of my product was not to build the next “Visual Basic” clone, but it was to build a power GUI engine (DLL). The designer originally was only an after thought, but eventually became a necessary part of the product. I do have some customers who write their entire application using EZGUI without using the Visual Designer at all. They hand code everything and no other Visual Designer tool can accomplish that. Its because the “vision” is the GUI engine and it still is. When I look at the quality of the applications created by some of my customers, then I realize the vision made sense.
Now this does not mean I can’t improve things and I am. EZGUI 4.0 was the first time I started concentrating on the Visual Designer in EZGUI, which is why I am a bit behind in some areas. I was concentrating so much on the GUI engine, I was not spending enough time on the Visual Designer. Now the vision is changing, just slightly and the Designer is getting big improvements, but the core vision is still the same and thats what makes my software unique. I am willing to be different, even if I get picked on for it. I am not saying my software is the best thing since apple pie and better than everyone elses. It is just that I have a vision for the software to fulfill a specific need and I am working hard to fulfull that need. Its nice that there are alternatives when it comes to software. What I design my not be everybodies favorite, but to those who are productive with it, it makes a difference to them.
A part of the user interface of a software product which is not always apparent is that below the interface the software must accomplish a task. The user interface is just the means for the user to communicate to the software what they want, so the software can then do the work it was designed for. You don’t design a user interface to just be like everyone elses or to look pretty. You design it so the user can effectively communicate to the software what they want, so the software gets the information it requires in the most efficient way possible. If what the software does “under the hood” is different than other applications, then its user interface needs to be different than other applications. This is one of the reasons my EZGUI Visual Designer is so different than everyone elses. You see the Designers purposes is to generate source code for use with the EZGUI GUI engine (DLL). The interface is designed to get information from the user to match that task, so it often must request different information that other Designers. For example EZGUI uses a palette of colors (indexed) rather than simply standalone RGB values, so when you select a color for a control you are given the ability to simply select a color from the palette rather than just select any RGB color. This is different. Then there has to be a place for the user to change that palette, which there is. Fonts work the same way. Fonts are selected from predefined font indexes. While you can select a custom font, you also normally select a font for a control from one of the predefined indexes (0 to 5 are fixed and 6 to 9 are user defineable), which is why my interface is different. But the advantage of this technique (which matchs the GUI engine) is that if I set all the controls to say font # 9, I can then change font # 9 to a different font definition and every control in the project (all forms) which use that font are all changed at once. I don’t think do that so easily with other Visual Design tools.
So you see, it is important to not compare your applications user interface to others or to copy them. Design your interface so it does the task your application needs to do. Base your interface on how your application does things behind the scenes. If your underlying code in the applications does things differently than others, then don’t be afraid to make the interface work differently. Design the interface so it best suits the needs of the underlying code. Make the interface as simple as possible. Emulate real work objects, if the software is doing the same task, rather than design it to look like everyone elses software. If the end user sees the relationship between the interface and say some real world object associated with the task (ie. software controls external hardware), they will more quickly understand it. Don’t be afraid to experiment, like Edison, with totally different interfaces. Have a vision of what you want to accomplish with the software and stick to that vision. Be willing to make changes when necessary and listen to user feedback, but remember not to let user feedback override the vision you have for the software. You can’t please everyone.