11. Bad 10 Ways to a Great App Simplicity Too Much Scrolling Repeats Content Too much scrolling Easy to Navigate What Makes a Good App? Directions Over-Blown Graphics Social Features Graphics Don’t Fit Matches the Libraries Look Don’t Rely on the Internet Calendar of Events Colors Too Light/Bright Content that Changes Confusing Navigation Too dull Interaction Update Treating the App Like a Website Lack of Order Fast Loading Pages
15. The Wonderful World of Widgets Beyond the Basics www.LibraryH3lp.com Chat Reference Widgets http://www.phonegap.com/community
16. WYSIWYG Editor www.swebapps.com www.appanda.com www.appbreeder.com Basic plan starts at $29 a month / $399 one-time fee (iPhone Support Only) $29.99 per month / one-time activation fee of $99 (iPhone and Android Development) $29 to $49 per month for iPhone app / free web app
So the first thing we need to consider when we think about mobile apps is “Why bother?” Is this something people really need? The image on the slide is what what my libraries website looks like on an iPhone. You’re seeing a blown up image of the page—think about it on a 4 inch screen. It isn’t pretty. The fact is, people are moving more and more away from the computer and to the palm of their hands. People still use computers, but computers don’t do us a lot of good when we are on the go. 80% of the world is said to have a Feature Phone—that means a phone that basically looks like this, and does not support apps. But one thing it does support is Mobile Websites. The good news is when you develop an iPhone App, you can develop a Mobile Website with a few very minor tweaks—so your essentially developing for more than just one phone.
If you look around at the amount of people using Smartphones—such as iPhones, Android phones, Windows phones, or BlackBerry’s, it’s not going be very hard to say “This is something the library needs.” But how much is it going to cost you? This is the bad news. To put it simply: More than almost any library can afford. The service most libraries with apps are using is Boopsie; I have nothing against it—it’s a great app; a powerful app; an app your patrons will love—but it’s expensive. Well over a 1000 annually. Another option is to hire a programmer, but this could ultimately prove even more expensive. An iPhone app developer can cost upwards of 400 dollars an hour; if you get lucky, you might be able to find someone for 50 an hour. Libraries everywhere are facing cuts—they’re trying to cling to what they have, not create something entirely new. But there’s a third, cost effective solution, that will only cost you the Apple Developer fee—currently $100 annually. It’s called PhoneGap—it’s open source, and completely free. What PhoneGap does is converts that normal HTML website into a functional iPhone App. So all you really need to do is make a mobile website, and PhoneGap will do the rest.
This bulk of this presentation is about iPhone Development, but just to give you an idea of what app development cost, I’ll give you a quick run through of development fees and other requirements.
So what should an app look like?
Ideally, a mobile app should look a little like this. Simple. No images. Just words. This is something that will look in seconds on a feature phone that doesn’t have 3G or 4G. Notice the phone numbers—they’re hyperlinks, which means when the person clicks them, it dials the number. With a SmartPhone, you can be a little more graphical. This is the Seattle Public Libraries library catalog on the iPhone; they’re using Boopsie for their iPhone app, and this is what it looks like on the App. A lot easier for the user! One really great thing about PhoneGap is you can actually see what your website looks like on several different phones. Even if you aren’t ready to develop an app, I would encourage you to download PhoneGap for this feature alone—before you develop an app, you really need to know what it looks like on different phones. The website for PhoneGap is www.phonegap.com
But why PhoneGap? Why not just learn how to develop an app using iPhone’s native programming language. It can’t be too hard, right? Wrong! Can you learn Objective-C? Of Course! But unless you are already well-versed in programming, then you are going to be spending WAY too much time. Personally, I probably spent a good couple weeks trying to learn it—I invested several hours. And I came away only with a basic understanding—I understood the logic, but I could not do it myself. Maybe you have a really supportive staff who would love nothing more than to get rid of you for several weeks so you can “kind of” understand it! So why use PhoneGap? Because it’s the quickest, easiest, way to get patrons something that they want.
So as you start developing your first Mobile App, you need to stop and ask, “What makes a Good App?” What you DON’T want to do is just copy and paste everything off your webpage. You want to try and give your patrons a little more.1. Easy to navigate – this is one of the biggest flaws in apps; the app works great, but there’s no way to get back to the home screen without re-launching the app, or there’s no way to navigate to the previous page without stating over.2. Social features – think of ways you can integrate things like Twitter, Facebook and other social websites into the app; maybe it’s a live feed of updates? Or maybe it’s a way to share books that the user is reading.3. Calendar of events – you don’t want to have to update your app every time something changes—what you want is the calendar to be fed into the app through an Internet/ 3G connection, that way if something is changed, a librarian changes it online. If possible, find a calendar that you can use on both your website and your app that way you only need to update one place.4. Interaction – one thing that will keep users coming back is any kind of interaction; this can be something like “IM a librarian” or even weekly surveys that poll app users.5. Fast loading pages – App users do not like or expect to wait; if a page is taking longer than a handful of seconds to load, you are wasting the users time. 6. Simplicity – Users don’t want to see multiple menus and layers in apps; they want things simple; look at all the top apps and, for the most part, they are simple at heart—simple doesn’t mean easier to build, however.7. Directions – App users are, more often than not, on the go. It makes sense that directions will be one of the top things people come to your app for.8. Matches the libraries look – your app doesn’t want to copy the libraries website, but you do want similarities; you want it to have the same colors, logos, and maybe even fonts; the user should take one look at your app and say, “Yes, that’s the library that I know.”9. Content that changes – take advantage of widgets and codes that let you feed content into your phone; you can’t update your app weekly (or even monthly), but you can feed fresh content to it on a regular bases. If users never see any change they won’t keep coming back.10. Update – Don’t build an app and walk away; prepare to release at least two updates a year to your app. It gives you a chance to rethink the apps direction and also tells users that you still are working on things—that you have abandoned mobile technologies altogether.Bad Apps1. Repeats content – the last thing you want to do is develop an app that simply repeats online library content; the point of any library app is to enhance it. Content will repeat, but be careful that you haven’t simply cut and pasted information. 2. Over-blown graphics – don’t try and impress the patron with overblown graphics; graphics should be simple. If you are trying too hard to impress the user with visuals then they are likely going to be more annoyed then impressed.3. Don’t rely on the Internet – not all devices have 3G. Some of the best app features will be the ones that rely on an Internet connection, and there’s no way around this. But things like hours and directions don’t need to be fed in and should not be. 4. Confusing navigation – Make sure every page has a way to get back to the main screen; depending on the number of pages in your app, it’s also a good idea to have a back button.5. Treating the app like a website – Before you invest too much time building the app, spend some time researching apps; look at the top apps—they all have similar designs. An app is not a website (even if this book is showing how to develop with HTML) so don’t treat it as such.6. Too much scrolling – scrolling with your finger gets annoying when you have to go several inches down for the content that you want; whenever possible put everything on the screen without scrolling.7. Graphics don’t fit on the page – nothing cries unprofessional page more than a graphics and / or text that don’t fit on the screen and force the user to pan to the side to see the rest of the content; make sure you test out the size.8. Colors that are too light or bright – remember where this app is likely to be seen: in the sun. Use colors and fonts that are readable in multiple environments.9. Too dull – you don’t want to overuse graphics, but at the same time you don’t want your app to simply be a bunch of menus and text—use graphics that are friendly and encourage the user to continue to use the app.10. Lack of order – make sure everything is group together in the place that the patron would expect it.
As you start thinking about apps the first thing you need to decide is what kind you want. There are really two basic interfaces. The first is graphical. The advantage of this kind of app is it’s eye pleasing and it feels like many other apps on the market. Ideally, you should have two people on your app team. One that’s good with HTML and one that’s good with graphics. This is especially true for graphic based apps. If you don’t have a graphic designer, then you can do what I did for this app—used images from OpenClipArt.com. The second kind of app is texted based. One very nice feature of a texted based app is you don’t have to do a lot to it if you want it to also serve as a mobile app.
So now the big question is how to get this mobile website to the website. That’s the easy part! First you need to get the the free SDK (software development kit) from Apple—you will need a Mac for this, unfortunately.
Once the SDK is downloaded, you’ll launch the program. You will select new project. Under templates, you will select PhoneGap. Finally you will add the HTML files from your mobile website to the WWW directory of the SDK. That’s it. You are DONE! There’s still testing to be done to make sure it looks and runs just how you want, but remarkably, this will get you a full-fledged iPhone app. From here you can load it on an iPhone or iPod Touch for testing or even get it on the app store—once you pay the developer fees.
Once you’ve had a chance to experiment with mobile apps, there are a few things you can do to make your app a little more interactive. What I would suggest is “Google” HTML widgets and just see what comes up. There’s another of mobile friend widgets—some, like Twitter, will work beautifully with the iPhone. Other’s…not so much. The best thing to do is just experiment. Look for widgets that feed into your app—this helps keep your app updated without have to actually to a physical app update, which a lengthy process. Here are a couple to get you started.
One final option, I want to briefly mention is WYSIWYG editors for apps. The advantage of these editors is they can quickly get your app to Android, iPhone and other phone platforms—and you don’t have to know HTML code. The downside is the limitations of what you can add and cost.
So that gives you a pretty brief overview of iPhone apps. What about Android? Obviously, I won’t have time to cover that in this session, and honestly have not yet had enough experience with it yet—Android uses a lot of command line inputting, which some users will not be completely comfortable with. I co-own a small publishing house, and we recently published a book on the topic, so I brought it along for anyone that’s interested. It’s 9.99; there’s also a book on iPhone for the same price. I will be publishing a book myself with ALA Edition; it’s complete, but I don’t know when it will be published yet—I’ve been told the Fall of this year, but that can change.
