For Pt. 1 of this post, I will discuss how the need developed for an app in our organization, what we wanted the app to do, how we chose what type of app and platform to use, and why we chose to use Conduit Mobile. Pt. 2 will go into detail how we created the PALNI Meeting app, our frustrations, and our usage.
Apps and app creation have been of interest since I started at PALNI but we really didn’t have a need to spend the resources to create one. It would have been just another thing to maintain with little added value to our librarians. However, Summer of 2012 rolled around and we started running all over the state to in-person meetings as well as numerous online meetings. It was in the mix of printing off campus maps, googling addresses to use in the gps, and trying to find the online login information that the need for a PALNI Meeting app became evident. It wasn’t until a late night on Reddit (r/technology) that I stumbled upon Conduit Mobile – a free mobile app creator – that I saw a way to create the Meeting app without killing myself trying to master code.
- Google Calendar integration
- Rss feed capability
- Easy Contact avenues – phone, email, text
- Customizable HTML pages
- Social Media RSS
- Ability to update with ease
- Available offline – desirable but not necessary
- Push Notifications – can’t do unless creating a native app
Native App VS Web-based App:
To decide between building an app from scratch and using a CMS GUI (like Mobile Conduit) as well as choosing between creating a web-app and a native app, I turned to O’Reilly’s ebook, iPhone Apps. PALNI started out working to create a native app that would be available for download at the iTunes store/Google Play store. However, we got bogged down in reviewing contracts between Apple, Google, and the mobile app creator platform. At one point, we realized that Apple was going to blame us if the 3rd party app creator platform did anything wrong and vice versa. Rather than pursue this headache of a mess and risk getting ourselves in a bind, we sacrificed the ability to access the phone’s hardware and went with the web-based app.
This made me happy as the developer since there was now less complexity to the project.
This made the Executive Director happy as the only contract we had to keep tabs on was the mobile app creator platform (Mobile Conduit).
This made the budget happy as we didn’t have to pay $99 to Apple and $25 to Google to put the app in the stores.
This (will make) users happy as the app will work on ALL smartphones as it is coming from the web and not a packaged application designed for a specific phone type.
As you can see, going with a web-app made sense for our organization. Perhaps we will design a native app in the future if we develop the need for it, but until then, our lives are little simpler with the web-based app.
Choosing a Mobile App Creator Platform:
PALNI chose to go with Conduit Mobile for their app maker as it provided many of the features we were looking for as well as being insanely easy to use.
|Google Calendar integration||YES|
|Rss feed capability||YES|
|Easy Contact avenues – phone, email, text||YES- but no texting*|
|Customizable HTML pages||YES|
|Maps||YES – but we went a different route**|
|Social Media RSS||YES|
|Ability to update with ease||YES|
|Short URL to access||YES & Customizable!|
*The documentation states this is possible with a native app since the app needs to be able to access your text message system on your phone.
** Because we serve 23 institutions, we needed a way to access 23 maps versus one. Check out Pt. 2 of this post to see our workaround using a Facebook feed.
I also looked into:
- AppMakr – Appeared to only make native apps which would require the contract and payment rig-a-ma-roll for the stores. No thanks! Might be a nice option for libraries making a native app and are will to pay for it. (Side note: I actually signed up for this LAST YEAR and completely forgot about it. We didn’t have a need for an app at PALNI yet but I enjoy looking at options for the future.)
- mobincube.com – Ya, something about this GUI rubbed me the wrong way. The GUI design was very modern and convenient but it lacked the UX principle of easy understanding. I found myself clicking all over the GUI trying to customize the app and then got completely lost when trying to publish the dang thing. Once I “published” it, the URL (which was a random assortment of numbers and letters) didn’t work and the QR code linked to a really random lost page. They do deserve bonus points for providing more ways to customize the look of the app but that’s moot when the app doesn’t publish properly.
- The AppBuilder – This is my runner-up choice as it has most of the features I was looking for AND provides the web-app for free. They offer some starting templates to use but I went with custom so I didn’t miss out on anything. The GUI is also awesome! They really stepped you through the process and made it very intuitive to use. BUT (and I wish there wasn’t a but) the Event page required me to input manually all our events which is too much of a time-waster when we use our Google Calendar everywhere else. I tried inputing the calendar RSS URL in the RSS feed section but it was REALLY unattractive and did not display any details of the event. For a meeting-specific app, I had to pass on AppBuilder due to their Events section not integrating with Google Calendar. Another problem I later found was the ridiculously long URL to access the web-app. I saw the long URL as a big hindrance to people accessing the app the first time.