There is a lot of advice out there about how to negate or fix this hack, but the cause is quite simple – our old friend the ‘admin’ user.

Matt Mullenweg lays out the basics on his blog:

Here’s what I would recommend: If you still use “admin” as a username on your blog, change it, use a strong password, if you’re on WP.com turn on two-factor authentication, and of course make sure you’re up-to-date on the latest version of WordPress. Do this and you’ll be ahead of 99% of sites out there and probably never have a problem.

http://ma.tt/2013/04/passwords-and-brute-force/

Follow these guidelines and you should be OK. If you are worried, contact your webhost (this is what I’m currently doing) and ask them to run a extra security scan.

I’m also taking this opportunity to do some security updates and general housekeeping so not all is lost

In this post there was a titbit which eluded to my ‘day-to-day-job’ stuff – this is the work I do as part of my role that isn’t really design or development or learning new things or making things or fixing things or anything else (I could go on….).

I think of it as ‘getting on with business’ and this has been the week so far.

This week

This week has been a prime example of ‘getting on with business’ – I came back from a weeks leave on Monday with an overflowing inbox and a handful of messages that needed following up. This took pretty much the whole of Monday and some of Tuesday morning. The work was mainly broken down into:

• Replying to emails
• Organising meetings
• Taking phone calls
• Adding news items to Intranet & website
• Setting up and auditing new Intranet editors
• Fixing problems that had arisen while I was away

Tuesday was slightly different because I only had a few hours in the office before I left for Manchester to attend the Public Sector Communications Awards for which I was nominated for ‘Best Public Sector Website’ (spoiler, I didn’t win, these guys did).

This time out of the office meant I was even more behind with all of my ‘day-to-day-job’ stuff and any design/dev time I had scheduled was quickly slipping away.

Wednesday was another oddity, I managed about an hour in the office before Mike the Knight showed up to our Children’s Ward and it was my job to take photos. This then meant spending an hour cropping and cleaning up said photos (I’m an awful photographer but decent with Photoshop). These photos were then added to our Facebook and Twitter profiles as well as a short news article on our website to promote them.

After this I had a couple of meetings and some more emails and phone calls to follow up. I then managed to quickly ‘design’ (in the loosest possible terms) a poster for our Project Management team for a local event they are running. I then went back to some more Intranet editor/news stuff and organised some more meetings.

Eventually I got some ‘work’ done and published the previously mentioned blog post which was actually sitting half-finished in draft mode from before I went on leave so it only took about half an hour to prep for publication.

Today (Thursday) is another day and although my calender was cleared for work on Canopy and some LESS work (zero meetings yey!) all of that is linked to the fact that I’m moving away from Coda (Mac)/Dreamweaver (PC) to Sublime Text 2 (Mac/PC) as my major text-editor so I can seamlessly do work on both platforms using a similar interface.

This is a pretty big task considering all of my projects will need to be re-organised and planned around this new workflow (this video series has been a big help).

Tomorrow (Friday) is already block-booked for board papers being added to the website in the morning and a visit from our local MP in the afternoon. With those types of distractions I doubt I will be able to get much of the design/dev/project work that I really want to but I’ll fit in what I can.

Reality check

So that’s my week in a nutshell, I’ve felt busy every day but have done very little ‘work’ (design or development work).

But that’s the reality of my role and as much as I desire being sat at my desk with headphones pumping Spotify into my ears while working on coding up the latest iteration of the website or designing a new microsite or learning something new sometimes I have to look up from my screen and do something else.

And let me be clear – I’m not complaining in this post – The ‘day-to-day-job’ stuff may remove me from my comfort zone but it makes the time spent working within my core skill set even more precious.

Not much has changed design-wise since this version was pushed out almost 12 months ago

Junk?

Although I built the design and framework of the site to be as lean and accessible as possible (always putting content first) I’ve noticed a lot of ‘design junk’ creep in.

For example our delightful homepage animated banner (AKA ‘the slider’) is much loved by everyone who has given me feedback about the site, but it’s junk.

The small thumbnail images on the homepage are also junk, they are totally unnecessary visual cues known as ‘decorative’ elements in accessibility terms (for example using images for links where you could just use text and a description).

So whilst I’m also using Responsive Web Design as a tool to alter the way our website is displayed on different sized screens I’m also using it as an excuse to cut down on these junk design items.

When will I be done?

I started this work 3 weeks ago and have probably only really written about 4 to 6 hours worth of real code, the rest has been planning, testing and research (the other bulk has been ‘day-to-day-job’ stuff).

And even though I tried to make sure I built this version of the site in a flexible responsive-ready way it’s a larger job than I anticipated to make everything fluid and work out the best use of breakpoints/media queries (I’ve even considered starting over and using the Bootstrap Grid).

I now expect a prototype of the responsive site sometime in the new year (2013). Which just goes to show, even though I made the existing site with responsiveness in mind, it wasn’t enough.

The main thing I wanted to achieve here was that the menu should at no point be hidden from view (displayed as an icon > dropdown). The major challenge was working out the different percentages for the slightly larger items.

Percentile headaches

The ‘Jobs & volunteers’ and ‘Patient Info’ links caused major headaches and led to code like this:

nav#global ul li {
    width:10.666%;
}
nav#global ul li.jobs,
nav#global ul li.patient {
    width:18%;
}

That had to then be re-worked over 3 major breakpoints (media queries).

In the end I managed to get the menu down to 2 lines and STILL be usable on a portrait smartphone (although I’ve yet to fully test any finger-fudging on real devices).

In this video you can see some of the work I’ve been doing behind the scenes (on our dev server) to finally introduce responsiveness to our homepage and navigation:

It’s early days yet but once I’ve got this hacked up version working I’ll post a more in depth update.

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.

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.

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

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

• John Lewis cookie page
• Number10 website cookie page
• The EU Cookie Law – what to do now
• Cookies: Majority of government sites to miss deadline
• Compliance with EU cookie law could cost the UK £10 billion
• The “cookie law” – everything you need to know
• Only 24% of online consumers are aware of EU cookie law
• How To Get Ready For The EU Cookie Directive
• he Information Commissioner’s Office (ICO)
• ICO “highly unlikely” to enforce law on cookie consent
• How BBC Online will meet changes to UK cookie laws 
• Definitive guide to the Cookie Law

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.