Text User Interface Development Series: Part Two - Standards And Roles
INTRODUCTION:
Welcome to this 2nd installement of the T.U.I. Development series. As stated in the first installement, I will be defining the different user interface elements in details as well as define the different roles a Text User Interface can have. A user interface can have many faces and greatly depend on the role of the interface (hence the type of program).
In this second section we'll cover what these types of programs might be and see if we can shed some light as to what might be expected from the user interface in relation to these types of programs. I will try to include screen shots to clarify my explanations as well. We will also define our Text User Interface framework. The main goal of this T.U.I. are to be a usable text user interface that can adapt itself to most of the common types of projects you may want to build for yourself or for others. You'll see in the definitions below that I've put a great effort on making sure I cover all grounds as much as possible.
WHAT DEFINES A TEXT USER INTERFACE:
By this I mean what a user interface is. Sure, by it's name, you can deduct that it is an interface that is presented to the user of your program. Not that far off from the truth. However, in order for an interface to be an interface more than just this notion of user presentation is needed. The first of these addition concepts is functionality. Needless to say functionality is the most varying part of any program or game. As a programmer you typically won't find all the answers you need. To really cover all the aspects of a user interface (text or graphic) you really have to put yourself in the shoes of those that will use the program or play the game you're making.
For example, a user interface for a business application maybe be expected to have certain things and function a certain way. A user interface for a game may work very differently. A Text User Interface is typically completely governed by three things in the global sense of the definition. These are:
- The type of program that will use this Text User Interface: There are as many roles for a T.U.I. as there are types of applications and/or games. Business applications, tools and utilities, games all have different uses for a T.U.I. that expects different types of functionality to be available. You might want to create a Text Based User interface much like Windows but in Text Mode. You might want to build a User Interface over an editor project. You might just want to make a calculator program with buttons and a display. All these types of projects will typically need some of the same elements and some unique (or specialized) elements that make a given type of program that much more usable as per the role of the program. At the beginning of the project it's important to sit down and think about these types of things so that you can evaluate what is need as far as user interface tools and components for your specific project.
- The Amount of User Interaction Required: Among other things, this is where you decide if the user can use mouse and/or keyboard to use the functionality. Depending on the type of program a mouse might prove easier for the user to use. however, in my opinion, a user interface with mouse support shouldn't depend only on the mouse, hence all functionality planned for the mouse should be accessible via keyboard somehow. Other than that, user interaction also means order of things and how to help the user perform his task. A text editor for example has minimal user interface, it presents the user with an area where he can type text and that's the bulk of what the user uses. However, a contact application will typically have a user interface that has a more important role for the user such as specific fields where to enter information, menues or buttons the user can push to add, delete, copy contact information and the likes. A game can be completely governed by the user interface. So just like when analyzing the type of program or game you are making, sitting down to think about this part is equally important. This can be where you start thinking about things like human error minimization (offer visual alternates to user typed information if possible. For example, selecting values from a list rather than typing them in manually can eliminate errors by only allowing right values to be entered. Input Masks can also be defined here if needed. How every part of your program connects and communicates to the other parts of your program also helps define how each part should function (independently and when interacting with other components of your user interface). As we'll see later in this document there's ways to define your interface that helps break these down the right way.
- The amount User Feedback required: This is the other side of user interface, dubbed the "dark side" by some and often neglected by most. The bottom line is if the user is expected to do something he should know what that is. If the program is building a huge report that takes time it should let the user know that this process is occuring, that the user should wait for it to finish and if possible give them visual queues of how things are going (I'm sure we've all heard the term progress bar) and these are very important aspects of a good user interface. Progress bar are one way, messages are another. If anything is to take some time to do let the user know. If anything needs to be done by the user (such as selecting an option or confirming an action to be performed) let them know and give them the tools they need to do what is expected of them. The rule of thumb is simple, don't leave your users in the dark. They'll usually appreciate this from your user interface a whole lot. Of course you also have to be careful not to over do it with the feedback. there are places where feedback is overkill and we'll try to identify those as well just to give you a complete picture of what makes sense. As you'll see here, common sense does play a great role in all of this. If it's too long for you, it is typically too long for anyone else. If you managed to create an error, overwrite a file because something (maybe a confirmation step) was overlooked by you it will be overlooked by others as well. So in a sense, a T.U.I. development project can be an ongoing experience that can teach you as it develops about what to think about, when certain things should happen and when it's time to let the user know or let the user step in.