Graphical User Interfaces - A Complete Study
Part 1 - GUI Design

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

When I wrote Graphical User Interface - Design Concepts back in Issue #13 of QB Express, I was wondering if and how I could continue this series, or what more I could write about in the field of GUI development. Brandon (from Jacob Palm's website recently emailed me the answer to that question he said: "Could you maybe write a Tutorial series for QB Express on how to make a GUI?" and that clicked. Although it's not a complete continuation of the Design Concepts, this series will be based on the design concepts I mentionned in that article.

In this first part of the series, we will start from the beginning, ask the important questions and see what we can come up with. Of course, your GUI project will have different answers to some or all of these questions since a GUI is really a question of taste, your personal taste and the taste of your potential user base. You will learn however, what these questions are and how to answer them specifically enough to have some valid information to work with when you start the design of your GUI. So let's get down to it. There's alot to cover so I'll do my best to be as clear and concise as I can be.

WHERE DOES IT ALL START:

That's always the hard part it seems. Usually, if you have the idea to create a GUI it's typically because you saw a GUI that you either really liked or really hated. If you liked it, you'd like to make your own that works the same. If you didn't like it, you'd like to make a GUI that works the way you want it to work. If it's neither of these answers, then you just might have gotten inspired by the fact that GUI development itself, no matter what the language, is a hot topic and you want to be part of it. The truth of the matter is that GUI development is, in itself, a great way to learn to program. It's a big enough project (even the smallest and simplest of GUIs) so that it covers alot of programming grounds. When you programmed a GUI you have a good understanding of many programming fields and if you develop enough tools and applications for your GUI, it will just broaden your programming knowledge. But the most important reason to take on such a project, is for the fun of it. If there's no fun, there's no point and that should go for any and all personal programming projects you'll ever give yourself.

in my letter to the editor in QB Express #12, I shared my reasons why I thought GUI development was such a hot topic in the Qmunity. I don't know how many agree with me, but those are also my reasons for wanting to create my own GUI. All this to say that you start by wanting to create a GUI. If you want to create a GUI then it shouldn't be a problem to actually make one. What comes next? Let's find out.

HOW TO BEGIN THE GUI DESIGN:

Jacob Palm wrote an interesting article on what a GUI should have in QB Express #10 so this section is not about repeating what's been mentionned in this article. How to begin a GUI is really about sitting down, determining the basics of your GUI and then seeing if you're on the right track. To me, there's two main reasons to create a GUI. The first reason is because you'd typically want to use the GUI you're making. The second reason is usually because you want others to use it. It's great if these are the your two main reasons, especially if they are in that order. If you're making a GUI just for others to use it, it won't be as motivating. However, you'll need to both to put yourself on the right track and keep yourself on the right track throught the development of your GUI. Here are some very typical questions you might want to ask yourself at this stage of the project. Right now, I'll enumerate the questions and later in this first part, I'll answer the questions and how these answers apply to my own GUI project. Hopefully this will help you answer these questions yourselves for your own GUI projects and see how these answers can affect the different parts of your GUI.

Some of these questions require a bit more detail when you answer them of course. But once you've sat down and answer them the best you can (take an extra day or two, or a week if you need to) you'll be much better prepared for the rest of the project. When making a GUI be it a very simple one, or a very complex one, it really helps to sit down and answer these questions to begin with. This will form the guidelines for the rest of the project. And now, let's see what I answered for my GUI project ErgonOS.

MY OWN ANSWERS TO THESE QUESTIONS:

When I first decided to make a GUI I had no idea what it would look like or anything. The only thing I had on my mind at the time was "I want to make a GUI that's simply never been seen before!". With that thought in mind, I started seeing what was out there. I visited Jacob Palm's website, found out about Todd's GUI Review website and started seeing what was already created , what they offered, how they worked, how they looked and the likes. I did this because I didn't want to make anything that already existed. This lead me to thinking, what if, I used something different on which to base the whole GUI on. What if the GUI wasn't defined by the applications it had but rather by some other form of defining attribute. With this in mind, here are my answers to those five questions. I'll put them in the order I answered them because in my case, how it worked governed all the other aspects of the GUI including how it looked. Here goes:

Because of all the OSes I want to be able to run under, I will have to do my best, in the coding process, to make sure I isolate (and eliminate if I can) anything that can be OS dependant at a very low level. This is commonly known as creating a level of abstraction between the GUI and the operating System. This way, any code that absolutely must be OS dependant can be in a specific place and easily changable and maintainable for the other OS I plan to support. This goes for any other ErgonOS related projects such as the database system and whatever else I'll be thinking of in the process. The GUI will come with it's own set of basic GUI tools and utilities like a file manager, calculator, graphics program, text editor, and other basic GUI related software. it will have a control panel that will allow the user to change most aspects of the GUI as well.

THE QUESTIONS ARE ANSWERED, NOW WHAT:

As you can see, I think I have a pretty clear picture of what I want my GUI to do and how I want it to do it. The design phase doesn't stop here however. Sure you can start coding, seeing how and if a few things work, basic research and development..but official coding for the GUI shouldn't begin right away (especially if your project is as big as a GUI). The most important defining attribute of a GUI is to make the computer easier to use as compared to it's non GUI counterpart. In that respect, you need to sit down (again) and start thinking about how simple your GUI should be based on keyboard, mouse and joystick considerations among other things. A prime example of this was Word Perfect 5.1 for DOS. It had every feature you could think of and more for a word processing application. So many in fact that it had no choice but to put some of these features in very complex key combinations like "Shift+Control+Alt+Key" that became very hard to learn and remember. So you need to sit down and think about a few factors. When you design a GUI, if you want it to be simple to use and easy to learn, You'll have to take the time to create standards, even more so if you're making your GUI for others to use.

If you use an Open Folder as an Icon for your File/Open options, you'll want to use that same icon for any program that allows to open a file regardless of what it does with the file. If you use the F2 key to Open a file, you'll want to make sure that any program uses F2 to open a file. This makes your GUI and any related programs that much quicker to learn and get used to. Which key you use is up to you, the important thing is that you use the same keys for the same functionality throught your GUI and that goes the same for which icon you use in your menues and/or toolbars. Also, a GUI is not just an environment to run other programs or games in, it is a user oriented interface to the DOS commands and instructions and show, therefore, offer standard things like file and folder management. With this in mind, here's a litte table explaining the keys I decided to use as a standard.

ErgonOS Standard Keyboard Definition
Key Description
F1 Help F1 will bring the ErgonOS help system to the screen, if the User presses Shift and F1 a context sensitive help will be brought forward.
F2 Open As you might have guessed, I selected F2 for the standard File Open operations. Anywhere you are in the GUI working on whichever type of file, F2 will always allow you to open a file.
F3 New When you want to create a new document or file, pressing F3 will always do that job for you. The current document (if any) will determine the type of the newly created document. If you have no documents or files opened then a list will be available to select the type of document you want to create.
F4 Close When you're done with a document or file F4 will close it for you, if it's changed it will ask you if you want to save it first. CTRL and F4 will close all files of a project that are open (a quicker way to close all project related files).
F5 Goto Since the age of Lotus 123 for DOS, F5 has been accepted for the means to get to a certain place in a document or file (in this case a spreadsheet). So I kept that standard for ErgonOS.
F6 Search This is pretty self explanatory. If you want to find something in your document or file, hit F6 and a standard Search/Replace dialog will appear asking you for standard search related information. If you already had a search, F6 will search again for the next occurrence of your criteria
F7 Print Do you want to make a hardcopy of your current file, F7 is the key to press. Shift F7 will bring the printer paramenters dialog up. In other words, F7 and it's Shift, CTRL and Alt combination will all be about printers and printing for any document type.
F8 File Search This is what you press if you don't have the file open but know what you're looking for. Specific file related criteria will be asked for so you can find exactly the file you want.
F9 Options If you want to change any aspect of working with a given document type. For example colors, available tools and the likes, F9 will allow you to do just that.
F10 Menu As you might have guessed, I selected F2 for the standard File Open operations. Anywhere you are in the GUI working on whichever type of file, F2 will always allow you to open a file.
F11 Custom I want to leave F11 and F12 definable by the user. However, by default F11 will bring the standard file manager up for operations. That will be true for any file type unless otherwise specified by the user.
F12 Custom User definable as well. It's default will be the ErgonOS global control panel and options dialog. That will also be true for any file type unless otherwise specified by the user.

As you can see, taking the time to write these down like this, I won't forget them for one thing, and it really help give a purpose to the GUI. I think it's very reassuring to know that no matter where I am and what I am doing in the GUI the same keys will server the same purpose. How quick and easy to learn does that get? To me, that's really what a GUI is all about easy to learn and use. Added to that a good visual design, and you have yourself a winning GUI combination. Taking the time to create such seemingly insignicant things as keyboard standards just helps add a stabilizing effect on your design. This was standards for the keyboard. The same can be done for the mouse (button graphics and all).

Another effect that creating these standards to is give you a better idea of what size your project will be. For instance, F1 will bring a help application up this help system will need basic functionality to open and search a help file and other help related operations, F2 will require us to create some standard File dialogs that allow us to browse the folders and file to select one (or more) file to be opened), this adds to our list of things to do and help us create a very tightly integrated GUI environment. Later in this first part I will enumerate these different GUI additions and describe them. I will of course need to design those dialogs so I can show them to you later in this series when we really start to code the GUI part itself. But in this first part, you will atleast know what those dialogs will be.

The more alert of your might also have noticed a pattern in my keyboard key definitions. Just Pressing the key affects the currently opened file, Shift and CTRL and Alt Affect the current file type. This is to say that the keys that are the more quickly accessed will have a direct relation to the current file. while the combination of Shift, CTRL and Alt will broaden the reach to a wider set of related files. This is my way of optimizing the functionality. Of course you can create your own standard as well, just be very specific as to what you have in mind it will make the standard easier to follow for all others that will use your GUI. In the next section, we'll break the the GUI into it's basic elements and enumerate them so we know what we'll have to code for in the following parts of this series.

BREAKING DOWN THE GUI ELEMENTS:

if you take a good look at the screenshot above, it represents the finished and combined GUI. However, this is not in a usable state. To make it usable, we have to take each component of this GUI independantly and save them in different filenames. Some of these we'll have to break into sections even because of the fact that they will need to adjust to different heights and widths depending on the size other controls are when the user changes them to his or her taste. As you can see there are 6 main areas on the screenshots. Let's review them and detail the purpose of each of them.

These six zones represent the whole screenshot that you see above. as I mentionned early, most of these can be resized and even hidden to give more space for the other areas. How it looks is entirely up to you. You could even put the main area on the left if you wanted to. It really depends how you like ErgonOS to work for you. Of course, the whole GUI doesn't stop at these 6 areas however. There will be a good list of tools (such as the calculator and file manager) that will appear as popups on top of the GUI. The next section will describe these tools (I will list the basic tools that "should" come with any respectable GUIs for my taste (but it's up to you and your GUI project to decide what you want as "essential" tools.

ERGONOS TOOLS AND UTILITIES:

I've already mentionned a few previously in this document. But as you know, a GUI is only as usable as the tools that are available. There's quite a few tools I plan on adding, I will enumerate them here with a description. Later in the series I'll create screenshots of those to give you an idea of what they will look like. I'm listing them here so that I don't forget them later in the development. These tools and utilities will just help make ErgonOS even more usable. Note that the main area will already have the ability to edit plain text files (this includes any source files, html file, notes, and so on. It will also allow to edit Rich Text documents and I'm thinking of making a small but quite useful spreadsheet application too. Added to that are these following tools:

These tools and utilities are the basis of what a home computer should be able to do. Nevermind a GUI or not, you buy a home computer it should be able to help you atleast manage your home. it's the one thing I always hated is when you buy a computer for your home only to find out you can't do a thing with it unless you get something else. That's basically why I want to create this set of tools, to really make the home computer useful.

ERGONOS STANDARD DIALOGS:

As I mentionned above, this section is where I will describe all of the standard dialogs I will need in this GUI. Standard dialogs are elements that any program can use to perform their operation. They are dialogs that make availabe standard functionality typical of a GUI's functionality. Let's list them here again so we don't forget about them and also, to give us a more complete view of the coding we'll need to do for the project. There are basically 5 dialogs, here they are:

Once again you can see the importance of planning a bit on a project like this. Some of you might be reading this and saying "duh, of course you need these!" that's easy to say because you can read them right here. But if i didn't include them, would you have automatically thought of them all? Think about that for a little bit. Again, listing them here gives a good idea on the coding ahead and helps to allocate time to the whole project in a much more accurate way.

IN CONCLUSION:

And this concludes the first part of this series. As you can see, we got our work cut out for us. But I think it's going to be well worth every effort. We've covered alot of ground in this first part we've defined alot of the functionality that we plan to have on our GUI project. Keep in mind that I'm using my own GUI project here, your project can and will differ from my own answers and my own vision of a GUI. The main purpose of this series is to tell you which questions you should answer, what details you should think about after you tell yourself "I want to make a GUI" and how to plan things out for the GUI itself and any or all the tools you know you want to include. It took me about 3 hours work to create this first part. Don't you think it really helps to define your GUI? I think so. If you just sit down and start coding, chances are you'll forget some important aspect of your GUI that might force you to start over (that's never fun). So taking a couple of hours, or even a couple of days to think about your project for a bit to make sure you cover atleast most of the bases, will only help you in your project. A GUI is no small task to begin with, and you're only adding to the work by not planning ahead and just thinking and using common sense as you define and detail your GUI. What's a couple of days work documenting if it's gonna save you maybe even a couple of months of starting over the coding? Well worth it if you ask me.

In the next part of this series, we'll be starting the more technical side of GUI development. We already took the screenshot and broke it down into it's main areas, and that was useful to tell us the bases of how the GUI will work. In the next part, we'll define all the "controls" that will be needed by the GUI itself, each of these controls will also be broken down it's their main pieces and we'll see what we need to know about them in order to make them work as a whole integrate system it needs to be to work as a GUI. We've already defined some global keyboard standards, we'll need to define more as we refine the GUI design and we'll also define Visual GUI standards as they are needed just like keyboard standards. I hope you enjoyed this first part of the series. Untill next time, maybe some of you might think about sitting down and documenting your efforts like this. in the long run, any project that should take more than 2 or 3 months to complete really benifits from good planning. If you have questions about this series, feel free to email me and let me know about it. Like everything else I write I like things to be crystal clear to those that read them. So let me know if something isn't clear. until next time, happy documenting, and coding.

MystikShadows
Stéphane Richard
srichard@adaworld.com