Why You Should Love Free Documentation

FLOSS Manuals فارسی

First draft of an article for publication:

Free software has enjoyed many years of support from the cultural sector. Artists and activists have often been active in promoting free technologies. Artists also often make a living through teaching and workshops centred on free technologies they use in their practice. Curators of exhibitions, symposiums and festivals have followed these themes and brought these issues into the public arena. Theorists have published and lectured about the need to use and develop software and hardware which is free. The support has often risen to the point of hyperbole. There were many years when every event seemed to be ‘open’ this or ‘free’ that.

However, it seems that the uptake of free software, despite the efforts, is very slow. Although most of the internet runs on free software (60% of web servers run Apache and 90% of Domain Name Servers run BIND), if we look at operating systems the share is somewhere under 2%  (1).

Free software, as opposed to free operating systems, does a little better with the current estimate for Firefox usage across all platforms coming in at something between 20-30% (2).

Still, this is very small. The user penetration of Firefox is an impressive achievement, but why haven’t other fine tools such as the Gimp or Audacity taken a similar “market” share?

And why, given that we all know how good free software is, that a wide variety is available and that it is free, as in gratis as well as libre, is the uptake so low?

The Free Software Foundation thinks the answer is quite simple :
“The biggest deficiency in free operating systems is not in the software—it is the lack of good free manuals” (3).

Many years teaching free tools (mostly streaming) have taken me to the same conclusion.

It’s not that there is no documentation. Often you can find something, if not on a developer’s site, or in a bookstore, then perhaps comments in a forum, mailing list, or maybe in a wiki somewhere. This seems to satisfy most geeks. Many ‘advanced’ users tell me this is enough. Google is their index, and they know how to use it to find solutions. The thinking is that when it comes to solving a problem in software, you aren’t the first to have the problem and someone somewhere has written down a solution to it. This is often true. If it isn’t true, then either you solve the problem yourself (by hitting your head against the wall until it works), or you find the appropriate IRC channel and quiz the developers. Even better…you’re using open source, right!? READ THE SOURCE CODE!

Well, I don’t know about you, but perhaps my brain isn’t big enough or I maybe don’t have enough time, or maybe, just maybe, I feel that I should not have to be a programmer to work out how to use software. Perhaps this threshold is a little too high and might be deterring users… y’think?

Free software should be well documented. You should be easily able to find out what a software does, what it doesn’t do, how it fits into the software universe, what the interface looks like, how to install it, how to set the most basic necessary configuration, and how to use its main functions. These things should be well explained and kept in a place that is easy to find.

The easier it is to access well-written documentation the larger the potential user base.

I have also often heard that it is simply not the case that there is a lack of documentation. There is a manual for $X! (replace ‘$X’ with your favourite free software). What do you mean!? $X has a great manual!

Well, I admire the effort put into the documentation of some free software. Unfortunately, however, it is seldom adequate.  The most common flaws include :

  • assumptions about the user’s knowledge are set too high
  • bad navigation
  • unexplained jargon
  • no visual component
  • proprietary (‘closed’) material
  • unreadable design
  • steps missing or unexplained
  • documentation is out of date
  • documentation is not easily re-usable
  • documentation is not easily modifiable

These mistakes are very common, and the situation is so bad it amounts to a crisis in the world of free software. I have made my own efforts to combat this situation butmore contributions are needed. Perhaps a clear summary of the basic issues would encourage others to contribute to free documentation projects.

Free documentation for free software

I sometimes feel this is too obvious a point to make. Documentation which is freely available and so ideologically aligned with the [free] software,  seems to me to me to be a natural match.

Practically, however, there are a few hiccups with this idea. Free software has developed a methodology and economy which free documentation lacks. The traditional method of making money in the manual business is to write a manual and sell it. To protect your interests, you use a standard ‘closed’ copyright notice. This is the ruling publishing model. Outside of this circle, you do the best you can voluntarily, and put the content online for others to access, where ever you can.

The Free Software sector has much better resources and models. Free software projects have a number of management tools available including sites like Savannah and SourceForge, and they have established working models. The financial model is much clearer too. Most obviously if you need to make money working on a free software project you get good at it and find a company that will pay you to work on it in-house or by contract.

Free documentation lacks all these components – there is no standard technical tool set, very few ‘communities’ of free documentation writers ,and less chances of being able to pay the rent if you choose to do create such documentation full time.

Finding a way to build these elements is critical to the evolution of a healthy free documentation sector, and, I would argue, to achieving the widespread adoption of free software. It is imperative that we find these models and tools, as closed documentation for free software contains a ideological paradox.

On another point – less ideologically and more practically speaking – free documentation is better argument than closed documentation.   The closed nature of proprietary documentation is a disadvantage: the ability  to update documentation at the same time as the software is updated is a huge advantage. It can thus be updated, modified, improved a la ‘many eyes make bugs shallow’, translated into your own language, or re-contextualised to better suit individual or organisational needs. Free documentation on these terms alone is a better argument than closed documentation, and when done well can be a tremendous asset to the uptake of free software.

Free documentation should be easy to access and easy to improve

If something can be improved then it should be able to be easily improved. Many free documentation projects inherit their technology strategy from free software development methods. These projects store their content in a CVS which means that you need to be pretty technically competent to be able to access the source material and contribute to it.

What this overlooks is that writers are not programmers. Writers have a different tool set, usually word processors, and do not have a familiarity with the typical programming tool set. To expect a free documentation writer to access content via CVS or similar tools is to make the same mistake as assuming the audience for your documentation knows more than they do. Setting the threshold for contributions so high means that many people that could contribute won’t contribute.

There is no need to trap content in CVS. All we are dealing with is text and images and there are plenty of tools that are easier to use.  I recommend a wiki with WYSIWG (What You See Is What Yo Get) editing – these are online tools that look and work like word processors except they are available anywhere you can get online via your browser. I personally don’t recommend using mark-up languages as even wiki mark-up is harder to use than WYSIWYG editors and a barrier to contributions.

Well structured
Many projects are now setting up unstructured wikis for their developers and users to use for writing documentation. Often MediaWiki is used (although the wiki used depends on the winds of software fashion). These resources can be extremely good, however, I believe unstructured wiki content with a contextual navigation system, is a poor substitute for well-structured content with a clear top-level index. Unstructured content is a good secondary documentation strategy, and certainly good for documenting the ‘nooks and cranies’ of sometimes archaic interface issues or strange hardware-specific conflicts, however, it doesn’t replace content that is designed to document the software thoroughly with a clear and structured flow.

Tell it as it is
I have found that documentation written by developers makes the simple mistake of writing how the software should work and not how it does work. Writing free documentation should not be done from memory or by those that cannot see the problems. Telling the user what is wrong with the software, what does not work, what could be improved, is absolutely necessary. It’s not bad-mouthing a free software to point out a quirk that should not be a quirk. It is far worse for potential users of that software if the user reads documentation that is inaccurate or which glosses over these issues.

Make it look good
Documentation should be attractive to read. Free software developers have discovered over the years that in order to interface with humans, software must look nice and allow the eye to easily engage with it. The same is true for documentation. Black text with blue links on a white background is not enticing. Embrace a layout than enhances readability but makes sure it also looks good.

Quality
Now we come to the bugbear. Quality. What is good quality documentation? Well, there are some mechanical benchmarks :

  1. no spelling mistakes
  2. set a style guide and stick to it
  3. make sure no steps are glossed over
  4. make sure the documentation is accurate

However, beyond the mechanical there is the subjective issue of quality. There is no solid rule: the best you can do is to get people to read the content and tell you if it makes sense. If you belong to a community of contributors then look to peer reviews.

FLOSS Manuals and the Pursuit of Funky Docs

It is easy enough to point out what is wrong with something and harp on about how it should be. It’s another issue to actually do something about it.

To resolve this, I am involved in a not-for-profit foundation called FLOSS Manuals. We are a community of free documentation writers committed to writing excellent documentation about free software. Anyone can join FLOSS Manuals and anyone can edit the material we publish. All content is licensed under a free license (the GPL).

When we started (the actual point of genesis is hard to determine but we officially launched in October 2007), there was, and still is, no good publication platform for collaborative authoring. Some may say that there are too many Content Management Systems already and surely, SURELY, there must be a CMS to meet our needs?

Well, no. The closer you get to identifying the needs of collaborative publishing systems, the further you stray from the functionality of most Content Management Systems. So we have hacked our way into the wonderful TWiki and developed our own set of plugins. TWiki has proven to be a very good platform for online publication. It has all the structured content features and user administration that make it a good shell for authoring collaborative content. What was missing, and what is missing from other CMSes is good copyright and credit tracking, easy ways to build indexes, and a nifty way to remix content.

However, we have remedied that now with our own custom plugins (which are available through the TWiki repository). There are still some things we need, in fact it’s quite a long list, but piece by piece we are turning TWiki into a publication engine. Currently, we are working on translation workflow features (also in plugin form).

Remixing
So, the word ‘remix’ may have caught your eye and you may have fleetingly thought ‘remixing manuals?!’. It might not seem intuitive at first glance but there are a lot of very good reasons why manuals are excellent material for remixing. I don’t mean remix in the William S Burroughs sense of cut-up… we do cherish linearity in the world of free documentation. I mean remix as in “re-combining multiple chapters from multiple disparate manuals to form one document.” Doing this enables you to create manuals specific to your needs whether they be for self-learning, teaching, in-house training or whatever purpose.

The FLOSS manuals remix feature (http://www.flossmanuals.net/remix) enables the remixing of content into indexed-PDF and downloadable-HTML (in zip or tar compressed form) with your own look and feel (CSS). Now we have also added a Remix API. This means that you can remix manuals and include them in your website by cutting and pasting a few lines of HTML – no messy ftp necessary…

This part of FLOSS Manuals is new and in test form, but it works very well and the possibility for combining remix with print-on-demand is an obvious next step. It can be done now as print-on-demand services use PDF as their source material, but the trick is in getting it to look nice in print form…

Print on Demand
In addition to the free online manuals FLOSS Manuals material is also turned into books via a print-on-demand service. The books look very nice, having been tweaked to look good in print, and they are available at cost price (we don’t put any mark-up on the books so they cost what the print-on-demand company charge to produce and send to the buyer). This is pretty exciting and I hope that we will soon see FLOSS Manuals on the bookshelves of retailers: bookshops after-all are a very important promotional venue for free software.

I find that the books themselves actually get the idea of what FLOSS Manuals is doing very effectively to most people I talk to. Imagining a website is one thing, but handing over a book sparks the understanding and gets people excited. So books are an excellent promotional medium for FLOSS Manuals as much as for the software (it’s a symbiotic relationship after-all).

I imagine print-on-demand will play a bigger role in the future of FLOSS Manuals. There are many possible paths, but, in the end, it comes down to capacity and we are this stage a very small organisation. If you wish to get involved with this (exciting) part of our evolution then let me know…

Quality Control
Lastly, a word on quality. The manuals aim to be better than any available documentation (sometimes this is not hard as there is often no other available documentation!) Keeping this level of quality has some interesting issues when working with an open system. Anyone can contribute to FLOSS Manuals – it is completely open. You need to register but this is not a method for gating contributions, it is there so we can abide by the license requirements of the GPL to credit authorship. Additionally, credit should be given where contributions have been made so we also credit modifications in the manuals.

SPAM is an obvious issue with an open system, as is the possibility of malicious content. Incorrect or malicious information in Wikipedia might lead you to quote the wrong King of Scotland or may misinform yo7u about the origins of potatoes, but incorrect information in documentation might lead you to wipe out your operating system. So we separate the ‘back end’ – where you can write manuals – from the ‘front end’ – where you can read manuals.

Manuals in the ‘WRITE’ section (http://www.flossmanuals.net/write) are in constant development. However, the same manual linked from the front page will be in the ‘stable’ form. This is managed by some existing TWiki tools that we twisted together to form a simple one-step publishing system. It works like this – every manual has a Maintainer. A Maintainer is a person – a volunteer – that keeps an eye on that particular manual. Edits and updates carry on through the WRITE section by anyone that wishes to contribute. When the Maintainer thinks the manual is in good form and an update is appropriate, they push the ‘publish’ button and all the material is copied to the ‘front  end’ version of the manual.

This way, the reader gets stable reliable documentation, and the writers can continue working on those docs without the reader being confronted by half-finished content etc. It’s a simple and effective system.

How you can help
Good free documentation is a necessary component of all good free software. If you can’t program or don’t want to, but you love free software and want to help, then help make free documentation!

Knowing where to contribute is now easy! You can :
read manuals – http://www.flossmanuals.net
write manuals – http://www.flossmanuals.net/write
or remix manuals – http://www.flossmanuals.net/remix

We have a growing number of very talented contributors and Maintainers and good manuals available online, but we need more manuals and more contributors. Contributing is pretty easy, and if you would like to be a part of helping create good manuals, then register with the project (http://www.flossmanuals.net/register) and read our manual on FLOSS Manuals (http://www.flossmanual.net/flossmanuals).

Anyone can contribute. You can spell-check documents, tidy up the layout, suggest ways of improving docs, test/review material, design icons, write or improve any material. Contribute in any way that you can and you will be helping not only to make the documentation better, but you will be assisting in the development and spread of free culture and free software.

The State of Free Software Documentation

It’s often hard to find good writing about the state of online documentation. Andy Oram writes for O’Reilly OnLamp, and he has contributed a couple of very interesting articles on the motivations of free documentation writers, and the state of free documentation.

Why Do People Write Free Documentation? Results of a Survey was published on 14 June 2007 and contains some very interesting research results.

Although I found the results very interesting, it was the preamble that I found most worthwhile. The assumptions Andy makes about the current state of free documentation online echoes very closely the motivations for creating FLOSS Manuals. Andy outlines four issues that reflect the general state of online docs today :

  • The same questions get asked over and over
  • Users don’t know where to start
  • Information quality is uneven
  • Optimal solutions are often undiscovered

I agree with these issues, but there are two issues I think he overlooked :

Licensing Interoperability

The current licensing situation for free documentation is pretty bad, the main issue being that there is no standard license that everyone agrees to use for documentation on the web. This would not be such a problem if licenses were compatible, enabling the easy transition of content from one source to the other, and allowing the combining of material released under differing licenses. However, this is not the situation now, as Lawrence Lessig mentioned in 1995:

"Even if all the creative work you want to remix is licensed under a copyleft license, because those licenses are different licenses, you can’t take creative work from one, and remix it in another. Wikipedia, for example, is licensed under the FDL. It requires derivatives be licensed under the FDL only. And the same is true of the Creative Commons Attribution-ShareAlike license that governs Opsound content, as well as much of the creativity within Flickr. All of these licenses were written without regard to the fundamental value of every significant advance in the digital age — interoperability"
 http://creativecommons.org/weblog/entry/5709

With free software, the GPL is the standard license, and since no such agreed ‘standard’ exists for documentation, then improving a document using multiple sources cannot occur.

FLOSS Manuals has decided to use the GPL. Since there is no ‘standard’ for docs (I have written about this in an earlier FLOSS Manuals post about the problems with the GNU Free Documentation License), then we might as well side with the programmers until this interoperability issue is resolved. Documentation is after all, often included with software, and it’s easier for programmers if they don’t have to worry about license compatibility problems between the documentation and the source code. However, one tactic we still might employ is to dual-license in Creative Commons so that bloggers etc could more easily copy and adapt documentation for their own use.

“It’s not a bug. It’s an undocumented feature.”

Andy Oram omitted the ever frustrating fact that often the documentation just doesn’t exist. This is always going to be the case as the first step of a software development project is seldom to write the user manual. Documentation is usually last on the to-do list, and sometimes it falls off the checklist all together. This might be understandable if the project was new. However, there are many times I have looked for documentation and found it doesn’t exist anywhere, even for relatively mature software. The only remedy for this is to hope that more software developers take documentation more seriously and develop a documentation team alongside their coding team. The other option is that community-led projects like FLOSS Manuals fill the gap. This is what we are trying to achieve but our efforts are only needed because the state of documentation online is so bad. In a better world, there would be no need for such an effort.

I enjoyed Andy Oram’s article very much and the results of the survey are well worth reading. You may want to map the findings against “What motivates Wikipedians: motivations for Wikipedia content contribution” (PDF) by Oded Nov. You can find more of Andy Oram’s writing here (thoroughly recommended): http://www.oreillynet.com/pub/au/36

06 February 2007

I-TASC expedition 2006/2007

Seas are relatively calm. We have a few more birds appearing out the back of the boat, but otherwise, all is the same.

Advice from the bottom of a well, Part 4 : extras
I thought I should write down some last bits I had forgotten in the last sections about what to bring if you ever find yourself going to SANAE.

* gloves
I have thought about the glove issue a bit. In the last week or so at the base, I found that the large windproof mitten gloves (the gloves without fingers) are excellent for warming up your hands while outside. If you get cold hands then you can take off any glove inners and put your ‘naked’ hands into the gloves. The natural warmth of your hands will warm your hands and fingers faster than any other way (except a heater). So bring a good pair of robust windproof mittens. Also, I mentioned earlier, merino glove inners, and lastly consider getting a really good pair of warm working gloves.

* Butane Solder Iron
If you are going to work with any electronics, then bring a butane soldering iron for working outside. It would pay to buy this in Cape Town as most airlines won’t allow them onboard aircraft in checked or onboard luggage.

* cups
It might seem a little trivial, but there is a lack of good cups and glasses at SANAE and it’s the little things that make a difference. Bring a big thermos flask type cup. Good for coffee up on the monkey deck on the boat, and good for long cold drinks at the base when you come in from a hot day’s work or a sauna.

* tradeables
Bring some extra CDs and DVDs, if you don’t use them, they are good currency on the boat for trading with the crew, and if you have a laptop with a dvd burner, you will also make good alliances if you don’t mind a bit of extra work ripping/burning.

* video
If you are going to take video you most definitely need a good ‘Zepplin’ microphone sock. You won’t get any outdoor sound without it.

* currency
Make sure you bring enough currency with you to pay for the communications and shop bill you might accumulate on the boat.

* USB stick
These days it almost goes without saying, but I’ll say it anyway. Bring a USB memory stick, at least 1GB. You need it if you want to send emails from the boat as you need to write emails, transfer them in a text file to a stick, and then give it to the radio comms officer. The officer then copies the text into an email and sends it (all emails leave via the same Agulhas email account). You get replies the same way except the radio officer prints them out for you. However, even without this, I used my USB stick several times a day while at the base.

* Wireless Router
Don’t leave home without one.

* Arduino
I wish I had a small PIC set up. If you know what an Arduino is then get one. We had to build a circuit on the fly on this trip for a reasonably critical role, but if we had an Arduino unit we could have done the same thing faster and more reliably.

* Radio
For listening to Radio SANAE!!!

* Disk Space
Make sure you have lots of disk space available for photos etc – consider an external disk.

* Rechargeable Batteries
Bring plenty of rechargeable batteries.

* Sunscreen
The stuff SANAE provides isn’t that good. Bring your own and make it as strong as possible.

* Extension cords
You won’t find any extra on the boat or at SANAE so bring your own extension cords and power boxes, especially if you are using plugs that are not South African plugs…bring as many extension boxes and cables as you can, you will use them all.

* Walkie Talkies
Not absolutely necessary to purchase for an individual, but useful for the team.  They can be expensive, but 2-way hand held radios are rare at the base. I would find out what kind they use (what frequencies they work on) and then buy a couple. This is the expensive way but it has the advantage that you can always have a radio that is on the same channels as the SANAE radios. A cheaper way would be to buy 2 or 4 small walkie talkies of the cheap variety for comms just within the crew.

* Attitude
Bring a good one 😉 – on this note -> you can expect tensions amongst your crew. It’s _normal_. Part of the experience of the trip is learning how to deal with team dynamics. I recommend you expect that tensions will arise and you prepare to forgive, forget, and move on as fast as possible. On-going issues need to be addressed but there is a lot to be said for a generosity of spirit. Provide your teammates with comradeship, and good feedback, never criticise the person but instead address the issue at hand with an attitude of improving the situation and not apportioning blame. Be prepared to own up to and laugh at your own mistakes. Find out what motivates your teammates, and work on that. They are old rules, you can take them or leave them, but trust me on the sunscreen 😉

petrel

05 February 2007

I-TASC expedition 2006/2007

Last night we moved through the last of the ice. it was sad to see the last remnants disappear behind the ship. While we were going, cutting through large islands of soft melting ice, the sun gave us a beautiful farewell sunset. It was so vibrant as to look almost fake.

Today I will sleep a little en leer Nederlands. It’s getting a bit of a swell in the sea… I had forgotten how foggy that makes the mind.

03 February 2007

I-TASC expedition 2006/2007

Back on the ship. It was an amazing helicopter ride from SANAE IV to the ship. I was very sad to leave the continent and couldn’t help shedding a tear or two on the trip back to the Agulhas. We left the base, swooped over the AWS, and then turned and dropped spectacularly over the Nunatuk…those chopper guys, they like to impress and I’m glad for it.

3feb2007-1

It was also amazing to fly over the ice shelf and see the ice stretching away to the horizon with ragged cliffs. Then the Agulhas. Beautiful on the sparkling blue water, cruising slowly in anticipation of our homecoming. She’s a queen of second homes amongst an array of second homes we have experienced on this trip. A good friend spent much of his life on the sea in the NZ Navy, and as a pilot in Dunedin. I could never understand how he could love it so, as it seemed a very harsh existence, but seeing the Agulhas again filled me with warmth and respect for the ship and the strange existence it offers. It made me realise how lucky I have been to have had a glimpse of life at sea, and I can see its attraction.

3feb2007-2

I was also sad to leave Zama behind. We had a tight cabin, the boys of B10. 3 of us came back but Zama was asked, just two weeks ago, to stay. I wouldn’t like to have been in his situation – the other over-winter crew had 2 months to train and many more to prepare psychologically for spending 14 months on the continent by themselves. However, Zama had no such luck. He decided to stay, and I am sure he will have an amazing experience. It would have been hard for him not to have said his goodbyes properly to family and friends.

3feb2007-3

It was also great to finally be able to call Lotte and talk for a whole 10 minutes! ah… the small pleasures of modern naval communications.

Anyway, we wait here on the ship for 2 more days, and then we move out across the Southern Ocean. I hope the seas are good. We were fortunate to have extremely good seas on the way here. I hope we get that luck twice. Leon (one of last year’s winter team) is hoping to see at least 10-metre waves and hopes the ship will surf some… I don’t share his enthusiasm… maybe the trip home will cure me of my new found respect for life at sea 😉

Outside, the crew are loading containers on the ship. There are a few more loads to come from the base, I think they expect to be finished with this tomorrow. They bring the containers down a steep bank cut they made in the ice. At this time the Agulhas is parked with its nose on the ice shelf and the containers are swung aboard.

3feb2007-4

So, I’m spending the days till we leave watching stupid American tv series, and taking photos. I am practising birdy shots with the telephoto…its kind of like skeet shooting… you follow the bird, trying to pull focus manually as quickly as you can, panning the cam at the same speed, and then pressing the trigger to get the perfecin-flightht shot… It’s great fun and quite addictive – I’m sure if they invented cameras before guns there would have been a lot less game shooting in the world (and consequently more animals still around, and the world would be better documented!). I got a couple of good shots, but I am anticpating that perfect trophy to hang on the wall, maybe an albatross in flight, or two snow petrels in frame with perfect focus.

3feb2007-5

First Born is sleeping through the day. He worked hard these last days outside.

When I get back to Cape Town I fly from Jo’burg on the 18th of Feb. Spending my birthday mid air 🙂 Then I land in Sydney and I hope I get to see Mr Snow, Zina, and the good Doctor Gillian for a day or so before winging it to NZ. Not long to go now before familiar shores and faces populate my existence… now i just got to strategise the best moment to shave…

3feb2007-6

02 February 2007

I-TASC expedition 2006/2007

The unit is installed. All is running, and we are also. Helicopter flight out in 1 hour, the base is like a ghost town. I’m now busy copying Boston Legal series 2+3 for the long wave home…

We will update from the boat, might take a day or so

Need some coffee….

Check these :
Groundhog Weather : [24hrs][Archive]

Congrats to all involved 🙂

01 February 2007

I-TASC expedition 2006/2007

News news news…we have had our travel plans altered and we leave tomorrow (the 2nd) in stead of the 3rd. This means we have one less day to get it together…

1feb2007

For those interested, here is the circuit we built yesterday (whoever has to do the maintenance on it next year, there is a copy of the full diagram provided.)

1feb2007_2


31 January 2007

I-TASC expedition 2006/2007

It’s been a busy few days. We fly out to the boat in two days and so it’s a mad rush to get everything done. Tom, Amanda, and First Born have been very busy outside with the AWS unit, setting it up with the wind turbines and solar panels. It looks fantastic and they have done an excellent job.

It’s been pretty cold these last days, and they have been outside most the time, coming back looking frozen. Today the wind turbine was finally working, and tomorrow we install all the AWS and communications equipment.

In the meantime, I have been inside working on the networking systems (writing scripts etc). It’s been warmer work than that of my colleagues but possibly a little bit more boring! 😉

Still, today was rewarding. I was looking for a way to restart the computer that will be in the AWS. If the batteries fail in the unit (if there is a storm during winter or other reason), then we need a way to power the computer on once the batteries have recharged. There are a number of ways this could be possible with some machines (bios settings for example) but this computer supports none of them. The computer has an on/off button which, if depressed momentarily, starts up the computer. So, we needed a circuit to solve this. After wedging off a plastic panel, it appears that shorting out the button momentarily would also start the computer.

So, we needed a circuit that would do this automagically. I wondered if a relay would do this. A relay will close a circuit when power is applied, but it couldn’t do this on its own, so I emailed some friends. We had excellent brainstorming sessions, and Mr Snow and Matthew Biederman helped shape the idea of what was necessary. But we had no circuit. So I visited Pierre (one of the scientists here) and naively asked him if a series of relays might do the trick. Before I knew it, Pierre had sketched out a circuit on some paper and helped me source the parts. I built it, but it didn’t work… so, Pierre then troubleshot the circuit, which took a good 6 hours or so. I could mumble some agreements, and nod a few times, while Pierre whizzed through the possible causes for many problems we were having with the circuit. Finally, we had a circuit that works. It might look a little crazy, but it does the job.

So now, if the batteries fall below 6 volts, the computer is more than likely to be turned off. Then when the power rises, at 10 volts the circuit triggers some relays, one of which short circuits the on-button for half a second or so and the laptop starts. Pierre is now drawing the circuit diagram and tomorrow we will publish it if anyone wants to use such a thing.

Anyways, off to bed now, a big day tomorrow.