The Software Developer

This is a good question, since the programming community one deals with may set “standards” of what “they” view as the proper way the user interface should look. It is not uncommon for programmers to simply copy what ever Microsoft does, since it may be felt that since they created the operating system (Windows), they should set the standards.

While it is true that it makes sense to copy standards in some areas where most people are familiar with (ie. most menus have the Files menu to the far left), this in my opinion only applies to the smaller aspects of the user interface (ie. menu layout, keyboard short cuts, etc.). The more critical aspects of the user interface should not be based simply on what everyone else is doing. Why ?

First, just because everyone else is doing it one way does not make it the best way to do something, nor does it mean it is the only way to do something. For example, Microsoft added the new interface called “Ribbons” to some of their software and now some programmers feel they have to have a ribbon in their application. Interestingly I was reading an article recently that said a survey indicated that IT managers were having a difficult time training people how to use the Ribbon interface and it was one of their bigger problems in training. Doesn’t sound like Ribbons were the best solution does it ?

Second, if we always copy how others design their interfaces, then what happens to creativity ? Some of the greatest inventions were things where the designer decided to do something totally differently. Let me for example, take something from the natural world which demonstrates why some times one must do it differently than everything else. In nature when materials get colder they always contract and get denser (more weight per volume and lesser volume). Its nice to know that all things appear to work the same. It provides consistancy. But …

There is one material that “breaks” this rule for some reason and we should be happy it does. That material is WATER (H2O) ! Why is this important ? If water contracted and got heavier (per volume) when it froze (at 32 degrees), then in very cold places, lakes would freeze solid. The ice would sink (because it was heavier) and the exposed top layer would freeze and if this occurs over and over again, eventually a lake could freeze solid. But this is not how it works in nature. Water breaks the rule and when it freezes is actually gets lighter (less dense) and this makes it float on top of the water. As the ices thickens, it stays on top of the lakes and oceans and provides a barrier which protects the water underneath so it stays warmer and does not freeze. This is why a winter fisherman can go out onto a lake, cut a hole in the ice and still catch fish. (Note: Now this is one good example of evidence of a creator).

When designing software, one needs to have that same mind set. Don’t simply copy what others do, simply thinking it always best. Consider the needs of the situation and design a user interface that accomplishs its purpose in the simplest and easiest way you can find, even if it is not the same as everyone elses. I use to design custom software for local businesses years ago (DOS based) and one rule I had was, when designing the user interface examine how the customer currently did things on paper and try to emulate this, rather than design it based on common programming practices. This made it easier for the customer to learn how to use the software, since it wasn’t all that different than what they currently were doing on paper. Now this actually required a good bit of creativity, since a computer screen is not the same as something on paper, so I had to customize every user interface to make the most out of the limited area of the screen.  I created all sorts of popup overlays, scrolling screens, etc. to make it possible to get more out of the limited 80 (width) x 25 (height) screen size (in characters).  In the end I had user interfaces that were unique, but to the end user they were simple and familiar. Sure I did copy something, but I copied what the end user did on paper, rather than what other programmers did on the screen. My software was so easy to learn, that I rarely had to write a manual for them and I could teach people who had little or no experience with computers how to use it in a matter of a few short hours. Amazingly some of those DOS applications designed in the mid 90′s are still in use by those customers today (2010/2011). They are just running it on Windows (but still DOS apps).

When designing the user interface, one must consider the end user. One must stop being a programmer for a bit and start thinking like the end user. It also helps to be willing to be a little creative. Don’t be afraid to try something different. Also don’t be afraid to be a little simple at times. Sometimes the best interface is one which doesn’t do anything fancy at all. Maybe a menu or some buttons is all that is needed.  One problem with some interfaces is what I would call “screen clutter”. If the interface has too many choices provided at one time, then it can cause a great deal of confusion. Also try not to depend upon keyboard shortcuts for key tasks. Use keyboard shortcuts as an alternative to a task which can be done with the mouse, but make sure it still can be done with the mouse if possible. As an example of screen clutter, I recently started using the open source Blender software which is an amazing 3D animation development tool. While it is very powerful, it suffers from a number of problems with its user interface. Because it was written to be cross platform (Linux and Windows) it does a number things in ways which almost seem unnatural on Windows (ie. selecting files). This is one of the problems with cross platform software, since they tend to not fully utilize each operating systems features to the full. The second problem with Blender is that it has screen clutter. I am a programmer, so you would thing that it would be easy for me to figure out how to use an application. Not so with Blender! I found it very difficult to find things I was looking for. Sure they were there, but I could not find them. If it wasn’t for all the free tutorials on Blender on the internet, I would have been lost.

The old rule of “keep it simple” really does apply to designing user interfaces. For example, with my softwares (EZGUI )Visual Designer I at times hear complaints from new users about how it doesn’t work like everyone elses Visual Designer. OK, I admit that it does things a bit differently. But it is designed to be simple to use and you can find things organized with a minimal amount of screen clutter. Actually when I look at it, I find the interface to be very simple with little clutter on the screen, almost to the point of being too simple. This is because I like to provide interface options in “steps” rather than all at once. True, this does require a few more mouse clicks at times, but is also keeps screen clutter down and you can deal with one task at a time which makes it easier to find what you are looking for. This is not to say that it can’t be improved upon. There have been big changes made from the version 4.0 to 5.0 in the designer. I am learning myself and I am willing to make changes. Now the first reaction I could have, from the complaints from new users such as ”it doesn’t work like other designers” could be to simply redesign it so it works exactly like other Designers. That is not the solution though. Maybe there are some real advantages to the way my designer works, which would be lost. Maybe the solution is to simply keep reworking the designer to find ways to make things easier for the user, while offering even more options. Take a lesson from Thomas Edison. He went through over a 1000 failures when trying to find the right material for the wire in light bulbs, but eventually he hit on the right one. He wasn’t afraid to fail a few times until he got it right, but when he got it right, he had an invention that would change the world. So to with sofware. Just because your first attempt with the user interface didn’t come out perfect, doesn’t mean you have failed. Likely you got some things right, while some other things you got wrong. Don’t give up now! View it as  a learning experience. Keep what works and then find ways to improve what didn’t. Feedback from end users is important. Now don’t take it personally when a few complain that it does not work exactly like “so and so’s software”.  Everybody has their opinion and you can’t please everyone. So instead of giving up or rewriting your software to look just like “so and so’s”, first ask your end users what specifically do they find difficult to do with your software. Find out what really is the problem (ie. it takes too many steps to do such and such or you simply can’t do it at all). View things as “tasks”. Find what tasks the end users need to do and offer solutions to solve their problems. 

Lastly, don’t give up on your unique vision of what you want to accomplish with your software. The truth is that the end users don’t dictate everything. Some times you have to stick to your vision of the software, even if initially end users may not understand. I don’t know how many times I added a feature to EZGUI, not because it was requested by end users, but because I personally saw the value of it. As I used my own software, I would often say, “now this would be really cool if I could do this or that”. I didn’t get bogged down on whether I could market the feature or whether enough end users were requesting it. I simply asked myself, “will this solve a problem which is mportant to solve”. Often it was only after end users started playing with the new feature that they would turn around and say “I really love this feature”, even though they never thought of it before. Some times its the simple stuff that makes a difference. For example recently a customer who is working with the PreRelease version of EZGUI 5.0 commented about a very simple little feature I threw in. No one requested it. I didn’t copy it from what others were doing. Just one day, I had a brainstorm and thought, it would be nice to allow controls to have their own private timer events. That customer still keeps commenting about how much he loves this little feature and uses it all the time. It was a small thing, but it is very useful and I knew that, which is why I added the feature.

When it comes to user interfaces, one needs to have the same “inventor” spirit and to be willing to try something different even if no one asks for it. Have a vision in your mind of what you want to accomplish and like Thomas Edison, don’t be afraid of a few failures. You learn from each mistake, but that does not mean the vision itself was wrong. Thomas Edison knew the light bulb would revolutize the world and it did. He was willing to learn from a lot of failures before he got his final vision, but the world thanks him for it (I surely wouldn’t want to be still using old fashioned oil lamps today). In the software industry today, everybody wants to follow the leaders so there are less inventors and artists today like Edison. True there are many talented programmers today, but maybe we need to be a little more like Edison. I am not afraid to admit that my own software EZGUI has had its own weaknesses in the past. Yet it also had many strengths with features not found in others and I built upon that vision. Each new version of EZGUI grows and develops as I see ways to tap into those strengths, while removing the weaknesses.  One time someone (not a customer) called my EZGUI’s visual designer “substandard” and “ugly”. Sure that hurts, but like Edison one must realize that some weaknesses in ones invention does not mean it is a total failure. Also what some may view as “ugly” may simply be because it is overly simple and that is not always bad. I have made signficant changes in EZGUI 5.0′s designer, but not simply to make it more “pretty”, but to make it more useful and powerful and easier to use. I do find it interesting that while my designers interface on the surface was viewed as ugly by some, my customers have often commented about how it generates such rock solid and readable source code. I have also tried to listen to my customers and make changes when possible. The problem with my Visual Designer (which is only a small part of the product) is that I do things differently and that is the first thing people notice. “Its not like everyone elses software” so it is assumed it is weak.

But a case in point is the kind of software some of my customers are developing with the tool. My Designer is a programming tool and it should be weighed by what end users accomplish with it. For example the early versions of EZGUI’s designers (1.0, 2.0 and 3.0) were very rudimentary in my opinion and I developed them. They were simple and not “pretty”. But yet customers did a lot with them. Why ? Because the purpose was not to be an all enclusive visual designer, but simply to be a code generator for what was really important in my product which was the GUI engine. Customers would often comment about how they (those rudimentary designers) generated such clean and readable code which ran flawlessly when compiled. You see, my “vision” of my product was not to build the next “Visual Basic” clone, but it was to build a power GUI engine (DLL). The designer originally was only an after thought, but eventually became a necessary part of the product. I do have some customers who write their entire application using EZGUI without using the Visual Designer at all. They hand code everything and no other Visual Designer tool can accomplish that. Its because the “vision” is the GUI engine and it still is. When I look at the quality of the applications created by some of my customers, then I realize the vision made sense.

Now this does not mean I can’t improve things and I am. EZGUI 4.0 was the first time I started concentrating on the Visual Designer in EZGUI, which is why I am a bit behind in some areas. I was concentrating so much on the GUI engine, I was not spending enough time on the Visual Designer. Now the vision is changing, just slightly and the Designer is getting big improvements, but the core vision is still the same and thats what makes my software unique. I am willing to be different, even if I get picked on for it. I am not saying my software is the best thing since apple pie and better than everyone elses. It is just that I have a vision for the software to fulfill a specific need and I am working hard to fulfull that need. Its nice that there are alternatives when it comes to software. What I design my not be everybodies favorite, but to those who are productive with it, it makes a difference to them.

A part of the user interface of a software product which is not always apparent is that below the interface the software must accomplish a task. The user interface is just the means for the user to communicate to the software what they want, so the software can then do the work it was designed for. You don’t design a user interface to just be like everyone elses or to look pretty. You design it so the user can effectively communicate to the software what they want, so the software gets the information it requires in the most efficient way possible. If what the software does “under the hood” is different than other applications, then its user interface needs to be different than other applications. This is one of the reasons my EZGUI Visual Designer is so different than everyone elses. You see the Designers purposes is to generate source code for use with the EZGUI GUI engine (DLL). The interface is designed to get information from the user to match that task, so it often must request different information that other Designers. For example EZGUI uses a palette of colors (indexed) rather than simply standalone RGB values, so when you select a color for a control you are given the ability to simply select a color from the palette rather than just select any RGB color. This is different. Then there has to be a place for the user to change that palette, which there is. Fonts work the same way. Fonts are selected from predefined font indexes. While you can select a custom font, you also normally select a font for a control from one of the predefined indexes (0 to 5 are fixed and 6 to 9 are user defineable), which is why my interface is different. But the advantage of this technique (which matchs the GUI engine) is that if I set all the controls to say font # 9, I can then change font # 9 to a different font definition and every control in the project (all forms) which use that font are all changed at once. I don’t think do that so easily with other Visual Design tools.

So you see, it is important to not compare your applications user interface to others or to copy them. Design your interface so it does the task your application needs to do. Base your interface on how your application does things behind the scenes. If your underlying code in the applications does things differently than others, then don’t be afraid to make the interface work differently. Design the interface so it best suits the needs of the underlying code. Make the interface as simple as possible. Emulate real work objects, if the software is doing the same task, rather than design it to look like everyone elses software. If the end user sees the relationship between the interface and say some real world object associated with the task (ie. software controls external hardware), they will more quickly understand it. Don’t be afraid to experiment, like Edison, with totally different interfaces. Have a vision of what you want to accomplish with the software and stick to that vision. Be willing to make changes when necessary and listen to user feedback, but remember not to let user feedback override the vision you have for the software. You can’t please everyone.

EZGUI 4.0 Professional is a powerful development system (combined with the PowerBasic compiler) which has some interesting advantages over the more common Windows development tools used by most programmers today (aka. MS Studio, dot.net stuff, etc.).

It has to do with a core design concept used right from its origin in version 1.0.

What is that ?

EZGUI was designed so it could run even on legacy operating systems, such as Windows 95/98. This meant using core API’s in Windows which have been around a long time (but trying to avoid ones which would become obsolete), while avoiding the “bleeding edge” as much as possible. When later API’s needed to be used, they are loaded dynamically, so the runtime can still run on Windows 95, but you have access to later API’s on systems like Windows XP to 7.

EZGUI is also very modular in its design (ie. reuses as much code in its runtime as possible for as many features as possible) which makes its runtime “lean and mean”, requiring a very small footprint (memory and disk size).  There is more packed into EZGUI’s main runtime DLL, than many other GUI libraries (ie. EZGUI has more UI functionality than the VB runtime with a number of added OCX’s combined).

EZGUI also uses its own software based solutions, rather than depend upon hardware based solutions. One example is its Sprite engine. It is a powerful 2D animation engine, which supports frame animation, alphablending and anti-aliasing all via software without the need for DirectX or OpenGL (I should note that EZGUI 5.0, which is still in development will be using OpenGL for 3D animation). The Sprite engine is fast for a software based engine, so it runs well even on limited hardware.

EZGUI’s design gives it an advantage for designing software which will run on low cost Windows NetBooks and Tablet PC’s.  Such PC’s may not run DirectX based graphics well, but EZGUI’s proprietary software based Sprite engine should run quite well on them.  Disk space may be limited on such computers, so EZGUI’s extremely small footprint is perfect for such PC’s. You can build apps which are huge in features, but which can still fit on a floppy disk. Now compare that to the dot.net generation of development tools !

EZGUI also runs quite well on Linux based PC’s which have Wine (Windows emulator) installed. One reason is because it stays away from the bleeding edge API’s, while still providing some amazing functionality. Also rather than create apps which depend upon third party ActiveX controls (which may not run well on Wine), EZGUI provides one of the richest user interface engines available so you can build it all with just EZGUI (and your Powerbasic compiler). EZGUI’s OwnerDraw and CustomDraw engines allow you to customize existing controls to create new ones. EZGUI’s subclassing engine allows you to expand upon existing controls with low level access to controls internal window procedures. EZGUI’s Graphic engine provides high level (Sprites) drawing as well as low level drawing (DIBSection Canvas buffers where you access pixels directly). EZGUI provides a number of custom controls such as a Canvas control (with sprite engine), MCI control, Masked Edit control, Shape/Hot Spot control, Turtle Graphics control (vector based graphics), Drag Handle control, Files Listbox control and Properties Listbox control. EZGUI has a built in Visual Design engine so you can build WYSIWYG style applications, even things like a Visual Designer. EZGUI provides extensive support for many of the Common Controls (ie. Listview, Treeview, Toolbar, tab, etc.) and the RichEdit control without any external OCX’s required. Try that with VB !

Compared to the latest development tools used by most programmers, EZGUI (with PowerBasic) is better suited to development of large scale applications which you want to run well on low cost, limited PC’s like Netbooks and Tablet PC’s (and even ones with Linux with Wine) than other development tools. If you want to target such computers with your software, then seriously consider what EZGUI 4.0 Professional has to offer.

IMO, I doubt there is any other development system that comes close to the extensive feature EZGUI has, which can be used to create “tiny” sized applications with “minimal hardware” requirements which will run well on the next generation of low cost, small size, PC’s. If you want an edge for this new market, EZGUI may have just what you need.

When you combine the power of EZGUI, with the PowerBasic compiler (you can even use their low cost Classic version with EZGUI) which also generates EXE’s and DLL’s with a very small footprint, you have a powerhouse combination.

EZGUI is in its 4th generation and has been used by programmers for the last 10 years. (Yes, EZGUI 5.0 is in development and it will just amaze you, but thats another story for another day!)

Because I develop a commercial product which I often refer to as a “GUI Engine”, I thought it might be interesting to discuss not only what I personally feel constitutes a GUI engine, but also some things a GUI should be, while some other things it should not be. I like to browse the internet to see what I can find which developers call a GUI engine and I have found a number of such tools.

First, I don’t think a “Skin Engine” should be called a “GUI Engine”. Call it what it really is !

A skin engine simply displays the same old user interface (buttons, listboxes, comboboxes), but with a different look. I like the results of some skin engines and they can add some “spark” to an application, but they are simply just a skin engine and don’t add anything new to a user interface. A button is still a button, albeit a little prettier.

Now a GUI engine is different !

GUI stands for Graphic User Interface. Consider the word “interface”. Interface means a sort of connection between the user and the software. To illustrate, a steering wheel on a car is an interface. It allows the user (driver) to control and manipulate the machine to make it do what the driver wants it to do. Now does a skinnned button make the user any more productive in any way ? Not really. Now if the button is made to stand out in some way so the user is quicker to realize what the button does, then its appearance does make a difference. Compare a software button control to a real button on a machine. Most machines in a factory have all sorts of buttons. Does making them prettier make them more useful ? Absolutely not! Now there are two factors which make a machines button more useful. One is size (easier to see) and the other is color (colors have real meaning in the real world). The color red on a machines button can have real meaning (stop buttons are usually red).  Green is often used on machine buttons to indicate a start button (or ON). Buttons which are more important on a machine, usually are bigger in size so they can’t be missed.

The point is that in the real world, a user interface benefits from simple things like color or size and some times shape, but they rarely if ever benefit from simply making them prettier.

So why should a skin engine be viewed as a “user interface” engine of sorts. Call it what it is, a “skin engine”.

Now in the real world (ie. machines, electronic devices, etc.) another aspect of a user interface is how things move, feel and visually appear. For example how a control moves (a machine control) can be important. There are sliders, toggle switches, buttons, etc. In software its the same. Notice the commonality among controls, no matter the operating system. There are button controls, slider controls, scrollbars, listboxes, etc. It is how the ‘work” which is important. Also appearance is important if it conveys a message. For example an LCD display which displays numbers (digits) is oh so useful in the real world. We have clocks, timers, counters which all are simple digital displays, but yet very important.

With software a GUI engine must deal with those real world aspects of controls which convey a message to the user or allow the user to convey a message to the computer (software). Its quite mundane when you really think about it, but yet it is very important. A GUI engine should give you complete control over the interface, even over the seemingly mundane things. A GUI engine does more than make an application look pretty, it makes an application useful.

Functionality is the key word here. Its the simple things that sometimes are the most useful. For example, I am working on the 5th generation of my commercial GUI engine and while it has many exciting new features, I was amazed when one user got real excited by a simple feature I added which was private timers for controls. Each control could have its own private timer which would fire an event at specific intervals. It took about 50 lines of code in the GUI engine to impliment this feature. Because I was already subclassing all controls, I was able to add some timer code to each controls window procedure so each control could have its own unique timer. I called them private timers, to differentiate their purpose from normal timers. This concept was not a big revelation in software development. What made it so exciting to the user was that it was oh so useful!

Thats the point!

A GUI engine must be useful, even if much of it seems a little mundane. Functionality is the key.

In one of my videos (see my web site for my video channel) I discuss a key concept to my GUI engine, which I refer to as being “task oriented”. Often developers of programming tools write API’s or wrappers of existing API’s. True their is a degree of functionality in such API’s. But how often do developers of a GUI engine design it based on real world “tasks”. Some tasks are simple and may only require a small amount of code and a few calls to the Windows API. Other tasks may be very complex and may require hundreds of lines of complex code. The key is to design a GUI engine based on “tasks” and not API’s.

Another concept I discuss in one of my videos is the concept of what I call “building blocks”.

A user interface may need to be more than the simple components found in Windows. If software must relate to some real world task, then often a developer will need to be creative and find a way to emulate the real world task in a software model. Once in the old DOS days, I had to write a custom application for a large company which was for tracking a large PBX (phone wiring) system for a really large complex. While DOS limited what you could display on the screen, I found a way to use a bunch of the block characters in DOS to visually emulate a real PBX system with all its patch cords. What the user saw in the real world was simulated on the computer screen. I had to create a unique user interface which was visual. It was not a matter of whether it was pretty or not. It was a matter of whether the users could understand what it represented and whether they could control the interface in a way that made sense to them.

Often user interfaces in the real world are created based on the need and the task at hand. You can’t always use a “stock” interface. Some times you have to create something new and unique.  The same holds true for software! A GUI engine should provide you with a limitless number of possibilities, by providing you with as many “building blocks” so you can build almost anything. Thats the concept behind my GUI engine. For example I added a Sprite engine to a Canvas control which I had written in the GUI engine. Some at first glance thought, “was I now making it a game tool ?” The answer was no! I found that a Sprite engine allowed users to create all sorts of animated controls which could emulate all sorts of real world tasks. In the real world often you need “parts” which can move, change shape or color and which can be tracked in their position or state. Sprites can emulate the same need for software.

So a GUI engine is not a skin engine.

A GUI engine is not a game engine (a game engine is for making games).

A GUI engine sometimes does a lot of mundane stuff.

A GUI engine is for building user interfaces which can emulate real world tasks, so it should provide all sorts of “building blocks” so you can build almost anything.