Previous page Previous     TOC Contents     Next pageNext

LESSON 3 - Designing the application

Starting the process

When you start to work on a VB Project you are no longer just a programmer - you are now a developer. You will have to get much more involved in the whole design process. Unless you are designing an application for your own use you will have to work with a team of specialists including, but not limited to, users, analysts, GUI designer, programmers, testers, network specialist, webmaster and marketing people. The whole process is iterative - do part of it, check it, get input, go back and correct it, do the next part, and so on. Nobody expects you to do a whole project in one fell swoop - it would probably be a disaster if you did do it that way.

The importance of Users

Any project that you develop has to involve Users. They are the people who will sit in front of your interface for eight hours a day and decide if they like it or not. If they don't like it, no matter how efficient the code and how many millions of dollars were spent developing it, they will find ways to sabotage it.

Get users involved from the start. If you are developing a product to specs, that is to be sold to some client eventually, there has to be someone who knows what that eventual client needs. Find a typical user of the product to use as a sounding board. Remember: you are just the developer; no matter how cool you think it would be to use all purple text on orange backgrounds, it is the user who will tell you what is cool and what is not. As you develop more and more parts of the application, run them by the user to check for accuracy, completeness, clarity, etc.

Here's an example of how to design for clarity. Given that 01/02/03 is a date, what date is it? If you are an American, you probably automatically assume that it is January 2nd, 2003. If your user is French, however, he would assume that it is February 1st, 2003. And if you are working with this Professor, who has a very definite opinion on the subject, he would say that it is February 3rd, 2001 and should always be written as 2001-02-03. If all your forms are designed as: "Enter date" with a blank box beside it, you are headed for trouble.

Program design today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
-- Rich Cook

That's just a joke, by the way. Most users are not idiots. Sometimes they appear confused because they are trying to solve the problem and they can't figure out how. But that's not their job. Their job is to explain clearly what it is they need. Your job is to figure out how to provide it. Don't underestimate users. Be patient, be understanding without being condescending and be humble. There's a lot of things that the user knows how to do that you don't.

Creating the User Interface

The user interface that you design is the most visible and perhaps the most important part of the application. The term commonly used for this type of interface is: GUI (Graphical User Interface). It's pronounced "goo-wee", not "guy". It is graphical because it consists of buttons, menus, icons, etc. An example of a non-GUI is DOS (remember that?) where everything is text. User interface refers to the fact that it is the part of the application between the user, in front of the screen, and the code behind the screen. How well the user can interact with the code depends on the quality of the interface.


Guiding principles

  • The user is in control. The user must feel he is in charge of the application. He must have a certain amount of control over such things as window size, window position, choice of fonts, etc. There should definitely be a "Preferences" item in the menu.

  • Consistency is maintained throughout the application. The user can move to any part of the application and not have to re-learn how things work. Consistency in the choice of icons, in date formats, in error messages means that the user can concentrate on the work. As much as possible, the application should be consistent with Windows standard. For example, "Move to the Recycle Bin" is different from "Delete" - the user has come to expect that an item in the Recycle Bin can be recovered if need be.

  • Application should be "forgiving", or "fault-tolerant". Users will make mistake. A single error should not bring the application crashing to the floor. If there is no room for errors, users will be afraid to experiment, to discover on their own how to do things. It will slow the learning process considerably.

  • Always supply feedback. The user should always know that something is going on, especially if it's in the background and may take several minutes to run. Display an hourglass or a progress meter or a status bar so that the user doesn't start to hit keys at random to get something to happen. It only takes a few seconds of inactivity for the user to get frustrated and think that the program is "hanging".

  • Don't neglect esthetics. The visual aspect is important. The environment should be pleasing to the eye. The presentation style should help in understanding the information presented.

  • Interface should be simple without being simplistic. There should be a balance between simplicity and functionality. Popup menus, for example, allow you to increase the functionality without having to encumber the screen with all kinds of details which are not used 95% of the time.

On the importance of language

Throughout the project you are going to be doing, you should give some thought to the quality of the language used. As a teacher of technology, I am constantly defending the compulsory language courses included in the curriculum. I have to point out that your mastery of the language, or lack thereof, projects an image of who and what you are. This is the 21st Century - image is everything!

When I was young, a long, long time ago, in a galaxy far, far away, teachers used to say all the time: "Sloppy work is the sign of a sloppy mind!". There is a lot of truth in that. If you can't be bothered to display the interface correctly, what does that say about the rest of your work? Professionalism should be evident in every part of what you create. If what is seen by the public is of poor quality, there is reason to believe that the work behind the interface (90% of the application) is also poor.

If you are developing an application for yourself, nobody cares what it looks like. If it's a small project for a client that you know, you may be able to get away with some mistakes. Usually however, a project is broader in scope and you don't know the audience. Remember that you are now working in the global village. The interface you write and display may be seen, via the Internet, by millions and millions of critical users. Even if it's not your reputation riding on it, the reputation of your client may be. And you can be sure that he will take it seriously, even if you don't. If language is not your area of expertise, get help from somebody whose area it is.

Having said all that, I realize that I am really sticking my neck out. Although every effort has been made to make these tutorials as error-free as possible, it is inevitable that some mistakes will slip through. You are allowed to say, "Gotcha!" when you spot mistakes. Accept my apology and I will correct all errors as soon as they are spotted.

To err is human.
But it takes the Web to let millions of people know that you erred!


Interface style

One of the first decisions you have to make is whether to go SDI (Single Document Interface) or MDI (Multiple Document Interface). If you have worked with Windows for any length of time, you have probably seen both. Notepad is an SDI - you can only have one document open at any time. Word is an MDI - you can open a number of documents and switch between them at will. An MDI application imposes different constraints on the developer because of the need to juggle several different forms at the same time. It usually requires more experience in the development process. For the purposes of this tutorial, we will work only with SDI applications.

Design considerations

  • What is the purpose of the application? Is it a once-a-year thing or one that is in use 24/7? The user will forget the details if he only uses it once a year and you will have to be a lot more specific with the Help functions.

  • Who is the intended audience? Beginning users will need more directions than experienced users.

  • How many different forms will be needed (you can have several forms without being MDI) and how will they be connected?

  • What are the menus going to say? Will toolbars be used to replicate menu functions?

  • How are errors going to be identified to the user? How will they be corrected?

  • How much Help (in the form of a Help function) is going to be provided?

  • How will consistency be maintained across the application? It is important that all forms have the same "look and feel" in terms of colors, fonts, menus, toolbars, etc.

We will examine the design process in more detail as we develop the Projects in the following lessons. If you are serious about the design aspect of software, one of the best sources of information is the book:
"The Windows Interface Guidelines for Software Design" published by Microsoft Press,
reference ISBN 1-55615-679-0.

If you haven't found the Visual Basic resource you're looking for,
use our Google Search box for more information.



Home | Tutorials | Contact | Sitemap | Add URL | Privacy policy