Text User Interface Development Series
Part One - T.U.I. Basics

Written by Stéphane Richard (Mystikshadows)


Welcome to this series on Text User Interface Development. Of course, T.U.I. development is not a new subject today. However, it is always an interesting one. If you want to program a text game of any kind, a tool or utility or a full fledged application, in many of those cases, having a good and intelligently designed text user interface can make a difference on how much your program will be loved and used by it's potential users. Alot of us have seen many examples of text user interfaces from a simple text editor, to other programs that use a text user interface to present the user with it's functionality. We'll be using many of them as examples in this series.

The layout of the series will be pretty straightfoward. This first part of the series that you are reading right now will basically present the basics of T.U.I. What are the components, what role would/could they play in a complete design, what they are typically used for and the likes. Some basic TUI concepts will also be explained in this first part so that they are clearly understood before they are used further in this series. Let's begin right now.


When you make a program, it's great to give it a good set of complete features and functionality that help your project accomplish it's designated role (game, application, tool and utility, you name it). The only way that the program becomes useful to a user is in the way that all that functionality is presented to them. To present these, in an intelligent way, to the user is the art of creating a user interface and a text user interface is a text only way of interacting with the user. In the course of computer history, there were basically four types of user interfaces that have arised. Here they are here with a brief explaination of what they entail.

Now, for the sake of this series, we will be concentrating on the S.A.A. / C.U.A. User interface design since it is, by far the most widespread of them all. As such, we'll be describing exactly what entails the C.U.A. standard. Everything it means, along with every single visual aspect of this standard as far as visual components, operation standards and the likes. Once this is done, and in future issues of this series we'll be building our codebase to create and operate a standard C.U.A. compliant and functional text based user interface framework that you can customize and use in all of your other projects if you wish.


In a nutshell, the C.U.A. standard is based on the fact that you have a file, database or document of some sort and are about to perform somekind of work on that document. You can have more than one type of document you might be working on, and you can have tools that might come in handy while you are working on that document. Think of a C.U.A. application as a desktop metaphore (much like Windows, OS/2, Gnome opr KDE in linux). Where the programs are different windows and tools (like a calculator, a calendar and the likes) are typical things that you might find on your desk. The menu system, of course, reflects the functionality available based on which type of file you are currently working on. I will be using existing text/DOS applications to explain the many components that make up a complete typical C.U.A. application. The system we'll be creating will be very similar to those however, since I believe some of the funcionality (visual and non visual) can be better, I will make them better in this series. Let's start by taking a look at three screenshots.

Now, the main reason I showed these 3 screenshots is so you get good visual examples of everything that make up a Text user Interface. As you can see from these three screenshots, there are many parts that make up a C.U.A. application. After this series is done, we'll have everything we need to build complete C.U.A. compliant applications. So then, let's start this by decribing what makes up a complete C.U.A. user interface, each component and each type of dialog and so on. and that will conclude this first part of the series. So let's get right to it shall we?


Now that we defined all these, it's time to get a glimpse at why these control exist, how they can be used in every day application development projects. The best way to do that is to define some standard dialogs. you can define a standard dialog as being a dialog that anything can use at will when needed. If doing a business application, chances are any business module might need to open either a document or a database from the hard drive (or the network depending). For those, you can create one dialog that will be available to all business modules (maybe even all other related applications as well, if it works in one place it will work in all places too). This minimizes the coding effort and once that one form is stabilized, it's good for every other module that might need to make use of it. So there's definitaly alot of advantages to taking the time to create standard dialogs and test them quite well. Here there are right here so we know what we'll be creating.


Standard dialogs are windows that offer common functionality that you are likely to find in all types of application no matter whether it's a game, a tool, a full fledged application you name it. Typically and especially when you are building more than one application, it's highly recommended that you offer a standard way to do certain things like opening files and the likes. This will greatly minimize the learning curve of all your applications and hence make your programming projects more interesting to your potential users. Here are these standard dialogs

Now that we have our standard dialogs defined, It's time to talk about standardization. I won't mention too much here because the rest of the series will detail our standardization in complete details. Here one thing I can say is that it's time to start thinking about keyboard and mouse access. it's time to start thinking about what Alt + F2 will do throughout your whole application or even complete range of applications. IT's important to define these right up front, before any coding is done so that you are prepared for it. It's also time to jot down what visual interaction you'll want your T.U.I. to allow the user to do. For example, will you want the user to be able to drag controls arounds, move them around the screen with the mouse (or keyboard of course), wil lAlt, or F10 be the key to activate the mouse. What part of the color configuration will the user be allowed to change (will he be able to select specific colors and/or specific themes of colors) and all these details. In the next part of the series we'll start covering all these details so that again, we know right up front, waht kind of coding project we're up against and be better prepared to start the coding phase.


And there you have it. I believe that with this first part, we'll now have a complete "to do list" in order to get started on implementing our T.U.I. framework. We've covered all the controls that we'll be implementing as well as our standard dialogs. I'm sure you started visualizing a bit how your whole T.U.I. framework will be, how things will be called. Maybe you even dared to start writing down some keyboard shortcuts and such to start preparing for our next installment. That's great. You're of course free to do whatever you want. But me, in the next installment is when I'll be defining all these things, maybe when you read that, you'll get ideas and insight on your own standards that might make you change a few things.

I'm always open to emails with criticism, suggestions, comments and compliments (of course) as well as exchange of ideas. So if by reading this, a whole bunch if things appeared in your head and you want to talk about it, feel free to email me (click my nick name below to email me) and we can have a good detailed discussion about all this. I answer, of course, any and all questions and critiques, the object of these series is that all of us become better at what we do best. That certainly can include me as well. Until our next installement, happy reading and coding.

Stéphane Richard