User Oriented Development

INTRODUCTION:

When you are creating your applications or games it's very easy to drift off from the one important fact you should never drift away from. Let's rule out your own personal projects that you make for yourself and yourself only. What's left? The projects (applications, tools, utilities or games) that you make for other people to use or play with. Believe it or not, this can make the impact of your program that much different to the users of it's users. User considerations throughout your program is a way of showing that you put the extra effort in your program to make it as easy to use or play for the user as possible.

This will be the main focus of this article. User Oriented Programming essentially means that whatever part of the program that needs something from the user needs to consider certain things. This can depend on more than one thing. But in general there's always a way to improve how your programs interact with the user. We'll look at what can need user interaction, what's good to give back to the user, what's overkill and such things so that when you make your programs you can make sure to consider what you need to make using your program as pleasant as possible to the user. So let's get right to it.

USER PRESENTATION:

This is usually the first view that users get of your program. Attention to detail from the very start can make or break the success of your programs. This is regardless of it's it's a GUI application or a Text based application you still need to take care to present your application the right way to the user. How can you tell how things should be presented? There's more than one criteria to help you determine this. Let's take a look at them.

• What Type Of Program Is Being Presented:
  If you're program is a game, it's important to give the user the impression that it's a game as soon as possible. A user shouldn't start your program and get the wrong impression from it. Same thing goes for business applications as well. If you are creating a spreadsheet application, it's good that the user sees that it's a spreadsheet application from the very first screen he'll see appear. The best way to get an idea of how to present your program is to take a look at how other programs (much like yours) are presented. For example, if You open Microsoft Excel, when the program appears, you're in an empty spreadsheet document, you can see what you can do next pretty much from the very start. Same thing for Microsoft Word. Basically, you need to take the main function of your program as the guideline to what the user is going to be seeing and allowed to do (more on this later).




• What Part Of The Program Is Being Presented:
  This is where you decide what happens first and what happens next. Typically, in a game, you'd present the main gaming menu (maybe after a title page) from where the player can create his profile, start a game, view the high scores, etc. In a business application there's a couple more things to consider. When you start any Microsoft Office application, you are essentially taken to a new empty document/database/spreadsheet/presentation. This makes sense because each of these applications deal with one thing only. In Excel, you'll be doing spreadsheets, that's all. On the other hand, if you take an accounting or business management package and start that, you'll typically be taken into some kind of menu because you'll usually have more than possible thing that you can do. For example, create customers, create invoices, manage your inventory and the likes. So you need to consider what your program has to offer to it's user. Are you managing more than one independent item in your program? Questions like this one can really help determine what the user sees first.




• What is Important To See First In That Part Of The Program:
  Let's use a billing system to best illustrate this. There's more than one available and when you open those modules up, you can be taken to two possible things. The first is an empty invoice waiting to be filled. Or, you can be taken to a list of existing invoices. Both are good methods, some creators simply though that creating an invoice as soon as possible was important while others believed that seeing your invoices (and searching for them) was more important. Is one better than the other? I think in this case both can be very useful to have. Eventually you just need to reach a decision and follow up on it.

Once you worked out these starting issues, it doesn't stop there. I guess you can say that user oriented programming is kinda like error management, it's a big job to integrate after your program is done so it's a good idea to start your programming project with these items in mind right from the start so that the work can be integrated into the regular programming tasks and hence not seem as big as it is. The general rule of thumb to remember for these projects is: "The easier you make it for the user, the harder you make it on you, the programmer.". Knowing this, since you already know you have big job ahead of you, you might as well break it down into small manageable parts throughout the project rather than putting it all in at the end of the project. You'll thank yourself later. Now what are the next steps? The very next step is all about where things should be and how the user can access the features of your program.

USER NAVIGATION:

Once the user starts your program, it's very important that he doesn't have to look too long to find out what he's supposed to do. One of the key things to remember is that everything should be accessible while at the same time not being hidden within to many levels if menus or sequences of actions from the user. The main reason for that is that not many users like to have to remember six sequences of keys before they can perform an action. Since this is an article on user based programming we'll be putting the user first here. Hence, if you want to know what the user might want to do, where he might expect things to be and the likes, there's more than one tool to get that information. Let's take a look at some of the more common ones.

• You Are Your First Source Of Information:
  Yes, that's where it all starts. You're a user of some application or another. You have your own expectations and wants when you open an application or game. Hence when you create a game or program that will be used by others you need to take the time to use it yourself. IF you find a certain feature is way to difficult to reach or has to many steps to it chances are your users are going to think the same thing. If you don't have a feature and wish you did put it, again, other users are probably going to want that feature too. So what you want as a user is the first step to making a programs other will want to use.




• Pools And Surveys:
  Of course, no one expects you to know everything that everyone might possibly want in your program. IF you happen to have a website or have access to a website it might be a great idea to create a survey (or more than one) about your program. Ask the questions that you have doubts about and always leave a space to let the ones filling in the survey tell you what they think of the feature and why it must/should be there. Hence a lot of the questions you might ask that offer a set of choice in them might benefit from having an "Other" selection with a text box to let the user enter what they mean by other. The idea of the surveys to get answers to your questions from the perspective of the potential users so what they want is important as it will tell you if you're on the right track or not. This means that the earlier you know what the users think and want, then after you can change your program to accommodate that. You can go on related forums and ask questions there too without creating a survey per se as well. Just make sure the forum is relevant to your project somehow to get at least a minimum of interest on the part of the members.




• How Do The Other Programs Do It:
  If you know of a program that does a similar feature (or at least a program that is aimed at the same industry or type of user you are aiming for) if you can see how they do it, it might e a first vital hint as to how you should present your own feature. IT gives you an idea of how high up in the priority list the feature is considered for one thing. There's a common accepted standard that says the easier it is ti reach a feature the more important it must be. Sure it depends on the program you're looking at but all in all you can learn a lot from another program. Including if a feature should be there or not. If you don't see a feature in a similar program, maybe they have a good reason not to have it there. This can play both ways, maybe they didn't think of that feature at all which ends up giving your project an edge if the feature is that important. So taking the time to look at other projects might prove more beneficial than you might think.

Of course, you can also ask friends, co workers, and other people live, in person or by telephone if you want. When it comes to getting the answers you need for the success of your project I think there's no limit to what you can do without being considered a spammer. The earlier you can do this in your programming effort the less work it becomes to take this new found knowledge and implement it in your own project. So then, assuming you did all this and you now have all the features you want to put in your program you need to define where they go and why. Here again you have more than one possible means of presenting the features. Let's take a look at the two most widespread ways of organizing an application.

• The Method Based Approach:
  This essential means that things are presented in the order they are to be executed. You have to create an invoice before you can print it, you might need to edit that invoice before printing it too which would give a menu that has the New Invoice, Modify Invoice, Print Invoice in that order to mimic the way things need to execute themselves in. This is a typical scenario in alot of business applications. it's a logical way of presenting the features that users of a specific domain are accustomed to since a lot (if not most) of the programs they user are based on this concept of sequence of steps. But today, it is not the only way to go about things. Which brings the next item in this list.




• Using The Right Metaphor:
  Yes, a metaphor, many programs can benefit form one of these. For example, Windows that most of your use to day is built around a metaphor. In the case of Windows it's a desktop metaphor. They try to mimic how you do things on the top of your desk. Today it's hard to imagine Windows working any other way. This concept of using a metaphor can be one of the best things for your projects because it's becoming a growing want of the users. They don't want to use your program, they want to experience it so to speak. Taking the time to see if a metaphor can and should be used can prove one of the best decisions you make for the success of your project.

So then, at this point you have your list of features, you hopefully made a choice as to which of the two methods above you will use for your project. All this should also give you a good base idea of the structure of your menus and overall user interface so far. Typically, everything that follows here is based on whether you used the Method Based Approach or the Metaphor Approach to your project. So what comes next will be explained under both methods whenever it's necessary. The next step is to start implementing the features themselves, and yes, the method used will help define a lot of what the data entry screens will look like and how they will behave, same thing for how reports will get generated (or how the sub subsequent game screens would/should appear. What else is there to consider? Funny how I used consider here because the next step is exactly, User Considerations. But before we get into that let's take a little time to define what the users really are.

TYPES OF USERS:

Throughout your project development you need to remember that all in all, there are two distinct types of users you'll be coding your project for. In each of these groups there are sub groups that determine a lot of things for you. But all in all everyone can be classified under the following two groups.

• The Mouse Users:
  These are the people that don't believe a computer is complete without a pointing device. They are typically people that believe that if you can't do it with the mouse, you can't do it at all. And yes, they exist out there. The main thing to consider for these users is to make use of the mouse on at least every important feature of your program while keeping things on par with the method used (method or metaphor) then your mouse users can do what they need to and won't complain too much if a specific feature can't be done with the mouse (such as data entry screens but that too can be mouse oriented to a certain point.




• The Keyboard Users:
  Of course these users don't care much for a mouse. Everything has to be done with keyboard and keyboard shortcuts. They love the function keys and well, every other key they see on a typical keyboard. They do not however like to relearn everything. So although the keyboard is a must for all the features, it's important to keep things consistent throughout the project, as in, if one module uses F2 to open a file, any module in that program that need to open a file should also use F2. I believe that with just a bit of common sense you can create a very usable keyboard standard.

I may have exaggerated my descriptions of these users, but the point of this article is to accommodate both extremes of the user base you might have to deal with. The bottom line, if your program works with the mouse or keyboard you can get that many more users just because of that one considerations. People like to work they way they work and trying to impose a give way to them won't make them to fond of your program. Is there certain projects or specific task that just can't be accomplished with the keyboard or the mouse? Depending on the project I have to answer yes to that question. More often than none however you can and should accommodate for the keyboard and the mouse by default. And in the unlikely event that something needs to be done with only one of these input devices, state it clearly on the screen "this operation must be performed with the keyboard" so that the user doesn't need to try to do it with the mouse if he can't. (see the user feedback section below for more of these user feedback tricks. And now let's take a look at what other considerations you can do for the users.

USER CONSIDERATIONS:

Are you thinking something like "Hey, did I do enough of that so far?" the answer is no. Let's not hide the facts, you're probably doing this project not just for others to use, you probably want to use it yourself too. Hence you might have your way of doing things and you'd like to see them in there right? At least some of them right? So where do you draw the line? The answer is you don't. But it doesn't mean you can't accommodate yourself too in this. Back in your surveys, you could suggest your method of doing it, and seeing if people agree with them or not. Leave them as suggestions however, not as set in stone methods of operations. IF you like it that way, chances or so will others. Who knows, you might be lucky enough that the way you want everything to work is OK with your potential users so it's not a bad idea to suggest your ways as at least some of your potential users might not have an idea of how to use the feature and might think your way seems logical and good.

I already mentioned some considerations throughout this article so far. Things like keying the features as directly and quickly accessible as possible to minimize keyboard or mouse actions is one of them. Another one I mentioned is to keep things consistent (such as the F2 key always being used to open files and documents). These are very important things to consider. There is more however. Let's take data entry into considerations. Data entry screens are of course the most user specific programs to write. Data Entry typically implies that something will get saved to some kind of file and hence the data provided by the user is very important. Users are human however, they do make mistakes and as such there are more than one trick to help make lower (or sometimes even eliminate) human errors. They have a great deal to do with the controls you use on the forms in most cases. So let's see what role these controls play in the data entry process. This of course can be used in Text Based user interfaces and in Graphical user Interfaces alike.

• A Regular Text Box:
  This is often used for to many purposes. There is no validation per se here. The user is allowed to enter pretty much whatever he wants into this type of control. This could be used for fields suck as name, notes, and other information. For most other types of fields one of the following is probably a much more recommended way of entering values.




• Masked Text Box:
  Even back in the days of DBase and Clipper (back in the 80s) this type of control has always been used to help minimize human error. Masked Input Boxes are created to allow only certain keys to be pressed and if there's a certain visual representation that need to be restricted by, the Ma




• Check Boxes and Radio Buttons:
  These are controls that typically have 2 values, they are either selected or not, In the case of check boxes, each checkbox can be selected or not. Useful for quick options that can all be selected or not. Radio buttons are different from Checkboxes because they only allow one of the list of radio buttons to be selected. If you have a list of fixed values from which only one can apply at one time, Radio Buttons are the type of control to use (provided not too many of them are needed.




• The Combo Box:
  This is represented by a text box and a list of items that can be brought down to allow to pick one of the available options. They can be play the role of Radio Buttons when you have a long list of possible options where only one needs to be selected.




• The Scroll Bar:
  If you have a field that can only have a certain range of numerical values (for example a volume control for a MIDI player you are making) a scroll bar is a great visual way to allow the users to enter a value instead of keying it in directly.

There are more controls but typically the play the role of one of these. Things like Date Drop Down which are a Masked Text Box with a button on the right side to make a calendar appear to allow to select a date. And others. Basically, since these controls can be used it becomes impossible to enter a wrong value into the system thus eliminating human error (or at the very least keeping human error to a strict minimum. After that is in place, you can of course add data validation to the whole screen. For example, if certain fields must be entered (known as mandatory fields) you can do a check before exiting the form or saving the data to make sure that these fields really do have values in them and warn the user if they are missing. The combination of these two elements will make sure that what gets saved is valid. And if there's valid data to begin with, chances are, valid data will come out of the system. So when data is a high priority element of your project, these techniques can really help you make sure that you get only good and valid data to begin with, to process, and most likely valid results from them (if you're making a report or something). There's one more form of user oriented programming I want to cover in this article and that is, of course, user feedback.

USER FEEDBACK:

Did you ever call the support department of a company, any company, got left there for a few minutes or a 1/2 hour without no one telling you what's going on? How does it feel? Did you know that your program, unless you make it do things otherwise, will treat your users exactly that way? In a sentence, this is what user feedback is all about, not leaving the user in the dark. Making sure he/she knows what's about to happen (especially of a complex process is about to occur). Letting them know how things are going, let them know if their choice was executed successfully or if a problem occurred. user feedback has been implemented before, you can probably learn a whole lot about what type of feedback you need to include just by looking at other programs. User feedback is a very important aspect of any projects that will be used by other users (this includes games and applications).

There are many things that can happen in a program. Some require more or less feedback to the user, This is were common sense and a bit of background knowledge is needed to determine where and when to give the user feedback. Here are some of the major situations where I believe user feedback becomes almost crucial.

• When Something Is About To Be Deleted Or Overwritten:
  Whether it's a record in a database, a file or anything that already exists it's important to let the user know what he's about to do and give him a chance to cancel or confirm the operation. a message like "you're about to delete something" isn't good enough either, you need to give him more information like what exactly is about to be overwritten or deleted so that he/she is well informed to make his/her decision to overwrite or delete the item in question.




• When Something Is Going To Take Some Time:
  Needles to say that if a process can take several minutes to complete it goes without saying that the user will want to know about it before the process occurs. In these cases I find it important to do the following. First, let the user confirm that he wishes to start the process. If he chooses to execute the process, given a progress of what's happening, a progress bar is a great way to do this so he can see quickly how much longer it's going to take. And a message at the stating that the process finished successfully or what errors occurred if any.




• When The User Is Expected To Do Something During A Process:
  If the program needs the user to do something (enter values such as criteria for a search or a range of records to consider for a report, he should know so right away so he can provided the expected information and get the process started. like the above point a progress bar (if it's a lengthy process) and a message stating if things were successful or not and why come highly recommended. It's really all about making sure the user knows three things. 1. What's about to happen, 2. What is happening, 3. What happened. By following these wherever an important thing is about to occur, it will help your program be that much more successful to the eyes of your user as they will not be left in the dark. Likewise, giving the right information will help them help you if they call you with one of these problems.

User feedback is a must, it's really the best thing to remember from this article. To determine what needs to be done where, put yourself in the shoes of your users. Try out everything before you publish your program. Once again, if there are places where you would have liked to know about something before executing a certain part of your project, chances are, your users will probably expect that too. So taking the time to see what's happening where and how important it is to you to know about them is a great first step to making sure user feedback is adequate throughout your project.

Another important thing is that if one of the feedback means that the user can't perform his selected action to let him know, if at all possible, why he can't perform it. Maybe there's no paper int he printer, maybe the record he's working with is locked by some else in the system and he has to wait for that user to be done with that specific record, maybe the system resources are insufficient for the needs of the application. No matter what the reason, letting the user know will also help him make sure he can perform the action which is, let's face it, the main reason why he's using your application in the first place. So when you can know the reason why, don't be afraid to share it with the user, he'll only appreciate your application more because of this little consideration.

IN CONCLUSION:

As you might have noticed, most of User Oriented Programming items I mentioned here involved more common sense than business knowledge per se. As a final note, I'd like to talk about business knowledge itself. In one special form. If your program is an accounting system, it's important that the terminology you use reflect the terminology used by your users (in this case, accountants). Just that fact, keeping the terminology domain specific like that, can often give the impact you need to make your program stand out from the rest as far as user consideration goes. Hence you need to learn enough about the domain your project is created for in order to use the right terminology that your users, in that field, will expect to see. It's a small form of respect if you will, for the knowledge your users have and are accustomed to work with. It doesn't take that much time to learn the right terminology, and does make a big difference in the impact of your project. So it's a quick and valuable tool for your creations.

I could probably write a whole book on just this subject alone, there's so many considerations involved when creating an application for your users. I hope this article opened up your eyes and your mind for your future projects. However, it's very possible that I've left something out, or didn't detail a specific aspect enough. IF you want more details you can email me (email is below my signature below). And talk to me about it, if there's enough grey areas I will create a 2nd part to this article that will cover them. This subject is important in all your projects that you want others to use so let me know if there's something you'd want to know more about that has been mentioned here. Until next time, happy reading and coding.