So this is a fun little thing.
I made a thing that goes out to Twitter, and finds instances of the phrase, “Santorum is a,” and posts it in to a big, bold ticker.
Now you can find out in real-time what the internet thinks a Santorum is.
What do you think? Funny or stupid?
Try it out here:
PS – If you’re interested, I made it with jQuery and a plugin called TweetQuote, which I modified a little.
With the explosion of mobile internet access that has been building for the past few years, I’ve gotten a lot of questions from people lately asking about what sort of strategy they should take in approaching mobile for their news or information site. Should I develop a mobile version of my web site? Should I build an iPhone app? What about Android, should I build an app for that, too? How much does it cost? How can I get the best return for my mobile development dollars?
Well, this is a question we’ve been working on at the ABA Journal, and we think we have found a good way to
The approach I’ve been advocating recently is to turn the bulk of your attention to building out the mobile web site, and then using small “wrapper” apps to maintain a presence in app stores.
There are several benefits to this strategy.
- It’s easy to develop for the web. After all, you’re already doing it. You probably have scripts and code to do 90% of what you want your mobile app to do, so why re-invent the wheel?
- Web development is much cheaper than app development. You know how your web developer wants $100 an hour? App developers want more than that, and it takes much, much more work to build out a native app.
- It’s fast to deploy new features. If you build out an iOS app, then sign it, get it submitted to the app store, get it approved, and then installed on the devices of your user, you’re not going to want to go through all that time and hassle again in three months when you want to roll out your shiny new feature. If your apps are just small wrappers pointing to a touch-ified website, when you want to change something, you just change it once, on the web, and the changes propagate through all your apps.
- All your platforms stay in feature-parity. Since you’re just changing the web app, every platform gets updated at the same time.
- It’s simple to write the wrapper apps. With Phonegap, you can turn your web app into a mobile app in no time. In fact, using Phonegap Build (their online, web-based compiler), I churned out apps for iOS, Android, Blackberry, Symbian and WebOS in a matter of hours. No nativedevelopment environment required.
- No worries about writing custom client-server protocols. It’s the web, so you use standard web stuff like JSON or XML for client-server stuff.
- You don’t have to use the advertising software the platform advocates. That means Apple doesn’t get a cut of your ad revenue, since you don’t have to use iAds.
Downsides? Yeah, there are some.
- Web apps are slower than native apps. For most information-driven applications, this doesn’t matter, but if you need to do heavy math or things like 3D animations and the like, then native is your only choice.
- Not all features are supported on all platforms. Blackberries, for instance, don’t have a compass sensor, so you can’t rely on having that input available.
- Web apps rely on the device’s default HTML handling capabilities. That can lead to layout differences, etc. so it may not look identical on all devices. This generally isn’t a problem, if you’re making sure to design your pages to gracefully degrade.
What it comes down to, for me at least, is that native apps are HARD. For each platform, you have to essentially learn a new language and a new set of tools, or hire someone to do it for you. Mobile developers are in high demand, so farming it out is expensive. So if web developers can build it out instead, why not go that route?
Anyhow, I’d love to hear if anyone else on the list has any insights on this approach.