Lost Boy

Some thinking aloud…
I’ve browsed through the Google App Engine gallery and the applications you can find there at the moment are pretty much what you’d expect: lots of Web 2.0 “share this, share that” sites. These are what you’d expect because firstly they’re the kind of simple application you’d build whilst exploring any new environment. Secondly because they’re exactly the kind of sites that are currently being released every which way you turn.
But for me App Engine is intriguing as it might provide an interesting new perspective on distributing shrink-wrapped packaged software. When Google take the lid off of the number of sign-ups, its going to be a simple matter for anyone to have their own App Engine environment. Forget cheap web hosting and the expensive and configuration overhead that that entails: just sign up for an App Engine account.
App Engine has the potential to provide an enormous number of people with a well-documented stable environment into which an application can be deployed.
It will be interesting to see if anyone seizes on App Engine as an opportunity to create a simple personal application that combines elements of all of the Web 2.0 favourites: bookmarks, blogging, calendar, photos, travel, and perhaps an OpenId provider. One that that makes me the administrator of all of my own data, but doesn’t scrimp on the options for other people to harvest, syndicate and browse what I’m uploading.
At the moment our online identities start out fragmented, because we have to push data into a number of different services. And then we strive for ways to bring that data together and knit it into other sites that we, or our social network, use.
But why not turn this on it’s head? And seize on App Engine as a way to avoid this early fragmentation and instead start out with a centralized, personal web presence; but one which seamlessly integrates with data in other spaces. The potential is in open data, and services that are built around it. So why aren’t we managing our own open data repositories and letting others offer us services against particular aspects of it?
The App Engine environment doesn’t involve any configuration on behalf of the end user, and I suspect you could probably create an App Engine Deployer using App Engine itself. So sign-up, deployment and upgrades could also be pretty straight-forward. Python seems well suited for creating a simple modular web application that could be extended to cover new areas as users needed.
Instead of using lots of different web applications, we can each have our own modular web application that is intimately linked into the web, and becomes the primary repository for the data you want on the web. Data portability follows from the fact that you’d be the administrator of your own data.
This would also change the nature of the kinds of applications that we’d need elsewhere on the web. Instead of lots of specialist databases, we need more generic services and more community/local/temporary aggregations.

Last week I gave a talk at the annual STM innovations seminar. It was a hugely enjoyable event. Kudos to Geoff for arranging an excellent line-up. I thought I’d post some thoughts/comments based on my impressions of the day.

Continue reading →

This article originally appeared in Freepint Newsletter 210.

Wikis, currently one of the biggest buzzwords in online publishing, helped solve a problem for my company, Ingenta. We needed to share information between the research and engineering departments, and we needed a simple tool to manage our rapidly growing set of references on key research initiatives and topics relevant to Ingenta’s core business area: offering technology services to academic publishers. I had created a wiki for myself to support my research and development role back then, and it seemed natural to expand it into an intranet alternative that allowed Ingenta’s users to edit and contribute to content collectively.

Now, four years later, Ingenta’s wiki is extremely popular. It has grown from one department to the entire company. We have even created wikis to interact with our clients as an easy means of sharing information.

Many companies are exploring the use of wiki environments, pressing them into service behind the firewall as a way to capture knowledge and improve communications within a business. Creating successful social software systems isn’t an exact science. Case studies and experience reports provide essential background when considering the success factors.

Deploying a wiki involves more than just selecting and installing an appropriate software package. They’re quite different beasts to the typical enterprise groupware or intranet application. They eschew rigid notions of hierarchy and permissions, letting users quickly create and shape a knowledge-sharing environment that supports them. Wikis are social software. Creating a wiki environment is as much of an exercise in community building as it is in software installation.

With this in mind, the first section of this article outlines how I introduced the Ingenta wiki. My aim is to present some tips to help other organisations deploy a corporate wiki, and to give them advice on creating a wiki culture.

Establishing need: the Ingenta corporate wiki

Having undergone rapid growth through several acquisitions and a major re-engineering project that resulted in a new platform for our core products, Ingenta needed a way to quickly capture and share knowledge. Turnover of contract staff necessitated a good knowledge-capture environment. The infrastructure to support these needs had not grown as rapidly as the company itself. Information was often in silos created by various teams using different tools and technologies. Grander visions for a corporate groupware solution were still on the horizon, but the engineering department needed something more immediate.

The idea of a wiki environment especially for the engineering team was natural. Already comfortable with web-based environments, they were also capable of installing and maintaining their own wiki. But while their ability to quickly learn the wiki functionality certainly contributed to the rapid success of the experiment, the more critical issue was that the wiki met immediate needs.

The environment worked well across increasingly distributed teams. The barrier to entry to contribute to the wiki is very low; documentation could be added and maintained very easily. Finally, the team already had a need to pass documentation around for review and sign-off. Requesting and incorporating changes became much easier as the wiki captured discussions directly rather than being lost in email. Reviewers could correct text and check revisions using the wiki change history.

Expanding the experiment

The wiki became a formal part of the engineering process after its initial success. All deliverables are now authored directly as wiki pages. Engineers use wiki pages to list current work priorities and capture the requirements for each project and incorporate release and testing documentation. The wiki also links to other internal tools and information sources. For example, release documentation links directly to our web-based bug-tracking system.

The initial growth of the wiki was almost viral. With little evangelism, the tool gradually expanded its user base to the rest of the company. It became natural for other departments, such as product management, to begin using the wiki. Users required little training to get started, since writing a wiki is as easy as writing an email. They also increasingly used the wiki as a daily resource, as the content was already closely aligned to many existing business processes.

Knitting together other sources of information using the wiki proved simple. For example, our shared network folders are web accessible, as are a number disparate tools and documentation. It was easy to create an intranet page in the wiki and link to these resources, creating a simple resource directory.

Today the wiki is actively used by every department, with the exception of finance. Perhaps I can tempt them away from their spreadsheets with wikiCalc <http://www.softwaregarden.com/wkcalpha/>! A reasonable number of users actively contribute new content and update existing documentation, while a larger group of users simply use it as a reference resource.

We’re now evaluating whether we’ve outgrown our current wiki platform and are looking at possible alternatives.

Choose your wiki

The obvious first step is to select some wiki software to use. The two biggest features I consider essential in a wiki are version tracking and search. Strong search facilities become particularly important once your wiki reaches a certain size.

In all, there’s a huge number of different implementations <http://en.wikipedia.org/wiki/Wiki_software/> to choose from. These range from simple no-frills versions to complete content-management systems. We opted for JSPWiki <http://www.jspwiki.org/>, as it meshed well with our existing technology platform. Another popular wiki is MediaWiki <http://mediawiki.org/>, which currently supports the Wikipedia sites and has an active user community.

There is also an increasing range of enterprise wikis such as Socialtext <http://www.socialtext.com/>, Confluence <http://www.atlassian.com/software/confluence/> and JotSpot <http://www.jot.com/>. Each offers a good range of features and commercial support options. You’ll need to take time to evaluate and experiment with a few different options. Migration between platforms isn’t always easy, as many wikis differ in features and syntax.

Build your community

Next you need to start building your wiki community. Start small. Focus on one or two teams initially. The wiki will need shepherding through its infancy, so nominate someone as a champion to help train staff members and guide them on how to get the best from the environment.

The best training exercise is to simply encourage users to wade in and start writing pages. We initially promoted a ‘sandbox’, or personal homepage, as a safe environment to play with wiki editing. More recently we’ve been encouraging new joiners to create their initial wiki page as part of their induction. This gives them familiarity with the tool from day one.

You’ll find that many users don’t always feel comfortable with editing existing content. Using a sandbox lets them build confidence before embarking on contributing to the main content.

One technique to introduce users to aspects of the wiki syntax and subtly encourage the view that the wiki is a shared environment is to edit someone’s homepage yourself. For example, I might tweak the page to make their email address a hyperlink, or just improve the display of their personal information. Letting them know that anyone can freely edit and tidy the information in a wiki is the most important point for users to grasp. It’s also the one that takes the longest to learn.

Stay relevant

Attempt to find or suggest ways for your initial community to usefully apply the wiki. Ensuring that the wiki meets a need and has relevant content will encourage sustained usage. Here are a few of the different ways that I’ve observed the wiki being used at Ingenta:

• As a user directory. Most of our staff have a personal homepage including their contact details and current assignments
• As a personal notebook to capture to-do lists or useful personal notes
• For recording minutes of meetings. Rather than write up and circulate meeting notes by email, we often now make notes directly into the wiki
• Managing information on clients, both current and prospective
• Brainstorming new product features
• Publishing documentation for both internal users and external clients
• Capturing technical documentation on our products and services
• Creating glossaries of terms. Every company and industry has jargon; we often define terms as separate pages in the wiki, enabling links to be added to documentation for clarification.

Avoid attachments

Some die-hard users insist they can’t possibly live without a word processor and say that a means to attach Word documents or spreadsheets to wiki pages is an essential requirement. Attachments are a useful feature for attaching diagrams or additional documentation to a page, but you should discourage overuse of attachments. If the useful content is in an attachment, then it’s not in the wiki and not easily editable. That’s not the wiki way.

Lay down pathways

Initially, we divided our wiki into people and projects. Pages were also introduced for teams and departments. These pages provided a basic organizing principle that became the primary means of navigating through the wiki. A similar structure would work in any corporate wiki.

However, these initial pathways provide more than just navigation. A wiki grows by people adding new links and pages to existing content. Your initial structure provides a cue as to where new content could or should be added. By introducing this structure from the start, you’ll help avoid the wiki deteriorating into a morass of interlinked pages.

As your wiki grows you’ll need to continue to organize it to reflect the needs of users and the growing body of content.

Employ a gardener

‘Wiki gardening’ <http://c2.com/cgi/wiki?WikiGardener> is a phrase used to describe tending a wiki to ensure that it stays fresh and remains navigable. Your wiki will need a gardener. During the early stages of deployment, you’ll manage with just a single ‘WikiMaster’. His or her role will be to lay down some of the initial pathways, tidy up pages and ensure content stays relevant. As the wiki grows, this role will become more than a one-person job. At Ingenta a number of my colleagues quickly embraced the wiki and became good WikiCitizens <http://c2.com/cgi/wiki?WikiCitizen>.

Typical wiki gardening tasks include:

• Tidying up and re-formatting pages to ensure they’re readable
• Helping ensure content is up-to-date
• Checking for orphaned pages that aren’t usefully connected into the main web of pages
• Breaking up long pages into smaller more manageable and useful chunks
• Identifying useful content to be contributed
• Promoting the wiki within their own department or team
• Renaming pages to better reflect their contents.

Ideally, your wiki gardeners will emerge naturally, but you can actively recruit them from individual departments. The idea isn’t to delegate maintaining the wiki to a small team of users; it’s more about community building. It’s essential for the user community to take ownership for their own content, and, most importantly, for other people’s content. This is one important difference between a wiki and traditional groupware.

Naming is everything

Naming is important in a wiki. Try to encourage good naming or navigation will suffer. Page names should reflect their content. Avoid use of abbreviations, acronyms, etc. Wikis work very well with CamelCaseNamesLikeThis. All wiki installations will automatically generate links from CamelCase words to the appropriately named page in the wiki.

With good naming you can write sentences like the following, and they will not only be readable, but also magically gain links to the relevant documentation:

When ConfiguringTheServer don’t forget to DeployTheWidget; if you need a reference read HowToStartTheApplication.

Or, perhaps:

We’re maintaining a list of CurrentClients and CurrentCompetitors. Delivery dates for ForthcomingProducts can be found in the ReleaseSchedule.

Naming conventions are also a good way to indicate that pages are related in some way. For example we often use a project’s name as a prefix for pages, e.g. ProjectNameOverview and ProjectNameReleases, or for user specific pages: LeighDoddsCalendar.

Avoiding a wiki explosion

If your wiki starts to become successful and other departments or teams embrace it, you may find yourself faced with a request that users need a wiki for their department only. Just say no!

If you create many small wikis then you inevitably recreate the kind of content silos that you’re undoubtedly trying to replace. Provide guidance on how users can create pages targeted for their own department, perhaps adopting a naming convention as outlined above. Explain that this will be less effective than a single inter-linked knowledge base. For example the content will not be cross-searchable.

Wherever we’ve deployed smaller per-department or per-team wikis they’ve rapidly grown stale. Either because there wasn’t enough content, or that users were already contributing to another wiki and naturally continued to add content there. In almost all cases we’ve ended up shutting them down.

The only occasion I’ve found when a separate wiki is not only useful but essential is when it’s shared with people outside the firewall. We’ve used a wiki at Ingenta as a way to share documentation with clients. It wouldn’t be appropriate for clients to have access to our main corporate wiki, so a separate installation works better.

Within an organisation, ensuring people share information requires extra work – anywhere from 30 minutes to a whole day. But I know I’m not the only one keeping an interested eye on the RecentChanges page on our wiki to see what’s happening elsewhere in the company.

Hopefully this article has provided some useful pointers that will help you explore the potential of your own corporate wiki. I’ve found it fascinating to see how a wiki environment can facilitate sharing and contribution amongst teams, as well as providing a low-cost and simple way of capturing knowledge within an organisation.

I was recently invited to write an article for the FreePint newsletter. The article “Embracing the Wiki Way: Deploying a Corporate Wiki” is now available. It serves as an update to my blog entry on bootstrapping a corporate wiki with more of an emphasis on tips for users.
If you’re thinking about deploying a corporate wiki then hopefully the article may help you plan your strategy. There are also plenty more case studies available for you to compare with.

I’ve been playing with Google Maps a bit for a talk I’m giving on Monday. It’s addictive stuff.
But I’d like to be able to use alternate kinds of maps. E.g. plotting Samuel Pepys’s diaries on a historical map of London, or points on a sonar map of the sea, or views of MMPORG maps.
It’s lead to me to wonder: has anyone written a general purpose front-end similar to Google Maps? Basically all of the Ajax/DHTML magic, but without the actual Google supplied tiles? It’d be interesting to have that and then be able to plugin in different server-supplied tiles, perhaps on the fly (e.g. radar vs satellite images).
The whole client-side framework would be portable I think. It would be an interesting way to explore any data set that can be visualised in two dimensions.
Anyone already done or doing this? Drop me a mail if you are.

So you’re sitting in a coffee shopping talking over an idea with a friend: how to get people to contribute quality metadata on all manner of topics. Kind of a semantic wikipedia but where the goal is data entry rather than essay writing.
The basic concept is straight-forward: start from a basic fact such as “Isaac Newton is a Person”. Then, using appropriate ontologies generate additional questions: a Person has a birthdate therefore, “what is Isaac Newton’s birthdate?”(*). And so on. Generate RSS feeds containing the questions with embedded forms allowing people to answer each question. Update your database based on the answers, using a voting (or similar) model to take the most common answer from all contributors. Provide stats on who answers the most questions, answers them first, answers most questions in a particular domain, etc. You’ll then end up with a positive feedback effect that (hopefully) encourages more people to contribute.
Move forward two days and Amazon have done all the hard work: Amazon Mechanical Turk. With the spin thats its all about micropayments rather than karma, and unlike the original it doesn’t play chess.
(*) January 4, 1643 by the Gregorian Calendar.

Some notes on a brief discussion I had with Geoff yesterday about tagging behaviour, in particular: what’s the etiquette involved in shared bookmarking?
Geoff has previously written about social bookmarking as telltale and the advantages of brain subscriptions. He’d also recently pointed me at a New Scientist article discussing research which shows that email forwarding amounts to ritual gift exchange
Or rather, he bookmarked it in del.icio.us and I noticed it via my RSS reader and went away and read the article. I, like Geoff, subscribe to various peoples del.icio.us bookmark feeds as a way to find interesting and relevant content.
As we subscribe to each others feeds, the act of bookmarking has started to subsume the previous activity of email/link forwarding. I think this is another form of tagging behaviour thats distinct from both filing and annotative approaches.
The potential point of etiquette was this: if you tag something, as a result of a friend’s bookmarking activity, are you adding noise to their aggregator? After all, they’ve seen it already.
I think we concluded that it wasn’t. After all one might still legitimately want to bookmark something to file it away. This raised the issue of whether both public and private bookmarks are useful features. Furl has them I believe, but del.icio.us does not. There’s also the fact that the additional bookmark constitutes another hop through the social network graph.
As I write this it occurs to me that the feedback loop is useful in that it indicates that the “gift” was received and deemed useful or relevant. Certainly worth a bookmark. Annotation features provide a way to add simple comments that might also be of interest to the originator of the bookmark. A kind of tagging back channel?
Given the level of interest in this space, I presume that someone has begun classifying these different types of activity. The classification would include not only the act of tagging (is it filing, annotation, or sharing) but also the types of tags themselves which range from keywords through actions, such as toread, to the descriptive conventions I discussed here.

The only real hypertext system I’ve worked with is the web. I’ve obviously used hypertext help and documentation browsers, but I’ve never really done any development within a proper hypertext environment.
I’m therefore always keen to see how richer hypertext linking capabilities can be built using web technologies. Bob DuCharme’s linking blog is always a good source of relevant discussion in that area. His one-To-Many linking demo is cool too.
I’m therefore glad to see that Geoff (after some nagging from yours truly!) has put up some screencasts of his old hypertext application, Abulafia.
If, like me, you’re a web weenie, then watch the screencasts and see whether it gets your creative juices flowing. The multi-headed, and conditional linking is particularly cool.
If you’re an old-hand hypertext user, then take a nostalgic trip down memory lane.