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.
- How will the GUI look?
Since it is a Graphical User Interface, the visual aspect of the GUI is indeed, very important. There are many parts to a GUI and each of them should like like it belongs with the rest of the GUI elements. How it looks is entirely up to you but if you want users to use your GUI, making a poll, asking around are great ways to help make sure that your GUI is on par with what the potential users might want to see. Here you can ask yourself such things as: Do you want it to look and work like Windows™, Mac OS™, Amiga Workbench™, or whichever other popular GUI you're thinking about. How similar you want it to be to that GUI, how different, and so on. Just really sit down and decide on exactly what the user can expect when they startup your GUI. Is it a 2D or 3D based GUI is another good question to ask yourself at this stage. IF you can, maybe you can even use a drawing program (I use paintbrush, it's enough for me) and start drawing some visual sketches of your idea, see what works and what doesn't but in a very broad sense, nothing too specific, just enough to give you a good idea. - How will the GUI work?
Believe it or not, this questions, although somewhat related to how the GUI looks, really has nothing to do with looks. Basically, at this stage you're not thinking about Graphical representation. You're thinking about "inner workings" or the beginning of the inner workings. This is where you'd answer questions like what can the GUI do, how would it do it. Can it get input from the keyboard, mouse, joystick, etc? Can it print? can it open and save files? So as you can see this question has nothing to do with looks. You can also decide on if the user will need to double click to get something to happen or if a single click will be enough, and what standard keyboard shortcuts you'll want to use (more on this later). - What programming language will I use to make this?
This is a very important factor which is why I put this 3rd in this list of questions. The other two questions following this can definitaly be affected by which language you decide to use for your GUI project. There are, as you know, many languages that you can choose from. And if you're passionate enough about your GUI project, learning a language you didn't know before to make sure your GUI is good would only broaden your knowledge horizon even further. Therefore you need to look at what you want to make, what you want to include in your GUI project, and then, looking at the programming languages, see if any of them might be better suited for the task. - What special features/services will the GUI Have?
As you know, windows isn't popular because it's simple to use or looks good (although special efforts were put into making it look good). It's popular because of everything it offers. Such as, networking, internet access, Direct X, Open G.L., Open A.L. and everything that is considered today some of the hottest features a GUI should have. So it's good, for the sake of your GUI, to take into consideration atleast some of these hot features and see what and how you can offer them as part of your GUI. GUI development should be about a balanced combination of these features combined with a great look and feel. Depending on the goal of your GUI, you might not even need any of these hot features, however, I think they should be seriously considered at the very beginning of your project. If not for anything else, knowing you'll want to include some of these or not can affect the way you code, you might leave your code open to new additions where you might not have if you didn't take these into consideration. - What Operating System the GUI run under?
Someone said that making a GUI for Windows™ really didn't have a purpose. To that I say that if you are planning to sell your GUI, I agree with that statement 95%. However, if you are creating a GUI for your own use, maybe the use of a few friends, making a GUI for Windows™ makes just as much sense as any other operating system, it again depends on the real goals of your GUI and why you are making it. But even commercially, some GUIs were available for Windows™, take the Norton Desktop which came out back in the days if Windows 3.XX. It had a certain degree of success and was indeed a GUI for Windows™. Also Central Point Software created Central Point Desktop which also made it's way. This is just to say that who knows, making a GUI for Windows™ might not be all that bad of an idea.
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:
- How will the GUI work?
I started telling myself: "ok what do I do when I use Windows™?". Typically I don't just open Windows™ and look at it. I'll either manage my files, write a document, create a spreadsheet (always love playing with numbers), create a webpage, program, browse the web, get and answer emails, play a game and chat. Then it clicked in my mind that Windows™ wouldn't be Windows™ without the possibility of doing all these things I do in Windows™. This is when the idea of basing my GUI totally on the document saw the light of day. In other other words, it wasn't all about the GUI itself, it was about what the user would do with the GUI. Once I had that concept in my mind I opened up Paintbrush and started creating a GUI based on the files themselves and not the applications that used these files. Ideas started connecting together with this model. For instance, I wanted a quick way to find the files since they are first priority. Likewise, as a programmer, I wanted to hav a quick way to locate files that had any relation to the file I was working on currently. For example, if I was coding maybe related files would be other source files in the same directory, todo lists, and other files that have to do with that given project. Same thing if I'm designing a website, maybe I'll want the other html or php files that pertain to the current website. Maybe I'll want images I used to create buttons and other visual aspects of the website. I think the best one phrase comparison I could use to explain my concept is this: Windows Mac OS/X Linux all use the Desktop metaphore where you have the screen (the deskop) and on that desktop you have what you'd need placed somewhere on your desk. ErgonOS uses the "Workload" metaphore where you have your list of things you want to work on or do and the GUI adapts itself to give you the functionality, features and tools you need to perform the work you are undertaking. - How will the GUI look?
How the GUI looked in my mind was based on how it worked. This meant that the document would have the majority of the screen realestate but directly visible would be means of relating and finding files that I would typically need to work with the current file. As such, an image formed in my head. Quickly, I opened up Paintbrush and started putting that image in my head into Paintbrush to see how I could all make it fit together. One small thing I addded (since I love command based applications like dbase and forth programming) was I wanted a command area where I could type commands to get things executed or files opened, whatever I wanted to do. One of the goal of ErgonOS is to allow to do anything from the command prompt that you could do with keyboard shortcuts and mouse clicks. in other words if it exists in the GUI it can be accessed from the command prompt. Here's a screenshot of that design: (some of you might remember this from Jacob's GUI news featured in QB Express #12).
Note that this design's original size is 800x600 which is the minimum resolution I wanted for it. At that scale, the design concurs with the items I detailed in my "Graphical User Interface - Design Concepts" that I posted here. At 800x600 (if you set your screen to that resolution), the buttons are quite big enough, even the scrollbar buttons to be easily and quickly accessible with the mouse. In my opinion, ErgonOS is very well designed for the target resolution and will offer a very efficient usability factor. The Project related items are files that pertain directly to the currently active file. The related Items could be other files of the same type, or anything you think can be useful if quickly available when working on your current file. The search Engine section is of course to search your Hard drive directly. The Shortcuts (bottom right) will probably be called Tools since that's basically what it will contain, things like a calculator, and other popup tools that you might need while you're working on your current file. It will have the ability to change on a per file type basis so you can really customize each type of file with the tools that really relate to that file. Each tab (upper right main section) represent a given file, more than one file of more than one type can be opened at the same time. All sections of the GUI can be resized and/or hidden except from the main section so that you can organize things the way you like them. - What programming language will I use to make this?
This is were I broke the "common knowledge and reasoning" factor. Go all around the web and ask the classic question "I want to make a GUI, what language should I use?". the "very big" majority of people will tell you, use C++, some might tell you to use Pascal or ObjectPascal, some might tell you to do it all in Assembler even. But I chose to do it in FreeBasic because it's a new language and since I want to do this for DOS and FreeBasic can create 32Bit DOS applications, I figured it could do the job quite well considering it's many DOS related features. I also chose FreeBasic to show the world how good it really is. Now if you think QuickBasic or FreeBasic or any basic is incapable of making anything close to a GUI. think again. Go to Jacob Palm's website or Todd's GUI review website (who's links are mentionned above), every single GUI reviewed on these sites were made with QuickBasic. So it just might be more capable than some of you might think. And since FreeBasic can do DOS 32bits with ease, it was easy for me to choose it for my project. - What special features/services will the GUI Have?
Other than the features I want to incorporate as far as usability is concerned. I will also be researching what is out there and what I can "possibly" make to allow for network support, internet support, soundcard support and USB ports as far as hardware is concerned. As far as software is concerned, althought the GUI won't make use of any special features (to keep it lightweight and efficient) I will want to use the Allegro game programming library. I will also research to see what other graphical library there exists and if it can be supported in ErgonOS. As well, to make it even more usable, I will be crating an SQL based 64 bit Database system. I will also see what DOS based database systems exist and see about integrating them to ErgonOS. Using something based on the principle of resource files, I want to implement multilingual features in the GUI so that users can define their own language for the OS to use. Finally, I want this GUI to be fully programmable in it's own compilable scripting language. - What Operating System the GUI run under?
In the case of ErgonOS, I decided to create for MS-DOS and variants like DR-DOS, PC-DOS, FreeDOS, FreeDOS 32 and other MS-DOS based Operating Systems. The main reason is because DOS is what I grew up with and still today I use it. Another good reason I chose DOS is because I'm also thinking of creating my own drivers for the operating system (in a phase 2 or 3 of the project). So I don't want any conflicts with existing drivers and I want this GUI to run on the most basic of system provided it has enough RAM and good enough video card to operate at 800x600 resolution. Because it will be a 32 bit Application, It will need atleast a 386 to be able to work. Once these DOS based OS are done, I might see what I can do implement it for the Lunix Operating System. Whether you create your GUI for DOS, Linux, Windows, or anything else, it's important to make sure your GUI can execute the native OS functionality. Since I'm making ErgonOS for DOS, it will have the ability to run any DOS programs atleast in fullscreen mode. I'll see about creating a DOS window or something, but that will come at a later time. Atleast to begin with, it will be able to run the programs.
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.
- The Main Area: (Upper right section)
This is where most of the action takes place. Each tab represent a complete document. Selecting the tab brings that document upfront so that the user can do what he needs to do with it. You can notice the menu on the top which works as a standard pulldown menu system. Under the menu is a toolbar (which could grow to 2 rows if needed to provide shortcuts to commonly used functionality for the given document type. If the file is a document, the menues and toolbars will change to give the user options typical of a word processing application. If the file is a source file, again menues and options expected for editing, compilation and execution will be presented. If it's a drawing they will provide drawing related options. This is what i mean when I say the document will govern everything that the user can do. NOw if you're running a game that needs to work in fullscreen mode (for whichever reason) or a specific application that needs the full screen, the main area can be zoomed in and/or maximized to accomodate that game or program. - The Command Area: (Right under the main area)
I am a DOS or Console lover. The command area is where you can enter commands and have them executed. You can also create batch commands that will be read and executed line by line. You'll be able to copy files, create folders, open files for editing right from the command prompt. The command prompt will be designed to allow all GUI functionality to be used at the command level. This means that you could even automate what files get opened as well as even change the width and colors of different elements of the GUI right from the command prompt. For those that don't want the command prompt you can hide it and gain more realestate for the main area. - The Shortcuts Area: (Right under the command area)
This area is where related tools and utilities can be assigned for a given document type. Let's say for example that you are working on a document. You might want to go into the paint utility to make a drawing for your document, you might need to calculator to get some results for a report you're writing. Well you can decide to put these two tools in the Shortcuts bar for quicker access to related tools and applications. Items on the left of the shortcuts are related tools, I tems on the right could be even more user tools or things like the file manager, control panel for the document type and other global GUI components. One of the main goal of this GUI is to allow itself to be totally customizable to the users taste and way of working. - The Project Related Area: (Upper left section)
Projects typically are used to group files together. If you're programming, you just might have more than one module for the current project you're working on. If you're creating a website, more than one html or php file, if you're working on a document, it might have more than one file. If that's the case and whatever your current document does relate to other documents, you can just take them all and drag them to the project related items box. Whenever you open the project you'll have access to all other files instantly. They don't have to be of the same file type either. In a website you can easily have html, jpg, png, gif files that all related to the current website you're building. they can be grouped just the same. - The Related Items Area: (Middle left section)
To better explain this one. Let's assume you have a folder, in that folder you have 20 source modules, some resource file (*.rc), some graphics, documents for your analysis of the programming project, and a couple other files (configuration or project files for example). let's say that the 20 source modules are already part of a project. You load that project up and you can see those 20 files in the Project Related Area. The Related Items will show all the other files in that folder that are not in the project you just loaded. This GUI being a document based environment, having access to pertinent document or files while working on other files will be it's main specialty and the Related Items is just another means of making files easily and quickly available to the user. This section can be resized to give more room to other areas of the GUI. It could even be completely hidden if the user doesn't want to see them at all. - The Search Engine Area: (Bottom section)
How many times have you ever told yourself: "Wish I could remember in which file did I put something or where did I save that document to?" the search engine is there to answer that very questons. Again because ErgonOS is file based, a readily available search engine is a very logical option to have. it will search your whole system or the current folder or the parent folder for either the file, or the contents of the files for what you are looking for. That section too can be hidden as well. Many user might prefer to have more screen realestate for the related items and the project related items and simply click on the file manager tool if the need to find other files. Again it's really up to the user to define how he or she prefers to work with the GUI.
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:
- The File Manager:
Essentially, this will be much like the Windows™ file manager application. On the left you'll have drives and folders, on the right you'll be able to see the files that are in that current location. You'll be able to move and copy files from one location to another and perform other standard file management tasks. - The Calculator:
Pretty much self explanatory. However this calculator will come in 4 flavors. Regular, scientific, programmer's calculator and financial. With these 4 calculators, there isn't much you wont be able to calculate. To me atleast, the programmer's calculator and the financial calculator are really missing from standard GUIs. If you think that GUIs like Windows™ are for home and business use, these kind of tools should be included. - The Image Editor:
What's to say about an image editor? It will allow you to open bitmaps and other types of image files, work on them or create new ones, save them and anything else you might want to do with your images and photos. One feature I will add to this is the ability to manage photo albums and be able to categorize your pictures. - The Home Financials:
This will be a very basic but useful system where you'll be able to do such things as: your personal budget, home inventory, mortgage calculations and amortization tables, saving up for college or other projects. Usesul tools for people wanting to plan their life a bit ahead of time. - The P.I.M. (Personal Information Manager):
This is a self contained application that will allow to manage your contacts, appointments, personal notes, some databases, to do lists, birthdays and the likes. Think of it as your electronic organizer. Basically, I want this GUI to be useful even if you just install the GUI itself. And by providing tools like this one and the others, you help make sure that people will be able to accomplish some basic useful things with your GUI. - The Control Panels:
Each file type will have it's own control panel. A standard dialog will be provided to allow the user to configure these file types. The main reason for this is, for example, each sourcefiles can then be configured to be compiled from different compilers for example. It will also let you define which shortcuts/tools you want available when you are editing files of that particular type. as well as decide the size and location of the six areas of the main GUI. There is the global GUI configuration where you can decided on the colors to use as well as the global settings for the six areas of the GUI. - The ErgonOS Scripting language:
Just to clear things up a bit, this is not the batch file interpreter, or atleast it's not just the batch file interpreter. The purpose of the scripting language is to allow you to create your own applications and tools that you feel you need. It will of course have a very BASIC feel to it so it can be learned quickly. And will allow access to all parts of the GUI and inner functionalities.
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:
- The File Dialog:
This dialog is called up when you need to open or save a document. Basically it presents the user with a list of clickable drives and folders and when a folder is clicked the right side of the dialog reflects the files that are in the currently selected folder. The user can then select the file(s) he or she wants to open or enter a name of a file if they are saving a file to disk. Once they are done they can hit the Ok or Save button (depending on the file operation they were doing) and the action will be performed then they will be returned to the main GUI. Pressing the escape key or clicking on the cancel button will exit the dialog without selecting any font. - The Font Dialog:
ErgonOS will use different fonts, these fonts will be available to the rest of the GUI and file types as well. A standard means of selecting the desired font is therefore necessary. This dialog will present the user with a list of available fonts, a preview area so they can see what the font looks like. The user can then select the desired font and click Ok to select the font and go back to the main GUI. Pressing the escape key or clicking on the cancel button will exit the dialog without selecting any font. - The Color Dialog:
Depending on the screen resolution and pixel depth currently selected for the GUI, this dialog will offer different color options. These colors can be used when writing documents or files or when drawing pictures. The dialog will present a bitmap of colors (based on the pixel depth) as well as Red, Green and Blue values that can be edited directly. Choosing the color on the bitmap will also change the values of the Red, Green and Blue textboxes. Clicking Ok will select the color and go back to the main GUI. Escape or Cancel will exit the dialog without selecting the color. - The Printer Dialog:
When the users decides to print his current file/document/image, he/she will be presented with this dialog, it will offer printing options like orientation, printing quality and the likes. The user can cancel his way back to the main GUI without printing or he can click Ok to begin the printing session. - Message Boxes:
This is the simplest of dialogs to make. It will allow to customize the title of the dialog, the message to display, the Icon to show the user (based on the dialog type) and the buttons to make available (buttons like Ok, Cancel, Yes, No and the likes). Depending on the dialog, pressing the buttons will either simply exit the dialog, or perform an action then exit to the main GUI.
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.
MystikShadowsStéphane Richard
srichard@adaworld.com