In a lot of respects, its rare to talk about Bible apps for one specific platform – there so many – the causality of Bible apps for the Symbian platform has been one of those questions that has gnawed at me a bit. Not so much even for the lack of applications, but the missed opportunities because of where the Symbian platform has been represented.
What is Symbian?
Symbian is a mobile operating system and platform that’s been used by Nokia, Samsung, Motorola, Fujitsu, and LG for mobile phones. To date, there have been over 600 million devices shipped and sold with the Symbian operating system, making it one of the most prolific in use.
Nokia has been quite adept at making Symbian fit its needs. It has pretty much been selling Symbian devices longer than people have given credence to there even being a category called smartphones. To that end, Symbian has been deployed with more carriers and in more world regions than all but the most basic of Java handsets.
Unfortunately, it is also considered an older platform that while stable and optimized for mobile devices, falls quite far behind some of the newer entrants in respect to ease-of-use, developer tools, and ease of finding applications. And so Symbian recently befell Nokia’s reorganization efforts (first spun into an open source platform, and now to be greatly minimized over the next years to be replaced by Windows Phone).
Symbian and Bibles
By accident of niche, Biblical software usually is a fairly easy one to fill. Find a publisher that has the languages that you want to address, write the application to deliver it, and then make it available. The issue with Symbian is that its actually a pretty difficult platform to build on. Without getting too technical, its just plain to say that developers have needed to had a certain type of older technical knowledge (previously) or invest in toolsets (Qt, Java, etc.) which required a good amount of patience before progress.
When I moved to the Symbian platform in 2008, there wasn’t much to find for Bible apps. Laridian, Olive Tree, Symbian Bible, and Go-Bible were pretty much your only options. And for a while, this was just fine and covered most of the Symbian devices that were in existence. When Symbian went to a touch-based user interface (UI), things got a lot fragmented, and Symbian Bible pretty much became the only option (Best eBible came on the scene later). Which was good and not good – a free application, using Bibles formatted for the Palm Bible+ application, and had no support for newer translations. Newer platforms ended up with a very easy “in” for adoption, they had what people could read, and could find.
A Missed Opportunity…
In light of all of that history, its easy to say that Symbian (and the companies associated with that platform) might have missed an opportunity to take a platform that has already made considerable inroads even further. But, it had a good bit going against it, and so it is now in the position it is in.
But does that mean that all potential opportunity for this platform have been lost? I’d say no, if technical aptitude is seen as a gift that can benefit the Body. When I say technical aptitude, a platform (like Symbian, but all qualify here) benefits by such knowledge as developer tools, device interfaces, language mapping, usage analytics, etc. A person who is skilled in any of these areas would be a suitable team member for a larger project creating an application, service, or refining a digital faith experience. These persons have to be looked for in “not normal places” as their gift isn’t something you’d find in Exodus on the way to creating a mobile altar (Exodus 25-27).
There’s also the benefit of much of Symbian’s assets being made available in open forums (for example Forum Nokia), through some open source technologies (for example Qt), and through the continued ownership of Symbian devices (installed-based analysis by Vision Mobile). In effect, there’s a lot of folks out there who can still benefit from a Bible solution on this platform.
The Lesson for Other Mobile Platforms
It is easy for the market, and popular (loud) opinion to state where you should place your development resources. Certainly, making plans for mobile software you’ve got to take into account devices, services, and experiences (the entire frame of mobile) and what is currently and what will be in the years to come.
When it comes to religious software, you also have the opportunity to always tap into the installed base of current users. Many times, your frequent fans and users of digital faith items will not splurge on the latest devices or services, though they will want to receive some of the same experiences that newer devices offer. It is in this that the opportunity lies, and where its possible to not just make a product, but help drive older platforms to a friendlier sunset.
Currently, there are several mobile platforms that have come and gone (Epoc, PalmOS, Windows Mobile), and some that are pretty much on their last legs (Symbian, older versions of Android and iOS, RIM’s BB OS 6 and earlier). Developers looking to cut their teeth on a mobile platform to learn and to provide experiences should not forget these platforms. And at the same time, you should go into any project with a clear (and simple) goal and definitive timeline. You will not be able to support those devices for very long when the official support has faded.
Lastly, when you are a platform that has cultured a community of content, but you are no longer able to support that platform, utilize the open code and support communities of Code.Google, Forum Nokia, SourceForge, GitHub, and others as places to put your code and release notes. There might be someone willing to take up the project, or at least help you migrate your project’s contents into a newer platform. For example, MMM participated in an effort to update the Rapier Bible application for Maemo 5 devices, fixing some linger bugs, but that also set the stage to develop (and later release into widespread testing) a Bible application written in Qt from the ground up called Katana. The rewritten application leans on lessons of the former, but has a much longer viable life because of decisions made early on to support certain content and programming hooks.
For Symbian, it may very well be the case that the sun is setting for it as a leading mobile platform. It is also the case that there are some years and various regions of users that still haven’t been served with digital faith content though having a platform capable of supporting it. Do keep that in mind as you consider your mobile strategies, and remember to study the past platforms for what is probably going to happen to many others in a nearer-than-you-can-expect future.
9(unknown*no*no*1)&guid=ON&x_utmac=MO-16595840-1){kind=small}
Continuing on Resolution #4: Raising the Bar on Mobile UX Standards
Sunday, January 22nd, 2012With 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:
*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.
Tags: Android, APIs, Apple, applications, best practices, bible applications, BlackBerry, CSS, HTML5, iOS, Mobile in Analytics/Marketing/Development, mobile in development, mobile in moment, mobility, native apps, services, standards, Symbian, tech, Windows Mobiile, Windows Phone
Posted in Commentary | No Comments »