Skip navigation
All Places > The Mimecaster Central Blog > Blog > Authors user.QZGHBD9VWW

Colum McAndrew is a Technical Copy Writer responsible for the style, structure, and content in the Mimecast Knowledge Base. Having joined in February 2016, he relishes getting others thinking about language, its meaning, and how it can be used to communicate efficiently.


There are currently 3,000+ pieces of content (inclusive of ideas, discussions, articles, and blogs) within Mimecaster Central, and rising. A large proportion of these sit within the Knowledge Base (KB), the home of all Mimecast product documentation. 


So what exactly does the KB contain? Perhaps a list of the top 10 most visited pages in the past month will give us a better idea of some of the top content.


Drum roll please......


In reverse order:


  1. Creating / Changing a Blocked Senders Policy
  1. LDAP Directory Synchronization Troubleshooting
  1. Rejected Messages
  1. Anti-Spoofing Policies
  1. Maintaining Digest Set Policies
  1. Secure Messaging: Troubleshooting Log In Issues
  1. Mimecast Data Centers and URLs


Onto the medal positions:


  1. Mimecast for Outlook Overview
  1. Using a Digest


And finally, the winner for most frequently visited Knowledge Base page in the past 30 days goes to...


  1. Mimecast SMTP Error Codes


Is this what you expected, or are there surprises? Maybe you have a favorite page that deserves a wider audience? Let us know in the comments below!


Also check out some of Colum's recent posts:


'Lights, Knowledge Base, Action!': How to Get More from the KB 

'It's Help, Jim, But Not as You Know It': Mimecast's User Assistance Evolution 

Colum McAndrew is a Technical Copy Writer responsible for the style, structure, and content in the Mimecast Knowledge Base. Having joined in February 2016, he relishes getting others thinking about language, its meaning, and how it can be used to communicate efficiently.


Remember the last cell phone you bought? I bet you couldn’t wait to take it out of the box and play with it.

Of course you did your research before purchasing it, right? You asked other users for their opinion. You saw the TV advert. Maybe you’d even read the manufacturer’s website. 

You just took it home, took it out of the box, and turned it on. Oh, and I bet the instruction manual is still in the box: untouched and unloved.

What’s that? There wasn’t an instruction manual? So how do you know how to use it? More to the point, what has the manufacturer done with all their technical writers?


Here's a help you with that manual

Before I try and answer that, let me tell you a story.

As a young IT professional, I worked with large IBM mainframes -- the sort that filled a large room, had flashing lights on the front, and less internal memory than a current day desktop calculator. They were proper machines, and each had a library of manuals in case things went wrong.

If you were lucky, you’d pull down a tome onto your desk, flick through to the relevant section, read a page of very dense text, and got your answer. All too often though, there’d be a cross reference to another manual. You’d repeat the same exercise, only to be referred to a third manual. Sometimes this would refer you back to a different chapter of the original manual!

Little did I know it then, but this perfectly illustrated many of the issues with technical documentation.


Changing user habits 

These days, things are very different.

With the rise of online content and social media, the attention span of users is astonishingly short. Don’t believe me? Ask yourself when the last time was you did a Google search, and went past the first page of results. In fact, I bet you didn’t look much past the first few entries.

The amount of online content these days creates a real challenge. In 2013, the Science Daily website reported that 90% of the world’s data had been created in the previous two years, and the trend is only getting faster.

So what role does technical communication have in helping users do their job, and how do we sift through the content mass to get to it? In fact, shouldn’t software providers be trying to prevent you having problems in the first place?

Ask yourself why you need help. Can the user interface be understood? Is the process being performed simple? If not, who can change it? The coding is the job of the developers, but as language experts, we add the other dimension. We can add assistance into our applications, be it in the form of field names, tooltips, error messages, or embedded user assistance. After all, forcing you to move away from the task in hand to find an answer, is inefficient.


Thinking differently

At Mimecast, I am proud to be part of a company that thinks differently. Questions like, “What does that field name mean to you?” and “Wouldn’t it be better if that error message also told the user what to do?” are frequently uttered. By working closely with the design and engineering teams, we aim to reduce ambiguity, while ensuring a consistency of style.

We also build assistance into our applications. The Connect Application, designed to on board new Mimecast customers, is a good example of this. It brings the Knowledge Base content, albeit in a more condensed user-friendly form, in front of the user at the point they need it.

So what about our online Knowledge Base? It is pretty big, and if I’m totally honest, big isn’t always pretty.

Mark Baker’s Every Page is Page One blog describes the problem of online content perfectly. His idea is simple. On the web, every page is page one. Think back to that Google search. You expect the answer to be in the first few results, so web content must be created to meet this expectation. Our challenge is to apply the same principles to our Knowledge Base content. For example, we're starting to use annotated images, video, and other interactive content:


Annotated Image

If content is king, context is queen 


So back to that cell phone with no manual. How did you know how to use it? I’ll tell you how -- good design and slick marketing.

Apple’s products are often held up as an example of why you don’t need documentation, but it’s not as simple as that. Sure, their design team did a great job of simplifying everyday tasks, but that’s only half the story. Their marketing cleverly focused on end-user actions. The results are devices that are simple to use, and a user base aware of what they need to do to use them on a day-to-day basis.

Or are they?

How did they learn how to sync their email with Outlook? What about understanding why some SMS appear in blue, while others are in green? That’s right -- there’s online content in the form of Apple’s documentation, a whole host of blogs, and industry reviews. In short, a community of users.

So if you’ve never used our Knowledge Base, that's OK. Maybe it just means that as a team, we’ve done our job well?