Weeknotes, 15th March

Why I’ve started writing weeknotes

It’s Giles Turnbull’s fault. I’ve been meaning to start writing more blog posts for the last five years or so, and never seem to get around to it. Then I read this new website, Doing Weeknotes, and it made me think that this might be a way in. I don’t know how long I’ll stick with it, but seems worth giving it a crack.

Doing weeknotes

Lauren Pope is one of my favourite people to read in the world of content, and she writes weeknotes. That seems like a good recommendation.

Lauren Pope: Weeknotes

Some rules

The first rule is I can change the rules if it seems like they need changing.

But aside from that:

  • Write every Friday
  • Don’t spend more than 30 minutes
  • Write about work stuff, mostly
  • It doesn’t need to be perfect

On that last point: I’ve found that working in content design requires taking a critical eye to writing. That’s good, but it can get in the way of publishing your own writing. Wanting to write clearly and unambiguously sometimes means that writing a blog post takes a long time when you get to editing it. For these weeknotes, I’m going to write and publish quickly, so it won’t always be as clear as it could be.

What I did this week

I’m planning our next training session

I’m running our fourth session of Content Design for EdWeb 2 next Thursday, 21 March. This is a content design training session for web publisher colleagues who are thinking about their site’s upcoming (or recent) migration to our new content management system, EdWeb 2.

Here’s the blurb:

“This session is delivered by the Website and Communications User Experience team and is aimed at Lead Publishers who have completed the EdWeb 2 training. Building on topics covered in the Effective Digital Content online course, this practical workshop looks at how to apply effective digital content design principles to your EdWeb 2 site.”

We’ve been asking attendees to bring along a piece of content that they want to improve. Then we can talk about content design principles and apply them to the examples from the attendees’ websites.

I was a bit nervous about this at first, but it’s gone really well. The examples are real and reflect the messiness of an actual website. Sometimes the topic of a page is complicated and it’s not easy to put it into Plain English.

It’s been good to see publishers show their sites to colleagues. It means they get an outside view on the language used on their site, and on how the content is broken up and organised.

I listened to a podcast about doing content design training for a large organisation

Kind of blew my mind that there’s a podcast about the exact thing I’m working on at the moment.

Here it is:

Training people at a UN Agency to write for their new intranet

Is that really 30 minutes?

Yep. That went faster than I expected.

See you next week.

Using UX research methods to inform online course design at the Royal (Dick) School of Veterinary Studies

In the Vet School’s Digital Education Unit we assist with the design, support and maintenance of a large portfolio of online postgraduate courses. With this project, we did user research to help us improve the design and usability of these courses in our virtual learning environment, Learn. We used a top tasks survey and interviews to learn more about the tasks our students need to complete and what their experience is like as they complete these tasks.

Read more

Creating documentation that you want to iterate on

It’s rare that you ever write documentation right the first time. Instead, what happens is this:

  1. You write a guide explaining how to do something.
  2. Later, you realise it could be better. Or maybe the user interface changes and you have to update the screenshots.
  3. You go back to the guide and improve it.
  4. Time passes, and then Step 2 happens again, ad infinitum.

As you iterate like this, the documentation gradually gets better and everyone wins. Fewer support calls and more self-supporting users.

But sometimes the digital media used to create the documentation is hard to edit, and this makes iterating a pain.

Here are three types of web-based digital media that people use to write documentation:

  • PDFs
  • Videos
  • HTML webpages

PDFs

Iterating on PDF documentation isn’t much fun because PDFs are typically hard to edit. Say your PDFs are Word docs that you publish as PDFs. To edit a PDF, you need to track down the original Word doc that was used to generate the PDF. Then you need to edit it, export it as a PDF and reupload the new PDF to the web. Sometimes you need to delete the old PDF from the web too. You’ll want local copies of the web-based files, and everything needs organising, versioning; maybe you’ll need to manually append numbers to the filenames so they’re called instructions_V02.3.pdf; maybe you’ll need to archive the now out of date instructions_V02.2.pdf.

See more here:

Why GOV.UK content should be published in HTML and not PDF

Videos

There are some good things about video documentation. Screen recordings capture the animated features of an interface: the buttons and menus that appear when you hover you cursor over the right place. Zooming in and out on the UI is a neat way to show where it is on your screen that you’ll find the small button you need to click.

But screen recording videos are a nightmare to edit. If I want to tweak a video, I need to find the original Camtasia project. Then I need to re-record the part of the screen recording that needs fixing, or more likely make a brand new one from scratch. Fixing the narration and subtitles involves re-writing and re-recording. The video needs to be exported out of Camtasia, then uploaded to a video hosting service in place of the old one, and then that video will probably need to be embedded on a website somewhere.

Consequences of PDF and video documentation

The main consequence of PDF and video documentation being hard to edit is that you start to ignore the feedback you’re getting at Step 2.

Worse case scenario, you start to convince yourself that you got things perfectly right the first time and that it’s not your documentation, it’s the feedback that’s wrong.

But more likely, you’ll listen to the feedback but won’t want to act on it. It’ll hang around in the swampy lagoons at the bottom of your to-do list.

HTML webpages

Fortunately, there’s a promised land: writing documentation as HTML webpages. They’re easy to edit, which means it isn’t a pain when you realise they need to be improved or brought up to date.

How to search the University of Edinburgh website directly from Google Chrome

In Chrome, you can search Google directly via the omnibox (the address bar where you type a URL) .

screenshot of omnibox searching google for llamas

It’s possible to customise this to search the University of Edinburgh website too.

screenshot of omnibox searching ed.ac.uk for llamas

How to set this up

Go to Chrome settings.

Search engine > Manage search engines.

Other search engines > Add.

Use these details:

Search engine: ed.ac.uk
Keyword: ed
URL with %s in place of query: https://search.ed.ac.uk/?q=%s

screenshot of chrome settings for an extra search engine

> Save

Now if you type “ed” in the omnibox and hit tab, you can search the University website directly from Chrome.

#cool #wow

How this works (Google Chrome support page)