Waverley Fortress Whinge

I’m in a bad mood and I have a blog. So here, have a whinge.

I’m not the only one thinking of the changes to Waverley Station are really just turning it into a fortress. Beyond how annoying it is to have to walk behind slow pedestrians on a very narrow pedestrian walkway, I’m fully expecting that there’s going to be an injury as a result of the location of the barriers at the top of the walkway.

I was regularly commuting from the North end of town when the conversion from Train Station to Fortress commenced. I started my coast down Waverley Bridge and found, out of nowhere, that there was a barrier preventing me from continuing to coast down the North Ramp into the station. I stopped abruptly at the barrier, dismounted and walked, certain there was a mistake — they had only JUST made North Ramp a dedicated cycle space! I wondered what they were up to that they’d need to temporarily close the ramp. Ooh, were they going to actually paint a cycle lane to let the pedestrians know that they ought not stand there and smoke? No.The next day was when I’d spotted the signs that said that this was going to be the way it is until further notice. No official explanation why. I tweeted Network Rail to ask, no response. I emailed to ask why they had to close it to cyclists, no response. I know, now, that many other cyclists also emailed and wrote letters, but still no response. Sure, we’ve got theories, but none that explain the blanket ban.

Time passes, annoyance increases.

I’m now commuting from the South end of town, and could much more easily enter the station from the Market Street entrance…. But the escalators are a bit too steep to take the bike down, the bike is a bit heavy for carrying down two flights of stairs, and the lifts are slow. Besides which, there’s road works on Market Street so I need to get past the temporary lights, navigate around the potholes, and squeeze between the cones to dismount in the first place. It’s a stressful way to end an otherwise lovely journey.

I tried going North up Waverley Bridge and turning right down the South Ramp. I wait for traffic and, as soon as it’s clear, I turn across traffic — to find there’s nowhere safe to dismount. The orange-and-white barriers that they’ve installed more recently are flush with the kerb against a moving lane of traffic. So traffic needs to be clear enough not just for me to cross traffic, but for me to cross traffic, slow to a stop, dismount, and get onto the pavement. Sure, there’s a bit of paint on the road to say that the kerb is meant to come out further than it physically does, but tell that to a taxi that’s just pulled out and is skirting the kerb closely because there’s a bus coming the opposite direction.

I had a word with the Network Rail staff in the office to ask if they could, at VERY least, move the orange-and-white barriers further back so I at least had somewhere to dismount. The fellow at the desk looked genuinely surprised that he’d not considered cyclists needing to dismount somewhere, to transition from being a vehicle to being a pedestrian on their stupidly narrow ramp footways. He said he’d speak to his manager about it. The next day, one of blocks forming the barrier at the top of each ramp was moved to the side, giving me somewhere to cycle to where I could dismount. By the following day it looked like the barrier blocks had been moved back.

Seriously. Waverley Station planners, whoever you may be, this is ridiculous and dangerous — fix it.

The Alternative Dawn Alarm

Daylight lamps are expensive. I had been saying for years that I was going to buy one but I hadn’t quite gotten around to it. I used one, once, when I had a flatmate who kept his in the communal kitchen /livingroom so I know what a difference they can make.

After I moved out, I’d researched them to decide which to buy and came across dawn simulators like the Lumie bodyclock alarm clock. These are designed to make your body “see” a sunrise at about the time your alarm clock would go off, so that you wake up more slowly and naturally (rather than being jolted out of sleep, mid-REM, by an alarm clock buzzer).

In the Scottish summertime, I keep the curtains and blinds closed tight, trying to keep out the 11pm sunset and 5am sunrise (it’s too bright for me to easily fall asleep and stay asleep). In the winter, those handful of daylight hours are just not enough for me to ever feel awake. Dawn simulators, unlike just keeping the curtains open, switch on at the same time every morning — so, despite the seasonal differences, I can keep the curtains closed tight and the room dark and I’ll still have a sunrise for when I need to wake up for work.

I didn’t manage to buy one back then, because they were all too expensive (and I was a poor student/graduate). By the time I had enough money that I could feel comfortable investing in one, I’d already ended up with a much, much cheaper alternative…

A few years ago (has it really been a few years already?!), I’d seen a Lifehacker article about under-bed lighting. I showed it to my partner who thought it was a nifty idea so we plugged a multi-colour IKEA strip light in under our Malm bed and set it to red so that it would be dark enough that it would be only just visible at night.

A short time later, my partner and I had watched a BBC Horizon episode on how humans perceive colours. It turns out that blue light makes your brain think it’s dawn! We put two-and-two together, switched our LED lights from red to blue, and plugged the whole thing into an outlet timer. Voilà! Instant daylight alarm clock!

Our current setup doesn’t have the lights under our bed, because our current bedroom is too small and the light doesn’t bounce around the room enough to wake us up. Instead, the light is behind the dresser, bounces off the semi-gloss painted walls, and lights up the whole far end of the bedroom.

Blue LED lights reflecting light off a painted wall
Showing the current light and outlet timer setup

It’s not the most ideal setup, because some mornings the faint “click” sound made by the outlet timer switching on wakes me up (if I’m in a particularly light sleep at the time), but it’s a lot better than waking up to a buzzer every day! We’ve been waking up to this for a few years now and it works a treat. About 15 minutes after the light turns on, the radio also switches on using a timer (tuned in to the peaceful classical music of BBC Radio 3) — but we’re usually already awake by then so we can enjoy the warmth of bed whilst we listen to the news headlines.

We have it set so that it doesn’t switch on at the weekends, but we barely sleep in more than 30 minutes, now, because our bodies have gotten so accustomed to waking up at a certain time. When the clocks changed, though, it only took us a few days of gently waking up earlier than we’d like before we were on the new schedule. I’ve never been a morning person, but I can wake up now without the grumpyness and anger at the alarm clock. I may still be tired if I haven’t gotten enough sleep, but at least I won’t be groggy.

Someday I’ll get a daylight lamp, to leave in the livingroom to have some “sunshine” in the winter evenings but, for now, this is enough.

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.