Leet service desk calls

Our support calls list shows 13 calls assigned to me, 37 to the whole team. That's so 1337 or leet!

1337

This morning I logged into UniDesk, our IT Service Desk incident management system, and noticed that the calls assigned to me next to the calls assigned to the whole web team read: 1337.

That’s so 1337! (Using leetspeak, an alternative alphabet for the English language, it reads: elite.)

We’ve been making a particular effort to drive down our support calls this week. Here’s how many calls we had at 09:00 each morning this week.

  • Monday: 67
  • Tuesday: 58
  • Wednesday: 55
  • Thursday: 37

We’re doing well. In fact, you could say we’re 1337!

Advertisements

Job vacancy: web developer

Spanner lying on a laptop keyboard

The University is looking for an experienced web developer to join the web team.

  • Grade: 5
  • Salary: £24, 766 — £29,541 per year
  • Fixed term: 3 years
  • Start: as soon as possible
  • Closing date for applications: Friday 19 July 2013

The main focus of the job will be in helping design and develop small-scale web applications, and add additional functionality to existing pages/websites so a solid and demonstrable knowledge of HTML, CSS, JavaScript, and PHP is required.

Our enterprise web content management system is the commercial, Java-based TerminalFour Site Manager (although we’ve never had to dabble with any Java) running on an Oracle database; and we’re working a lot with WordPress (and MySQL) too these days (both stand-alone installations and WordPress multisite). Pre-knowledge of either is not required as training will be offered.

We’re currently using an adapted version of the Blueprint CSS framework and a patchwork of jQuery plugins, but we have plans to move to the Bootstrap framework, the LESS CSS pre-processor and a host of other Node.js enabled time-saving goodies. We currently don’t use any particular PHP framework, although PHPMaker has been used to help generate a few applications; that’s not to say that we’re not option to the adoption of a PHP framework. We often use Agile methodologies in our project work and use Trello to keep ourselves organised.

It’s not all about hardcore coding, however. An important element of the job will be to deal with website users and content creators in a support and perhaps even training role. The web team offers first, second and third line support, and you will be expected to get involved there too.

The web team is currently made up of four members (web manager, web architect, web editor and web apprentice) with a fifth member on secondment to Corporate Communications for 18 months. Speaking as someone who is obviously somewhat biased, the web team is a good, fun and supportive place to work. Do you fancy joining us?

More details can be found on the University’s job vacancy website – the job reference code is SB1005.

Which browsers do you support?

Five web browsers

Chrome, IE, Opera, Safari and Firefox

I’m currently working on a document of guidelines for our web team and web developers. Something that I’ve been asked to include is to indicate which browsers we support.

Digging around, for example, Yahoo! have their fine Graded Browser Support page which lists specific version numbers of various browsers. Google Apps, on the other hand, supports

“the current and previous major releases of Firefox, Internet Explorer, and Safari on a rolling basis. Each time a new version is released, [they] begin supporting that version and stop supporting the third most recent version.”

What do you folks do? Do you have browser support guidelines, either written down or not? Where do you draw the line (do you still support IE7, for example)? What are your criteria for what you support and don’t support?

And what about mobile devices?

I’d love to read your thoughts about this.

Web team support calls from 2010-2011

Graph of support calls over two semesters

(Click the graph to see a larger version.)

This morning I’ve been gathering data for a meeting with have with the University Lean team tomorrow, including this graph of support calls (above). I thought I’d share something of what I’ve discovered.

The project with Lean is to help us design a more efficient way to manage projects and to explore how to better balance moving projects forward with our on-going, and unpredictable, support calls.

In the academic year 2010-2011 the Web team recorded how many calls we received each week. This included:

  • Emails to our IT Helpdesk call management system
  • Support-related emails to our personal inboxes
  • Telephone calls
  • Personal visits to the Web team offices

Basically, if it wasn’t related to an on-going project then we recorded, grouped into calls that took up to

  1. 10 minutes
  2. 60 minutes
  3. 120 minutes or more

And we further categorised them as

  • Advice—e.g. could you tell us what template to use for this website? Do we support IE6 now?, etc.
  • Fix—e.g. this page is broken please fix it, please remove this document from the server, etc.
  • Request—e.g. could we have a meeting with you about x? Could you create a generic page template for this web application, etc.
Support calls (2010-2011)
Advice Fix Request
Semester 1 434 722 509
Semester 2 328 547 382
Total 762 1,269 891

That’s a grand total of 2,922 calls over the course of 35 weeks. Or approximately 83 calls per week.

What it shows us immediately is what we’d long suspected: that the start of each semester is the busiest time of year for us. This should help us to plan projects and which parts of the year to keep clear to make room for more support requests.

Something that this has highlighted too is to look into how to reduce the number of calls asking us to make fixes to existing content, structure or CMS elements.

No doubt we’ll report back as we progress through this project with Lean.

This week I are been mostly…

20110728-unidesk

Above: Our current list of outstanding support calls.

In the style of The Fast Show: this week I are been mostly… answering support calls.

Many people suspect that the Web team summers are quiet affairs, with plenty of peace and quiet to get on with projects. Sadly that’s not the case, and particular while we’re playing ‘holiday tennis’ with one another. (By the time I return from holiday on Monday 15 August I will not have seen my colleague, Steve Evans, for 6 weeks.)

So, for the last two weeks, while I’ve been desperate to get on with various projects (redesign of the Sport and Athletic Union pages, for example) all I’ve done is answer support calls as the Web team strength has fluctuated around the 40-60% mark.

It’s been both a very satisfying and a mildly frustrating way to work. But that’s just the way it is just now, so no point in complaining.

(I did manage to get the Course Catalogue pages moved, though.)

Contacting the web team

Email @ symbol

To help us manage more effectively how we deal with support calls, we would like to encourage people to email support requests to webteam@st-andrews.ac.uk rather than directly to individual members of the web team. These calls can easily be assigned to any member of the web team using the IT Helpdesk call management system; direct emails cannot and run the risk of not being attended to at all if the recipient is on holiday.

We found that many people erroneously thought that webmaster@st-andrews.ac.uk was the personal email address of the University Web Manager, Dr Stephen Evans. It’s not, so the webteam email address has been newly created to reflect the fact that these emails are sent to the whole team.

Should we still be supporting Internet Explorer 6?

Keep calm and debug IE6

Keep calm and debug IE6

Every couple of months the same topic of conversation comes up in the Web team office: should we still be supporting Internet Explorer 6? The answer so far has always been a resigned yes, but that may not be the case for too long.

A little history: IE6 was released on 27 August 2001, three days after Windows XP was released.  Since then IE7 was released in October 2006, IE8 in March 2009 and IE9 public beta in September 2010.  So, surely it’s now time to withdraw support for a browser that is over nine years old.

Bring down IE6

In 2009 .net magazine started a campaign called “Bring down IE6“.

Bring down IE6

Their mission:

The premise is simple: Internet Explorer 6 is antiquated, doesn’t support key web standards, and should be phased out. This isn’t about being anti-Microsoft, it’s about making sure that we encourage people to move to modern browsers such as IE8, Firefox, Chrome, Safari and Opera.

Case-by-case

In an article entitled “Calling time on IE6” Craig Grannell “asks designers and developers if it’s finally time to take IE6 behind the shed and shoot it”!  He leaves the conclusion of the article to Web standards hero Jeffrey Zeldman:

How much longer we prop up this ageing browser must be decided on a case-by-case basis. Not every site can afford to dump it today, but the writing’s on the wall.

I think that’s a really important point because until recently the primary browser on the University’s default PC setup, that was installed on every Windows PC in the PC classrooms, was Internet Explorer 6.  If we wanted our websites to be viewable and usable across the University then we had to support it, we had no option.

Supporting IE6 is a drag. As all web developers will know, you spend a couple of hours building something that works perfectly in Chrome, Firefox, Opera and Safari and then you spend twice as long again debugging it in IE6 and IE7 and IE8, which all appear to have introduced new bugs to the game.  Keep calm and debug IE!

Analytics

Since the University’s default PC setup (‘standard build’) has now moved to Windows XP (and will hopefully soon move again to Windows 7) the default browser is now IE8, and s the requirement to support IE6 has now been reduced.

This is backed up by the statistics from our Google Analytics account that tracks which pages are being view most often and by which browsers.

Unsurprisingly Internet Explorer, being the default browser on our standard build PC, is the most popular browser to use to visit the University website; Apple Safari (the default browser on Apple Macs) is second.  42.5% of all visitors in the last month have used one version or another of Internet Explorer.  The breakdown of which version is interesting:

  1. IE8: 79.8% (382,394 visits)
  2. IE7: 15.4% (73,944 visits)
  3. IE6: 4.4% (21,186 visits)
  4. IE9 beta: 0.29% (1,395 visits)

That means that only 1.8% of all visitors to the University website last month used IE6. But 21,186 visits is still quite a lot.

Frameworks

Adopting the Blueprint CSS framework a few years back made a considerable difference to our development time.  Blueprint comes with a build-in IE hacks/workarounds stylesheet that addresses a good number of common IE5, IE6 and IE7 issues that has literally saved us hours and hours of hair-pulling.

Similarly we’re using the jQuery JavaScript framework which still supports IE6 and so makes cross-browser coding much simpler.

My view is that with such good support built-in to these frameworks for IE6 there’s really no excuse at the moment to completely drop providing a certain degree of support for IE6. The bugs are well known and the hacks are well-documented, and so finding workarounds for those that are not already contained in the framework files really doesn’t take that long to code these days.

Yahoo! graded browser support

However, it doesn’t mean that pages need to look pixel-for-pixel identical in every browser.  Something that is made explicit in the Yahoo! Graded Browser Support chart:

Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates an artificial barrier to participation. Availability and accessibility of content should be our key priority.

Over the last two to three years I’ve used the Yahoo! GBS chart to inform the Web team about how much support we should be affording to the various browsers.  IE6 is still granted A-grade support but it appears from a blog post “Graded Browser Support Update: Q4 2010” on the Yahoo! User Interface Blog that this is all about to change.

Listed among the various changes, which includes dropping A-grade support for Firefox 3.0 and initiating support for WebKit browsers on iOS and Android OS, is this:

Forecast discontinuation of A-grade coverage for Internet Explorer 6 in Q1 2011; we expect to move IE6 to the C-grade browser list as of the next update.

C-grade browsers, according to the GBS page are “identified, incapable, antiquated and rare.”

I would say that the bell is tolling for IE6 but it would appear from some corners of the Web that it has already rung out.  Google has already held a Funeral for IE6 after it withdrew support for the aged browser.  Microsoft sent flowers!

Conclusion

According to Google IE6 is already dead and buried, while Yahoo! are expected to degrade support for it in early 2011. Microsoft themselves, on the other hand, have committed to supporting IE6 until Windows XP SP3 support is removed in 2014; but that just means removing security issues rather than adding new features.  IE6 will never, on its own, support HTML5 or CSS3, for example.

So, should we still be supporting Internet Explorer 6? I expect that we’ll follow Yahoo!’s lead next year and move to providing only a base level of support for it.  When we move to using HTML5 and CSS3 then I expect we’ll have to drop support for IE6 completely.

We’ll make sure that content is readable but not worry too much about the presentation (CSS) and behaviour (JavaScript) layers; we’re already kind of doing that already in places, to be honest.  But as we’re using frameworks for CSS and JavaScript which still support IE6 the elderly blue ‘e’ may be inadvertently supported for a little while to come.

Then all we need to do is try to kill off IE7.  Who’s with me?