Since Apple launched its App Store, over 1bn applications have been downloaded. This year, it expanded the idea to cover its Mac computers and sold 1 million apps on its day of launch. Given such unequivocal success, are there things that we might learn for the intranet world? The idea could be translated several ways. Perhaps intranet interfaces should look more like a collection of apps than a web site? Or could it be a way for employees to create a personalised experience? Both of these have merit, but what I feel has most potential in the near term is a third version: an app store for intranet site owners.
The Intranet as a Collection of Apps
Around 10 years ago when everyone was talking ‘portals’ the vision for intranets was not dissimilar to an app-based interface created from a collection of portlets. Portal home pages were going to be a ‘one stop shop’ to meet all your needs, not just for information but transactions too. However, integration proved costly and the business case for replacing the native software interface was often unclear. As a consequence, portals and intranets have often lapsed back into doing the basics of information dissemination, and transaction needs are poorly met by links to native applications. This in turn has hampered usability, with each application having its own interface and learning curve.
Apple’s App Store demonstrates that software companies will adapt their interfaces when the demand is clear, but it would probably require the critical mass of a single platform like SharePoint to make it a tempting proposition. Microsoft has been talking about this for quite some time and there appears to be plenty of interest from the SharePoint community. However the makers of larger enterprise transaction systems have been slower to show the same enthusiasm.
The App Store for Employees
The second way we might think of an intranet App Store is as a service for employees: a place where they select the applications that most meet their needs from those available internally. This sounds promising as people clearly embrace the idea as a way to add services to their phones and Facebook accounts. Again, many portals included this feature with users able to configure portlet collections to personalise their home page, much like iGoogle or Netvibes. In practice though, tailoring in the intranet world only rarely seems to take off. When companies do offer it, the uptake is usually less than 10% and most people leave their pages exactly as they were set up on day one.
When you ask employees why, they often say that they are too busy, or they expect someone to do it for them. This isn’t unreasonable; if an intranet team knows there’s an app that would be of use to a segment of their workforce, why wait for them to find it rather than pushing it out there? The App Store can’t do this because it doesn’t know what you do and it is a competitive marketplace where there are multiple solutions for the same problem. An intranet can because it knows its users and no rational business would develop more than one solution for a given need.
The App Store for Site Owners
This brings me to the final interpretation: that an intranet app store is a place where site owners go to select content and features. For small intranets this may be redundant, but for larger sites, where there are multiple communities with different needs, it makes more sense. Here the role of the site owner is someone who knows a community intimately and can build a site to meet their specific needs. In that sense, the whole intranet can be viewed as a marketplace. Just as an iPhone user will select apps and customise their pages to meet their needs, so the site owner should select content and functionality from across the intranet and assemble an experience that is tailored to their community.
Sadly, few intranet tools at the moment offer such an internal app store equivalent, but there is no reason why central intranet teams can’t build such an experience aimed at site owners rather than everybody. This combines the versatility of an apps approach, without the shortcomings of expecting employees or third parties to make the first move.
[This post originally appeared as a column in Intranets Magazine, March 2011]