A few articles ago, we went a bit on a extended talk about the All Books Bible Reader that I’m developing for personal use. After talking through the technical features and goals, we wrapped up with a statement talking about clarifying the goals and features for your mobile(-first) endeavors, and being mindful of the specific UX needs mobile presents:

Mobile-Friendly and Personalization As Core to User Experience
The takeaway from this project is that there have been several methods to engaging Bible/document reading, social/offline networking, funddraising, and other initiatives in mobile ministry. However, even if you nail the features, at some point in the maturing of that person using the service or the company offering it, doing something that fits the mobile context and that’s personalized will come forth. It might not be the aims of your projects initially, but do know that eventually, they all point to these goals needing to be met.

With that starting point, we want to highlight a bit more about Mobile (UX) Standards and in referencing that All Books Project, and some of the items to keep in mind whiile moving forward in your mobile initiatives this year and beyond.

Mobile UX Standards
It is assumed that the idea of what makes for a great mobile user experience is pretty easy – just grab yourself an Apple iPhone and use it for a week or two, then switch to another platform for the same amount of time and note how often you frown, toss the device, or find yourself limited in some fashion. And while we can agree that Apple’s iOS platform does make for some suitable claims towards what makes a good mobile experience (consistency, quality, variety of applications, etc.), its not the only mobile experience, nor does it answer every question anyone developing, selling, or using mobility will ask towards.

Over at UX Mag, an excellent article talking about mobile standards beyond the styleguides, frameworks, and guidelines that would usually reference as we develop apps makes an excellent point:

…Apple, Android, and Blackberry all do a great job of sharing standards with their developer communities. They share detailed guidelines on standard UI elements, the associated terminology, and their behaviors, and give usage examples for the UI. However, what they don’t do is string them all together into patterns.

• What happens after you click this button?
• How should these messages change in context of the task?
• If you’re opening a document online, should it open in a new window or in the current window?
• When and where do error messages appear in a form?
• Is that different or the same in a wizard or series of forms?

These are the questions that designers and developers spend most of their time toiling over—the little things that pull UI elements together into a full interaction. And these are also the questions that the OS standards do not cover. This is a key gap in standards for designers and developers that can be filled by a new custom set of guidelines, which further save money and time in development efforts and add value to the existing, basic OS standards.

*List formattting added

Beyond simply saying “we want to go mobile” or “let’s use this or that to go mobile,” you really have to ask core questions about the interaction and steer adamantly towards those goals. What happens when you don’t steer specifically towards the goal, understanding these kinds of questions throughout, is that you end up with a glut of features, conflicting brand messages, dis-engaged users, and missed opportunities to deliever the depth of the Gospel that you/your group intends that application or service to portray.

Start With A Picture, Ask Until the Ink Dries
With the All Books Project, I started with an idea in my head (more efficient Bible reading on my personal mobile device that wasn’t limited to closed-licensed texts), and started scraping together what was needed and what wasn’t in order to make that happen. I boiled things down to two features: reading and searching. And then I took to one of my favorite apps on my iPad (Tactilis) to sketch some reasonable ideas towards how I would get there.

This UX flow document is my gage of whether I’m meeting my goals. If I am, then the lines here continue to make sense. If not, then I go back to this document towards what I (originally or later modified) thought and ask whether my thinking should continue down the path I’m or, or get back on course to what was drawn.

One of the pieces of interaction that I’m aiming for with All Books is a sliding popup for when I click on those verses with footnotes. The feature is harder to implement than its drawn. But, because I’m clear towards what I want to do when the popup is envoked, how its interacted with, and how it is dismissed, I can keep my programming focused and timelines (generally) well kept.

A Good Mobile UX Is Also Your Feedback Loop’s Process
In designing an effective mobile user experience (UX), you also need to take into account the development/design of your support infrastructure. As we talked about once before when developing mobile web apps, you need to have in place the resources not just to build the app, but to support, maintain, and maybe even update it.

Build, Get It Out There
After I was able to figure out my issue relating to displaying content within All Books, I needed to start using it. It didn’t matter that there was (noted) performance issues or the inability to see the footnotes as I’d like. Getting it into my normal use allows me to catch things that I’d not considered in my initial development and design, and then adjust on the fly without effecting other pieces of the project. For example, I realized that for all the work I did with makng this a spatially-orienting design, I still felt lost when navigating. The insertion of colored indicators on the section that I was within helped this considerably, and it was a few lines of code to add to do this (1 CSS class and 1 JS statement).

With that: do you have your mobile UX resolution refined now. Its the middle of January, don’t let too much longer go by.