Visual languages: Branding, buttons, and the brain by Pam Rotella
Earlier this month, I was looking through some old backups and came across a FileMaker application named RPM. The program has an impressive visual presentation, and RPM is also a good example of a technique that helps people learn and navigate a system more efficiently. Specifically, RPM uses images unique to the database as a sort of shorthand, or visual language.
The title of this article probably led some to believe that I'd be discussing a language similar to Visual Basic here. Rather, I'm referring to the use of symbols and other visuals within a database to create a sort of shorthand for their verbal meaning. Verbal descriptions can be included with the symbols for new or occasional users, but the connection between the brain and the symbols' meanings will gradually need no verbal translation. Over time, as the database is used, symbol meanings will become understood and direct.
In fact, this technique is familiar to all recent computer users. For example, a magnifying glass usually means to search or to find. A scissors means cut, two pages next to each other mean copy, a page on a clipboard means paste, etc. Many applications have standardized this language at least somewhat, with slightly different variations unique to each software manufacturer. It's a shorthand that, once learned, saves people the time of reading text descriptions on each button.
The same sort of technical hieroglyphs can be used in the design of FileMaker database applications. As with more standardized symbols, the visual images should diagram something well enough to appear intuitive, or at least easily identifiable. As a person uses a database over time, more symbols' meanings should become recognizable.
RPM's design helped to train its users a shorthand or language as they worked, using representative images unique to the database. It's a technique I use often, for example I'll often make report buttons look very much like a miniature version of the printed form.
In this article, I'll cover two examples of how RPM taught its users image translations -- branding and buttons.
If you had two or three seconds to communicate something at the beginning and end of a database user's session, what would it be? In RPM's case, it was "My name is..."
RPM was named by its department manager while we were already working on the project, and by "we," I mean a team of MS-Access/Visual Basic programmers who I was training to also program in FileMaker Pro.
The name of the application was carefully selected to be memorable as well as descriptive. In this case, the name of the application had to mean something outside of the application itself, preferably associating its name with a visual image. This technique helps people learn the name more easily than initials unique to the application. For example, one of the company's other applications-in-development was named SCOUT, and the initials S.C.O.U.T. stood for something. Its splash screen showed a Native American on a horse, obviously meant to be a Native scout. RPM meant something, too -- revolutions per minute. Words or abbreviations that already exist in the English vocabulary help people associate the application with a picture in their head, and hopefully remember the corresponding application name more easily.
At the same time, RPM and SCOUT were abbreviations for the full names of their applications, which described the purpose of the applications. RPM meant -- and I'll only mention this once -- Reimbursement Policy Management. For the privacy of the client company, I won't hint at the purpose of their application, or even their industry. It isn't necessary to discuss branding and buttons.
Now for that two or three seconds as a person enters the database. This is what people saw just after signing onto RPM:
A database application programmed as a product to sell would normally have a better design, perhaps created by a professional graphic artist. Databases internal to a company usually don't have that type of luxury in their budgets. This windmill design is simple clip art, but it comes with a story.
After the name of the application came down from management, I selected a "working" graphic for the opening splash screen. I found a photograph on the internet of the electrical generators at Niagara Falls. It was a copyrighted picture, and so of course we weren't going to use it for the final copy of the application -- it was only a placeholder for a few days, something to remind us as programmers that a graphic belonged in that spot.
The generator picture earned a good laugh from my coworkers. They were "typical guys" -- when they heard "RPM," they thought of racecars. They talked about having a hotrod on the splash screen of their new application. Then the boss went through the clip art, and sent us his selection of RPM-related graphics. We'd make the final pick. There were cars, dashboards, seemingly everything that my team wanted for their new racecar-themed database. But then an interesting thing happened. We all agreed that we liked the graphic of windmills the best. The splash screen theme would remain electrical power generation, even after the idea was originally laughed off.
For purposes of branding, the graphic and the name match, and that's what matters. The subject or theme of the graphic helps people to remember that the application has a name, and that name is RPM. Every time they open RPM, they see windmills, and if they think about it for a second, windmills have RPMs. Even if employees only use the application a few times before having to refer to it in conversation, describing it as the application with windmills will clearly identify the application as RPM to more experienced coworkers. And after using it dozens of times, it's unlikely that anyone will forget the name RPM. Every time it's opened, RPM's splash screen greets people with its name, and an image to remember it by. Every time they leave the application, the application tells them this:
When a software trainer or manager sits down and trains an employee on the new application, the name may be mentioned once or at most a few times. After that, a well-branded application takes over the name recognition training itself. While almost all of RPM's screens have the initials "RPM" and the company logo at the top, that doesn't mean that an employee will notice or remember details from such a busy visual presentation. Rather, the 2 or 3 seconds before and after the application's use give the employee a chance to sit back and witness the one piece of information being presented.
Creating a name or brand for a database is important. A manager may be in charge of dozens of applications for his or her department, and employees may use several applications on a daily basis. When a system is easily identified, and the staff is trained to specifically identify an application by name, there's no confusion as to where data was stored or where to generate a report. The application is identified correctly every time.
In general, splash screens and exit screens are a source of pride for programmers -- a way to give that "finished" look to their new application's visual presentation. In FileMaker, splash and exit screens are easy to create, and referenced in what I call "Startup" and "Shutdown" scripts, specified in the File / FileOptions menu (see Figure 3 to the right).
I typically name my startup and shutdown scripts "Startup" and "Shutdown," but the scripts could have any name in FileMaker. RPM's opening or startup script was fairly complex, typical of most professional databases dealing with user rights, menus, preferences and the like. I won't show RPM's script here because much of it is specific to the client company. However, the splash screen portion of a FileMaker startup script is relatively simple to write -- launching a window that goes to an extra layout with the splash screen graphic, resizing it to fit around the splash graphic, and then pausing the script for maybe three seconds before moving onto wherever a person's startup script goes. There can be other issues involved, for example providing an opt-out button should the application freeze on the opening screen, or preventing "live" records from being accessed at the splash screen, but overall a startup or splash screen can be fast and easy to include in a startup script.
In RPM's case, I added an exit screen, referenced in the application's "Shutdown" script. For the closing graphic, I unofficially "licensed" one of my windmill snapshots to the company for purposes of the application. The picture is interesting enough to entertain the eye -- light is bouncing off of the corn giving it texture, and the colors are very relaxing. I overheard one woman tell a coworker that the picture was so pretty that she could sit and look at it all day. That tells me that she won't tire of the photo easily, and so she'll probably look at it often enough to see the application's name as she exits. I also liked the logical progression of the photo -- on the splash screen, people see a drawing of a windmill, but on the exit screen they see a photo of a real windmill landscape.
For those programmers who want to take the same path, I'd recommend not using your best digital photo, or even one of your best. You'll want it to be good, but not the picture you'd hang on a gallery wall or even post on your personal blog. In this case, I had about a dozen snapshots of the same windmills that were better than this one, but this photo was still nice enough for an application's exit screen. That's the type of picture to choose -- one you won't miss if the company interprets your copy and paste job as a gift rather than a single act of licensing.
There were no written agreements over the photograph used on RPM's exit screen, and there are copyright issues, namely the picture was taken on my own time, years before working for the client, and therefore technically copyrighted by me. I'm sure the company's legal department wouldn't approve if they knew what was happening in their I.T. Department. But in my programmer's mind, I own the picture and I can decide how to use it. It was only a snapshot, good but not the best, and I'm only providing a limited-sized jpg file copy that's adequate for a web page at most. I didn't mind donating its use to enrich the experience of my database application's users. I think most people would agree it's understood that I'm granting the company use of my picture by physically copying and pasting it into their application with my own hand, on company time.
There is another legal issue that may come up with snapshot images, and I have taken digital photography classes from a teacher who sometimes testifies in court as an expert witness on photography copyright issues. He told me that as long as a subject is not individually identifiable -- like a cornstalk in a field or a bird sitting in a tree, with nothing in the picture to positively identify the landowner or address -- then it is in fact owned by the photographer completely, not the property owner. No signed release is required.
I'm sorry, what was the name of that application again?
Did you think of RPM directly because I've mentioned its name so often, or did you think of windmills and then the term "RPM"? Thinking of both would probably be the best reaction, as it shows an association between the physical application and its name. People need a method to communicate the exact applications they mean, and application branding provides an effective way to mentally connect visual images of applications with their corresponding names.
One of my favorite RPM features didn't involve creating symbols at all. It's what I call "sticky buttons." One bank of "sticky buttons" on RPM's main screen looked like this when two buttons (Texas and Virginia) were "pressed"...
This particular feature was requested by the client, for consistency with their MS-Access/Visual Basic applications. Basically, when a button was clicked or "pressed," its visual image would appear to be a depressed button... until clicked again, when the image would appear to pop back out to its normal "position."
As buttons were "pressed," they added their group of records to the found set below, providing a simple and quick way for people to query lists. The design also helped people remember the categories selected at any given time by displaying the "pressed" buttons above the list. This method obviously has limited querying power, but the client told me that "sticky buttons" were very good at helping employees find basic sets of records with a minimum amount of training.
The query logic for this technique was relatively straightforward. As a person clicked or "pressed" buttons, the found set changed to correspond to the selected buttons. If no buttons were pressed, then all records were shown. If a person didn't have rights to certain buttons (set by a database administrator and shown as gray buttons that wouldn't respond), then records corresponding to those buttons were never included in a person's found or restricted set. (We were fortunate that RPM's management was satisfied with allowing buttons to appear even if a user didn't have rights to them. Otherwise, we would have had to design a sliding button system according to user rights, with very little time budgeted for the application's development.) Clicking buttons a second time to "unpress" them would make corresponding records drop out of the found set. In addition, a second bank of "sticky buttons" was located beneath this group, with department-specific categories. That second set of buttons would show all records corresponding to the first bank of buttons' selection if no additional buttons were pressed, but would restrict the set accordingly when more buttons were pressed.
"Sticky button" graphics were easy to design. Buttons were basically boxes created to appear darker and embossed for those buttons not pressed, lighter and engraved for the depressed buttons. There was a third category, not shown here, that was gray and light for those markets that some users didn't have rights to see. In RPM's case, the button images were created in layout mode, and then copied and stored as graphics in container fields. Clicking a field calculating (and therefore appearing to be) a button would set a variable or global field to a value which would alter the display calculation for that particular field -- as it also launched a script to adjust the found set according to the new parameter.
This technique could be designed in a number of different ways. RPM was created in FileMaker version 8, and so more calculation tools have become available since then to vary color by calculation rather than stored images, although either method is adequate for the purpose of "sticky buttons."
Other buttons in RPM had graphic symbols that referred to screens and functions specific to the database.
One reason that I selected RPM for this article is that most of RPM's buttons were made with FileMaker tools. However, my occasional use of FileMaker as a button design program should not be interpreted as an opinion that FileMaker is the best tool for designing buttons. In most cases, I prefer graphics designed in a graphic arts package, for example Adobe Photoshop Elements. Elements is a good starter program for database programmers -- it isn't as expensive as Photoshop proper, and the learning curve isn't as steep for those not trained in graphic arts. The reason that I prefer images and text stored in GIF files with clear backgrounds is that their proportions remain the same. From system to system, version to version, FileMaker-generated graphics can change. Fonts, screen resolution, Mac vs. PC -- I've seen distortions in FileMaker-created buttons from several different causes through the years. When lettering or symbols become part of a GIF file, changing or missing fonts won't resize that lettering beyond its button, and differing screen resolutions won't cause images to run into each other.
Even so, FileMaker can be adequate for creating buttons in many programming environments. And creating a visual code to help people navigate a database is an improvement over text-only buttons.
To follow is a basic example of how lines, circles, and boxes created and grouped within FileMaker can become a well-known image of a magnifying glass -- a common graphic for search or find tools in many applications. This button is actually much smaller than it appears here. That's another trick for FileMaker button design -- boost the zoom magnification to 300-400%, and buttons are easy to create. Put them back at 100% zoom to see how they'll look in practice...
The actual size of the button appears to the right.
For symbol meanings widely known and used, like a magnifying glass to represent a search, there's no need to reinvent the symbol. In fact, a previously-established connection between symbol and task can help reduce training time.
For example, in some databases I use blue underlined wording to indicate that words can be clicked like a button. The concept comes from internet navigation, not PC database programming. But the visual association already exists in the minds of people who use the internet, and so that "language" can be used to help people learn a database more quickly by providing an environment with familiar elements.
For symbols with common meanings, the problem becomes finding images that can be used without copyright infringement. Magnifying glass images are so widespread today that I found one in the Webdings font set of Adobe Elements version 7 -- it's the equivalent of an uppercase "L" (shown to the right). FileMaker also sometimes provides database files with clip art images for database development. And like the button images shown here, simple images can be created quickly within FileMaker itself.
In the case of buttons with meanings unique to a database application, a programmer can choose to make visual images related or unrelated to corresponding button tasks. For example, making a button green or placing a star on it could be used to represent accounting features. The color green and star symbols by themselves don't represent accounting, but over time users will learn the association within that particular application.
The other choice is creating images that correspond to screens or concepts within the application, and that's why the buttons to the right look like a simplified miniature view of RPM's opening projects list screen. Whenever a button references the main RPM screen, the simple diagram on these buttons is included. That's to help people spot the button for the main screen without having to read the words on each button. When the symbol is learned through repeated use, no verbal translation is necessary -- they see the screen they want, and they click it. The buttons to the right are actual size. To follow is an enlargement, which demonstrates the simplicity of the image's design. Notice that one of the buttons' alt tags is visible. Such messages are helpful for those employees who have less experience with the application. Repeated use should make the extra reading obsolete.
RPM's main screen is actually much more complex than its diagram -- RPM has some amazing features that I can't cover here without turning this article into a small book. But its main look is that of a list with a blue header on top, and so the above diagram is a clear enough representation of the main screen in miniature.
Another button symbol unique to RPM was similar to the diagram of its main screen, shown to the right (actual size). It's the detail screen button. Notice that this diagram has a large, rounded box near the bottom of the diagram, while the diagram for the main screen does not. The detail screen actually has a large tabbed area on its lower half, and so the diagram resembles the screen in a very simplified form. If a person is looking at the two buttons next to each other, the box near the bottom means it's the detail screen; the absence of the box means it's the main screen.
To follow is an enlargement of the detail screen's buttons. In addition to the simplicity of design, notice that the buttons come from differing color schemes. Although systems that allow people to set their own colors on a preference screen are nice, fixed color themes can help people to remember where they are. RPM's main screens were a slate blue and peachy yellow -- I think the colors had something to do with a football team, selected by my programming team. But RPM's various detail screens were color-coded according to category. And so screens used to set priorities were different from those used to document progress or complete other tasks.
To follow is a graphic of the detail screen's component parts. This graphic was very fast and easy to make within FileMaker.
Button images can also represent tasks, and one of the main tasks within RPM was setting priorities, numerically. That was an easy enough concept, and so I made the diagrams to the right as very simple visual representations of setting priorities.
The tiny numbers on this screen represent the priority order that people see when using the priority screen. Literally, the priority screen is full of numbers, and so the mental association between numbers and the priority screen is firmly established through repeat application use.
To follow is an enlargement of the priority buttons.
To the right is a diagram of one priority button's components.
For the experienced application user trying to navigate a bank of many buttons on a database screen, these diagrams in miniature can provide a method of instant recognition -- a sort of hieroglyphic language unique to the database application, to help identify target destinations or tasks quickly.
Complex applications often intimidate new users, who are confronted with a steep learning curve. Button images may not make all concepts apparent immediately, but they can and should aid in the learning process.
The time and design skill required to gain this advantage is usually minimal. Button images can be quick and easy to create. While graphic design programs and clip art may produce the most attractive button images, they aren't necessary.
For images so small, the line, box, and circle drawing features within FileMaker software are an adequate tool. In general, simpler designs are easier to recognize on button-sized art. Buttons are almost always too small for elaborate designs, as screen space is very limited and most database developers dedicate the majority of screen real estate to data. As the samples on this page have shown, designs that appear simple in their larger form serve very well as descriptive images in their miniature size on buttons.
Visual images can teach people words, as with application branding, or make words largely unnecessary, as with button images. The well-planned use of images within a database application aids in employee training and contributes to customer satisfaction, both practically and aesthetically.
Images make every application screen into a familiar environment. They become a direct image-to-brain language that will eventually be understood, without words, through repeat use and exposure.
Good application branding can help employees to identify applications specifically and correctly, even in complex environments with dozens of applications.
Button or navigation images can provide a method of instant recognition, saving time and contributing to workflow efficiency. The brain doesn't need letters or words to understand a concept. Its response can become faster when a verbal translation isn't necessary.
While corporations, database applications, and jobs are usually quite complex, often individual tasks are not. An employee has a pile of work sitting on a desk, and the same pile of work is there every day or every week. The same application is launched every time, the same data entry screen is used, the same report is run, and the same person is notified when the job is complete. Are words really needed to proceed to the next step in this process?
When an employee has a screen to find, ideally its symbol is familiar and the button is spotted within a second and clicked. No need for words. Such a system contributes to work flow efficiency and should, over time, provide at least some cost savings.
The quality of user experience is also mentioned as a reason for using graphic images. Some say that images provide an attractive, professional environment, and that's true. But with continued use, the images become a visual language, intended or not. Their consistency, differentiation, and potential recognition should become primary considerations in their design.
While graphic images are more of a preference than a programming necessity, they help define the visual presentation of a database application. Every database program is a reflection of choices. Time, budget, specifications, and other factors all play a role. The choice of well-designed images and patterns becomes the direct image-to-brain visual language of the database, and, when planned well, contributes to a positive work experience overall.
- Pam Rotella is a Senior FileMaker Developer with over 20 years of I.T./PC database programming experience, more than 15 of those years working with FileMaker. She frequently consults with major US corporations and medium-sized companies, and can be reached via e-mail at firstname.lastname@example.org.
DISCLAIMER: This site is not affiliated with FileMaker software company, but rather seeks to provide a forum for credible discussion on software use. Tips provided here are not intended as individual consultation or advice. All papers published here are the opinions of their respective authors, and are not necessarily endorsed by FileMakerPapers.com or Pam Rotella.