Bugs and User Interface Design

I’ve been dealing with bugs a lot, lately. Not the living insect variety, but the computer bug sort. It is my job. Yes, I’m a missionary, and I do “missionary-like” stuff like living in a remote area in an exotic nation, preach in another language, and continually have faith in God to supply the needs of my family, my ministry, and myself, because I get no salary. My 40-hour-a-week job, though, is IT support and custom programming for a mission aviation organization with 7 aircraft. I support Bible translation work by supporting the people who get the Bible translators in and out of their villages, and who keep supplies coming in a land with very few roads.

In combating computer software bugs, I have learned to recognize some really common ones. I have also learned some things about writing software to avoid them. Just like bugs in the animal kingdom, there is a taxonomy that can be used to describe them. One major distinction is the source of the bug: bad design, bad implementation of a good design, or both. The bad implementation side is the one people usually focus on. I have seen several lists of common errors, like stack overflows, arrays with indexes out of bounds, improper validation of input (especially if that input is going to be interpreted by another process like a SQL server), etc. Such things are important to pay attention to, but those are like miller moths (the kind of bug found in a relay of one of the first computers, and for which all computer bugs are named). They can’t bite you, don’t normally carry diseases, and as long as you keep them from laying eggs in your stored clothing or wedging their bodies into your relays, it takes a lot of them to really do much damage. Design problems, however, are more like centipedes, scorpions, and poisonous spiders. They can be lethal to a project.

One particular design problem that I have seen too much of is in the form of bad user interface design. Human interaction with machines is very complex, because humans are extremely complex and the machines they use tend to be a little complex, too. I enjoy the computers on Star Trek, because they are so speedy, recognize natural speech in almost any language in the galaxy, can store the collected information from multitudes of civilizations and search and analyze it all in seconds, and can produce any kind of food or beverage on command. They always seem to just understand what the user wants. Not so with the computer I’m typing this article on. I could name at least two projects that had serious user interface (UI) problems in the world of Bible translation and Bible translation support software, but I won’t, at least here. One of those is basically irrelevant except as a how-not-to lesson, as it is essentially dead, killed by lack of use. The other has credible hope of being resurrected with a UI make-over in at least the most critical areas.

Rather than detailing all that is wrong with the UI designs I have seen, I prefer to be a little more positive, and focus on what is good and right about the best UI designs that I have seen. Here are some things to keep in mind when designing a new program or program suite that may save you some grief:

  • Before writing a single line of code, design at least the basics of the user interface. What are the inputs, outputs, and interactions? How do they fit with the work flow of your customers? Is this the same as what they do, now, or better? (If it is not the same or better, then scrap the idea and start over.) To really do this right, you need a good understanding of what problem(s) you are trying to solve, and good lines of communication with your customers. (Yes, you have customers, even if you write free software.)
  • Know your customer base. Know their education level range, their familiarity with computers, other programs, and operating systems. Know what kinds of computers they use and are likely to use. Know why they would want to use your new and/or improved program. Talk with them frequently before, during, and after design and development of the program. If the entire user base is too daunting and could consume all of your time, talk to a few truly representative users, and make some way for others to send feedback (i. e. bug reports, feature requests, etc.).
  • Make your UI intuitive. That means make it so obvious how things should be used that someone who has never used it before can use it. In reality, the only way you will get this done is to copy the good ideas and behaviors of other common programs that users have likely used, before.
  • Read up on good UI design. Microsoft and GNOME both have good things to say in this regard. Even if you don’t like all of their ideas, you need to use most of them or your interface will seem strange to people, because it is different.
  • Use a good UI design toolkit/library. Not only does this save you from “re-inventing the wheel,” it makes it easier to both be consistent and be more like other programs (and therefore more intuitive).
  • Do not get too “creative” with your UI. Sometimes even something that is arguably better is much less intuitive, because people aren’t expecting whatever you are throwing at them. Choose a “normal” way of doing things. Read Microsoft’s Common User Interface guidelines and the Gnome project’s user interface guidelines for some good ideas that you should probably stick to unless you have a good reason not to.
  • Match the UI to the task. For example, if it is a control system for a physical system with fluid or material flows, lay out your UI in an easy schematic diagram of that system. If is a calendar, make it look like one. If it is a recipe book, make sure it is easy to find the recipe “cards,” and once you present them, they look like what cooks are used to seeing. If it is a flight simulator, make it look like a cockpit. I once visited a business web site that was programmed like a video game, but the business had nothing to do with video games. Match the form to the function.
  • Make the common stuff easy to do and easy to find. Minimize the number of mouse clicks and keystrokes it takes to do stuff that is done frequently.
  • De-emphasize the more esoteric or “advanced” stuff, lest it confuse the beginners and casual users of only the basic functions.
  • In de-emphasizing the advanced or infrequently-used features, take care not to hide things too well. Make such things reasonably obvious to find, too. Sometimes it is better to have a larger set of options shown at once, and sometimes you need to show just a few. Knowing when to do which is a matter for experience and wisdom. Usually, this balance has to do with putting “advanced” features on a separate dialog box, or having a less/more button on a dialog box. It also explains the partially-hidden menus in some programs, although I never liked that feature myself. So, if you do that, make sure the users that are annoyed by that can turn the menu-hiding off.
  • Be consistent. This includes layouts of dialogs (i. e. normal locations of OK and Cancel buttons) as well as when and how things get saved. Some programs automatically save everything you do instantly, with no “save” button needed, but some require an explicit “save” function. Try to do it the same way within the same program.
  • Give the user good feedback. When something happens, make it look like it happened. Users are ALWAYS confused if you don’t do this. Better yet, give feedback of exactly what happened, visually, audibly, or both. Make it obvious what is going on.
  • Provide an “undo” function where appropriate. People goof. Often, they recognize immediately that they goofed (especially if you give good feedback), and they want a way to repent, undo, and avoid disaster. Make it possible.
  • “Are you sure you want to launch a nuclear missile?” messages are no substitute for a good undo function. Choose wisely where you put “Are you sure?” prompts, and don’t over-use them. Otherwise, they will be ignored when they are really needed.
  • Avoid overusing modalism, or the shifting of controls into different modes. Computer interfaces are inherently modal. Different menus, buttons, controls, etc., appear on your screen at different times in different situations. This is both flexible and annoying. It is both powerful and non-intuitive. Consistency is intuitive and easy. Consider the automobile. The accelerator pedal is on the right. The brake is to the left of it. Turning the steering wheel clockwise turns the car to the right when moving forward. It is always the same, in all cars, all over the world. I like that. When practical, keep the same kinds of controls in the same places.
  • Keep it SIMPLE! This is probably the most important suggestions. It takes careful balance. Don’t bedazzle & befuddle the user with too many things at once, but don’t make it too tedious to find all of the things that the user wants to do. Group things together that logically go together in the user’s normal work flow.
  • Make the program forgiving. I detest programs that you have to press 3 buttons exactly once, in order, exactly one time per month, or things get messed up. If one of the buttons doesn’t work, programmer intervention is required. Don’t do that. If a button can be pressed, make it do something safe and useful. If not, disable or hide it. If something has to be done exactly once a month, reconsider the design.
  • Write clear, concise, indexed, illustrated instructions. If you can’t write well, find someone who can to help you. Include the instructions with the program and keep them up to date with the program.
  • Keep the design of the over-all program simple. If you have trouble explaining to someone how to use it, chances are that it really is too hard to use, and needs to be changed.
  • Keep the number of controls to the minimum needed to accomplish the task efficiently. Remember that for each control you add, you raise the minimum I. Q. of the operator by 3 points.

Now I’ve reminded myself of what I’m shooting for as I redesign some software. I hope it helps you, too.

Bible Dedications 2008-2009

The following is a list of Scripture dedications already celebrated or planned in 2008 and 2009. It is possible that some were missed, or possibly omitted from this list for security reasons, so really there are probably a few more. Please be in prayer for the people who speak these languages and for the translation teams as they work through the final stages of checking and typesetting. Spiritual warfare tends to be intense at this time, but we are on the winning side. Please also pray for the people getting new Bible translations in their own language that they will read, hear, study, and meditate on God’s Word and that it will bear much fruit in their lives. Obviously, I feel a stronger personal connection to some of these dedications than others, because of help I have provided and/or knowing some of the translation teams and some of the people who speak the languages listed below, but I thank God for ALL of them!

This list is compiled by Wycliffe Bible Translators, but includes work by several different Bible translation agencies.

PACIFIC Old or New Testament DEDICATIONS 08/09

AUHELAWA; Papua New Guinea; 1,200; January 18, 2008

BIMIN; Papua New Guinea; 2,500; November 1-2, 2008.

DJAMBARRPUYNU; Australia; 450; June 7-9, 2008

IPILI; Papua New Guinea; 26,000; August 13, 2008

KUBE; Papua New Guinea; 10,500; March 22, 2008

KUMAN; Papua New Guinea; 120,000; June 27, 2008

MAPE; Papua New Guinea; 12,000; December 21, 2008

NATQGU; Solomon Islands; 5,899; July 20, 2008

NGAANYATJARRA Shorter Bible; Australia; 1,200; May 11, 2008

PIJIN Old Testament; Solomon Islands; 24,390; July 7, 2008

TANGOA; Vanuatu; 900; April 12, 2009

TANNA, North; Vanuatu; 2,000; July 20, 2008

WALA*; Solomon Islands; 6,978; March 16, 2008


BAUZI; Southeast Asia; 1,500; March 17, 2009

IFUGAO, ANTIPOLO Bible; Philippines; 8,000; June 12, 2009

KAGAYANEN; Philippines; 25,000; April 19, 2008

KEMTUIK; Papua; 5,000; July 25, 2008

KINARAY-A; Philippines; 378,000; September 26, 2009

KISAR; Southeast Asia; 20,000; May 8, 2009

TBOLI Bible; Philippines; 90,000; January 30, 2008

WANA; Southeast Asia; 100,000; New Tribes Mission; February 17, 2008


CAKCHIQUEL, SOUTH CENTRAL; Guatemala; 43,000; April 13, 2008

CHA’PALAA language, Chachilla people (Chachi); Ecuador; 9,000; August 16 & 17, 2008

IXIL, Nebaj; Guatemala; 59,500; August 12, 2008

MIXTEC, TEZOATLAN; Americas; 6,200; March 15, 2008

TERIBE; Panama; 3,005; August 17, 2008

TEPEHUAN, Southeastern; Americas; 9,937; May 17-18, 2008 Audio NT & OT abridgment

ZAPOTEC, OZOLOTEPEC; Mexico; 6,500; March 15, 2008


DINKA, Southwestern; Sudan; 450,000; April 20, 2008

FAREFARE Bible; Ghana; 845,100; April 26, 2008

GABRI-KIMRE; Chad; 15,000; April 12, 2008

GUJI; Ethiopia; 2,000,000; August 2, 2008

JOLA-KASA; Senegal; 40,850; January 3, 2009

KONO; Sierra Leone; 190,000; June 14, 2008

LOKAA language, Yakurr people; Nigeria; 120,000; March 15, 2008

MAALE; Ethiopia; 53,779; August 2008

MOBA (Ben); Togo; 191,200; March 15, 2008

MOFU-GUDUR; Cameroon; 60,000; February 16, 2008

MWAN; Cote d’Ivoire; 17,000; March 29, 2009

SENOUFO, Supyire; Mali; 364,000; December 20, 2008

SERE-SINE Bible; Senegal; 1,183,120; January 6, 2008

TAABWA; Democratic Republic of Congo; 250,000; Distributed 2008

TIRA; Sudan; 40,000; February 18, 2009

VOLTA region multi-project*: Lelemi Old Testament 48,900, New Testaments in Sekpele 23,400,

Selee 11,300, Siwu 27,000, and Tuwuli 11,400; Ghana; April 12, 2009


AVAR; Russia 600,959; September 19, 2008

KOMI-ZYRIAN; Russia; 345,000; October 10, 2008

MARI, MEADOW; Russia; 534,569; March 4-5, 2008

Check for updates to the above list at The Seed Company.

Computers, Teamwork, and Missionaries

When I was very young, I had an idea of what a missionary was: a person who went off to extremely remote areas of the world, far away from anything resembling the civilization we were used to. He or she had to learn new languages, convince people that it was better to listen than to eat the messenger, and somehow get lots of people saved or die trying. The missionary image in my young mental image worked pretty much alone. The cliché cartoon image of the missionaries tied up in a large cauldron, boiling over a large fire almost always came to mind. Somehow, teamwork, computers, rocket science, and aviation didn’t usually cross my mind, although I had heard stories of some of the early uses of small airplanes by missionaries. Now that I have had some experience, I have a different view. For example, I’ve never seen a large cauldron out in the jungle. (Other dangers, sure, but no cauldrons.) I see and experience lots of teamwork. I see lots of applications of appropriate transportation, communication, and computation technology in getting the Word of God to people, even in very remote areas. I have also noticed a lot of variety in the vocations represented on the mission field. I also see a wide variety of mission fields, with a wide diversity of cultures, languages, economies, and stages of development.

The Body of Christ really does have many diverse members, with many diverse missions and organizations, but we all work together in the same mission of fulfilling The Great Commission and The Great Commandment. My little niche is mostly in computer support, although I do teach and preach and do some other things from time to time. Finding and eliminating computer bugs may not sound very glamorous, but it is one of many very different jobs in the Body of Christ. All of this works together for good, according to God’s good plan.

Can you imagine what it would be like to go back to living without computers? I can, and it isn’t a pretty thought. It would take a whole lot more manual labor to do pretty much anything you can think of. This is definitely true of Christian mission work in general, and Bible translation in particular. The most useful software for missionaries and missions is software that can be freely shared. I’m a very big fan of Free/Libre Open Source Software on the mission field. (And yes, I’m writing this article using open source software on Linux.) The work of the software developer gets used far more, and by more people in missions, that way. The only down side, of course, is that the software developer has to raise support, just like most of the other missionaries, and live on donations instead of royalties. That is OK. A million years from now, what will matter is the souls brought into the Kingdom of God, not who paid the bills for the work of the Great Commission.