Your INTRANET is bad and you should FEEL bad

Posted on July 6, 2012 by Kimb Jones

Truth is your Intranet is bad. But so are everyone else’s right? Yes, yes they are. And especially in NHS organisations.

Take ours for example:

It’s an in-house cobbled together classic-ASP mess that has been hacked up and re-worked so many times since it launched back in 2001 I’ve lost count of what ‘version’ we are on.

It’s utterly inflexible and impossible to improve upon without a complete overhaul. But who has the time, money and resources to put into such a project when in the general feeling is that - it works.

Familiarity is your enemy

In general staff at the hospital like our Intranet. They see it as a good way to catch up with the latest news and goings on and have a chat in our message boards.

It’s rare that anyone ever comes forward to criticise it. Even new staff seem to simply accept the inevitable and get on with using it.

The sad truth is we could use this Intranet for another 10 years and I honestly don’t think any of our staff would mind.

So why should I bother?

Because, as I said in the title, its bad and it makes me feel bad. Really bad :(

I feel bad that it has been left for so long since anything significant changed on the Intranet and I feel awful that the promise of shiny new tools like SharePoint have just come in and muddied the waters and added an extra layer of complexity for our users.

To me it’s a mess – a big ugly mess. A mess that I’m responsible for because I helped build it and I maintain the status quo by containing hack and slash at the code to keep it running.

Enter project Canopy

Project Canopy is just a name I’ve given to our new Intranet prototype (excuse the logo, I only had 15 minutes). I’m starting preliminary work on the project next week while at the WordCamp UK Retreat in Edinburgh.

I’ve worked with the marketing & engagement team to come up with some realistic objectives for this project. The key sticking point is that this will not replace our entire Intranet system.It will instead augment it and run over-the-top (hence the name) of our existing Intranet-based systems like SharePoint and our telephone book system giving our staff a clean modern and fresh portal (I hate that word but it’s relevant here) to everything we have on our internal network as well as a few external items like NHS Mail and our website.

It should also make things easier to find because we can build a new less-cluttered front-page and leverage the modern tagging and indexing technologies built into WordPress to make sure everything is searchable and attributed to the correct area.

The basic outline for phase one goes something like:

  1. Improve the way news & information is processed
    Allow for different ‘types’ of news such as events, documents, links andstatuses (think tweets). News should be properly categorised and tagged using extensive taxonomies. It should cut down on emails to the marketing team by allowing different types of news to be user-submitted via online forms so only the essential information is received before being published.
  2. Create a directory where all items on the hospital network can be added and indexed for quick access
    Sort of like a ‘human Google’ this will involve blitzing though all of the links off to SharePoint, shared drives, important documents, clinical systems, apps, tools, resources etc and placing them in an intelligently indexed database (like our A to Z only more flexible). Oh and it will be searchable.
  3. Implement a poll system to improve staff engagement
    Another no-brainer Quick and simple polls are a great way to gauge staff opinions and  emotions and gather feedback.
  4. Some slight Twitter an Facebook integration
    We recently were able to open up social-media sites to our staff by getting IT to unblock them. However, it’s still a challenge making staff aware that this service is available and it should be encouraged.

So, in essence Canopy will just be a news publishing system. But a modern and polished one.

Oh and it will be built using WordPress. In fact, I’ve spent most of the R&D into this project assessing if WordPress is right for this. And it is, for reasons that will be explained in more detail once the prototype is up-and-running.

Hopefully by the time this is over I won’t feel so bad.

Posted in Development | Tagged , , | 12 Comments

Using YSlow to diagnose performance issues

Posted on June 25, 2012 by Kimb Jones

A couple of months ago I rolled out some small performance updates to our site and last week I managed to add a few more little tweaks which resulted in our YSlow grade increasing from a lowly ‘C’ to a more respectable ‘A’.

What is YSlow?

YSlow analyzes web pages and why they’re slow based on Yahoo!’s rules for high performance web sites – visit yslow.org for more info.

The image above shows the newly updated hospital live site on the left (green) and the old development site on the right (red).

‘Dev’ v ‘Live’

The development site is basically a clone of our site when it launched back in January 2012. It has remained unchanged making it an excellent tool to test any performance changes against. Both sites are also on the same server.

Note: I also run a ‘staging’ server where recent updates to the site were made before going live.

What was the problem

When the new website launched it was noticeably slow at times. And although it wasn’t any slower than the previous version of our site I had assumed that the new leaner design and bulked up server config would have significantly improved page load times – this wasn’t the case.

The real problem was that I had launched the site in semi-development-state without any real performance considerations. Basically, I had been a bit lazy.

What was changed

After tinkering with YSlow for a day I made the following simple changes that at least halved the load times of the site:

1. Combined 4 CSS style sheets into a single style sheet

This included normalize.css the core style sheet I developed and a print style.

The reason I had 4 separate files (each fed through a single file via @import) is purely organisational. When developing I like to keep my different style types (grids, typography, resets etc) in separate files so it’s easier to comprehend when making changes.

All I did to rectify this was build a new stylesheet and copied/pasted all of my styles into it.

2. Add ‘Expires headers’ to my .htaccess file

This was by far the most effective change – by adding a few simple rules to my .htaccess I could stop items such as images and CSS from re-loading every time a visitor hits our site:

What are Expires headers? - A first-time visit to a page may require several HTTP requests to load all the components. By using Expires headers these components become cacheable, which avoids unnecessary HTTP requests on subsequent page view. Read more.

And here is the magic code:

<filesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Mon, 6 Aug 2012 09:00:00 GMT"
</filesMatch>

As you can see, it tells the system to set expiration dates for the given files types – in this case all images/css etc will expire Monday August 6th. The date can be set programmatically (say every 30 days) but in my case I’ve done it manually.

3. Compressed CSS and JS with Gzip

Another dead simple .htaccess rule here:

<ifModule mod_deflate.c>
<filesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</filesMatch>
</ifModule>

Using gzip generally reduces the size of these components by about 70% – leading to faster load times all round. Read more about Gzip.

4. Configure ETags

I’ll confess I still don’t understand what ETags are or how they work but this was just another simple .htaccess hack:

Header unset ETag
FileETag None

5. Properly scale images in HTML

I’d been a bit lazy here again and used CSS resizing to make images appear smaller rather than physically resize the images.

A good example was the news thumbnails on our site – they are 215px x 215px but I was using CSS to resize them down to be much smaller.

I fixed this by adding new image sizes to WordPress and then loading these new physically resized images rather than the standard larger thumbnail.

So you get this (size: 6.7 KB):

Instead of this (size: 12.1 KB):

That’s it, was it worth it?

The work involved here took about a day to achieve and outcome was pretty impressive. Everyone who was asked to test the site noted that it loads a LOT faster. I was personally amazed not only by how much faster the site was but how simple some of these changes were to make.

A good example is the ‘About Barnsley Hospital‘ page which dropped from 3 second load time to just over 1 second.

OK, so what wasn’t done?

In an ideal world I would have also made the following changes, but these will have to wait until the next development opportunity:

a. Start using a CDN

I’m not 100% convinced that our site needs to use a CDN (Content Delivery Network) but it can only help so I will be investigating the best, simplest and cheapest way to achieve this.

b. CSS Sprites

YSlow reminded me that “This page has 13 external background images. Try combining them with CSS sprites.” - again, this is just a matter of time. I have my new ‘sprite sheet’ set up in Photoshop but have yet to export it and make the necessary CSS changes.

c. WordPress Caching (yet)

There are a number of highly respected and recommended WordPress caching plugins available but in my experience they need to be extensively tested before being used on a production site (I once broke the hospital site pretty badly when testing W3 Total Cache a few years ago).

These plugins tend to bundle together a lot of the recommended efficiencies mentioned in the YSlow reports (like the .htaccess rules I’m already using) as well as doing database caching and even CDN integration.

Posted in General | Leave a comment

WordPress admin modifications/simplifications

Posted on June 22, 2012 by Kimb Jones

This is a screenshot showing an update I’ve just rolled out to our main site which simplifies the WordPress dashboard admin menu for our content editors.

The mission here was to make the ever-confusing WordPress menu simpler to navigate for the rest of the media team. To do this I’ve concentrated on removing all non-content related items such as Plugins/Themes while also re-ordering the menu so the important items (news posts and pages) are at the top.

What’s important to note is that our content editors are still WordPress ‘Administrators’ (this is important for reasons I can’t convey in such a short post) and I have not used standard capability rationing to achieve this – it’s all down to having access to the Super/Network Admin features that are available in MultiSite.

Not as easy as you’d think

The work that went into this really deserves an in-depth blog post filled with code snippets, moans, gripes and advice for anyone else trying to do this. So, once I have everything together and fully tested (user tested and tech tested) I will see about doing just that :)

Posted in Development | Leave a comment

Meeting the Cookie Law requirements in a simple and pragmatic way

Posted on May 24, 2012 by Kimb Jones

Edit: The law was changed at the eleventh hour to allow ‘implied consent’ read more in this Guardian article. This change makes the approach detailed here a viable solution for most websites.

This week the EU Cookie Law comes into force and UK-based businesses and organisations are sweating in the summer heat worrying if their website is compliant while at the other side of the table web-agencies are busy selling for ‘solutions’ which lean towards adding ugly and inaccessible pop-ups to said websites in the hope that this will please ICO.

Relax, it doesn’t have to be so complicated

I’ve just added some basic changes to our website that make us compliant with the new law and they don’t include throwing a pop-up in our visitors faces or scaring our site visitors with paranoid warnings about how we may or may-not be tracking them.

Our new 'Privacy & Website Cookies' section

Why it doesn’t have to be complicated

The fact is we don’t really use many cookies on our site. We are not a cookie-heavy e-commerce conglomerate or a social media site or a spam-tastic-porn-network (no link, you get the idea).

We are none of these things, we are a hospital, a trusted bastion of transparency, we do not need or want to use of malicious cookies on our site and I imagine neither do a large percentage of other websites that are being worried into compliance of what is quite clearly a very misunderstood law.

The cookies we use

It may seem simple but here comes the potential fly in the ointment to this approach:

Some key extracts from the ICO cookie guidance:

…

Non-exempt: Example non-exempt cookies are given too: analytics, advertising related, and per-user customisation.  (p10)

via: http://thewebalyst.com/how-to-get-ready-for-the-eu-cookie-directive-deadline-may-25th-2012/

The only cookies that we have on our site are added by Google Analytics and these are ESSENTIAL (this is important) to the upkeep and improvement of our website. These cookies feed our essential (that word again) visitor reports (download a sample of one of our reports and take a look 5 pages, PDF).

These essential (there it is again) reports go to the hospital leadership board and are used by myself and the rest of the media team to ensure that our website is fit-for-purpose. Without them we would be flying blind trying to 2nd guess our website users.

Now, the law states that analytics cannot be deemed ‘essential’ – why? Well, probably because other less-honourable organisations use (abuse) this information for advertising purposes, but we don’t, and as long as we are being open and honest about using these cookies I don’t see a problem.

Defining cookies as ‘essential’

It is important to declare any cookies such as Google Analytics as ‘essential’ because it should mean that you do not have to have the users permission to use them (hence no annoying pop-ups or complex coding on your site):

On the plus side, the new law says that “essential” cookies can be saved without the user’s permission. The definition of what “essential” actually means isn’t precise, but as we understand it, it refers to cookies without which the site would just stop working. Even so, the new law requires your site to tell visitors that those cookies exist, even if it doesn’t ask for permission to save them.

Via http://gilest.org/20120517-cookie-law-text.html

Even if the law states that analytics cookies are non-essential as long as you are open and honest about their existence you should be fine.

Remember, we are not hiding the fact that we are using these cookies its right there on every page in our site.

Essential/non-essential

In my opinion (disclaimer: I’m not a lawyer) Google Analytics-style cookies are essential to the management of pretty much any website. Without data about how people use your site you simply cannot make sure that your site is doing its job.

This may seem like an exploitable grey-area but if you can back up your claims for essential-cookies and (again) be open and honest about it AND have a nice obvious link in your website header/footer to this information then you should be fine until any extra guidance comes out of ICO.

OK, so enough about what to do, here is how to do it:

Putting together a cookie information page

First off, I did an audit of our website to find all of our cookies. This was pretty straight forward and anyone can do it. Just hop into your web browser settings (generally via right-click menu) and you can easily find something like this:

The 'Page Info' option in FireFox - note the 'View Cookies' button

This will show you all of the cookies you currently hold for a specific website.

Cookie hunting

To be certain you catch ALL the cookies you have to browse around all the major sections of your website FIRST. Basically, interact with your site in the same way a visitor would.

To do this I had a quick browse around, added a dummy comment to one of our news items, checked our twitter feed, watched a video, and used the search option a few times.

After all of this I was left with:

The major cookies used on our site - Google Analytics and page comments

The __utmx ones are from our old friend Google Analytics and the comment_author_xxx are from the dummy news post – that’s it.

OK, so we’ve got the cookies, now we need to explain why we use them to our site visitors.

Don’t confuse, inform

Remember, most people do not know what a cookie is or why they should care. So write this information in a clear and easy-t0-follow format using simple language anyone can understand, for example:

We actively use cookies to record how our visitors use and browse around our website. This helps us determine popular and unpopular pages and lets us know where we need to improve and what services we may need need to promote or update.

Then once you have your explanations clearly outlined list the cookies in a simple table like this:

The cookies on our site, listed and described

This is similar to how the now famous John Lewis page has listed its (many) cookies and how the UK Government list theirs so you’re in safe hands following their lead.

Cookie creep

Finally, if you integrate with, or even just link to, other sites that have social media functions and log-ins then list these as potential cookies.

We use facebook, twitter and YouTube on our site so it made sense that occasionally some cookies may creep over from these cookie-heavy sites. To combat this I linked to the respective cookie and privacy policies on each of those sites.

Final thoughts

This may not be the solution for everyone, but it works for us. One thing we could have done was to simply turn off Google Analytics and disable comments on our news items. meaning we would be using zero cookies. But doing this would have severely neutered our ability to run a useful website.

Of course the other option is to install opt-in pop-ups and warnings which is quite frankly overkill for the majority of sites trying to comply with this law. Only do this if you use cookies extensively, for example for e-commerce purposes or visitor log-ins.

It’s my opinion that it will be a long time before this law is fully understood and adopted so its better to do something in-the-middle like this than do nothing. I guarantee there will be changes to this law in the near future and when you realise that even the UK government will not be compliant in time the potential legal impact begins to feel a lot less serious.

Useful cookie law links and articles

Posted in Development | 1 Comment

Promotion landing page/microsite for new new hospital PAS (Patient Admin System)

Posted on March 1, 2012 by Kimb Jones

Last week I posted a quick article detailing how I have developed a series of campaign specific landing pages (microsites) for internal use using static HTML pages hosted on our ailing Intranet server)

One of the sites I posted an image of was an early version of our New PAS campaign site:

Which was recently polished off to look like this:

The idea here is that we hook-in hospital staff with a simple and engaging design which is much more effective that posting out a simple news post to our dreary Intranet news feed or sending out those dreaded global emails.

How I built it

The key components here are HTML5 boiler plate, 960.gs a mix of free icons and some illustrations purchased from stock.

Using 960.gs and HTML5 boilerplate meant for extremely rapid prototyping. I was able to get a layout set up in less than a day and populate it with the provided content. This was then sent for review and after another days work tweaking and cleaning up the site was done.

Feedback for this site in particular has been very positive – in fact, overwhelmingly so. So much so that I’m now sketching out some ideas about how these sites could be converted into reusable templates with CMS functions which would make possible easier and faster developments in future.

Posted in Design | Leave a comment