Kahunapule’s Journal

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.

I was really happy to have succeeded at fixing a satellite relay station of the Papua New Guinea Christian Broadcasting Network (Wantok Radio Light) in Kainantu. The man in the picture is smiling because I just gave him a solar-powered fix-tuned radio, playing Wantok Radio Light. That nice little Galcom radio is really good for PNG, because batteries cost lots of money relative to people’s income, and people don’t always have access to electrical power. The thrill of victory turned to the agony of defeat quickly when I got back to Aiyura, and the station had gone off the air, again, then drifted on and off rapidly enough to make the station pretty useless. I had done all I knew to do. I just turned to the Lord, and asked Him to either fix it Himself, send an angel to fix it, send someone else to fix it, or show me how to fix it. That evening, the radio station came back on. And stayed on. I’m listening to it, now. Glory be to GOD! He is a better electronics technician than I am. He is the master architect, engineer, designer, and Creator of all that is used to make anything electronic.

In a land where only about 10% of the people have electrical power in their houses, you might wonder what good such technology as electronics, satellites, radio, and cell phones might be. Actually, such technology is very useful, indeed. Technology is no substitute for living and proclaiming the Word of God. It can, however, make it easier to reach people with the Word of God and make the logistics of getting the Word of God to new people groups much easier.

We rely heavily on communication satellites. All of our telephone calls from Ukarumpa to anywhere farther than Kainantu are carried by satellite, no matter which way we make them. The Papua New Guinea Christian Broadcasting Network (also known as Wantok Radio Light) uses a satellite channel to distribute its programming to FM radio stations scattered all over the country. Our Internet connection is via satellite. In a country consisting of about 600 islands, including the very large and mountainous island of New Guinea, satellite links are the most practical way to communicate in many cases. Running cables all over the place is way too expensive, and far to vulnerable to damage by vandals, earthquakes, and other problems. We also make heavy use of HF and UHF radio links.

A few weeks ago, the local Wantok Radio Light station in Kainantu stopped working. Its receiver (shown in the picture) apparently suffered damage to its RF front end in a lightning storm. The station manager sent a replacement up via an SIL flight, and I put the new one in place. Many people were happy to be able to hear their favorite Christian programming, again.

Although few people have electrical power in their houses in Papua New Guinea, there are many battery-operated radios listening in. We have distributed about 700 fix-tuned, solar powered radios to people in Wantok Radio Light’s service area, so far.

Yes, the Good News of Jesus Christ is simple enough for a child to believe. Rocket science can help deliver that good news.

Another missionary working in Papua New Guinea (and currently on another island) told my wife that they only got a newsletter out about once or twice a year. It is hard, and they just can’t “whip one out like [Michael] does.” I have a confession. I don’t just “whip out” a newsletter. OK, maybe a quick photo of the week email with no major content is pretty quick, but the “official” newsletter that we archive on our web site, email to our partners, and have printed and mailed to our email-less partners takes about two days of labor to produce. It would take less time if we made it longer, actually. We know that people are busy, so we endeavor to keep the newsletters short; no more than one sheet of 8.5 x 11 inch paper, printed on both sides, using type that most people won’t need a magnifying glass to read. In addition, we know that people like pictures. We like them, too. Pictures aren’t just fun to take, they are also effective tools to communicate a lot in a little time. Pictures tell stories. Of course, pictures bring to mind stories, too— usually more stories than I tell. Actually, one of the best things about our web site is that it gives me a place to put the overflow from stuff that didn’t make it into the newsletters. It also is a nice place to be able to post pictures without a really small size limit on the captions. Of course, I realize that not nearly as many people will read all that I post or enjoy the pictures as read our newsletters, but that is OK.

The richness of the full-color range of experiences and adventures with God here and in our travels just flat-out won’t fit in two pages every month or three. There are many significant things going on, times where God has gotten glory by protecting and healing His people, trials and victories over trials great and small, all mixed in with cross-cultural salsa and sprinkled with miracles. Sometimes it seems like a real struggle just to not lose heart, and other times, the joy of the Lord just overwhelms a guy. Through it all, God is faithful. Of course, adventures with God don’t require crossing large quantities of salt water. People struggle to grow close to the Lord in the busy USA, too. So, we keep trying to condense significant events, prayer requests, vision, thanks, and news of what we are doing into less than a page a month. Why do we even bother? Accountability. Reminders for both senders and sent of their dependence on each other. Reminders to pray. That makes it worth it.

Lately, I’ve been experimenting with making the newsletters a little “deeper,” at least for some people. By embedding hyperlinks in our newsletters, I make a way for people who are reading the electronic version online to dig a little deeper or see a little clearer picture with a simple click. At least that works for people who are on the Internet at the time. If they aren’t, or if they are looking at a printed copy, then they still get a decent newsletter.

I’ve also used prayer letter writing as a learning experience. I suppose that a normal person would figure out one software program for creating prayer letters and stick with it. I’ve used a wide variety of programs, sometimes just to learn to use that program. The most recent newsletter I produced was the first one that I produced with Scribus running under Ubuntu Linux. I like it. I think I’ll keep using Scribus for our newsletters for a while. It makes a really good PDF file for our purposes.

I still remember when I first found out about the World-Wide Web and HTML-based web browsers. I had know about the Internet, text-based email, ftp, and Usenet, but this was a new thing, still highly experimental. By that time, the Lord had already directed me to start work on the World English Bible for free electronic distribution. Electronic bulletin boards were popular among a few people, and a 2400 baud dial-up modem was considered fast. Flash forward in time to the present, and Internet web site addresses adorn the packaging of much of the food in your kitchen, the backs of trucks, and TV commercials. Students do research using Google and other search engines, Wikipedia, and the on-line databases of libraries with their favorite web browsers. Paper library card catalogs are being phased out. Large numbers of people, especially young people, exchange information about themselves on social networking sites like facebook and myspace. Large numbers of people like to write web logs or blogs (like this one). Some of them are even worth reading. All major public relations efforts in the technologically developed world include an Internet web site presence. Domain names become valuable property, like trademarks, and sometimes sell for surprisingly large amounts of money.

Why should a nonprofit organization or a missionary have a web site? After all, the work of the Great Commission and missionary work have gone on long before the Internet. And before radio. And before jet aircraft. And before Gutenburg’s printing press.
Here are my favorite reasons for a nonprofit organization to have a web site:

• To provide contact information for people you want to hear from (partners, potential partners, potential members, clients, etc.). Often people search the web before even thinking of a phone book– and those are so limited in reach, anyway. If you don’t do anything else, a simple web page with contact information and a clue as to who you are and why you exist would meet the minimum expectations of many people.
• To further the mission of the organization by direct ministry. For example, if an organization exists to publish and promote the Holy Bible, the text of the Holy Scriptures can be published on line for reading and downloading. Information to help hurting people with their problems can be posted on line. Churches can post sermon recordings on line.
• To solicit donations. Fund-raising is not evil. Rather, it is a necessary part of keeping the organization running and fulfilling its mission. Donations are voluntary contributions by like-minded people and groups to further the cause of the mission.
• To recruit more volunteers, members, or (in some cases) employees.
• To communicate with partners and others. Communication runs both ways. The communication may be news, prayer requests, praise reports, answers to questions, etc. Outbound communication is fairly obvious. Inbound communication can be handled with web forms (usually more spam-resistant than regular email), email, email discussion lists, web-based forums, comments on blogs, etc.
• To communicate with members or employees things of a personal nature (such as financial statements or mailing lists) or things of interest only within the organization (such as policies, forms, etc.). This sort of thing should obviously be placed in a password-protected secure area instead of a public area.
• To sell things related to the mission of the organization, such as books and audio recordings, if applicable.
• To promote your organization and cause. Public relations is important both in terms of being able to perform your main mission and to gain funding for that work. The image cast must be truthful and reliable, as well as being positive. (This, of course, implies that your organization must also be good.)

My favorite reasons to not have a web site are:

• Your organization is secret. You don’t want any unauthorized people to know you exist.
• Your organization can’t properly manage even a simple web site, nor can it find a trustworthy and knowledgeable person to do so, and wants to save itself from very public embarrassment.

A good web site:

• Is up-to-date. Information marked current is really current. Archives of old or superceded information is clearly marked as such.
• Is accurate, truthful, and reliable. Not everything need be made public, but what is should reflect reality.
• Is efficient and loads quickly. Just because you have an extraordinarily fast broadband connection doesn’t mean that everyone else does. Even people with broadband connections tend to have short attention spans, and expect snappy performance. Some people are still on dial-up connections, and some people have even worse or more expensive connections in developing nations.
• Is compatible with the top browsers on multiple operating systems. Currently, this means reasonably current versions of Microsoft Internet Explorer, Firefox (and other Mozilla derivatives), Opera, Netscape, and Safari. Web pages should not do anything that tie visitors to one operating system (like using Microsoft Active-X controls).
• Is safe. Private and financial information is kept safe using careful design and proper use of encryption. Site infrastructure is kept reasonably well updated and secure against hacker attacks.
• Is accessible. Consider visually impaired people using smaller pixel size screens or audio screen readers. A design that looks great at 1280 x 1024 pixels may be unusable at 640 x 480 pixels. Tag pictures with meaningful alternate text. Make sure the site is navigable if graphics are not visible. If the target audience speaks more than one language, translations of the site are available.
• Has appropriate content. Things are made public that should be made public, and things are not made public that should not be made public. The content of the site accomplishes the purpose of the site.
• Is culturally sensitive. Web sites are international in reach and subject to being read by people of many cultures, religions, races, and nations. It may be impossible to avoid offending absolutely everyone, but try to minimize the offense.
• Is attractive and easy to read. Pay attention to graphic design. Great graphic design is no substitute for good content, but it can sure help enhance that content or at least make reading it more pleasant.
• Is intuitive to navigate and consistent in operation. Just say “no” to novel user interface ideas unless you have very compelling reasons not to. There are many ways to create consistent navigational structures, technically. Some are much easier to maintain than others, especially as the number of pages in a web site grows. With large sites, including a search engine may be a good idea. Avoid menus that are too long. (Nest or cascade menus, if necessary, to keep them manageable.)
• Has stable URLs. People can link to pages within your site and expect the links not to break right away. Search engines can send people directly to the page of most relevance to their search. Among other things, this means not arbitrarily changing page names or directory structures. Sometimes it means leaving a trail from the old to the new with a redirect, alias, or other technique. Useful content doesn’t disappear before its usefulness expires.
• Uses pictures to tell a story, but not to hold large amounts of text. Pictures should be big enough and clear enough to do their job, but not so big as to slow down page loading. If someone might want to see a larger version of a smaller picture, it is normal to make it available by linking the smaller picture to a larger version, or to provide links to multiple sizes.
• Is functional. The links, buttons, and other controls all work, and do what you would expect. If you feel compelled to make dead or stub links, either do so for very little time (like less than a day), or (better yet) go study web design some more until that feeling goes away.
• Is maintained and under construction, but doesn’t have a lot of “under construction” signs and excuses up. We expect web sites to change content, sometimes daily, but the really good sites that change the most never give you an “under construction” page. Either the page is there, and there are links to it, or it is not public, and there are no public links to it. It is clear who has authority and responsibility for site maintenance, and they do their jobs. It is actually unusual for one person to have all of the skills necessary to manage all aspects of web site design and maintenance single-handedly. Therefore, those working on the site must work together to combine their strengths.
• Is corrected promptly when things change or errors are found. Out-of date information is promptly removed.
• Displays journalistic excellence. Accuracy, spelling, and grammar count.
• Properly represents the organization. The views and opinions expressed in the web site accurately reflect the organization as a whole and its leadership. It is an advocate for the organization that emphasizes the strengths of the organization, the work and qualifications of its members, and the merits of its mission, without losing sight of humility.
• Doesn’t annoy people without just cause. Use flashing text, animated video, pop-ups, etc., sparingly, if at all.
• Keeps content primary and presentation technology secondary.
• Has an easy-to-remember and easy-to-type URL. The domain name is properly registered and kept safe from inadvertent lapse in registration. In some cases, it is worth registering more than one domain name for the same site. In other cases, it is fine just to use a new directory or subdomain on an existing domain (like eBible.org/Johnson or AdaptIt.ebt.cx).

So, how can you improve your web site, today? How can I improve mine?

I like email. It is much faster, much cheaper, and more environmentally friendly than paper mail. Email follows me when I travel, without having to give people a new address. Email is useful for personal communications, newsletters, discussion lists, and some kinds of business. Unfortunately, the advantages of email have not escaped the notice of both legitimate and illegitimate marketers and scammers. Junk email is a serious problem that threatens legitimate uses of email by (1) flooding the system with junk, making it harder to find legitimate email, (2) seriously reducing the trust people have in email, and (3) restricting the flow of legitimate email as people try to stem the tide of electronic trash. Of the last 5,500 messages sent to me that made it past the first line of defense (IP address blacklists), about 80% were junk and about 20% were good mail. Of course, anti-spam measures affect email I send, too. From the last email newsletter that we sent out, 5% of the messages bounced back or were detained by overzealous anti-spam measures. About 3% bounced back due to closed or suspended email accounts, or for accounts that the mailbox was over its quota. Some unknown percentage was silently detained or deleted without being read. (This is probably no worse than the problem of some paper mail being discarded without being read, except that we spent less money sending it.)

So, what will is the solution? Continue the battle. I’ll keep using email. I’ll adapt my junk filtering techniques even as the spammers adapt theirs to try to get past filters, and I’ll adapt my email sending strategies to make sure that messages we send look as little like spam as possible and that they are easy to safelist. I’ll use digital signatures and encryption when appropriate to combat the erosion of trust. I still want to be approachable by people I haven’t met before on topics relating to the World English Bible and our mission work, so I’ll keep my public email addresses and web contact form active, but keep my low-spam email addresses more private. (The web contact form is spam-free except for an occasional Nigerian scam letter– something I could probably fix with some appropriate text on the contact page.)

I wrote on this topic some time ago, and most of the general ideas are the same, but some things have changed. I have switched from Eudora paid mode with its spam filter to Mozilla Thunderbird with its built-in spam filter. Recently, I discovered that many of the junk email messages that I was getting were specifically designed to defeat Thunderbird’s spam filter, so I started using POPFile again in conjunction with Thunderbird, and now my spam filtering accuracy is back up above 97% again.

Enough on the mechanics of getting newsletters out and getting to read the good email. Another challenge with email in general and newsletters in particular is knowing what to write. The audience is broad, but includes lots of busy people with limited time to read whatever we send. We try to keep our “official” newsletters down to two letter-sized pages, without resorting to tiny type sizes. We also try to include some pictures, as they communicate so much, so fast. From our perspective, there is so much going on in our ministry and our lives that this turns out to be hard. It would actually be easier to write a very long newsletter every time—one that most of our partners would not take time to read much of. We want to communicate effectively with our partners what we are up to and why, communicate vision for the ministry God has called us to, encourage people, stay steadfast in speaking and writing faith in Jesus Christ, be honest, seek to avoid inappropriate offense amonge a diverse readership, avoid saying too much about certain sensitive topics. It should be informative, fun, honest, discreet, appropriate, and honoring to God. It should encourage people to pray. It should be thankful. It should not be too long. If I really have more to say that is important, there are other venues, like this blog, one of our web sites, another newsletter, etc.

As if getting the content right isn’t enough, I try to use newsletter writing as an opportunity to learn new software. I have used Ventura Publisher (now an orphan product), Microsoft Word (perfectly usable, but not the best tool for the job), Microsoft Publisher (a good balance between simplicity and flexability), OpenOffice.org Writer (which can be used to create very nice newsletters at very low software cost, once you learn how) and (for our latest newsletter) Adobe InDesign CS2 (which has pretty much any feature you would want at a price you may not be able to afford) to write newsletters. These are for the “official” newsletters that go out in paper mail, posted on our web site, and emailed as PDF attachments. In between these official newsletters are email-only updates, which we normally compose in our email client (currently Thunderbird) and blog entries (like this one).

I like to take pictures. I like to capture an impression of a part of the beauty that God created, even though it seems pale compared to the original. Evan likes to take pictures, too. (He took this one.) There was a double rainbow all around Mount Princeton, that morning. Sometimes I share pictures in email updates and this blog that have something to do with what we are up to. Sometimes I just share a picture because I think you might like it and thank the Lord for the beauty He has created. God is good!