Monday, June 20, 2011

An Overview of buzztouch, A Mobile App CMS for Non-Programmers

The other day I stumbled on a Make Use Of article about buzztouch, a "iPhone, iPad, Android app builder and content management system."  Since we're researching options for creating cross-platform mobile applications, and the article indictated that it was worth checking out, I decided to sign up and give buzztouch a spin.

buzztouch is designed to let non-programmers build a mobile app on the buzztouch website using a collection of web-based forms.  The app-building interface prompts you to create certain items, like a launcher icon for the app, a banner image for the home screen, and an "info" page for the app, but you choose what other content you wish to provide from a drop-down list of different components.  One component lets you create a screen of formatted text using CKEditor, while another lets you create an app screen using HTML, CSS, and Javascript.  There are components for pulling in remote content such as web pages, YouTube pages, streaming audio and video files, and RSS feeds.  One component lets you pinpoint one or more locations on a Google Map with brief location information that a user of the app can then use to get driving directions to those locations from their current position.  Even though I was casually playing with the system, I was able to create an app using several of these components in under two hours.

Once you've created the app, you can then download the native source code for the app:  you're provided with separated source code downloads for IOS and for Android.  The source code comes in a .zip file, which also contains a readme file with instructions on how to compile the source code for that particular platform and create the native app.  It only took me a few minutes to create an Android app from the source code, and it only took me that long because I had to provide a Google Maps API key to enable the mapping component I'd added (the readme provided exact instructions on the changes I need to make it the code to use the key).  I had my IOS developer colleague compile the IOS version of the app, and it was also smooth sailing for him.  The resulting app on the Android platform looked a little rough simply because of the generic design elements, but the IOS version looked pitch-perfect.

The first time you access any component or screen in the mobile app, there is a pause as the app retrieves the content or content instructions from buzztouch then caches it for local use.  This is where the content management system aspect of buzztouch kicks in:  any changes you make to the app on the buzztouch site get pushed to (or pulled by, not sure which) the mobile app.  So the app owner doesn't need to recompile and update the app through the App Store or the Android Market in order to make content changes.  If the mobile device doesn't have a network connection, then the cached content is used.

So what's my overall take on buzztouch?  I think that if you need to build a mostly informational mobile app, something that serves the same purpose as a mobile-optimized website, then buzztouch is a compelling option because of how easy it is to create the app and then update the content.  Even if your long-term strategy is to redesign an existing "desktop"-optimized website to be mobile-friendly as well, a buzztouch app could fill the void until that goal was reached.

If you need to build a mobile app that's more interactive, one where the user can send and receive custom data, then buzztouch is at best an incomplete solution.  There are no buzztouch components for collecting data (though the app itself will capture GPS info from the device in order to map where the app has been used, which is both useful and slightly disturbing), but you could probably use the Custom HTML component to create a web form that transmitted data via a regular form submit or via AJAX.  And there are as yet no components that let you access device-specific functions like the camera or accelerometer.

On the other hand, if you are capable of doing some IOS or Android coding, the native code provided by buzztouch could serve as a starting point for adding additional functionality:  the buzztouch folks seem to be open to folks using the generated code to advance their learning of native app programming.

So overall, I'm impressed with what buzztouch has done so far with the direction they've taken, and I hope they continue to improve on the platform.

Friday, June 10, 2011

For CFSelenium Users: An Ant Script to Transcribe Your Tests For Multiple Browsers

The easiest way to create a CFSelenium test case is to use the Selenium IDE plugin for Firefox to compose the test, then export the test using the export formatter Bob Silverberg included in the CFSelenium project.  You end up with a test that can be run against Firefox but can be further customized to your needs.

Of course the beauty of CFSelenium is that it lets you run those tests against browsers other than Firefox, to conduct cross-browser testing.  But who wants to create multiple copies of the original tests, or edit the test files whenever you want to check them against another browser?

Not this guy.

So I went ahead and created an Ant script that will take the CFSelenium tests generated for Firefox and transcribe them to work for other browsers I wanted to test against.  The script includes configuration properties that allow you to customize the browser settings to your environment.  For example, I needed the script to be able to rewrite my Internet Explorer tests to run IE on a virtual machine rather than on localhost.  I also took what I learned about capturing screenshots using CFSelenium and added a nice screenshot management feature to the script:  if you add one or more captureScreenshot or captureEntirePageScreenshot statements to your tests, the script will make sure you're using the correct statement for the particular browser, will rewrite the statement to place the screenshot files in a particular directory, and will add code that will incrementally name the screenshot images so you can take and preserve multiple screenshots for one or more tests.

I've put this Ant script up on GitHub at  The Ant file itself provides a lot of guidance on how to configure and use the script and some hints on using CFSelenium in general.  Hopefully it's usable even by folks who aren't completely comfortable with Ant.  I myself am still something of an Ant noob:  I'm sure there are more elegant ways of writing this script, and Ant gurus are welcome to fork the GitHub repo and make improvements.