We recently restructured some of our intranet sections and took the opportunity to do some plain English rewrites to the page content.
This example is from one of the guidance pages dealing with security when moving offices. The original is filled with passive voice and is afraid to give instructions. I’ve marked up in red.
It is extremely important to consider the security aspects of an accommodation move and plan accordingly at an early stage. If potentially sensitive information or valuable equipment is being moved, Corporate Security Branch or agency security teams should be made aware at the earliest opportunity.
If any protectively marked assets (files, papers, or even lap-tops containing information marked RESTRICTED or above) or valuable assets are being moved, the following precautions need to be taken:
Transit crates should be used, items should be packed into them by the individuals having responsibility for the assets, and each crate should be sealed. Crates must be clearly marked with the destination in the new accommodation.
The use of commercial removal companies to transport protectively marked assets is acceptable, up to PROTECT. A security escort should remain with the vehicle whenever it contains protectively marked assets.
Corporate Security Branch can advise further on any aspect of this guidance.
Plain English copy rewrite
Think about security when you start to plan an office move.
If you plan to move potentially sensitive information or valuable equipment, tell Corporate Security Branch or agency security teams as soon as possible. If you plan to move any protectively marked or valuable assets (files, papers, laptops containing information marked RESTRICTED or above), then you must use a transit crate. Pack the assets that you have responsibility for. Seal the crate and clearly mark the destination.
You can use commercial removal companies to transport protectively marked assets up to PROTECT. A security escort should stay with the vehicle whenever it contains protectively marked assets.
Contact Corporate Security Branch for more information.
Learn more about protective marking.
The rewritten piece is shorter, more instructional and gives useful links to related information.
A-Z index pages are very popular on our intranet. More popular than search. Our staff like to find what they want by looking it up in a list. If they don’t find it in the list they may resort to the search box. By looking at what phrases staff use when they perform a search from an A-Z index page, we can get a good idea of what’s missing from the A-Z listing.
Google Analytics has an inbuilt function to segment visits where staff used the search function. It was this functionality that highlighted our A-Z index pages.
I like to visualise a visit to the intranet as a trip to the convenience store. A member of staff needs something. Some people enter the store and walk up and down the aisles trying to locate what they need (menu navigation). Some look up where to go in a catalogue (A-Z index). Some enter the store and immediately ask for help (search) and others ask for help as a last resort. It is this asking for help as a last resort (searching) that can benefit us.
When I looked at the segmented analytics showing only those visits in which a search occurred, it showed, unsurprisingly, that lots of people search from the homepage, equivalent to entering the store and immediately asking for help. Equally unsurprisingly, lots of our popular pages are showing up. But also high in the reports were our A-Z index pages, indicating that lots of staff are going to the A-Z listings and then having to search.
Having highlighted a problem, I can now take action. I can target the A-Z pages and produce analytics that will tell me which search terms are being used when staff resort to using search from these pages. I can then feed these terms back into the A-Z listings, if appropriate, and over time, improve our offering.
Staff who search from the homepage are just using their preferred method of getting to content. Staff who repeatedly search from an area of content deeper within the intranet structure may highlight a symptom that there is a problem with the content.
At the start of October we introduced the next step in our strategy to improve engagement with news stories on the intranet. A month later we are seeing a 53% increase in traffic.
I had a good hunch that introducing the box would generate *some* interest, but I was amazed by the results at the end of just one month. Pageviews for news stories climbed from 44,185 to 67,872. Similar to Google Adwords, simple text adverts, when placed in context, can be effective.
This increase in news story traffic started when we introduced a “Related stories” advert box, placed top-right of feature news pages. Nothing clever. It’s a simple text box containing a bulleted list of links to past stories. A maximum of 3 links, with something in common between them all.
It’s a manual process for our intranet news editor (yes we just have the one!) to link up the relevant back-stories. We publish at least one, usually two feature stories every day, timed to coincide with our peak news readership periods (elevenses and late lunch) aiming to give a sense of steady momentum to the homepage news stream. Our feature news is varied, with stories from the front-line to seasonal pieces to interviews with board members.
The recent enhancement is a great success for my internal communications colleagues. For them, it suggests an increase in reach and shows that staff are interested enough to want to browse through back-stories to get the news behind the news, creating a richer picture. Being practical, we’d like it if staff had already read these stories, but related stories give us a second chance to increase coverage and helps staff to discover articles that they would not otherwise find. Over time, the ripples should start to run through our news collection as more and more stories backlink and crosslink to each other.
We use the Google Search Appliance (GSA) across our family of intranets. In 2009 we launched a new search experience to coincide with an upgrade to the GSA.
Analysis of original search experience
I so wish I had some screenshots of the original search results pages. If I manage to find some, I’ll post.
Back in 2008, a typical search from any one of the family of intranets produced results from all the intranets. I know it is considered best practice to include everything in the initial scope of a search and then allow users to winnow down the results. But in this case, because each intranet served a very specific part of the organisation, results from all intranets clouded the experience. Inadequate metadata and file names made the experience worse and the interface was generally busy, as if someone had got into the admin page and turned on every option. Just because you can do something, doesn’t mean you should.
Search interface redesign
For the interface, I decided to localise the results and narrow the scope of the initial search to the intranet that staff search from. I thought that it would improve orientation. So if I search from the HQ intranet then I just get results from the HQ intranet. Same goes for intranet 1, 2, 3…
For the results page I included the Google logo to psychologically increase confidence in the results. I placed a nice wide search box at the top, pre-filled with the original search phrase to allow staff to easily refine their query. I used a drop-down menu so that staff could switch to results from a different intranet. The presentation of the results themselves also followed Google’s public design with a title, snippet, URL and links to the cached version.
I decided to use icons for downloads instead of the existing [PDF] text that came by default with the GSA template. The template also included the amount of time it took to fetch and display the results, which I dropped in favour of simplicity. I changed the *Cached* link to *Text view* in the hope of encouraging staff to use this is a quick method of viewing PDF and Word files in a text version rather than waiting ages for the application to load.
Advanced search is available, but inconspicuous, since my experience of watching users try advanced searches is that they tend to overly restrict themselves. I also rewrote the help page.
The results display by relevance with the most relevant at the top (I’ve never understood some websites which clutter the search results page with a relevance or significance scale against each result; surely the first result is ALWAYS the most relevant?) There’s also the option to sort by date.
GSA backend tweaks
In addition to the interface, I also had a play around with the backend configuration with the aim of improving search quality, relevance and general usability.
For each entry on the search results page there is a date. But what does the date mean? It is not always the date when the page or document was last amended. Consider a date-specific news article that is published and then gets amended several months later. Which date do we show in search results; the date of the article or the date is was last amended? This is just one question that I had to face while tweaking the interface. It’s possible to extract a date for inclusion in search results from the page or document title, filename, URL, from within the content itself, from metadata or the file datestamp. That’s a lot of choices. Our search result dates are contextual so that if you see a news story, the date reflects the initial publishing date. If you see minutes from a board meeting on a certain date, that’s the date we’ll show.
You can manually control the ranking of documents or folders within the GSA. I use this functionality to manually demote date-specific content, such as news stories and meeting minutes and to promote popular areas.
When it comes to configuring the backend, it really helps if you are working with a well organised folder structure and good file naming conventions. For example, we have a policy of putting date-specific information in correctly labelled folders. So the meeting minutes for 2007 are filed in the /whatever/2007/ folder. The same rule applies no matter whereabouts you are in the intranet structure. In GSA, we can then use regular expressions to specify any folder with /2007/ in the path and automatically apply the same rules across the intranet. In the example below, content in any /2007/ folder gets a medium decrease in result biasing, since we prefer old news stories, old meeting minutes etc. to have less importance in the rankings.
Manual biasing also allows us to exert control over specific intranet areas and I use this, for example, when we are HiPPOed into creating sections that we’d rather did not show up and cloud search results 😉
The GSA has functionality that automatically promotes more recent pages, across the board. But I don’t use this. I prefer to use the manual method of specifying folders to promote and demote because some of our pages and documents are old (long-standing), yet current. Example: the annual leave template is a popular search request but it was amended years ago. It’s still the correct template. But because it is old, GSA would demote it in the results page if we used date biasing. Since we have various forms, policies and guidance which are still current but old, I don’t use this built-in functionality.
Crawl frequency and freshness
I also use our folder structure to help Google know how often to crawl areas of content. I know that some areas of content, such as news stories and meeting minutes, once published to the intranet, do not often change. So I help Google by specifying these areas and instructing not to waste so much time in attempting to re-index.
This is a manual method of promoting alternative or related queries. I don’t use it much since Google does a great job of serving results. I mainly use it where there is problem with internal office language with projects which insist on calling themselves one thing when everyone else knows it as something else. Clicking the alternative suggestion will perform another search.
Another manual method of promoting results. Key matches differ from related queries because clicking the suggestion will take staff directly to the intranet page rather than performing another search. Again I don’t saturate staff with these but I do use it for staff who come to the HQ intranet expecting to find popular items on their local intranets.
Query expansion (synonyms)
The GSA comes with a default set of synonyms, in different languages. Unfortunately, the UK set comes with American spellings so I had to change all the -ize, -ized, -izing to -ise, -ised, -ising. Again, I use this functionality for dealing with problems with internal language. Query expansion differs from key matches and related queries in that the GSA will incorporate the expanded search terms into the initial query. Example: I search for *organogram* and GSA will also include *org chart* and *organisation chart* into my query and return any results containing those terms.
The remaining improvements to the search experience rely on the quality of the content that Google is crawling. I spent weeks going through a good proportion of the HTML, PDF, DOC, XLS and PPT files on the intranet, getting the metadata into shape.
I posted last month on the importance of quality metadata, with examples of what happens if you don’t think about metadata:
As we publish more and more content on the intranet it is a constant battle trying to maintain the quality of search results. However, the importance of metadata is slowly but surely becoming embedded into our processes. We are still using an older version of the GSA (version 5.2) so we don’t have the advantages of any of the newer developments such as type-ahead search results and allowing staff to tag and rate results. But I believe it’s important to get the basics right before adding the frills.
We have a “family” of intranets and we use Google Search Appliance for our search engine. The quality of search results varies widely across the different intranets.
To demonstrate the difference in quality, I tested a one-word search which was the name of a project I wanted to find out about. Let’s call it ProjectX.
Corporate HQ intranet search results
1. ProjectX homepage
2. ProjectX academy
3. How to use ProjectX
4. ProjectX success stories
5. ProjectX open day (London 6/08/10)
On our Corporate HQ intranet, the search results listed the project page as the top result, with various associated documents and news stories going down the list. They are all well labelled and it’s clear what you will get if you click any of them. Key words appear at the start of the title and each title stands out.
Now, while the HQ intranet hosts the main pages for this project, the other intranets should have some pages that mention it, since the project is about ways of working within the organisation. So here are some of the search result titles that the other intranets had to offer (company name and acronyms are made up, GOPIT and Pods are not the word that I searched for):
Intranet 1 is not well optimised for the search engine, to put it mildly. It highlights the common mistake of using breadcrumb information for your page title. The result is that all search results look the same. This mistake is common in CMS systems that output an automated page title based on a rigid menu structure and means that the content provider does not have to think about a meaningful page title. Staff will scan the first few words down the left hand side of the list. If they are all the same then you are forcing them to work harder in scanning left to right along each search result, and in the case of Intranet 1, not giving them any benefit for their hard work. Google cuts off search results at 63 characters on our intranet.
Intranet 2 search results
1. recruitment authority form internal recruitment
2. recruitment authority form internal recruitment
3. Recruitment authority form internal recruitment
4. job advert template
5. GOPIT Trouble Shooters
Intranet 2 demonstrates how few content providers think about the search engine when publishing documents on the intranet (Microsoft Word, Powerpoint, Excel, Adobe PDF etc.) You can directly control the search engine results by adding metadata to documents. Google will read the title field in the document properties. Just remember, File, Properties.
Another common problem when search engines index CMS systems is that content providers may enter a meaningful document title within the CMS, but fail to do the same for the physical document. Search engines that do not read the CMS database but which index the resultant HTML and .DOC, .XLS, .PDF files, will use the metadata within the files. Intranet 2 obviously uses the same job vacancy template again and again for each vacancy, but fails to add appropriate metadata to each version of the document, i.e. what is the job title and where is the job based? I don’t know what GOPIT Trouble Shooters is (don’t use acronyms!), but it doesn’t sound like the project I was looking for.
Poor old Intranet 3. The first title is caused by a Powerpoint presentation that contains loads of images but has no text AND zero metadata. And it would never pass accessibility. Loser! The final 4 results may contain news about the project, but I’m not tempted to click.
There are no excuses for poor metatdata! It took me 22 seconds to press the necessary keys and create the metadata for a document as shown in this blog image. 22 seconds of my time saves lots of lots of seconds of staff time.