iPhone app development: Rocket science or old hat already?
Posted by Nancy Proctor on | August 20, 2009 | 10 Comments
A colleague and I were talking about mobile strategy yesterday. I argued that in terms of iPhone app development, we’re in something like the late 90s of website development: the platform is new, and it probably makes sense to outsource to developers who can gather best practice from a range of clients’ projects to ensure we get a superior product with minimal hassle. Later at least the bulk of that best practice will be so well known that we can more economically bring the development in-house as necessary.
My colleague argues that this transition from ‘cutting-edge’ to ‘old hat’ is happening faster than I think. That iPhone app development is far from rocket-science, so we should be building in-house already. Of course these decisions must vary from museum to museum, depending on available skills and resources. What is your take? What is your museum’s strategy? How will you decide what to bring in-house and what to outsource?
Comments
10 Responses to “iPhone app development: Rocket science or old hat already?”
Leave a Reply
Search
What’s New
- inSitu Solutions™ by Kanvasys
- Products & Services
- My Tours
- Exhibitly (in progress)
- MCN Annual Conference 16-19 Nov 2011, Atlanta
- Museum-Mobile online conference
- AAM's Technology, Interpretation and Education 2011
- Exhibitly Needs Your Help!
- Virtuality, Technology & Feminism in the Museum
- DC Area Mobile Collaborations
Login
Mailing LIst
Loading...
August 20th, 2009 @ 8:32 pm
It depends on the resources that you have. Take for example a small museum wanting to mobile enable so of their collections and provide some more interactive content for their visitors. The cost of developing an iPhone application in-house would be prohibitively expensive.
On the other hand some of the larger institutions may in-fact have the time and resources to build a fully custom application with custom user interfaces and enhanced functionality. However if I was at an institution I would carefully consider the skills required to build yourself. iPhone applications are not as easy to build as websites (even late 90′s websites.)
What we are trying to do at My Tours is to build a set of tools to allow the museums to get the best of both worlds – Their own custom iPhone application but without the cost of expensive programming resources. We think we can supply all of the functionality required for a good proportion of museums via a SaaS model. This will allow museums to mobile enable content quickly and cheaply while still allowing the museum to develop their own applications down the road should their needs outgrow what My Tours can provide.
In any case I would be interested in other peoples thoughts – What risks do you see in outsourcing?
Glen
August 20th, 2009 @ 9:39 pm
Hi Glen,
I think the main concerns about outsourcing are that museums don’t want to be liberated from the traditional audio tour model, in which the vendor controls the platform, only to chain themselves to another proprietary product that becomes expensive to maintain and even more expensive to leave should the product or service no longer respond to the museum’s needs, or the provider goes out of business.
Also, museums with in-house developers like the freedom to make at least minor changes themselves in the interest of speed and economy, and to experiment with new solutions as their understanding of their audiences’ needs evolves.
And finally, there is a huge need for centralized content management. The proliferation of platforms across which museums are publishing threatens to become crippling in terms of the staff time required to maintain and update the same content in multiple places (on our website, in our audio tour, in Flickr, in Facebook, in YouTube, in Wikipedia…). If museums build their solutions in-house, they are more likely to be able to feed them from their existing content management systems or at least minimize duplicated publishing efforts.
That said, there is also an enormous investment in doing all this in-house which may not always be possible. And I think there’s a real advantage to museums using a standardized interface so that visitors get to learn how to use it and can quickly and easily use mobile apps in whatever museum they visit – the learning curve is minimized and the visitor can focus on the content and experience rather than the technology.
Is your solution in use anywhere that we can check it out?
August 20th, 2009 @ 10:49 pm
I think the concerns about vendor lock-in are very valid which is why I am really keen on seeing something like the TourML format being adopted (or at least an understanding of the common attributes of a ‘tour’. I think the use of API’s and easy import/export features should go some way to alleviating these issues. I think (hope!) the days of proprietary data formats are slowly coming to an end.
Our solution is nearing a first release. We should have a simple web-based tour builder released in a few days (images, text, audio and maps) and the iPhone application will come after that. I will send you a note once we have things up and running, it would be good to get your feedback.
Glen
August 20th, 2009 @ 11:51 pm
After years of resisting outsourcing, I finally figured it out – have your tech lead / architect in-house, and outsource the bulk of the engineering (app, db, qa). You will get the same or better quality as with an in-house approach, at a tiny fraction of the cost and with much better scalability (both up and down) in your tech team. The catch? Well, figure on six months and multiple trips to your outsource vendor before you can be completely productive. But even with that cost — I’m totally sold on this approach. The ‘other’ catch? Sometimes you don’t find the right vendor on the first pass.
But stick with it — there are definitely vendors out there who can do anything an in-house team can do — with proper supervision and guidance.
August 24th, 2009 @ 3:45 pm
I think you should outsource as much of the technology development as possible. It is changing quite frequently and evolving at a ferocious pace. Or are you going to pick one platform and hope the majority of your museum visitors adopt it? What’s your bet: will that be blackberry, or iPhone?
Or (rhetorical question) do you want to avoid having to answer that just yet?
The next wave of “platform independence” might be coming, but we’re years away from the platform vendors collaborating on a ubiquitous platform. In the meantime, is a museum really going to hire an Android team, a Windows team, an iPhone team and a Symbian team?
Are you going to build competencies in the nuances of each of these platforms as they, (and more important the conventions and end users’ expectations) evolve?
This is the problem you are choosing to solve if you choose to build stuff in-house.
Is it practically viable for each museum to build its own “museum guide” team, or should museums collectively invest to nurture a handful of *competitive* providers?
iPhone and Android and Blackberry and Windows are far less similar than firefox, mozilla, explorer and Chrome… convergence is some years away. I side with you on this one. Outsource.
August 26th, 2009 @ 6:57 am
[...] are the risks of outsourcing? @barnaclebarnes asks & I offer some thoughts: http://wiki.museummobile.info/archives/445 #mtogo iPhone app development: Rocket science or old hat already? Outsourcing vs DIY [...]
August 26th, 2009 @ 11:20 am
Speaking from the small museum perspective, I’m with others on the outsourcing vote. Unless you have a large IT and tech staff, it’s highly unlikely you’ll have the information and knowledge necessary to plan for all types of new platforms and with all new technologies. Have a visionary on staff, who can guide the project and do the quality control, but leave the grunt work to the experts.
August 26th, 2009 @ 12:55 pm
[...] of outsourcing iPhone App dev from the small museum’s perspective by @psully http://wiki.museummobile.info/archives/445 #mtogo I’m fascinated by this emerging concensus on http://is.gd/2A4Kv: "forget map, go [...]
August 27th, 2009 @ 11:01 am
Carl,
I think you approach is ideal as long as the person guiding the outsource team can speak their language, the communication channels are fast and effective and the outsource team is not a big company (with lots of bureaucracy). I think the freelance model rather than a big company can work better. Work in stages (so you can replace less than ideal freelancers) and keep dynamic goals (beta releases, small upgrades, scalabilty instead of trying to come up with a big development at once, that is going to be obsolete by the time you finish).
Developing for mobile is becoming less and less a platform challenge (dealing with linux vs. windows / flash vs java) but more a customization challenge (same content, presented in different ways). The new windows servers supporting PHP and the open source applets reaching out to both platforms (like wordpress) are examples of this, so much that I think of iPhone apps as a simple interface change.
Many flash free websites like ours (americanart.si.edu) run fine from Safari, so probably our mobile challenge is on Blackberries. There is no way that we can have a team for each platform, but we can not outsource for each platform either. Users determine platforms this days, not the opposite. And that is a good thing.
Perian, I like “visionary”… in our case, it is going to require a real “technology evangelist”. http://en.wikipedia.org/wiki/Technology_evangelist
thanks everyone
August 27th, 2009 @ 11:07 am
[...] Carl @ 2009-08-20 23:51 [...]