Interview: Ken Banks (FrontlineSMS)

The Friday, 20 April 2007 BBC News headline read:

"Texts monitor Nigerian elections"

"Anyone trying to rig or tamper with Saturday's presidential elections in Nigeria could be caught out by a team of volunteers armed with mobile phones."

"NMEM is using a free system called Frontline SMS, developed by programmer Ken Banks, to keep track of all of the texts." (source)

We at The UI Thread came across Ken's story, and FrontlineSMS, at ShareIdeas.org. (The website is dedicated to 'positive' uses of mobile technology.)

After learning more about Ken's application--which has enabled numerous organizations' communicative robustness--we took an opportunity to inquire about its history and User Interface.

Ken was kind enough to engage in an email-based interview over a period of a couple of weeks. (We hope to talk in person some time!)

Interview with Ken Banks:

UIT - How are people finding out about this application and how to use it?

Ken - "When FrontlineSMS was released to the world towards the end of 2005, I had no marketing plan (or experience), and hardly any contacts who could help promote it (and no money). So initially it was just graft getting it discussed on news sites and blogs. One of the breakthrough contacts was Mike Grenville at 160Characters, who put news of its release in his newsletter (it is widely distributed). Other than that, news about the software has been entirely viral. I must confess to being a pain in the butt (but in a proactive way!) by not letting a single opportunity go by where I felt I could shout about it. It’s now been picked up and reported on in a number of reports (such as the MobileActive series), another time in a Gates Foundation report, and more recently in an as-yet unpublished paper from Acumen Fund. There are actually more Google hits for “FrontlineSMS” than there are for “kiwanja.net”, which is interesting. In terms of finding out how to use it, the website is clear on set up and configuration issues (the fact I get so few technical support questions is proof to me of how clear it is). The software has a built-in HTML help system, but it’s intuitive enough, I believe, for most people to be able to start using it quite quickly. The screens generally have a ‘flow’ about them, and being a user myself, and having spent a lot of time with colleagues in developing countries and knowing a little bit about how they got on with computers (I trained some of the Nigerian staff while I was working at a primate sanctuary there – two years before I wrote FrontlineSMS). Again, I have not heard of any issues in usability"


UIT - How do people perceive FrontlineSMS in terms of a new system they weren't exposed to?

Ken - "FrontlineSMS has been received so incredibly well I think in part down to the project’s aims and objectives, and the overall work ethic (i.e. trying to empower, not dictate, and free software and free support, and a genuine interest in the work of non-profits and what they’re trying to achieve, and experience working where they work in many cases). I think this, above everything, has been a major factor in the contacts I’ve been getting, and the requests to use the software. The general vibe of the project stands above the software itself, in a way (does that make sense?). So, when users get hold of FrontlineSMS they are already excited and captivated by it. I get numerous mails telling me how great it is and thanking me for developing it BEFORE the users even get to use it. So, when they are finally exposed to it I think they’re just grateful for it being there for them, and none have made any critical comments or suggestions on how it can be improved. This may be in part to their lack of knowing what to expect. Also, mobile is such an exciting area for most people, many are just grateful for being able to do something in the space"


UIT - In terms of FrontlineSMS usage for the Nigerian elections, which environmental conditions made FrontlineSMS an attractive choice for users?

Ken - "I think, for the Nigerians, it was attractive because it was “written for them” in the sense of the NGO approach (so there were no concerns about being taken for a ride financially), and that it’s use in developing countries has been widely reported. It was also quite likely the only solution out there for them (I don’t know of anything else which quite does was FrontlineSMS does, although I may be wrong). The Nigerians had a minimal budget, little experience of setting up a telecoms service, and little time. They wouldn’t have known how to deal with their local operators to get short codes, for example, and there would have been big time and cost implications for them. Also, having the software run on a local machine, rather than being web-based, meant that they had a sense of “ownership” of it, I suspect. You know, it’s their system and their data and their effort. I think that, more widely speaking, this sense of ownership is a key element in ICT software development when you talk about it in a developing country context. At the end of the day, I think people just “get” FrontlineSMS – you know, the whole thing about putting software on THAT laptop and then connecting A phone to it. It’s a very visual solution"


UIT - What were the alternatives to completing the task FrontlineSMS was used for in Nigeria?

Ken - "As I mentioned, I don’t think there’s really much else out there. The NMEM team could have maybe gone to an operator and tried to get a deal with an access number, or a short code or something. They could have also perhaps just tried to use a smarter phone, and tried to save the messages somewhere (this would have been difficult with 10,000+ replies). They may have also looked at some of the commercial systems out there. I think their situation conspired against them in all these cases – particularly in terms of the technical and financial challenges it would have created"


UIT - When designing FrontlineSMS, how did you explore cultural and regional considerations for the User Interface (e.g. if you knew many people in developing regions would be using it)?

Ken - "In short, I didn't have time to do any of that. I've developed a number of systems before, and generally have a good grasp of what users like and don't like. So FrontlineSMS has no hugely thought-out UI design, although I have received positive comments on the whole, and no-one has experienced problems in using it. 2.0 will have multi-language support"


UIT - In general, how did you go about designing the User Interface? ( E.g. did you apply any design heuristics, usability methods or leverage any ethnographic data?)

Ken - "As mentioned above, I didn't plan it too much. I only had 5 weeks to develop it, so there wasn't a lot of lead time. I'd be interested in hearing your thoughts, though! =) "


UIT - Will the forthcoming version of FrontlineSMS include any substantial changes at the GUI level, or user interactions? If so, what elicited the changes?

Ken - "I do not anticipate too many changes in the UI in the new version, since there doesn’t seem to be a call for any. A couple of things I have picked up on need doing, such as moving the phone settings from a main screen into a menu somewhere, but there really isn’t much. To be honest, a lot of the current screen design only turned out the way it did because it was the only way I could make everything fit. In the first version I wanted to give the user everything they needed at once, rather than expect them to find a configuration menu somewhere else. From my experience of users in developing countries, not being able to configure the phone, for example, on the same screen as the messages are sent, would be counter-intuitive. The screens are being built in the new version in such a way that they can be changed easily – the open source community will be free to do any of this – and the screen text will be held in central files to allow for the support of multiple languages in the future"


UIT - SMS is the killer app in Africa. When will that change?

Ken - "The Mobile Web will probably change that, but SMS will always have a place in the mobile universe. Handsets in developing countries – rural areas in particular - won't be able to handle anything other than SMS as data for another few years, is my guess. Read my http://www.blogspot.kiwanja.net/2007/09/digital-divider.html for a better review"


UIT - Why will that change?

Ken - "SMS has obvious limitations (message length, literacy issues, cost – it's very expensive if you think about the actual amount of data being sent). There are others but I'll need to think a little more…"


Follow-up message from UIT:

As UI-oriented people, we're obligated to hold UI methodologies in high esteem. However, UI design is not simply GUI design--a common oversight.

Effective UI designers know the importance of User-Centered Design (UCD) and wouldn't be worth their screen-flows without it.

Ken Banks and FrontlineSMS exist in the exciting and evolving domain of social-driven mobile applications. (We've coined an aspect of this domain "OpenUCD" which identifies a need for User-Centered Design in F/OSS, as much as the practice of it.)

FrontlineSMS goes beyond effective GUI because it, as an interactive system, is backed by substantial user research, understanding and a consumer-targeted approach. Evidenced by Ken's responses to our questions, this mobile interactive system is a product of ad-hoc ethnography as much as rapid-prototyping.

In fact, perhaps without realizing it, Ken has done a commendable job at UCD by making UI choices in response to actual user needs. For that he has been rewarded (by the rapid uptake of his application).

Our praise of Ken's work, however, is balanced by the recognition that many social-oriented projects may not have the good fortune of in-depth user research or domain expertise.

So we at The UI Thread put forth a call to action for those wishing to develop interactive-systems on shoe-string budgets:

Embody "OpenUCD." Find ways to follow UCD methodologies the best you can.

Ask for help if you feel you need it.
(e.g. http://groups.google.com/group/openucd)

For more on Ken Banks' initiatives, and FrontlineSMS, please visit Ken's website Kiwanja.net.

Learn about his background and experiences at this ShareIdeas.org Webinar.

Thanks Ken!

- UIT

A Scientific Method of Designing

1. Finding Need in the Market
   
2. Targeting a Customer Segment
   
3. Identifying Use Cases of Ideal Solution
   
4. Prioritizing via Functional Limitations 
   
5. Creating an Information Architecture
   
6. Modularize Layout of UI
   
7. Designing Efficiency of Interaction
   

Let me cut you off right there. You are correct. There is no hard science behind design. However without some framework, design is downright impossible. Let’s leverage the best practices of business, engineering, and visual arts to deliver the richest experience to our end-user.

A Seemingly Useless Epiphany

People need a place to live.

   Let’s face it. We encounter so many problems every day. Technology hasn’t made us less stressed or happy; rather, it has given us higher expectations of what the world should deliver. Lucky for us designers, technology only creates more opportunities for innovation. There is no shortage of problems and neither is there a shortage of ideas. Thus, finding a need in the market is really a matter of identifying a single group of issues that can be met with an innovative, elegant solution from technology.

A Need in the Market

People need to be able to find a place to live.

   More than likely, you’ll find almost everyone can benefit to a solution to the problems you encountered. Well due to evolution or some higher power, we are not all created equal but somehow we fit into nice groups we can call demographics. Each demographic has it’s own constraints, whether financially, technically, or even accessibly. By “discriminating,” you now have the ability to target a niche. Thus you have the upper hand to compromise less and deliver the highest utility to the select rather than compromise completely and deliver a lower utility to everyone. All in all, your goal is to compromise the least in order to provide that rich experience to as many users as possible.

A Customer Segment

American technical 20-somethings need to be able to find a place to live.

   Now it’s time to think big. You must identify all the circumstances and objectives you can satisfy with your innovation. By targeting a customer segment, you have the ability to cater to their needs and wants. At this point, you should not get bogged down in the details but instead identify objectives, features, and other consumer-friendly uses of your ideal solution. Remember, for each problem you solve, consumers will want to reach that solution more efficiently and effectively.

Use Cases of an Ideal Solution

These people want to be able to access an online tool 

to find a place to live optimized for their 

finances, activities, locations, fun, and overall happiness.

   Then, it hits you. You remember you’re still living in the blossoming present, not the rosy future. (Municipal Wi-Fi is still five years away like it was five years ago.) The use cases you identified are what your target customer wants. Since you have a target customer, his or her use cases are not a result of any compromise yet. Instead, you have the ability to prioritize the use cases based on functional limitations. Not everything can be done with the technology of today. However by prioritizing what you know what you can deliver today, you have essentially identified what you may be able to better deliver tomorrow. By now you have created a matrix of use cases, ordered by importance to the user coupled with the roadmap of when you can deliver on those solutions.

Prioritizing via Functional Limitations

There is no measure of happiness but there is a measure of finances 

e.g. personal online banking information.

   With a fixed set of use cases, you can figure out the most efficient paths for users to achieve their end result. By crawling into the mind of our target user, we can trace the steps he or she would take. Many of the use cases will have common steps and lead toward a complex web of information. By creating a hierarchy of these steps and connecting commonalities, information architecture will follow.

Information Architecture from Prioritized Use Cases

Housing > Finances > What I can afford > With Loans > With Interest

vs

Housing > What I can afford (with loans with interest)

   Here’s the tricky part. A path for a common use case may have a long series of steps. If you were to directly map the information architecture into a hierarchy-based UI, your user would be very inefficient in achieving this task. One solution is to minimize this issue, by providing a “shortcut” to this action (or actions via a group). Each of these shortcuts take away from the organized structure you tried to map from your information architecture. However, these shortcuts are a necessary evil. By modularizing your UI, you can properly distinguish your shortcuts (and groups of shortcuts) from your hierarchy to help users gain quick access to solutions to common use cases while at the same time providing a logical path to other solutions.

Modularization of the UI

Hierarchy: Optimize finance, Optimize activities, Optimize distance

Shortcuts: Automatically optimize everything based on my online information

   Just by segmenting the layout of the UI, the interaction does not automatically become optimized for efficiency. This is where usability and benchmarking takes place. Obviously, we are not the target customers so we should not take our own wisdom as the final say. Getting target users involved early in the process leads to more user-centered design. This prevents usability “fixes” and supports an elegant solution from the beginning.

Each of these six topics may deserve their own blog post but at the same time, it is necessary to have a general yet clearer idea of the issues that must be considered in design. By communicating a process, I hope to initiate discussion of the larger topics that fit into each step. This framework may be referenced in future threads as a starting point for further discussion.