Posts Tagged ‘mobile in development’

That Ever-Evasive Calculation of Mobile ROI

Wednesday, May 23rd, 2012

Mobile ROI

Caught this on the 271st Carnival of the Mobilists (hosted by MobiThinking) and thought it just great to put into the stream of posts given the direction the past two have taken:

Many execs put items on their roadmap that their gut tells them are important, but it’s difficult to calculate the ROI.

While I agree that it’s impossible to calculate the exact ROI of soft ROI initiatives, I think you can calculate the ROI enough to objectively assess your priorities.

In fact, I think it’s critical that you do so. The mobile landscape is littered with too much wasted money because of executive gut decisions that didn’t end up the way they expected.

So, let’s walk through an example…

Read the rest of Mobile Roadmap: Calculating Hard ROI on Soft ROI Initiatives at Mobile Manifesto

In other words, it can be hard as counting black beans in the dark but its not impossible. A lot of how you determine that ROI starts from what you know and don’t know. Perhaps in light of the piece at Mobile Manifesto, these posts will help make your ROI calculation, and project viability measures, a bit easier to understand and work through:

 

Trying Out the biNu Mobile App Developer Platform

Friday, May 11th, 2012

Per our usual activities here, we occasionally check out processes and software which would be relevant to the #mobmin (mobile ministry) world. A question for many groups is the process of making a mobile application, and so we definitely like to take a look at the various application creation platforms that are out there to get an idea of what’s needed in terms of graphical, technological, and marketing knowledge to get things up and running. The latest of these development platforms we are looking at is the biNu platform.

biNu is a software delivery platform. Think, something like an app store – but optimized for feature phones (non-smartphones). When there is an opportunity for an engagement to be accented with a mobile app on a (most likely) Java-based mobile, biNu is positioned through its delivery platform to refactor your RSS feeds or any other custom (mobile-lite) page content into a downloadable application for these mobiles.

We took a look at it from the perspective of  a content owner who’s looking to gain a presence on feature phones (its a good idea to read Should Our Church Have an App or Mobile Website prior to this). Therefore, our most important places of entry happen through the biNu Dev portal (still in beta – this comes up again).

Note: the screenshots and activity here were performed on a Windows 7 laptop using the Google Chrome browser. For the benefit of the impression, this is an imposed boundary to using the product.

Step 1: Registering for at the biNU Developer Portal

As with similar services, you have to go through a short process to register for the biNU developer portal (http://developer.binu.com/). After filling out the form, you get a confirmation screen noting that you need to complete a step in your email in order to complete the process. Nice and simple in this respect.

Step 2: Navigating

biNU Developer Dashboard

Once you login, you are presented a straight-forward list of what you’d want to do: List Apps (see all the apps you’ve built), or create a new Basic or regular app. First up on my listing was to do the Basic App (this would most likely be the used option for 1st time users of this service).

Step 3: The Basic App Wizard

biNU App Wizard

Once you get into the Basic App creation wizard, you simply just add the title and description to your app. You do need three graphic files here. Though the sizes were specified, I noticed in the test view that all of them seemed to be resized fine. I’d recommend here not using anything smaller than the recommendation, and you will need to ensure that its a PNG graphic w/o transparency for best effect.

You will also need the URL for the RSS feeds that you would use to populate the app. I took our raw feed, in addition to our Twitter feed and the Twitter feed for the #mobmin hashtag (we’ve done this previously with other apps) and there seemed to be no issue with either of those kinds of sources.

Step 4: Testing/Further Edits

biNu testing emulator

biNu offers a Java-based emulator that gives you an impression of how your content will flow to the smaller screen and different input controls of a feature phone. On the PC that I used, I didn’t update the Java client in order for this to work properly (but you would probably want to do this).

Step 5: Publishing

biNU Publishing Your App

Once you have created and tested your app in the emulator, next is to publish it. There are two avenues for publishing – the first puts the app on the biNu platform “store” where those who’ve downloaded biNu would be able to search and download it among other similar apps/services. The second avenue is for you to generate the app yourself using biNU, and then use publish that app on your website or wider-serving app stores such as GetJar.

biNU Generate Java/Android app

When you choose the option to generate an app, you are taken to a screen that’s similar to the app wizard where you refine the details about your app. What’s most interesting here is that you see the option to generate either a “regular” Java app (ideally, compatible with most Java mobiles) or an Android java app (an apk, compatible with Android devices). Apps can be unsigned or signed using Verisign or Thawte. Again, good options for an app which could be distributed in an open market environment.

Generating the app was the only point in the process where I entered an issue that I had to escalate to biNu directly. As of this writing, this is something being looked at.

Step 6: All Done, Go Build Some More
biNU listed apps dashboard

Once you’ve finished making your app (testing, publishing, and generating Java versions), you are pretty much done. As seen in the publishing step, you’ve been given a URL with which to publicize the app (I’d recommend using a URL shortening service like TinyURL or Bit.ly to make it smaller, more share-friendly, and easier to add to marketing materials). View/Download the 1st MMM biNu app.

Conclusions:

Overall, using the biNu app wizard enabled me to build an app in less than 30min. When I went back through the process to build an app from scratch (see Step 2: Navigating), the process took even less time because the source for the app was an existing mobile website (in this case, our alternate mobile site which is written using HTML5 and jQuery). Given the speed and costs (free) to just get on their platform, this isn’t a bad idea for many sites. I’d like to know how some of the more interactive content offerings would fare here – for example, those doing church online might want this for a presence, but the experience of viewing media on a 2.2in screen that’s not optimized for such “snack time” viewing might be a turn off in some respects. Still, there’s some sense that could be made from doing this and perhaps pointing to your YouTube feed of content.

For more information about biNU, do check out their website. Again, the developer section of the site is in beta right now, so if you enter into any issues with it, do chalk it up to that aspect of things. Still, there aren’t too many mobile services specifically targeting feature phones (more people use these than smartphones by a very wide margin). If your content is ready to go, then biNu should be ready for you.

 

The Firehose that is MMM

Tuesday, April 24th, 2012

The other week, we were approached with shuttling some of our content to a mobilized service. That service would basically take the RSS feed and then do some optimizations in order to make it work best for its platform.Well, we’ve got a lot of content here, and one of the items that came back to us was that we’ve got a lot of content and it makes it hard for them to figure out the best way to present our content. That’s a problem, but also speaks to the nature of the content here at MMM, and some of what has been happening behind the scenes to make the experience of reading the most relevant content more possible.

Developing The Firehose

Back when MMM got started online (April 2005), we had a model that was basically a copy of many of the high-traffic websites of the time: publish, publish, publish. I can remember at one point putting up 5-6 pieces a day, and many times unique pieces. For those not knowing what MMM was (amazing how folks stumbled upon us via a simple search), this wasn’t a bad thing. But over time, that got to be a bit much. We went to a single-post-a-day schedule many years back, and for the most part have been able to keep a consistent and constant stream of content flowing.

With that change in frequency came a change in the type of writing. I noticed from the analytics that the longer posts that we made had people stick around a bit longer. And not just to read that post, but they were most likely to go visit someplace else on the site. I shifted into making long-form content, best suited for contemplative reading – rather than quick skimming (other tech sites went this route) – but not to the length of what would be found on many theological sites (dissertations I tell ya). That change was also good for consistency, but a pain in the butt for organization.

The Battle to Organize Content

The move to WordPress from Blogger presented a chance to address some issues in terms of how content was organized on the site. At the time of that move, there were almost 3000 posts published and not quite a half of them were tagged/categorized. Google moved Blogger to a tagging system in the midst of our writing, and – well, its a lot of work to go back and retag content. I did a retaxionomy of the content based around some tighter editorial needs in that move to WordPress, and for the most part, its served us well.

What you might not have noticed is that some of those old posts from Blogger (see, http://archived.mobileministrymagazine.com) have been slowly making their way into WordPress. Unfortunately, the amount of content and structure of content wouldn’t import into WordPress, so each post has to be individually added to WordPress, retagged, and then categorized. That’s just something that will continue to take a while. In the meantime, there’s new content being produced that meets the current organizational schemes, in that long-form method, that’s usually quite unique, and generally posted on a consistent basis.

See the fun?

Steps of Manage the Firehose

Now, you would think that with some background in content management and information architecture that we probably shouldn’t be in this situation – but the fact of the matter is that MMM has changed over the years, as has its audience, as has the content. There are some streams of content not as often posted here anymore (direct software and hardware reviews), and there are others which tend to get much more the light of day (processes and UX matters). Where the content here becomes usable for you is in two offerings – based on the detail of the types of categorizing that happens here:

  • Search
  • RSS

Search is probably the most important (and most used) functional feature of this resource. Mainly because it is able to not only deal with the content that we’ve organized, but also dig a bit more into what we haven’t organized (thanks Google and WordPress). One of the pieces that is (unfortunately) missing from our mobile website is a suitable search interface (this is present on the alternate mobile website however). Not sure how and when that could be addressed on the mobile site, but its clear – at least from those of you who come here via Internet Explorer/Firefox/Safari that its a needed feature in terms of getting around.

RSS is the quieter feature used to manage the amount of content here. The way its used is actually a crafty by-product of the tags and categorization system present within WordPress. Every category and every tag points to a page that has its own RSS feed. This means, if you are looking at a subject area (perhaps Mobile in Missions/Evangelism for example) and you want to just get the updates for that stream of content only as it is published here, then all you need to do is either click on the RSS (orange colored) button in your URL bar, or take the URL for that page (http://mobileministrymagazine.com/tag/mobile-in-missionsevangelism/) and just add “feed/” to the end of the address and you have just the data stream for that page. Nearly every page has that functionality built in – and I’ve just not done a great job in talking about it.

The Missteps in that Firehose

The problem with things comes on some of our static pages (Bible apps, Case Studies, etc.) of which there is a listing of content, but those items are merely just a listing. There wasn’t a design to that set of data other than just putting it out there, making sure it linked to the right places, and sat under the correct subheading. That’s now biting MMM in the butt. Especially with the Case Studies/Resources page, there’s just an increasingly deep listing of content, and outside of searching on the page (click F3 on your keyboard if you are on a laptop and you can search within any single webpage), you just will have a hard time of finding what you are looking for.

WordPress is a decent content management system. However, making it work for this application (a multi-contextual listing of resources) would be stretching it a bit – even with extensions. The goal for each page is to be available, but to also be easy to manage. Until recently, that’s not been a problem. The query from the mobile services provider poked at that crack in the wall and we’ve got to figure something to do around it.

One of the solutions is to republish every resource and link on those static pages as a posting with their own set of categories/tags, and then build a custom page that would be able to contain those items. For those reading the blog, that’s going to be a lot of content coming through – and while some might be good to see, there are a lot of links to republish there. Another solution is to use the Links feature within WordPress, and then create a series of custom pages that would display those links as organized. Some of the work to do that has been started (in the background), but I’m still not sure what the final result will look like – though it will be a breeze to manage.

How You Can Help

As you can see, we are indeed aware of the amount and level of content that’s published here. Contrary to some opinions, we are quite focused as to what gets published and how it stays relevant to the overall purpose of this magazine. What we don’t know is how you engage the content here? That kind of information would help us better address what comes out of this hose, and how to continue to make sure what comes out is valuable. With that said, a few questions:

  • Do you use a mobile app to view MMM? If so, which app(s) and why?
  • Do you use an RSS reader to view MMM (which, why)?
  • Do you use either the normal or alternate mobile websites?
  • Do you use the email subscription via Feedburner to read content? If so, how do you archive, organize, resource those emails?

Thanks for your feedback on this. And if you have other ideas on how we can better manage the amount of content that comes here, do feel free to chime in via an article comment, the contact form, or Twitter (@mobileminmag)

 

Desknots and the 7 Deadly Myths of Mobile

Monday, April 23rd, 2012

Caught both of these last week while taking in some of the tweets happening during the Breaking Development Conference (#bdconf). I’ll let the quotes and full articles pretty much speak for themselves:

Desknots are connected devices that present alternative contexts and form factors for non-desktop computing… Desknots aren’t (necessarily) mobile. Desknots aren’t (necessarily) wireless. Desknots aren’t (necessarily) personal. Every category of desknot has contexts, form factor, use cases, and usability considerations that are very different from the desktop. It’s useful to have a term that suggests: “hey, it’s not just about the desktop…

Read the rest of Desknots at Global Moxie – would you agree with the term?

In light of desknots, there’s also this reclarifying about what mobile is and isn’t. Here’s a listing of some mobile myths from Josh Clark which break this down:

  • mobile myth #1: users are on the go and rushed
  • myth #2: mobile = less
  • myth #3: complexity is a dirty word
  • myth #4: extra taps and clicks are evil
  • myth #5: you gotta have a mobile website
  • myth #6: mobile is about apps
  • myth #7: cms & api are for database nerds

I’d recommend reading in detail why Josh Clark calls this myths on the full post at his website. At the moment, I’min agreement with all but one of them (go ahead guess that one).

How do these perspective fall inline with your existing thoughts about mobile? Do you gain clarity, or is there a muddling of definitions?

 

Enterra Gives Developers Insight to Business Mobile App Development

Friday, April 20th, 2012

banner methodology written on glassOne of the requests we’ve had out there for sometime is some testimonials, or case studies, in which those whom are building applications and services that service mobile and mobile ministry endeavors can be highlighted and lend some light to the depth and challenges in this space. A response came from a company, Enterra, whose post on business mobile application development, specifically from a developer’s point of view, is quite appreciated. Here’s a snippet of this expansive and well-written piecce:

…One of the main steps of contract preparation is writing a SOW (Scope Of Work) – a brief list of requirements to the application. For small and medium projects SOW is enough to start the development. For large-scale projects after the contract signing there’s a preparation of technical task.

SOW and technical task are a formalization of developer’s and customer’s vision in terms of the developed applications. It’s an opportunity to get sure that the vision is the same, the borders are set and the wishes are known. But these documents are strictly technical and may not fully reflect the business processes inside the app. So it’s best to read the documentation thoroughly, ask about all the terms and require comments for acquiring your wishes.

In some cases the estimation changes after preparing the SOW, mostly to the larger side. Maybe you came out of your own task borders. Maybe it turned out that the cheaper technologies cannot be used, and the more expensive ones are required. Maybe the contractor offered something more expensive, but more progressive or easier to deploy. The decision of continuing/cancelling the work is up to you and your trust to the contractor. But I strongly recommend to discuss all the changes. If the increase of cost is really required and useful, the contractor will always be able to explain in adequately…

Read the rest of Business Mobile Application Development: The Developer’s Insight at Enterra

The perspectives in this mirrors our mobile minsitry methodology and how we’ve recommended you approach building a mobile ministry app/website, while offering some very real accounts of what works and what doesn’t.

For more information including getting a quote for development work, visit Enterra’s website.

 

All Books Project on Github

Tuesday, April 3rd, 2012

All Books Screenshot
I’ve added my All Books Project to Github for those who might be interested in taking a look as to what I’ve been working on. Right now, that’s just the UX. I’ll get the ReadMe and Wiki updated in time.

As of now, I’m not really planning to do much more to it before I finish some lessons with JavaScript and figure out the speed issues on my Nokia N8. But, if you’ve got ideas, or want to jump in, well, there it is.

Oh… the colors, measurements, and arrangement is all for a reason. That all comes in the documentation… stay tuned.

 

Mobile Industry Review and the Emporia Telecom Series

Wednesday, March 21st, 2012

For a number of weeks now, Mobile Industry Review has been doing a series with Emporia Telecom, a company whose mobile offerings are designed around the needs of those persons who might be older or have needs for simpler and easier to undestand mobile devices. I hesitate to pigeon-hole their offerings into something just for an older audience, because everyone can do with better designed user interfaces, attention to detail/behavior, and such. But, their focus on this group is notable, specifically because it seems to follow along the lines of what we were getting at with our 4th resolution, intentional design decisions and UIs/UXs which follow mobile perspectives.

The Mobile Industry Review series has about six videos (at the time of writing) already published. I’d encourage you to take a look at them:

While watching these videos, or after watching them, consider these points in view of what you are planning or doing in respect to mobile ministry:

  • Does your application or service not just include smartphone and non-smartphone users, but the various ranges of age groups within each?
  • How does your application or service scale to age groups where information is consumed and retained in a different bucket than a UI guide’s recommended “lines per screen?”
  • How do you track or model healthier communication behaviors across age/demographic groups?

A step perhaps towards addressing that resolution by seeing the wisdom of designing for those who carry the most wisdom in many of our communities.

 

John Dyer and Digital Bible Society Introduce Bible Browser

Thursday, March 15th, 2012

Was meandering about the web when I saw a note from John Dyer speaking about a new(ish) project he worked on with the Digital Bible Society (DBS). Called the Bible Browser, its very similar to the apprach I’ve taken with the All Books Project in terms of making a Bible reader that is built with HTML, CSS, and jQuery. John’s a better coder (by a few country miles) than I, and there were several groups participating in this project, so the end result is a good bit more polished, and further ahead. Still, the Bible Browser represents what I think should be the base level of performace and integration we should be seeing in the use of HTML as a platform for publishing with the Bible starting as the foundation.

Here’s a bit more about the project from John’s announcement:

…Now, there are already lots of amazing Bible website and applications out there today built by wonderful Christian brothers and sisters, so it might seem unnecessary to build yet another Bible application. Each of these has a place in what God is doing in the world, but the software that DBS creates has some special requirements that necessitates something new:

  • Must be able to run without Internet access
  • Must be able to run without being “installed”
  • Must be able to run in any browser on any device

In a country where it’s illegal to follow Christ or ask about Christianity, installing Bible software and accessing Bible website are big no-nos, so this security is absolutely paramount. The best solution we have so far is to create an HTML/JavaScript application that runs on whatever browser the user has installed.

The challenged is that HTML-based applications can be a bit slower than full desktop software (like the awesome apps Logos, Accordance, or SWORD) and since we are designing them to run without Internet access (like the amazing YouVersion or Biblia) they can’t have a powerful server to do things like process search queries. This makes for some interesting programming challenges, but it’s also part of the fun of doing something different to serve the church at large. The app also needs to be able to run on very basic phones with limited HTML/CSS support, another fun challenge.

For those technically inclined, the basic setup is that each chapter of the Bible is a separate HTML file linked together by jQuery Mobile which makes browsing the Bible work really well on basic phones all the way up to iPhone/Android. Then a desktop application reads these same HTML files and uses them to produces the multi-pane application you see in the video above…

Very cool stuff. We’ve added it to the Bible Apps page and definitely want to encourage you to check out the Digital Bible Society’s website and support their efforts. John Dyer also has some other neat projects which are great to take a look into (Bib.ly, Bible Web App, etc.) and support.

Now, back to work on All Books… am encouraged to continue and persue this project’s direction.