Why I Pedalled on Parliament

Yesterday was the third Pedal on Parliament. This year, rather than simply riding with the crowd, I heeded the call to arms and found myself marshalling at St. Mary’s Street, helping slow down (and stop) cyclists briefly as the lovely traffic police stopped cross-traffic and removed the barriers.

I was told that the only problem with marshalling down the road is that you don’t get the fun of joining in ringing a bike bell with everyone else or exhilaration of being part of the crowd moving down the Royal Mile — but I had the distinct pleasure of seeing every single cyclist pass by me on their way to the Scottish Parliament.

It’s seeing the crowd there that really drove home why I wanted to be there, why I needed to help —

I’m not alone on these streets.

There are hundreds of us, thousands of us. We are men, women, and children. We are families with wee bairns on balance bikes, we are teens with stereos, we are lovely ladies and men in lycra.

Some of us came in our Sunday best and some came out out in our most casual of jeans. Some of us wore fluorescent jackets and helmets, some wore just helmets, some wore nothing special at all. Some of us rode recumbants, tandems, racing bikes, mountain bikes, folders, bikes with trailers and tagalongs, and some of us walked.

And we were all there, together, showing that we, people of all ages and abilities, have one thing in common:

We want Scotland to be a cycle-friendly country. And we want it now.

If you want to support Pedal on Parliament, please contact your MP, MSP or local counsellor and tell them that you want to see more! You can also donate to Pedal on Parliament through the PayPal link on their website.

Reaching out

On the 10 July 2013, I gave a presentation at Edinburgh Tech Meetup on documentation. The audience was a room full of software engineers – some were freelance, some were managers of small startups, some were students who hadn’t entered industry yet. The video and slides are available on my presentations page. After my presentation, I was contacted by the editor for Communicator, the journal for the Institute of Scientific and Technical Communicators (ISTC), and asked if I would write an article on the topic.

I wrote the following article for the Winter 2013 edition of Communicator.

Reaching out

Not everyone likes writing documentation. Denise Marshall explains to developers how to stop worrying and love the document.

In my experience, it is the rare software developer who enjoys writing documentation. I have become accustomed to looks of bafflement from software developer friends. Their experience is the polar opposite of my own: they find it profoundly frustrating.

One of the regular events that I attend is Edinburgh Tech Meetup. It’s primarily a networking event for freelance software engineers, software startup founders, and many others who are generally interested in computing. One evening every month, the group meets to listen to two presentations and spend several hours in discussion. While I usually find the talks interesting, my primary interest is meeting with other members in the software and technology community. It was in a conversation with a developer at one of these evenings that I realised that documentation is getting a bad name among those who could be its staunchest allies.

“What can I say to my boss to convince him to hire a technical communicator?”

As I conversed with the developer, I heard a story that I’d realised I’d heard several times from different software engineers. There seems to be a level of wishful thinking present in the software world that says that the software product should be obvious enough to the users that documentation simply isn’t necessary. Likewise, the code should be obvious enough to anyone who’s reading the source code that a couple of comments in the source is sufficient to understand how all the sources work together. Of course, most developers are aware that this is a pipe dream.

In reality, documentation needs to be available alongside the product. For the work that I do, my readers often don’t refer to the documentation except in their hour of need, either when the workflow isn’t obvious and they cannot find the solution themselves or when they want confirmation that what they’re about to do is correct. For my documentation to be useful, it needs to be thorough enough that they can find the answer to their question and clear enough that they can understand the solution.

The organisations that these developers work for rely on them to document their work. This makes sense because the developers know what the software is meant to do (they have their formal requirements, at least) and they know how to use it. It follows, then, that it would take the developers little time to write up what they’ve done, because they’re the ones in the best position to know what they’ve done.

But these same developers have deadlines that they must meet to deliver the software and are often too pressed to make time for documentation. With documentation included in the requirement, the organisation’s projects can fall behind. The inevitable cycle would lead to someone in management deciding to hire another developer to take up the slack. The existing developers don’t know how to write documentation and get frustrated that more and more of their time is wasted (their words) on documenting their code, rather than being spent on writing good code. Sadly, the blame is placed on the documentation for putting them behind schedule. To add to the feeling of frustration, the developers I speak to generally feel that they weren’t documenting well, because they didn’t know what they were doing. And the new developer needed to be brought up-to-speed, further slowing the development process. I offered the best advice I could: “Convince your manager to hire a technical communicator. They’d happily do the documentation part of the process.” Then would come the inevitable reply: “My manager says we can’t afford a technical communicator. Could you give me some pointers on how to get started?”

What could help their experience with documentation?

I set about creating a primer on producing documentation for those developers at Edinburgh TechMeetup who had no choice but to provide the documentation because their companies could not take on a technical communicator. I could, at the same time, provide those employers who had never considered hiring a technical communicator with an argument for considering one in the future. I knew that the audience I would have in front of me would see documentation as something unpleasant so I wanted them to know that I knew where they were coming from.

A primer on documentation

I’m fairly certain that any reader of Communicator will know how best to communicate information to their audience – it probably comes as second nature – but, for the uninitiated, it can be a baffling world of text editors, words, and images. I laid down the basics that a non-technical communicator would need to produce a minimum standard of documentation:

  1. Know your audience. If you know who your audience is, then the style and content of your documentation often becomes obvious. For example, if you are explaining to a developer how to use the different functions of an API, then an API reference guide makes sense. If you want to get new hires up to speed quickly then a wiki with some overview information might be sufficient. Do you need to explain how to use software to groups of pre-literate children? Pictures might be best.
  2. Create a structure. This can sometimes be hard but I find that, in the absence of a strict template, it’s often made easier by writing each idea into separate topics on notecards. These notecards can then be grouped, arranged, and rearranged until they make the most logical sense. This also encourages topic-based documentation. (I also reassured them that, after they’ve got a basic outline, they can save it as a template to simply fill in the next time they needed it.)
  3. Find your style. Be Consistent and Be Clear. For example, there are many ways to write ‘email’ (Email, E-mail, email, e-mail, eMail, etc), but as long as you pick one and stick to it, you’ll never have to wonder again which is the correct one. Likewise, phrases such as ‘Enter text into the text field’ should be made consistent (other options might include ‘Type text in the field’, ‘Write text in the box’, and ‘Fill in the text’). If you write the phrases consistently, the perceived quality of the documentation increases and the technical communicator can move more confidently into other areas of the writing.It’s also important to avoid ambiguous language. While it can sometimes be hard to know if your sentences will be misread (that’s where asking someone else to review it is useful), it’s easy to avoid ambiguous words. A list of words that should be avoided can be added to a personal dictionary in your preferred word processor. At the top of my current list are ‘since’ (when you can use ‘because’), ‘once’ (when you can use ‘after’), and ‘appears’ (instead, use ‘opens’ or ‘is displayed’).
  4. Consider graphics. Graphics should be avoided unless you’re absolutely sure that you need them. This reduces file sizes, reduces translation costs, and means that you don’t need to update them with every small UI change. There are times when graphics are good, such as when you’re drawing a diagram of system architecture and it’s important to consider your audience when deciding the necessity of graphics – some audiences might genuinely require a screenshot of every single page in a Wizard.

And that was it. I tried to keep the rules as simple as possible, in the hope that some of it would stick. If one developer could, at the end, decide who their audience was, organise their ideas, and be consistent throughout, then I knew it was worth it. But I wasn’t quite done yet.

Is it worth hiring a technical communicator?

After explaining to an entire room of developers how to approach technical documentation, I asked them the question that was at the heart of the reason that I delivered the presentation: “Would you rather be writing documentation than coding?” The only people in the room who raised their hands were, like me, technical communicators. Every developer I’ve ever worked with has expressed how much easier we make their lives, because we know how to put all the things they know into words on paper. Unfortunately, many in the audience hadn’t had the opportunity to work with a technical communicator. So I laid it out as succinctly as I could:

Hire a technical communicator and the developers have more time to code. Yes, they still spend time on documentation because they need to explain things to the technical communicator, but it is a very small fraction of time compared to what they would be spending otherwise. In addition to that, the technical communicator would be more efficient because they would know how to write.

Reaching out

The most surprising thing that happened, at the end of the talk, was that a developer approached me and confessed that he didn’t think he was going to like my talk. He’d done documentation before and, like the others I’d spoken to, didn’t like it and didn’t really see much use for it. He told me that he was inspired to start documenting the project he was working on. Another developer told me that he’d never heard of technical communicators and had a friend who would probably love the job and asked if there were any training courses available.

I hope this article has helped you realise that we don’t need to limit our audience to the readers of our documentation.

Burley Travoy Pack Mule

I walked up to the counter at the local grocery store, my shopping trolly full nearly to the brim. I set the separator down at the end of the belt, to make it stop moving. I then proceeded to unload the trolley while the cashier dealt with the previous customer who was still bagging her groceries. I put the large, heavy things closest to the till, the light bread and eggs near the end of the belt, and left the giant bag of pasta to the very end. By the time I was finished, the previous customer had left and the cashier turned his attention to me:
“Do you want help packing?”

It’s not my favourite question, for many reasons, but I answered as I always do when I have my bicycle trailer with me:
“No, it’s ok. I’ll just fit it all in this bag.”

At this point, of course, the trailer was still collapsed and in the trolley. It didn’t look like much and it certainly didn’t look like it’d fit a trolley worth of groceries into it, once full. The cashier looked at me, very puzzled. “It’s a big bag. I swear, I’ll unfold it, it’ll fit.” He nodded in a way that made it clear that he didn’t believe me but he was going to humour me because I am a paying customer.

Item by item, I packed the bag. Heavy items went to the bottom, the lighter and crushable things on top. A grocery Tetris game. Sure enough, I was able to pack it all into the bag, minus the huge bag of pasta that I lashed to the top of the trailer. The look of confusion on the cashier’s face melted away to boredom. Can’t impress everyone.

Burley Travoy trailer full of groceries
Bike trailer full of groceries, en-route home

I got it home and took a picture of all of it unloaded. About two weeks of food for me and my other half — about half what would fit in the boot of our old Renault Clio but easily five or six times what I once carried in a rucksack.

Groceries spread across the dining table
The amount of groceries that can fit into the Burley Travoy bike trailer

People keep telling me that they can’t really carry much when they’re cycling — but that’s because they keep thinking of their bike as only what they can fit in their rucksack. But there’s a whole world out there of pannier bags and trailers that’ll completely change how you can use your bike. Oh, and the bike AND the trailer fit in that tiny space under the stairs when I’m done.

NaNoWriMo 2013

This is the first year that I’ve joined National Novel Writers Month (NaNoWriMo). For those who are unfamiliar with NaNoWriMo, it is a challenge for participants to write a 50,000 word novel in only the 30 days of November. I don’t write much fiction, preferrering the structure, regularity, and utter lack-of-frills in technical writing.

Not to say that I haven’t tried “creative writing”. When I was still in school, I would often embark upon a short story, get about two thousands words into it, then give up rather unceremoniously. I thoroughly enjoyed creating the world, creating characters, but I struggled with finding a sound plot and the dialogue that I attempted was always dire.

I’ve had many friends get to the end of NaNoWriMo and tell me how liberating it was, quieting their inner editor to produce volume over quality. They wrote without regard to how well it would be written and it let them explore their writing in ways they’d never done before. There was also the satisfaction of having completed such a challenge, though silly it could be from an outsider’s perspective. The writers equivalent of running a marathon for no other reason than just to say you’ve done it once. I’d considered it in years past but something always came up – university exams, moving house, getting married – so I never tried. But this year, I had no excuses….

The first week of this year’s NaNoWriMo was exciting. I started out with dialogue and used that to create my characters. I interspersed it with some scene setting and sprinkled in some intruigue, hoping that any of it would lead to a plot. By the end of the first week, I had just over 10,000 words and no fewer than six interesting characters. Unfortunately, the story had gone nowhere.

It’s now Day 16 and I’m approximately 1000 words behind where I ought to be for this time on this day. I fell behind during what is referred to as the “week 2 blues”. I’d experienced something similar before – my company offerered an intensive one month training course (6.5 hours of lecture a day, 5 days a week, 3.5 weeks). The beginning of the second week was painful and all I wanted to do was give it a rest. For this NaNoWriMo, writing was like pulling teeth. I was uninspired and found myself wishing I was reading the Metro on the train instead of standing with my laptop propped up on the bicycle rack. I never stopped writing but I spent so much time staring at the screen that I’d fallen 2500 words behind.

Someone recommended that I introduce a natural disaster to shake the characters out of their lull – another friend recommended a fire. I thought I’d run with it, wrote that a neighbour’s house was set on fire, and let the characters react to that. Somehow, a plot bloomed. I found myself geting angry when the train stopped at my station and I had to shut down the computer to cycle home. I’d had a series of evening after-work outings and really ought to have been sleeping as soon as I got in, but I found myself laying awake in bed, forcing myself not to get out of bed to grab the laptop.

If in doubt, put your characters in a fire. If you really like them, then they’ll easily find a way to escape. If you don’t like them, then maybe their clever escape will redeem them.

15 days down, 15 days to go… [to be continued]

The Techaddicted Guide to Documentation

I’m forever telling my developer friends that “Documentation is not a dirty word!”. But, for most of them, documentation is that thing their managers tell them they need to do, that thing that gets in the way of coding, that thing that takes forever because they don’t know how to do it and the don’t want to do it. These same friends keep asking me “We’re falling behind schedule at work and so my boss wants to hire another developer — I suggested hiring a writer but apparently we don’t have the budget for that! How do I convince management that it’s worthwhile to hire a writer?!” I’ve previously written a blog post about this, but I realise it’s not enough.

So I put together a presentation that addresses two main points:

  1. How to write documentation – Because sometimes documentation is inescapable and it doesn’t need to always be painful.
  2. How to justify hiring a technical writer – Lacking hard statistics, but with a story and diagram.

I presented this at Tech Meetup Edinburgh back in July. You can watch my presentation below (30min, including questions) or you can just flick through the slides yourself (View Slides).

Denise Marshall talks about Documentation from TechMeetup on Vimeo.

NOTE: Most of my images are from XKCD. See http://xkcd.com/license.html for license info.

Words to Avoid

After my presentation, I got a few requests to share my list of Words-to-Avoid

That list can really be broken down into two categories:

  1. Ambiguous words – they have more than one meaning and both meanings are frequently used. But one way of using the word can be easily replaced with another, non-ambiguous word. Sometimes you need to use a word that has multiple meanings, but if you consistently use it to only ever mean one thing, then that goes a long way to helping keep things clear.
  2. Warning words – words that should warn you that your writing is in the wrong tense, wrong tone, or something else un-good.#

Lets start with the ambiguous words….

Ambiguous Words


Once should only ever be used to mean one time. You do something only once. Though once upon a time doesn’t really belong in serious documentation. Most of the time, the word after is a perfect drop-in replacement for the incorrect usage of once.

Hint: If you use once at the start of the sentence, it’s probably incorrect. Sometimes it’ll be in the middle of the sentence. Every time you use the word once, think to yourself if you can replace once with after and keep the meaning of the sentence – if you can, then do it.

Good: Click the button once to save your document.
Bad: Once you’ve clicked the button,  the system restarts.

Replace bad of once with after

Correction: After you’ve clicked the button, the system restarts.


Since is commonly used in conversational English to mean because. For example, “Since I don’t like peppers, I always have to pick them off of the veggie pizza” is fine for explaining that I am picking peppers off my pizza because I don’t like them. But since also serves as a great word for describing “time that has elapsed between this previous event and now” quite succinctly, such as in “I haven’t eaten since breakfast”. Because since can easily be replaced by because in some cases, the because sense of since should be replaced with because to make the usage of since in the temporal as unambiguous as possible.

Good: If you have not restarted your system since installing updates, do so now.
Bad: The updates have not been fully installed since you have not yet restarted your computer.

Replace bad since with because

Correction: The updates have not been fully installed because you have not yet restarted your computer.


May and might suffer from the same problem — are you trying to say that it is possible that something has the ability to happen or are you saying that something has permission to do something. It’s like being back in school again and Miss is telling you “Yes, you can go to the toilet but no, you may not”.

Just forget about may and might and your Miss who’s making you hold it until lunchtime. Just use can and could instead. But when would you use which?

  • can for permission
  • could for ability

Good: You can create a new customer account.
Good: The system could crash if you do not create the order using the wizard.
Bad: You may create a new customer account. (Do you mean “You have permission to”? “You have the ability to”? “There is a possibility that you want to”? etc. So many different meanings!)
Bad: The system might crash if you do not create the order using the wizard.

Warning Words


If you’re using the word will, it means you’ve slipped into future tense. Stay in present tense.

Good: The report opens.
Bad: The report will open.


You don’t need to be nice in serious documentation.  Conversational writing can work for you, but be careful of humour in technical documents. Humour is difficult to read and is even more difficult to translate. If you’re including words like please, you may be slipping into other casual language. In technical documents, just stick to the facts.

Please implies that the reader does not need to do what you’re going to ask them to do and that you don’t think they’ll like to do it – you just need to tell them do do it.


Nothing should happen. Either it can happen or it does happen.

Pedal on Parliament 2 Musings

Pedal on Parliament, for those who haven’t heard of it, is a gathering of cyclists before the Scottish Parliament who believe that the Scottish government need to do more to support cyclists and pedestrians in this country. Last year, 3000 riders made it – this year it was 4000 despite the gloomy weather. The message, we hope, was clear: we need more.

My Brompton with Burley Travoy trailer

I took my Brompton, expecting that there might be a few other bikes on the train – but it was surprisingly quiet. I was, though, headed into Edinburgh several hours before the start of the ride.

I dressed my bike with my Burley Travoy, mostly to show it off to folk who may not have realised that not all trailers are designed for long hauls or children. I got a few comments from folk who saw how it could double as a shopping trolly (which is actually how I tend to use it) and thought it was a good design. I’d attached the Brompton’s front bag to the trailer just so that there would be something on the trailer.

I wore my helmet to and from Pedal on Parliament 2, but I took advantage of the opportunity and left it attached to my trailer for the group ride from the Meadows to the Scottish Parliament. It was… unbelievably liberating.
I’ve written a separate post about my bicycle helmet and why I wear it when I cycle in the city. Have a look here: http://www.techaddiction.co.uk/2013/05/bicycle-helmets/

What I saw

The crowd of cyclists at Pedal on Parliament 2

I was absolutely tickled at the sheer number of families that were there with kids. I know it must not have been easy cycling down the Royal Mile with them (cobblestone streets aren’t pleasant at the best of times), the poor dears must have been terribly shaken (literally) by the time they reached the bottom. I don’t have kids but I desperately hope that, by the time I do have them and they’re big enough to ride their own pedal bikes, the roads are friendly enough that I can cycle along with them to school without worrying about their safety.

I was actually surprised by the amount of florescent I’d seen that day. I was expecting less. Really, I was expecting it to look more like the Pedal for Scotland last year where the vast majority of cyclists were just cycling in whatever they thought would be most comfortable for the day (generally shorts and t-shirts), like a miniature  Amsterdam or Copenhagen, if only for a couple roads for a couple hours.

On the day, I ended up wearing my florescent pink cycling jacket, mostly because there were some people I was hoping to meet up with and there aren’t many who wear hot pink on their bikes. I wanted to be found in the crowd.

I usually wear the florescent so that cars will see me when I’m pedalling  down the road. I’d recently read a study done by Direct Line which used eye tracking to find that that one in five cyclists aren’t seen by car drivers [source]. I don’t fancy being one of those unseen cyclists, especially when I’m cycling down the middle of the lane trying to avoid the horrible potholes.

What I hope happens now

Car driving in the cycle lane

As I’m sure you can tell, by now, all I want is a place I can cycle without needing to worry that I’m going to end up under someone’s wheels. The current infrastructure is neglected — the advanced stop boxes are not enforced; cars park in cycle lanes; cycle lanes end just before roads  narrow (where cycle lanes are most important); cars frequently ride in the cycle lanes, endangering cyclists currently using them; etc.

I really hope that our turnout shows those who have control over the planning and budget that we expect more of them.

Bicycle Helmets

I tell people that  the reason that I wear a helmet is because I once came off my bike (after skidding on a patch of sand left over from the winter’s gritting) and ended up against a stone wall. A helmet didn’t save my life, probably didn’t even save me a concussion, but it could have.

The truth is that the older I get, the less I think that my helmet is worthwhile. I keep hoping that, eventually, I’ll be able to cycle without the helmet. It’s really wonderful feeling the breeze through my hair. I forget just how sweaty the helmet makes my forehead. I keep thinking to myself I think I could enjoy cycling  without a helmet. And I don’t think it’s likely that a helmet would help much in the types of accidents I’m likely to have. [cyclehelmets.org]

But I keep reading, in the papers and online, stories like that of Audrey Fyfe who was struck by a car [BBC News]. Some key lines jump out at me that I feel compelled to share:

The cyclist, who was not wearing a helmet at the time…


The sheriff said Mrs Fyffe “wasn’t to blame in any way for the accident”, but added: “She was not wearing a safety helmet and that in my view contributed to her death.”

I find it  frustrating that journalists feel the need to mention whether or not the cyclist was wearing a helmet, as if that’s the thing that determines whether whether it’s a tragic accident or an asked-for eventuality. And I wonder if this attitude by the media is a reflection of the attitudes of the public on the whole (like the sheriff who partly blamed Mrs Fyffe for her own death) or if the attitudes of the public are affected by this constant reminder that this cyclist or that cyclist was or was not wearing a helmet.

So every time I read a news article that mentions whether or not the cyclist was wearing a helmet, I am forced to think to myself if I were to get into a collision, completely the fault of another road user, would my family be denied compensation because I wasn’t wearing a helmet?

NHS Hack Scotland

Two weekends ago, I attended NHS Hack Scotland with my husband. Well, he attended the whole weekend and I turned up for the Sunday. I really wish I’d been there for the full weekend!

The weekend event took place at the Edinburgh Tech Cube, an older university building that has been re-imagined as a first class technology startup space. I’d never been in the building before but I’d walked past it dozens upon dozens of times in my years at uni. The space that the NHS Hack Scotland was taking up was only very recently opened and was yet unfinished. Cables hung from the ceiling in a way that I could only describe as “a bit steampunk” but the paint was fresh, there were power sockets everywhere, and the wifi was strong!

When I arrived at the end of the Saturday, I sat quietly in the corner until an organiser (whose name I can’t recall) approached and asked if I’d just arrived. When I said I had and asked how the event was progressing, he waved me over to where my husband was and encouraged me to join the group. I quickly learned that my husband’s group was creating a One Website to Rule Them All for the NHS, pulling in local information about NHS24, GPs and A&Es and such, so that a user could quickly get contact details for the help they need. I must say that I was a bit disheartened to find that such a tool was necessary in the first place, as I had assumed that the NHS24 site was already doing precisely that (See NOTE 1 below).

That evening, I joined everyone in the pub and then on to Illegal Jacks where I  chatted with a couple other attendees at length about Basic English and restricted vocabularies to increase consistency in patient pamphlets (See NOTE 2 below).

Because I was only there for the second day, most of what I learned about the other groups came during the final presentations. I watched many groups describing solutions such as an app to record anxiety levels (to contrast with the current pen-and-paper solution), an app to direct ambulance drivers to the nearest GP, pharmacy, or A&E (since they are already at the house with the patient, it doesn’t strictly send them out of their way to bring a not-too-ill patient to their GP instead of to the A&E), and a game that encourages patients to continue on with a new regimen. All of them were great ideas to solve problems that I didn’t know the NHS even had!

The folks that were there were quite split between developers and NHS staff. It was great having the opportunity to show those who are not particularly technical how problems can be solved relatively quickly and easily with a bit of clever code. I, myself, am not a coder, nor was I NHS, so I provided what services I could — I drew a wee logo and helped facilitate conversation. I would love to attend an event like this again in the near future, especially knowing that it doesn’t matter that I’m not a stellar programmer.

Yes, that is all.

NOTE 1: The poor information architecture of the NHS24 website, in contrast to the webpage that our team put together, made me very interested in learning more about UI design. It’s something I’ve always wanted to get involved in but, without an academic qualification in the subject, few will trust my suggestions. So, driven, I’ve signed up for a Human Computer Interaction course on coursera.org. Wish me luck!

NOTE 2: A future NHS hack project might be creating a text editor for the NHS that restricts the vocabulary to only words that a child about 10 years old could read and understand. If a user of the text editor uses a word that is not in the dictionary, it underlines the word and suggests simple synonyms. Because medicine has a lot of required terminology, a word can be “excused” provided it is defined in a glossary written in simple English at the back. This would ensure that the majority of patients could understand what is written, and it would encourage more consistent writing across practices.

Cyclist Labelling

Anyone who’s spoken to me in the last couple years is probably bored of hearing about my bicycle. I love my bicycle and I love cycling — to the point that I am starting to hate walking and how slow it is. I love the feeling of wind through my hair (well, what wind can make it through the holes in my cycling helmet) and the rush that comes from keeping up with the taxis going down the hill. I also love talking about cycling, about infrastructure improvements, about infrastructure failings, about my experiences cycling…. (ask me sometime, when you’ve got a few hours free)

But when I talk to people about cycling, I have to make it clear that I don’t represent all cyclists. In fact, there’s as many different types of cyclist as there are types of driver or pedestrian. So here’s a couple terms that could be used to describe me:

  • I am a female cyclist. It shouldn’t make a difference but it seemingly does to some. From what I can see on the streets of Edinburgh, there’s one female cyclist for every 3 male cyclists, which agrees with the various websites I’ve read. There are still many of us, but we are a minority.
  • I am a transportation cyclist (a.k.a. utility cyclist). I cycle instead of using a car, every chance I get (though, to be fair, I usually only cycle as far as the nearest train station). I have my Brompton which folds up to go on the train or the bus as necessary, and I have a Burley Travoy for when I have a lot to carry on my bike. I don’t cycle for sport and very rarely do I go for a wander on my bicycle. I don’t like Lycra and would rather cycle in everyday clothes because it’s more convenient for me (the only cycling-specific clothing I tend to wear is my fluorescent pink cycling jacket, so cars see me). I enjoy running my errands by bicycle but, if I don’t have somewhere to go, I tend to stay home.
  • I am a vehicular cyclist, partially. Vehicular cyclists want to be treated like any other vehicle on the road and they behave like any other vehicle on the road (this includes stopping at red lights, yielding to buses pulling out, not filtering through lanes, etc). Unfortunately, though, ‘vehicular cyclist’ is also the term ascribed to any cyclist who campaigns against cycling infrastructure because they believe that cyclists belong on the roads with any other vehicle (which I don’t). I’m of the opinion that I will use the roads and expect to be treated as any other vehicle on the road (admittedly, a slower one, perhaps not unlike a tractor), until there are safe cycling routes that are equal to or superior to the main roads in terms of convenience of use. It also means that I rage just as much as a car driver  when I see another cyclist flaunting the rules of the road.
According to this study by the Department for Transport (which I highly suggest everyone read), I can also be defined thus:
  • Reasons for Cycling: Experiential aspects of cycling
  • Ways of Cycling: Assertion

So, before you next start ranting about cyclists (or, if you’re a cylist, ranting about drivers), pause to consider — we cyclists are individuals, and that cyclist over there who just ran the red light was not me.

Digital Weddings

On a day like today, with the sun shining bright and the birds singing, the last thing I want to be doing is sitting at my computer, sorting the receipts for things we’ve bought for our wedding. Thankfully, we’ve got ourselves a shared Google Docs spreadsheet that’s keeping track of our budget, and a last-minute to-do list on the whiteboard.

Our friends will know that ThatScottishEngineer and I are both rather heavy tech-users.

When we began our wedding planning, we were thrilled that Google had created www.google.com/weddings which helped us keep organised. At the time, I was living in Cambridge and he was living in Newark, so most of our planning was done over Google Talk and using these shared spreadsheets. Our wedding website was set up using Google Sites and our RSVP was a Google Docs spreadsheet form.

But not everything is on Google’s servers. Our very-digital wedding registries are at Amazon.co.uk and Argos.co.uk. Invites were drawn in InkScape, our seating plan was drawn up in Microsoft Office Powerpoint, and all the letters I’ve had to send with cheques were written up in LibreOffice. Constantly having to move files from my Windows work machine to the Linux machine with the printer or my WordPress server has deepened my appreciation for both FileZilla and DropBox.

But what sort of documents are needed for a wedding that are well suited to the digital world? I didn’t think it would be that many until I got engaged and got started planning this massive project. Here’s a rough idea of what we’ve cobbled together:

  1. Website — Google Sites
    Just like context-sensitive HTML help! It helps if you make it clear to everyone that it’s being regularly updated and that they should check it frequently for changes. Not all grandparents understand RSS feeds.
  2. Invitations — Designed with Inkscape, printed on postcards from Moo.com. Digital until publishing, like some other items that I’m including in this list. No hand-drawing/writing for me!  In fact, doing these on the computer was not too different to flyers I’ve done before. Probably the easiest thing about the whole wedding was designing these.
  3. Guest list — Google Documents
    Name, household, address, phone number, email address, invites sent, kids ages (kids don’t count for the meal), etc.
  4. Photo shoot list — Google Documents
    A comprehensive list of all the shots I want taken (lists of guest names for each) of our wedding  day for my pretty album.
  5. RSVP spreadsheet — Google Documents
    Urgh, spreadsheet from HELL. Because it was a Google form, it ended up being very poorly formatted. Name, address, phone number, email address, which events attending (UK wedding, UK reception, US reception), whether transportation is needed to/from reception,  Dietary requirements…. I rather wish I’d done it in Microsoft Office Excel so I could colour-code it all, but it was attached to the RSVP and very much a Google Doc. Ended up copying most things over to the Guest List (#3).
  6. Seating Plan — Microsoft Office PowerPoint
    If you have £10 to spend, I’d suggest using www.toptableplanner.com. For the amount of time I’ve wasted fiddling with PowerPoint, it’s probably worth the cost.
  7. Gift Registry — Amazon.co.uk
  8. Gift Registry — Argos
  9. Thank You list — Google Documents
    Consolidated from the Gift Registry pages and extra notes of personal cards we’d gotten.

Those are just the digital documents. Certainly, though,  there’s a lot of scraps of paper in the expanding file folder on the shelf, including sketches of the wedding venue and schedules. But for the most part, this wedding has gone digital because it lets me collaborate with my partner and parents and anyone else who wanted to help.

So I guess digital is better for documents. When it comes to other things, though, I still suspect that an organist would be more reliable than an MP3 player…