Mobile Ministry Magazine

This is the meat of the MMM Mobile Experiment Report, and also where it makes the transition from being just a review of software and online services to one of looking beyond the offering to the ability that it lends. Here's an outline of what is covered in this, Part Two, of the MMM Mobile Experiment Report:

• Additional Setup Items
• Day to Day Use
• Immediate Challenges
• Accessibility versus Versatility

Given the length of this, section of the report, it will be an extra day before publishing the third and final section. This report will also be made available as a singular download (debating on the format of that now). Enjoy Part Two, and please do not hesitate to give any comments to this or Part One.

Part Two:

Having set up the Mobile Web Server application on my device, and creating the Mobile Web Server website, I had to set up some initial pages so that in coming to the site, Mobile Ministry Magazine readers would be greeting with more than just a blank page. There are two parts to setting things up for day to day use; one part is on the mobile device and the other is through a browser (that can be on the mobile device or not; but most might choose not to go that route and just use a separate computer).

Setup on the Mobile Device

On the mobile device, one navigates to the Web Server application and is presented with a series of screens. First, you are asked to insert your user name and password that was set up on the MWS website. There are a few easy to figure out section of the application that is always shown when it is opened from here: Users, Status Message, Statistics, Access Log, Folders, and Settings.

The Users section was probably the one that I spent the most time with initially. There is a default Guest account where one can set Guest access to the MWS; and then from contacts in one's address book, you can set specific users to have ability with a user name based on their name in your address book and a password that you have set for them. I quickly abandoned doing this for a lot of people and just settled on making sure that I had a user group for my family to special sections of the MWS site, and everyone else just got the Guest account.

Truth be told, I spent a lot of time looking at the Access Log. I wanted to see how many people were hitting the site, and it was kind of neat the first few days of the experiment. We averaged about 10 unique users per day and for the most part people did not have issues with logging in (user names are case-sensitive; found that out halfway through the project).

Setup through the Web Browser

There is a setup wizard that one has to access from a device that has a suitable web browser while the mobile web server (MWS) is running. On my end, I used my Nokia N800 Internet Tablet connected to a Wi-Fi hotspot at a local coffeehouse while the MWS was running on my N75.

Two parts of this allow you to set up things like the welcome screen, offline page and message, and get a badge that can be displayed on several websites. After this wizard, there is a control panel that keeps the latter items, and allows for presence updates on the status page. One can change the theme to several types; however they are nothing more than color and banner changes. Unless you want to dig in the mobile device and play, there is no way to create custom layouts or fiddle with the CSS for more customization.

From the web browser one is able to set all types of options and create content and points of contact.

• Home
• Blog
• Camera
• Gallery
• Guestbook
• Contact Me
• Presence
• Web Chat
• Calendar
• Messaging
• Phone Log
• Contacts

By default, guests only see the Home, Blog, Presence, and Contact Me sections. The Gallery has to be setup to either show (share) pictures that are shared from the phone's internal memory, memory card, or both. I found that the Guestbook was a bit of a redundant feature, but it could prove beneficial in some applications. The Web Chat section is interesting as when someone starts a web chat, there is notification on the mobile device of the chat and then an IM-like interface is given. From there chat happens just as it would in any other chat room. The Calendar, Phone Log, and Contacts are pulled right from the mobile device and gives a browser-accessible means to see and edit content. I liked this feature, but wished that there was more granularities so that some users could see "Busy" instead of the specific event. Presence tells the state of the mobile phone such as how long it has been idle, battery life, and a status message. And finally Messaging allows one to send an email or SMS message directly to you as well as see all the SMS and MMS messages that are stored on your mobile device (Inbox and those sent).

One neat feature that is present throughout is the fact that all contacts that appear in various applications such as Calendar and Messaging are linked to their contact card. This contact card shows the last call as well as links to the address book entry. Simple, but really neat.

From registration to setting up the welcome page and basic access rights it took about 30 minutes to get rolling. After that it was just a matter of running the MWS on my device and engaging with people as they visited MMM Mobile.

Day to Day Use

The Mobile Web Server is pretty much a set it and forget it type of application. I let it run most of the day, taking it down in the AM in order to use my mobile device as a modem for my Internet Tablet and desktop. During this time, I updated the status message to point visitors to the MMM Jaiku channel. In pointing people to the MMM Jaiku channel, it was my hope to engage the usual readers of MMM, and the new visitors of the breadth of content related to Mobile Ministry Magazine, as well as engage in some discussions across a social network in a slightly different function than what is normally done in blog-driven websites.

On the downside of the day to day use, the MWS was an inconvenience in terms of the other connectivity that I aspire to have on my mobile device. Usually, I run the Emoze email client and the Jaiku Mobile client. Because of the MWS, I was not able to run these and have a long functioning device. Either the MWS would take over the connections, or the applications would consume too much memory and cause one or all of them to shut down. During the experiment, I only suffered one total device crash, but this was an instance where the hardware specifications of my N75 (which has about 15MB of memory free for running programs at boot) was at the very bottom of what is needed to run the MWS.

Because of this limitation, I was not able to use programs such as widgets to keep me abreast of what was going on at the MWS without opening the application. That being said, it was quite nice to have the server running and not have to think about it unless I needed some kind of functionality that was a bit more than normal.

A small note: the Nokia N75 is a 3G phone, meaning that it has the ability to use a high speed data network called HSDPA. Because of the specifications of this network, the device is able to use applications that connect to the Internet at the same time as using voice functions. While running the MWS, there was no drop off in voice quality or phone functions except for occasional slowness for MMS message processing.

Immediate Challenges

While there were those hardware challenges, the large and more pertinent challenges to using the MWS was trying to keep the same kind of communicative presence that had been done at Mobile Ministry Magazine. Essentially, opportunities to post to the blog, upload pictures, and engage the reading community were all things that seemed a lot easier when connectivity was spread across devices instead of being centered on one device.

For example, whenever I needed to use the web browser on the N75, I had to shut down the MWS because the two applications were too large to run at the same time. This meant that I would have to create a status message saying that the server was down and point people to the MMM Jaiku channel; then initiate a discussion at the MMM Jaiku channel; and then I would be able to continue with using the web browser. Certainly, having a device with later hardware (more memory and processor speed) would have been great here.

Another issue that I found was that in order to publish to the blog, I needed some type of dual connection. Using the MWS made situations of traveling to WI-Fi hotspots a bit of an adventure as now instead of using them just as a rest place, I wanted to be strategic in making sure that I could create a conversation piece around the use of the technology. It was not until later in the experiment that I realized that there would be times that I would be able to use the web browser on the N75 in order to populate the blog. This stretched the mobile device, but creating a blog post where I was able to live blog a sermon and have my notes created on the N75 instantly appear online was quite exciting (mental note: taking a T9 typing class before doing this should be a prerequisite).

Accessibility versus Versatility

This challenge of balancing multiple devices, multiple input methods, and then just the plan fact that a web server can really go with you anytime makes one feel more accessible than ever. The granular level of being able to assign contacts or groups of contacts to various parts of one's mobile device presents a solution that is present already in some enterprise applications such as SharePoint and even commercial ones like Movable Type. But those are PC-focused solutions. Nothing wrong with that, but as mobile devices become more versatile, one should not just assume, but see that a lot more of what we do can be driven from a mobile platform.

The Mobile Web Server is an answer to a question that is not yet asked so loudly yet though. Its not so much an issue of how does one stay accessible, as many connected devices open to you; but it allows you to determine how you want people to connect to you based on the social network that you have built - your phone book. This is more powerful and empowering when combined with a communications strategy and a personality that invites people to want to connect to you. That being said, its not accessibility that is the focus of using the MWS, its versatility. Versatility meaning that you are empowered to take your social network with you, and how they connect to you is determined by you, not by the service that you subscribe to.

This is if you where using the software and service makes a change from being just a piece of software or just another online service. It would be easy to just put the MWS into one of those categories and then judge it based on its benchmarks; but there is nothing to just it against. Nokia's Mobile Web Server is a canvas that if given the network and the hardware (and economies) becomes a canvas that enable the kind of personal computing that was dreamed about in the 1950s when the foundations of the Internet began, and now realized with the fast and (nearly) open wireless networks that most of the world has access to.

Flash Sideshow of MWS Screens, via Share on Ovi

Labels: accessiblity, browser, community, device, internet tablet, Jaiku, mobile, Mobile Web Server, mobiles, mobility, N75, Nokia, review, SMS, software, tech, usablity

Greetings all; thanks to all of you who have visited and commented on MMM Mobile in the past week. It was certainly a new experience for me to use a mobile device as the web server and I have a greater appreciation for a lot of aspects of server administration that I had not had before.

Seeing what my mobile device could do under the pressure of being a communications platform in every sense of the word was tough as well. From blogging, to the web chat on day one, to just making sure that I would keep the MMM Jaiku channel going with back-chat; it was both a pleasure and a challenge to do something that (to my knowledge) has not been tried before.

What's next is a report of things that I found, as well as why such an experiment has relevance in this highly connected world. With talk of net neutrality, the new digital divide, and Christian digital responsibility, there's a good deal that this experiment opened that I will be bringing to you in a three part report.

To give you a heads up, here is an outline of what you can expect in my next three posts:

Part One:

• Reasons and Goals of Experiment
• Explanation of Nokia's Mobile Web Server and my Device
• Social Networking Component

Part Two:

• Day to Day Use
• Immediate Challenges
• Accessibility versus Versatility

Part Three:

• Lessons Learned
• Current and Future Applications
• Why This Is A Model for the [Digital] Church

I am trying to take my time with this, and I do encourage you to ask questions along the way towards parts that need to be better explained or clarified. Like I stated earlier, making sure that you (this audience) understands why such an mobile experiment has relevance for you today is a big goal of this report. Keeping in mind of the Word to always encourage one another, its my hope that this would encourage you to not just think about how to use technology, but how your innovative use of it will give people a chance to view Christ in ways that they never imagined.

Again, stay tuned, Part One is just about finished being written and edited. Looking forward to your comments.

Labels: Bible, browser, community, mission, Mobile Web Server, mobiles, mobility, tech

Last night, I downloaded Nokia's Mobile Web Server onto my N75 and have to say that its am impressive piece of work. Besides being a web server, aka I can run a website off my phone, I can also use it to extend things like my calendar and contacts to friends and family and essentially have a website for direct communication.

That, of course, got me thinking about Mobile Ministry Magazine (MMM) and a route that could be taken with it. Essentially, I was thinking of taking a week to host the site on my phone, and then use the MMM Jaiku channel to supplement things when I need to take it offline (ya know , to turn off the phone or use it for something else).

But before I go off the deep end and really make MMM mobile, I wanted to ask you all of your thoughts. Here is the poll, please place your responses in the comments.

• MMM should stay as it is and the mobile MMM just be an aside
• MMM should go mobile as described above
• Something else entirely (please describe)

Please understand, I am totally mobile and so doing this for a short time is mostly a test of the technology and my abilities to be productive with it. My phone will certainly have a fit with it, but this is part of the reason I get the devices I do, I like to push.

Thanks in advance, and I hope your week can start off with some innovative ways at addressing life and tech.

Labels: browser, community, device, Jaiku, mobility, N75, Nokia, phone, software, tech

Image from Wikipedia

For many of you, its not an issue of "if" to extend your offices, by using web and mobile technology, its a matter of "how."

To answer the "how" we are going to look at a few areas: engaging people to use the tools and selecting what works best with your budget.

Engaging the Team

A major hurdle to using anything new is getting people sold on the idea that it would work best for them. Unfortunately, we are creatures of habit. Doing something different, especially when it comes to utilizing mobile devices, services, or applications can be a bear.

One thing you want to have in place before you roll out a solution is some type of easy to access help system. This should be in two layers (simple): knowledge base and people (in that order). The first questions people ask are the "how do I do this" ones, so making sure that this is populated, and constantly maintained, is of great importance. This resources should be emphasized during any training, and a part of a weekly routine of checking on the progress of implementing a solution.

What this looks like to the minister's on-the-go-office could be a wiki that is saved on the mobile device with common topics. It could be a contact entry that is constantly synced with a note detailing how to do immediate problem solving.

The people resource should be the second and final one. This is where one asks for assistance in doing a feature, or needs a refresher in what was taught originally. Everyone needs a point of contact, and assuring them that there is a person that can be contacted makes it easier for people to accept that there's a change in the workflow in the mist.

Actually getting the team to use those new tools might be less difficult if it could be implemented into the normal routine. For example, in one SharePoint installation I was a part of, instead of making the entire enterprise use it all at once, we made the departments use it only for announcements. We left it open for individuals to play with, but made them know that the only way to know about what was going on was to visit the SharePoint website. Over time, we rolled out more and more SharePoint-only features, backed up with training key users on more features so they would talk about it, getting others involved into using it on a more consistent basis. Basically speaking, giving it to them in small bits is better than force-feeding.

Budget Concerns

One of the questions that is always asked when talking about extending one's office using mobile tech is the cost. Cost doesn't just include the money, its also inclusive of the time, the administration, and any thing else that is not actively using the tech. Balancing cost versus use is hard, but here are some things to think about when evaluating cost:

• Are those providing support or those building the system a volunteer who may leave at any given time?
• Does using a mobile device require additional learning outside of just using office tools, such as user interface and system maintenance issues?
• What is the backup plan? Will implementing a backup plan cost as much as implementing the primary plan? Can using the backup be easier for users than using the primary?
• What are the cost savings/expenses of an entire ministry team being online? Are subsidies or grants available to offset the costs of running/not running a physical office?
• In extending the office, what are the costs to family, friends, and ministry endeavors? Can appropriate boundaries be kept?

Addressing Smaller Offices

Some of you reading this might see these as all well and good, but you are part of a 5-man or smaller team. Things just aren't that deep (in scope or budget). So what can you do?

Take advantage of web suites like Google Apps or Zoho Office. While providing a centralized interface for work, it will also keep things manageable in one area. Using smartphones, Internet Tablets, and UMPC devices are a good means to take light work on the go. Remember though that more devices are more things to manage. Choose the device carefully, basing the costs and engagement on what you already do and what you need to do better.

Labels: browser, community, device, email, family, Google, mission, mobile accessories, mobility, networking, SharePoint, stewardship, study, tech

I commented on a recent post at the Mobile Opportunity blog that the idea of hybrid apps is something that should be better explored, especically by Bible software manufacturers. As more and more users are expecting to interact with their content online, yet be able to use it profitably offline as well, to do an hybrid (or RIA in developer speak) application is not just a possiblity, but the way applications are gonig.

So what are some possible routes that these hybrid applicaitons can go? As one developer noted (referenced in the MO blog), there are 3 million platforms with 100 users each. In other words, with over 3.3 billion users of mobile phones, there are very few dominant platforms. There really isn't any that are. Unless one wants to say that the browser is. And then things get interesting. One, because there are several players, but two because most of them are trying to bring the best web solution after the aftermath of the iPhone.

Some examples of developer tools for making hybrid applications include Java, Adobe AIR, Silverlight, Flash, and just plain ole' CSS/XHMTL-driven AJAX. For the most part, mobile browsers can do the latter, but its when you add that additional layer via something like Adobe AIR, things can really get interesting. Besides creating something that is accessible online, the paradigm of use is extended to blend the online-offline realms and then richer content and productivity can be taken into account.

The positives in this approach are that content publishers can keep their licenses and continue to sell their content. Softawre developers though would be resigned to creating facnier and more intuitive packaging, drawing people in with service add-ons such as online storage or integration with other web services. And finally end-users will have competiting and mostly useful solutions for staying informed, but also connected towards their preference. The downside of this is that there will be more subscription-based services, but as you move from a client-application to a service-application model this is something that is bound to happen (as services meet critical mass this cost is a lot easier to swallow all around).

An example of a near-hybrid Bible reader application is Laridian's iPocketBible. Its a browser service/application that allows the transfer of content from the iPhone/iPod Touch owner's device to any other device that has a suitable browser. And with added features such as the new bookmarks and desktop syncing, its only a matter of time before others come, and take what we know of as just a browser and make it more than just a place to consume information.

Another example of this is Google Gears. Google Gears allows for some AJAX driven websites to be used offline, and then when the user gets a connection again, sync back to the online item. When I was at Bible study last night, I began by using eBible and wished for this functionality to be something there for my notes. Wouldn't you know that a port of Google Gears for the Internet Tablet had even been released. Now it would be up to websites to support such a feature (here's one way to do so) and then users to take it and run.

There's more than a place for hybrid apps to take up where many of us have been disappointed in the condition of mobile Bible readers. The question now is if developers and companies see the writing on the wall, and take things a considerable step towards a future of ubiquious connectivity.

Labels: browser, community, software