Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.petesqbsite.com/sections/express/issue21/tuiseriespart1.htm below:

Text User Interface Development Series: Part One

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.

• Command Based Interface:
  These interface are of course the easiest of interfaces. They typically require hardly any design at all. They have a set list of keywords that the user can manually enter at the prompt of the program and depending on the command that the user enters, some specific part of the program is executed. The classic example of this type of interface is the DOS command prompt.


• The Menuless Interface:
  In this type of application, any option on a given screen is usually readily available and seen on the main screen of the application. User typically need to select one of these options which in turns lets them interact with the rest of the screen. For example, you'd see a customer screen and either on top, left, right or bottom you'd see direct commands or buttons to say Add, modify, Delete, Find and other functions on the customer. There's no special key or you don't need to enter a special mode, everything is there.


• The Selection List Interface:
  This is a more structured approach to interface design. It arised when too many functions were need on the menuless interface that they had to be broken down into function groups. When this type of application begins, you're typically in a menu. In a classic design, the first menu you see presents the different modules (customers, suppliers, Inventory, for example). After selectign a module, you would typically fall into the options for that module (such as Add, Modify, Delete and the likes). Once you select that option you would fall into the proper input screen for the module where you can begin data entry or processing depending. Many applications were created based on this artchitecture because although sometimes longer to use, it helped keepthings very organized and sequential, hence, easier to learn and use.


• The S.A.A. User Interface:
  In 1985, with the beginning of Windows and other GUI, User interaction took a whole new meaning. I.B.M. created what is called the Standard Application Architecture standard which include the C.U.A. (Common User Access) derivative. C.U.A. successfully created what we know and use today in Windows, and most of the more recent DOS or Windows Console Applications will use that standard as well. One of the most classic set of applications was Borland's Turbo C++ and Turbo Pascal wich both had a complete implementation of C.U.A. functionality. This defined that a pulldown menu system should be at the top of the screen, status bar at the bottom, shorcut keys should stay the same for all common functionality (F2 to Open for example would work in all applications that followed the S.A.A. standard). This greatly helped the speed at which users could learn an application so it cought on quick and became an industry standard.

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.

• FreePascal Version 2.0.2 I.D.E.
  Here's a screenshot that shows a typically C.U.A. screen layout. You can notice the puldown menu system on the top row, shortcut bar on the bottom and in this case, the rest of the screen is basically known as the desktop area where any file and or tools and utilities (here a calculator and an ASCII chart) are shown and used by the yser.

• Microsoft QBasic Version 1.1 Environment
  Basically, this program reflects alot of the standard C.U.A. components, you can see the dialog box here showing the list of subs and function that make up the current source file. Again, the pull down menu on the top, the status/shortcut bar on the bottom, work file in the rest of the screen. Main difference here is that there's no desktop per se. In this program the "background" of the screen is the current work document.

• Microsoft Windows XP Text Based Editor
  Here's another example. This one I'm showing you so you can see a good example of a standard dialog. one that alot of your programs might need. In this case, you can see the "File Open" dialog where files, folders and drives are shown. The main idea is to select the file you want work on and hit the "Ok" button.

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?

• Labels:
  Small rectangular areas that can hold descriptive texts. In the screenshot above (last one) you can see a label that says "File Name:" it's basically there to tell the user what is expected or what is currently going on.


• Text Box:
  Small rectangular areas that is there to allow the user to enter information usually with the keyboard. With some coding, you can make it so a text box can accept a specific set of keys like only allow numbers for example. Many fields don't need special formatting features, in that case, the text box is the ideal control to use.


• Formatted Text Box:
  This works pretty much the same way as a text box (above). Except it is created to allow a very specific data format to be entered and managed. For example a telephone number (which has an area code and 7 digits that look like ### ###-####). Or dates can benefit from this kind of control as well.


• List Box:
  As the name implies, a list box is a box, that offers a list of items from which the user can pick one (sometimes more than one depending). In the screenshots, you can see the list of files and folders or the list of subs and functions as good examples of list boxes. It's a rather straightfoward scrollable list of items with a selection highlight (also called marque). you can typically click the desired item with the mouse or using the arrow keys.


• Command Box:
  this is a type of control that only has two event. You can either click on it with the mouse's left button or press enter. It can have a caption to indicate what the purpose of the button is and can have more than one look (see the screen shots above for examples of different styles of command buttons).


• Combo Box:
  This is a combination control (hence it's name). It involves a text box, a command button and a listbox. you can either enter text in the text box section or push the button to bring down the list box where you can select something from it isntead of typing the value in. This comes in handy for any values that have a fixed number of possible valid answers.


• Check Box:
  A checkbox basically is a box that can be clicked or unclicked. For example "[X] Print to file" the X can be click with the mouse or the push of the space bar. the X is either there when the value is checked or an empty space when the value is unchecked. Basically they are there to select one or more of possible options when performing a given task. Note that if you have more than one check box, any and all of them can be checked at once.


• Radio Buttons:
  A radio button works as a special group of checkboxes where only one of them can be selected at one time. for example, if you'd want to send a print job to one of the printer ports (just one) you would use radio buttons named like: "(*) LPT1 ( ) LPT2 ( ) LPT3" if you select LPT2, LPT1 will be deselected as only one of those printer port can be chosen at any one time.


• Scrollbars:
  Scrollbars consists of a line, arrows on each edge (top and bottom for vertical scrollbars and left and right for horizontal scrollbars (take a look at first screenshot for sames of scrollbars around the source file window (dark blue) on the screenshot). On the bar is an indicator that shows visually, where in the file or list or database you are (if the indicator is about 1/2 in the middle of the bar you can say you're about halfway down the total list or number of lines etc etc....arrow keys, home, end, page up or page down all affect the value of the indicator. You can also use the mouse to scroll down, up, left or right as well. To use a scroll bar you typicallyh need a minimum and maximum value as well as a Current Value to know where you are in the range of the document or database lines.


• Pulldown/ Popup Menu System:
  Today, pretty much any application you use in windows atleast have a pulldown menu. you have a menu bar at the top (look at the screenshots) and when selected, these options on the menu bar pull down a sub menu of options relative to the menu bar option name. For example, the FIle menu would bring down options like New2 File, Open File, Close File, etc... When you are creating more than one appliation with the same interface it's important to keep the pulldown menu as similar as possible in all programs. SO if File / Open opens a file, it's best to make sure that all options that open a file are under the File menu. It helps keep things consistent and again shortens the learning curve dramatically.


• Status Line:
  Today, user feedback is a very important part of user interaction. A status line does one basic thing. Give the status of things to the user in a one line format. Basically, if the caps lock key is pressed (or other such keys) the status line will show that. Likewise, the status line will show which file, project, document, database you are currently working on as added feedback. There's no need in putting too much information on a status line. But the information should be relevant to what's currently going on.


• Shortcut Line:
  Most programs today can be accessed either with the mouse or using the keyboard. Depending on where you are in your application and what should be available to the user at that specific point in time, the shortcut line contants a list of most used keyboard shortcuts showing what can be done without going through menus or complex screens. These are know as shortcuts. you can either press the indicated shortcut key or click on that part of the shortcut key to have that short cut execute the appropriate code it's destined to execute.


• Frame Box:
  Frame boxes are rectangular boxes that can have a solid background or not. Their main purpose in an T.U.I. is to group items together (radio buttons for example). They can have a caption that appear on the top line of the frame and can also be flat or have a 3D look and appear raised or inset. when a screen has a lot of fields for entry, sometimes frames can really help keep things in perspective and grouped intelligently.


• Outline Control:
  This is probably the most complicated control to create and quite possibly the most useful as well. This control allows you to categorize alist of items in a group that resembles the branches of a tree. For example, you could visually see that Dog, cat, horse and others are part of the Mammals category because they would appear slightly shifted right compared to the position of the Mammals element. Windows coders might be more familiar with the term "treeview control" which is the same thing in windows. If you open Windows Explorer, the folders on the left are organized in a treeview just to give you an idea of what the outline control can be used for.


• Grid Box:
  Whether it's a spreadsheet, a list of items, records in a database with independant fields, if it can be represented as tabular data (data organized in a table format) then it belongs in a grid control. typically, you setup the columns independantly to be adjusted later by the program or by the user. when the user navigates in the grid he/she either changes record number or shifts between the different fields of a record that are displayed on the grid. A grid is a composite of labels, textboxes and scrollbars all connected together in order to make it operate the way it's supposed to. Users of Microsoft Excel, Lotus 123 or Quattro Pro will know what a grid control is all about.


• Tab Control:
  Tab controls are tabs, much like tabs you'd find in a filing cabinet. You typically click on a desired tab to view whatever bits of information or screen that the selected tab should show. When you have a long data entry screen for example where many bits of information are required by the user, it's a good idea to use tabs to split the big form into smaller more manageable pages. If different types of options pertain to very different types of domains (like options of an application where some affect printing, others affect the screen, etc etc, using tabs to seperate all the options into category pages like this also help make your screens alot more usable and much easier to understand.

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

• File Open/Save Dialog:
  As you can see from the screenshot above, a standard file dialog as they are called allow you to select the drive, directory and file. Or, when saving, allow you to enter a filename and extension in order to save the current file.


• Change Directory Dialog:
  This is basically part of the File Open dialog. But this is typically used to change the current directory we are working in. There are options to select the drive and folder we will be positioning ourselves in. Once selected and the ok button selected, everything we do with files will be saved and updated in the newly selected folder.


• Printer Dialogs:
  These aren't shown on the screenshots either. Basically, there's three types of printer dialogs, a dialog about the current print job which lets you select current printing options and hit ok to perform the actual printing. A dialog for Printer Options such as printer orientation, print quality and the likes. Finally there's a dialog that basically lists all the printers available in order to select which printer to send the print job at.


• Color Dialog:
  As you can see from the screenshot above, a standard file dialog as they are called allow you to select the drive, directory and file. Or, when saving, allow you to enter a filename and extension in order to save the current file.


• Font Dialog:
  This name speaks for itself. Sure, in a text mode environment, you can't see the font per se. However, if you are making a text based word processor, you'll still want the ability to select a font and such. This dialog is basically a list of installed fonts and the ability to choose a color for the font.


• Message Box:
  This dialog has more than one role. When an error occurs you'd use a message box to popup the error on the screen for the user to see. You can also use message boxes for confirmation and simple information messages too. This typically displays the message to the user in a window, and expects the user to click a button to leave the dialog. This could of course mean selecting a yes or no button, an Ok, Cancel and apply buttons depending on the type of message being displayed.


• The Document Window:
  This is not a dialog per se, but any application will have atleast one special kind of form design to work with the data in question. For example, a text editor form will allow to edit a file on the screen. A grid view will allow to edit any type of tabular data (say in a spreadsheet program for example). OThers might be data entry screens where many fields are displayed and the user can edit them directly on the screen as if they were filling out a form. There's many types of document related forms and they all depend on the application and what the form is expected to do.

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.

MystikShadows
Stéphane Richard

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3