Monthly Archives: November 2009

Rise of the Mega Menu

Mega Menus might sound like McDonalds’ latest attempt to Super Size your life but not in the web design community.  Here we’re talking about a relatively new development to help navigation around websites.

For quite a long time drop down menus have been a popular navigation feature on the web – our corporate website has used them for many years and they go some way to solve the problem of linking to lots of information while using a small amount of screen space.  Drop down navigation isn’t without its problems – nine years ago, usability guru Jakob Nielson advised to use them sparingly – and mega menus are an attempt to do drop downs better.

Our interest in expanding navigation isn’t for the corporate website but GO. As part of the staff intranet to GO migration we are facing the problem of vastly increasing the amount of information available and guiding people to their required system.  The top global GO navigation that shows in most internally facing services and currently contains half a dozen links won’t scale when every department and system is available through GO.

This isn’t an overnight surprise and we’ve seen this coming for over a year but now is the right time to make changes.

I don’t believe “mega menu” is a standard term and many sites implement the idea in different ways but the general idea is to have an expanding menu area linking to many parts of a site.  The first example is an extension of standard drop-down navigation.

image

Typically there will be several menu items each with their own drop down containing a variety of information.  The larger area means there is greater flexibility in how links are shown.

The second type of mega menu can be seen on the BBC websites.  In early 2008 they added an “Explore the BBC” button to the masthead of their pages. Unlike mega drop down menus, this is a button you must click on and opens up to a selection of links:

image

The explore button in provides a mix of fixed popular subsites – iPlayer, News, TV etc – and time-limited promotional links – currently Strictly, Democracy Live and Merlin.  There’s also a link to their full A-Z list (the topic of a future blog post!).

Jakob Nielson has something to say about mega drop down menus as well and it’s useful advice which we have hopefully applied to our own implementation.

Our planned approach is somewhere between the two design patterns.  We’re experimenting with ways to add “More” to the GO navigation.  We’re currently testing solutions and hope to launch something in the next few weeks.

What’s Up Docs?

image There are big changes coming to the staff intranet!  The staff intranet, also known as “docs”, is the default homepage for staff on campus and has served us well for the last… actually I don’t know how many years!  But it’s becoming increasingly apparent that the systems – both process and technical – are not able to scale with the growth of the University and with the increasing reliance on the web as a publishing point.

Along side the staff intranet, for the last three years we have had GO, our portal system available to both staff and students offering single sign on access to a range of web-based services from Edge Hill.  While it’s been possible to access the intranet via GO, it’s never been well integrated but our changes will move to a single platform.

For about a year we’ve been slowly growing our use of Confluence, an enterprise wiki system which will manage most of the content available through GO.  To date the Faculty of Health has been the largest user as part of their extranet project but over the next few months we will be implementing the migration of the contents of the staff intranet into Confluence.

We’ll be using this opportunity to give sites a good winter clean and give access to departments to enable them to easily create and update pages and link to files, all through a web interface.  The wiki offers a number of other benefits such as searching across pages and documents, and – of course – integrates with many other services available through GO.

GO and the staff intranet are very different beasts and so we’ll be making further developments to aid the transition.  Some of these might be temporary such as a new default homepage for people who haven’t yet taken advantage of the personalisation available through GO.  Other changes will apply to everyone including students.

I’m pretty excited by the changes that are coming and we’ll be introducing some possibly as soon as early December so stay tuned to find out more!

Burning down the house

image

This week Web Services started a new way of running some of the projects we undertake.  It’s still early days (five of them!) but I thought it might be useful to explain what we’re doing so that we can reference it in future.

The system we’ve adopted is called Scrum – the name comes from the game of rugby – and is a commonly used agile development technique.

As with any project management system there’s a whole load of terminology and scrum is no exception.  We’ve got pigs and chickens, scrum masters, product owners, sprints, backlogs and daily standups!  I’m not going to explain everything now but here’s a few of the things we’ve done this week.  I’m sure we’re doing some things “wrong”, but that doesn’t bother me too much.

The first project we’ve introduced this technique to is the migration of the staff intranet into GO.  We’ve set ourselves an ambitious timescale to get it moved across by the end of the year and it has a good balance of development, design, content creation and training meaning everyone in the team is involved.  Again, there will be more information about the intranet to GO migration coming out soon!

I was advised by Alison Wildish Kerwin (formerly of this parish) that the roles of product owner and scrum master should be distinct so Steve, whose work for the Faculty of Health involves a lot of development work on GO, agreed to take on the latter role.

The process started off at the end of last week when Steve and I – now undertaking the role of product owner – met to draw up the product backlog.  This is the list of things that need to be done on the project.  We already had lots of things to do to GO and added in a bunch of jobs related to the migration.  We tried to make sure each job was well defined so that anyone undertaking the task could get going straight away.

Fast forward to Monday morning, 10am and our first team scrum meeting.  After I’d explained what I understood it to be about we took a break to play poker.

Planning Poker CardsBefore I get into trouble, we weren’t sat round a table with a stack of chips playing Texas hold’em, we were playing Planning Poker.  This is a way for the team to collectively decide how difficult each task is.  In our case we’re using story points instead of time as a measure of complexity as everyone has different skills so what takes me a few hours might be done by someone else in a matter of minutes, but the complexity doesn’t change.

Aside: I’ve seen some really nice planning poker cards from Moo and other companies but I’m cheap and don’t want to pay $$$ for them so I made a set with a marker pen and some of the hundreds of old business cards that are in my drawer!

In Planning Poker, each task is read out and players each choose a card.  If there is a consensus, the ticket is allocated that point score, otherwise the highest and lowest players are given the opportunity to argue their case.  The process is repeated until there is agreement before moving on to the next ticket.

Once this was finished I quickly sorted through the tickets and gave each a priority from one to five before passing the product backlog back to the team to select tasks.  Some tasks were selected by individuals, others by pairs to undertake during the first sprint.  I didn’t try to influence this process too much but if a job was selected, it had to be completed by the end of the week.

Nine tasks totally 65 story points were selected to form the Sprint #1 backlog and the project was now underway.

Sprints are short, iterative cycles in the project development where each final output should be a “finished” product.  I consider finished not necessarily to be something we’d release to the public but at least something that we’d show to stakeholders and clients.  In most scrum teams, sprints are 30 days long but I think this is probably too long for many web development projects where there are fewer hard software engineering problems.

So we have adopted one week sprints.  This may turn out to be too short but for now it’s giving us the opportunity to see how the cycles work in a shorter time.

Each day at exactly 11am we have our “daily standup”. So far there hasn’t been much standing up going on but I can let that slide.  Each person in the team has the opportunity to say:

  1. What they did yesterday
  2. What they’re doing today
  3. Any problems preventing them from achieving their goal

Sprint #1 Burndown ChartThese meetings last at most 15 minutes (and so far much shorter) but are really useful to give everyone an awareness of how the project is progressing. As tasks are completed they are closed in our ticket tracking system and we can update our burndown chart. This is a graph showing how many story points are outstanding each day and means we can see at a glance how work is progressing.

Today after the daily scrum meeting we took the remaining items from the product backlog (with a few additions) and started the next cycle, first playing planning poker, then choosing tickets to undertake next week.  For next week we’ve introduced one task from another project – Topics/125 – and we’ll be using scrum for more work over the next couple of months while we assess its long term effectiveness.

So that’s all for our first week of scrum! I need to thank Alison and Andy Male from the University of Bath Web Services.  They’ve been very patient in answering all my questions about how they use scrum over the last few weeks (and months!).

Argleton goes national!

image

It seems Argleton just won’t die! Late to the game behind the Ormskirk Advertiser, Mister Roy’s visit and my post about the village some 13 months ago, the Daily Telegraph yesterday revealed the mystery of Argleton, the ‘Google’ town that only exists online.

It’s a nice article with exclusive interviews from Joe Moran from LJMU and, of course, Roy Bayfield. They’ve also managed to get answers from Google and their data provider Tele Atlas.  Google’s spokesman said:

“While the vast majority of this information is correct there are occasional errors. We’re constantly working to improve the quality and accuracy of the information available in Google Maps and appreciate our users’ feedback in helping us do so. People can report an issue to the data provider directly and this will be updated at a later date.”

Ah yes, report the fault… that’d be what we’ve done on several occasions without success and may be the reason why Google have decided to take corrections into their own – or more accurately the user’s own – hands.  It seems that drawing the attention of a national newspaper has caused Tele Atlas to pull their finger out:

“Mistakes like this are not common, and I really can’t explain why these anomalies get into our database.”

Let’s try a bit harder, shall we… is it because there is no process for checking data before it’s added?  Is it because you’ve chosen not to buy additional sources of data to verify against? Is it because your error reporting procedure is so poor that 13 months later it’s still in the database?  No?

For Google, errors like these are annoying.  They recently announced Google Maps Navigation for Android 2.0 offering turn-by-turn directions similar to Tom Tom and other devices but for free.  Accuracy of maps and the ability to keep them up to date will be one of the big selling points.

But time may be nearly up for Argleton “A spokesman [for Tele Atlas] said it would now wipe the non-existent town from the map.”

Update: Mister Roy appeared on Radio 5live’s The Weekend News (starts at 25 minutes).