One laptop per child OLPC Sydney

On Friday night I attended a SLUG meeting where Pia Waugh and Jeff Waugh demonstrated the XO computers used in the One Laptop Per Child (OLPC) project. The little machines are a cute, impressive package. The OLPC project is visionary, intriguing, and I think bound to grow beyond what’s yet dreamt of in our philosophy.

The OLPC project aims to give a specially-designed computer laptop, the XO, to children in remote and underprivileged areas of the world. The goal is to give these children access to the most up-to-date technologies for learning, experimentation, self-expression and collaboration. The project was first announced publicly in 2005.

This blog post is about the things that struck me most during the presentation in Sydney on Friday 28 March 2008. There’s a lot more information on the OLPC web site about the XO machines and about the aims, history and growth of the project.

The XO hardware

Pia and Jeff brought along a few of the XO laptops. Before the talk started, I wandered to the front and picked one up. First, I had to figure out how to open it. I dare say a five-year-old child would have figured it out in two seconds. It took me a bit longer, but eventually I flipped up the two bunny ears and opened the lid.

The machine is small — you can comfortably hold it with one hand and press the keys with the other. It has a handy grab bar at the back, so there’s little chance of dropping it while you tap the keys. The outer casing is quite tough, and the keys are overlaid with a soft rubbery cover. Jeff mentioned a use case that has been tested:

You can spill a glass of wine on the keys and they’ll still work.

Though, he said, that’s not necessarily a use case that was designed for since the principle users of the XOs are children — what’s more they’re children in remote and disadvantaged areas of the world.

You can also throw the XO against a wall, and most of it will still work. It is recommended that you close it first. (Wink again )

Jeff is a mine of interesting titbits. Here are just a few of them:

• To conserve power, the machine goes into low power mode three seconds after you stop hitting the keys. But the screen stays alive much longer.
• There is no hard drive, just flash memory. This makes the machine very robust.
  • That’s the throw-it-at-a-wall use case.
• You can put the display into black-and-white mode — triple the resolution. This is great for use as an eBook. You can twist the screen round, to make the machine even more compact while reading.
  • This is great for reading under a tree.
• Two round holes conceal the (video) camera and microphone. Above these are two pinprick lights, showing when the camera or mic is activated. These lights are wired-in hardware, not software-controlled.
  • So there’s no way to trick the child into being recorded unknowingly.
• The battery lasts six to eight hours and can handle 40 degrees ambient temperature. There are a number of ways to recharge it, including situations where there’s no electricity:
  • Hand-held crank, in the same cool dark-lime green and robust chunky design as the laptop.
  • Solar power recharger, which can be located at a school so that the children can recharge while in class.
  • Cow power — attach your cow to a long pole and walk it round in circles, charging the battery.
  • The normal electric recharger we all know and love.
  • Foot crank.
  • And so on — new and funky rechargers keep appearing.

The XO software

Endearing and clever — those are the terms I’d pick.

What’s endearing is the appearance of the machine itself and of the user interface. The XO motif is used cleverly, to represent little people —’O’ over ‘X’ representing a head and body. Click the ‘Neighbourhood’ key on the keyboard or the corresponding icon on the screen (both will get you to the same place) . Now you see little XO icons dotted around the screen, representing others on your mesh network.

Pia showed us around the user interface, activities and collaborative features. It’s a little like Facebook or other social networking tools. You can choose your friends and interact with them. Other nearby networks will appear too, even if you don’t have access to them.

The applications are called ‘Activities’. Examples might be a web browser (Firefox); Chat; a text processor (Write); and so on. When using an application, you can choose to share it. Then it will appear on other people’s Neighbourhood screens and they can jump right in and collaborate with you.

The designers of the user interface have avoided text as much as possible. They are also attempting to steer clear of a file system display (like Windows Explorer). Instead, there’s a pie chart to show which activities are loaded, and a ‘life stream’ of all the things you are doing.

The focus is on learning, of course. But not only on learning pre-determined material. The focus is also on creative activities — composing music, writing code, experimentation, and collaborating with others in your network.

The mesh network concept is pretty cool. James Cameron, an Ozzie outback software engineer, hung one XO in a tree and took another for a ride in his ute. He got them pinging each other at a distance of two kilometres. In Peru, they’ve managed to bring internet access to a remote town by putting an XO every two kilometres over a distance of thirty kilometres.

Stephen, a young boy who is an XO wizard, showed us some Python code he’d put together. There are three software development environments:

• Pippy — based on Python, allows you to code, run and share with ease.
• EToys — based on SmallTalk.
• TurtleArt — a cool graphical tool, where you drag and drop components into a flowchart.

OLPC Australia and region
Pia and Jeff mentioned lots of trials happening in New Zealand, the Solomon Islands and regional Australia. The objectives are to give the remote and disadvanted communities access to cool educational stuff.

The future

The open source community is developing new applications for the XO all the time. Here’s one that caught my attention:

Soon, a cog on the keyboard will give you access to the source for the Python front end. So the children will be able to ‘mess up’ their own PCs by changing the code.

They can reinstall from a friend’s PC via the mesh network, or just switch from customised mode back to the default.

My conclusions

A big thank you to the Sydney Linux Users Group and to Pia and Jeff. And thank you to Atlassian for hosting the event in their Sydney office.

In the past few months, I’ve seen pictures of the laptops and I’ve followed Anne Gentle‘s excellent and in-depth blog posts on her work with the OLPC project. Now it was great to play with the machines myself, and to meet Jeff and Pia who are so absorbed in and committed to the project.

My husband Peter was at the meeting too. Afterwards, he said that he’d like to know more about the politics behind the project. Now, that’s a really good point. What sort of political impediments do the OLPC guys have to work around, to get the laptops out to the areas where they’re most needed? Is every country actually eager to allow them in? A couple of people mentioned that we might be seen as foisting Western technology on the children of the world. But does any country or political force actually see it that way?

I’ll be following this project with great interest, and also looking into how I might become involved. Ann Gentle has jumped in already. I wonder if the Australian branch needs the input from a technical writer like me?

Document Freedom Day in Sydney 26 March 2008

Document freedom — what’s that? It’s all about being able to read something you wrote a few years ago, and being able to read something that someone else has written — whether now or hundreds of years ago. Or even just knowing that you’ll be able to read what someone writes tomorrow. It’s all about freedom from the bounds that may be imposed by a proprietary document format.

On Wednesday this week, a group of us got together at the Google offices in Sydney to swap stories and ideas and to kick off the Sydney team for the Document Freedom Day initiative. The immediate aim is to raise awareness of the problems and to promote the idea of open standards for document formats.

We carefully, almost, didn’t mention Microsoft’s Open Office XML (OOXML) document format and its bid to get it declared an ISO standard.

The problem

If your writing is encased in a proprietary format, then to a certain extent you are at the mercy of the owners of that format. If they abandon backwards compatibility, the world will move on without really taking note of that event. A few years later, no-one will be able to read your work. Even worse, you may be unable to find some essential information that you know is out there, but is hidden from you because you’re using a different technology.

The meeting

The Sydney meeting was one of 200 similar events happening in 60 countries on the same day.

We started with a short introduction from each of the three sponsors:

• Alan Noble, chief of engineering at Google Australia, was a debonair and skilled MC. His introduction was accompanied by a fair bit of wry humour, mentioning ‘notorious formatting incompatibilities, without naming specific software suites or operating systems’. He raised the simple question: Who owns the data? And he issued
  • a challenge to software engineers to come up with a format that will be readable for the next 1000 years.
• Holly Raiche from Internet Society of Australia pointed out that part of the need is to educate and assist people who are concerned about interoperability. Many people are worried, but feel that they don’t know enough and are worried about seeming foolish.
• Sridhar Dhanapalan from the Sydney Linux Users Group said that open formats tie in with open source. He looked at the Magna Carta and the Domesday Book — low tech, but we can still read them centuries later — and compared them to the BBC Domesday Project, putting the book onto laser disks which were unreadable 16 years later.

The two main speakers of the evening were Kate Lundy and David Vaile. Both so different, and both so interesting.

Kate Lundy — Wow, what a dynamo! She is Senator for the Australian Capital Territory, and has a strong interest in information technology, the National Archives, open technology and the laws governing freedom of information. Her talk was short and pithy. One of the main points I got out of it is this (my synopsis, not a direct quote):

With the recent change in the Australian Federal Government comes a unique opportunity for creative change. We should seize this opportunity to promote a drive towards open standards — particularly within the government services themselves. The National Archives, for example, have a range of rules governing standards for document formats, such as metadata.

Kate drew a parallel between the government’s ‘New Federalism’ (breaking down boundaries and sharing responsibilities) and the drive for open standards. I’m not so sure I get the comparison, but it was great to hear her enthusiasm, commitment and ideas.

David Vaile — The enthusiastic self-professed devil’s advocate. He was determined not to mention the war, and mostly succeeded. David is executive director of the Cyberspace Law and Policy Centre at the University of New South Wales. His talk covered a wide range of information. He divided the topic into three areas:

• Open content (public domain; creative commons and free for education licences; Google’s friendly acquisition and acquiescence; crown copyright etc; and hybrids of the above)
• Open source and free/libre software
• Open standards and formats

There are some disquieting ins and outs to all this. Here are just some of the things David raised, in his role as devil’s advocate. Should we consider standards as ‘legislation lite’? Look at the wars going on within big companies. Even the Microsoft-versus-the-world standards wars are not black and white. Yes, we did mention the war after all Look at the process of defining the standards — does it work? Does the buzzword ‘open’ mask other interests? What does ‘free’ actually mean — does it include the rider ‘but within the boundaries laid down by me’? Are we in danger of moving towards extremism?

David urged us always to take a step back (actually, it was more like being gently shoved back) and be sceptical. He challenged us to think in terms of 500 years — especially for archives and such.

After the speeches, we held a short question time. I thought these two were the most interesting:

• How can we participate in the Document Freedom initiative, moving on from this meeting? Kate Lundy answered that the online facilities were being set up.
• How does cloud computing affect the openness of documents? There was quite a discussion around this point. Does the cloud get around the problem of obsolescence? Who owns the data? Bandwidth is costly, especially in some areas of the world. Governments, including the Australian government, have a risk aversion to technology — but this may not be a bad thing. We should look at a dual model, i.e. cloud plus local presences. The concepts of ‘control of data’ and ‘location of data’ should be separated because they actually have nothing to do with each other. (You may think you control your data if it’s on your own hard disk. But what happens when your disk crashes, or becomes obsolete?)

My conclusions

This was really interesting. I’m staying tuned.

One thing I’d like to get deeper into, is the open formats themselves. At the meeting, we concentrated a fair bit on the content of documents (ownership and security) rather than the actual format. We did mention ODF and HTML. What about XML formats like DITA and DocBook? Are they mature enough for mainstream use? If not, what can we do to promote them? And why do WYSIWYG editing tools always seem to lag behind? Why is transformation between formats so difficult (e.g. XSLT) — is this stuff just for geeks

Update on 1 April: Check out this excellent comparison of DocBook and DITA by Teresa Mulvihill.

After the formal meeting, most people went on to dinner and informal networking. I had been awake since 01:30 that morning (yes, that’s just after midnight — and don’t ask why, because it’s nothing exciting) so I left. I guess I probably missed out on some really cool stuff. If anyone who was there reads this blog, please let me know what happened.

Ceci n’est pas un screenshot

The Treachery of Images takes on a whole new meaning for technical writers. A screenshot can be so realistic that it’s positively misleading. Especially when accompanied by text that says something like, ‘Click the dropdown list on the screen’.

I’m busy reworking the installation and setup guides for our wiki product, Confluence. I’ve come across a page which triggered a funny memory from my first few days on the job. Take a look at this page, which contains some text and a screenshot:

Screenshot — Ceci n’est pas un screenshot:

Part of my job as tech writer on a technical documentation wiki is to monitor customers’ comments on the documentation pages. A short while after I started this job, a customer added a comment to the above page, saying something like:

The database configuration screen is broken. Nothing happens when I click the database drop-down menu.

Very soon, two other customers replied that they had the same problem.

We had just released a new version of Confluence, so I took this problem seriously and reported it to the development team. They could find nothing wrong with the product. Then another customer pointed out that people should try clicking the application screen rather than the documentation screenshot!

At that time, the above documentation page did not contain the words ‘as shown in the screenshot below‘, nor ‘Screenshot : Custom Installation – Database Configuration Wizard‘. I added those as soon as I realised what was happening.

Now that I’m doing a big rewrite of the installation and setup documents, I’m going to add a big friendly ‘don’t panic’ sort of message, saying something like this:

Hint: The above image and all the images on this page are screenshots. Clicking an image will not install Confluence.

It may sound a bit naive, to be duped into clicking a screenshot rather than the living and breathing application screen. But when you consider that the Confluence application is a web application, and the documentation is a web page too, and the documentation is hosted on Confluence itself what’s more…. Well, it’s a pretty easy mistake to make!

Other things we could do: Add a watermark or callout on every screenshot; put a border around a screenshot, so that it’s clearly separate from the text; …

Have you had any such experiences, and what techniques do you use to avoid misunderstandings?

Ah, the treachery of images. What’s real (read the first paragraph on the linked page — it’s awesome) and what’s not? It’s a tech writer’s job to clarify that small but non-trivial matter. I think I might have mentioned before that this leads to the inescapable conclusion that documentation is at the centre of the life, the universe and everything

BTW if you really do want to install Confluence, this button really will work. Really

Ratio of developers to technical writers

How many developers/engineers are there in a typical product development organisation, and how many technical writers? It boils down to this: How many developers are at the top of the funnel, creating the new features and updates which pour into your well of documentation work?

A quick Google yields some interesting surveys.

Average 12 to 1: Posted on KnowGenesis (November 2007). Based on 162 responses. Plenty of other interesting stats in this article too. And a recommendation that the an optimal ratio is 5 – 7 developers per writer. Does anyone inhabit such an ideal world? An interesting point: The very same research and result were published by Cherryleaf in April 2003.

Mostly fewer than 10 to 1: From KeyContent (March 2007). Based on 30 responses.

Average 42 to 1, but mostly fewer than 24 to 1: From the Suncoast STC (March 2006). Based on 10 responses, the average is 42 developers to 1 technical writer. But 7 of the 10 responses gave a ratio of 24 to 1 or fewer.

Typically 8 to 1: From Scriptorium (2001), in their Software Development Executive’s Guide to Managing Technical Publications.

What about me? Well, it’s difficult to be precise. We have 3 full-time technical writers and somewhere between 60 to 70 developers, depending on how you count ‘em. In the technical writing team, we divide the work by product rather than by number of developers. Let’s go with this: If we count only developers but not support engineers or other teams who funnel work our way, it’s approximately 30 developers to 1 technical writer.

What about you – do you find this interesting, and what are the ratios you have experienced?