Trello now has a calendar view

Trello now with added calendar

Trello now with added calendar

It’s no secret that we are big fans of Trello here.

A fabulous feature they added in August—which may make the tool more useful to some people—is the addition of a calendar view.

For as long as I can remember, Trello has always had the ability to set due-dates on cards. These dates turn orange when the due date is near, and red when it has past. A useful visual cue. But now being able to view cards’ due dates by week or month in this new calendar view is tremendously helpful.

It’s been really well thought out too:

  • You can drag and drop cards from one date to the next to change the due date.
  • New cards can be added directly to the calendar.
  • Dates with more than one card clearly show you there are more cards, which appear in a small, scrollable pop-up window when you click on them

If you’ve not already, then sign up for Trello. It’s a really useful, flexible tool to tracking just about anything.

A change in role

Chocolate chip cookies

This month, I have begun a secondment to Admissions. I will still be working on web projects. But my focus for the next 18 months will be on webpages for Admissions and Corporate Communications.

From my point of view, there are a few different motivations behind the move.

  1. After over three great years working as part of the web team, I felt like it was time to try something new.
  2. The Admissions project will give me the chance to sink my teeth into an important project, which is quite exciting. Being seconded to Admissions will give me the space required to push on without being diverted.
  3. The coffee at St Katharine’s West is nicer.

Progress so far

For the past few months, I have been participating in Lean sessions with a group of staff from Admissions and the wider University community. We were only able to meet for a total of five days spread across roughly as many weeks. Despite the stop-start nature of our meetings, I think the results of them have been very good. Together, we have come up with the foundations of a strong information architecture, and some great ideas on functionality.

Over the years I have been involved in a few different sessions looking at information architecture with different departments. Often, such sessions run into problems. Many people become fixated on their own small sections of the website, at the expense of the bigger picture. Worse still, some try to structure a website based on the structure of the organisation, even if this would be confusing to the user.

Thankfully, the Admissions Lean group has (for the most part) avoided these pitfalls. There is strong agreement within the group that webpages should be user-centred, and that we should avoid imposing University structures or jargon on anyone that doesn’t need to know it.

I have really enjoyed participating in these Lean sessions. They avoid the need to get too bogged down in rigid processes. They also provide the scope and freedom to come up with creative solutions, without too many cheesy appeals for blue sky thinking.

For these reasons, I am excited to be working on the Admissions web project, and optimistic about what we can achieve.

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.

Two useful resources when planning Web projects

Web ReDesign 2.0

20110823-webredesign20

A few years ago I came across this really excellent book by Kelly Goto and Emily Cotler: Web ReDesign 2.0: Workflow that Works (New Riders, 2005).

In 10 chapters Kelly and Emily lead you through the workflow of a complete website redesign. They break the process down into five phases:

  1. Define the project.
  2. Develop site structure.
  3. Design visual interface.
  4. Build and integrate.
  5. Launch and beyond.

I’ve increasingly found this framework to be really useful, not only for website redesigns but for developing new sites too. I now think in terms of five phases for most Web-related projects that I work on. I’ve found it also provides a very simple overview for clients to help them understand where we are in the overall project lifecycle.

I now have the book sitting on my desk at all times, within easy reach. Their website also has a number of downloadable resources such as a client survey, tech check list, budget tracker, etc.

Web Design Sketchbook

20110823-webdesignsketchbook

Another resource that I’m finding really useful particularly during phase 1 (define the project) is the Web Design Sketchbook from 37 Media.

The first nine pages contain questions to ask the client, which I’ve found really help you understand the project better. Questions such as:

  • What objectives are you trying to achieve with this site design / redesign?
  • What is the primary “action” the site visitor should take when coming to your site (e.g. make a purchase, become a member, search for information)?
  • If you could communicate only one message to visitors, what would it be?
  • What should users think or feel when they look at the design of you site?

The final page of questions includes a list of word pairs to help you determine the tone of the site, e.g.

  • conservative or progressive
  • cold or warm
  • spontaneous or orderly
  • trendy or classic

The second half of the book contains what they call “layout brainstorming pages with full browser chrome and grids to better plan how your site will look and operate when it’s finished”. A nifty idea.

You can order the sketchbook in two varieties (single project at US $12 or a full 104 page sketchbook for US $25) or you can download and print out the free version, which is released under a Creative Commons license.

Build your own

These resources have inspired us to build our own, drawing on resources from each as well as our own experience and requirements here at St Andrews. When we have I’ll post a link to it here.

What would you include in a Web project workbook?

Making the Student Handbook mobile-friendly

Yesterday I wrote a post about our first steps into the mobile web. Today I will look at what I had to do to make it happen.

Learning about the principles

The first step was to think about the principles behind mobile web design. I am well versed in the principles behind desktop web design, but mobile is a different ball game. The focus is even more strongly centred on a streamlined approach — less is more.

The only other thing I really knew is that there are no easy answers. I had to do my research.

The first question to ask myself was, is a three year old book about mobile web design still relevant? Gareth let me borrow this book, and while parts of it feel out of date, there is still plenty of insight to chew over. It is particularly useful when thinking about older or non-‘smart’ mobile devices. There is a tendency nowadays for articles about mobile to be heavily focussed on iPhone and Android. While this book does feature the iPhone, it is much more about the wider principles of mobile web design.

I also found it useful to take a look at Patrick Lauke’s slides about the mobile web, which he delivered at IWMW. These are more up-to-date, and it was useful to refresh my memory about what I had learnt.

There are three major approaches to tackling mobile:

  1. Do nothing and hope for the best.
  2. Create a separate mobile site.
  3. Adapt what already exists.

Option 3 was the only one really open to us. This option requires compromises to be made. It probably also leads to the largest file sizes. But it is easier, and if you use web standards and code your website well, it should work well enough on a mobile device.

The stylesheet

The first step was to create a stylesheet optimised for mobile devices. A decision was taken early on to focus on the current generation of browsers, as mSaint is designed primarily for smartphones. Mobile Safari, Android and Opera Mini and Mobile all ignore stylesheets with the attribute media="handheld". Modern mobile browsers like to think of themselves as a cut above that sort of thing. They try to render a webpage more or less as you would expect it to on a desktop.

(Handheld stylesheets have always been shakily supported anyway. I have created one nonetheless as a fallback for any mobile browsers that prefer to deliver a webpage in this way.)

But accepting that modern mobile browsers will render the desktop version was not an option in this case. The technique around this is to use CSS3 media queries, which allow us to dictate which stylesheet is used based on the width of the device or browser window. Perfect for adapting content for mobile!

There is a good tutorial on how to use media queries. Guess which browser doesn’t quite like it? Internet Explorer’s issues were the source of some of the biggest puzzles I faced. But since I figured out how to make IE play nicely, it has worked well.

Design

So that it integrates well with mSaint, we have removed a lot of the devices that you find on a standard University webpage. The header, main navigation, left hand navigation and footer have all gone. Basically, everything except the content has gone. Thank goodness for display: none;!

Much of the rest of the stylesheet has been lifted straight from the existing stylesheets. So it should look and feel pretty familiar to regular users of the University website. The other major change I made was to lay out all of the content so that it sits in one mobile-sized column. So any items that appear in the right hand sidebar on the desktop version of the Student Handbook will appear beneath the main content on the mobile version.

When deciding on the ideal width of the column, I settled on a maximum width of 480px. This is the width of an iPhone in landscape mode. But I did not just make this decision with iPhone goggles on. Looking at standard screen resolutions for mobile devices (QVGA, HVGA, VGA and WVGA), 480px is the dimension that comes up the most.

Viewport

The main thing that I have learnt that I was not aware of before is to do with the viewport. The iPhone automatically displays every webpage as though it were 980px wide, and this becomes the scrollable area of the webpage. But if you have optimised the content specifically for mobile display, this is no good. The text is zoomed out and unreadable. The user must manually zoom in, even though there is absolutely nothing on the rest of the page.

The answer is to use the viewport meta tag:

<meta name="viewport" content="width=device-width" />

This tells your mobile browser to automatically zoom in as though the web page were as wide as the mobile device. You can also set a specific width, as well as setting an initial scale and control how far the user can zoom in and out. Originally introduced by Apple for Safari, it seems as though most modern mobile browsers recognise and support this — though this hasn’t been without its problems.

I have been a bit iffy about including the viewport meta tag on these standard web pages. From what I gather, its presence is supposed to indicate that the webpage has been optimised for mobile, which ours hasn’t. It also appears to alter the behaviour of Opera Mobile (by disabling the mobile view option). However, it appears to have no effect on the way desktop browsers display the page, while making it look much better on mobile devices. So we are sticking with it for the time being.

But just when I had got my head around how to control the viewport, imagine my shock when I discovered that a pixel is not a pixel. That is to say, the number of pixels on your device is not the same as the number of pixels that appear to be displayed. Accommodating different screen sizes and resolutions seem complicated at first, and unfortunately it only becomes more complicated as you learn more!

Apple have a very useful guide for developers called Safari Reference Library. It was hugely useful in helping me understand about the viewport and a lot of the other quirks of Safari for iOS, such as automatic text resizing. I think Safari tries to be too clever for its own good sometimes. This makes it a brilliant mobile browser overall, but it is quite frustrating as a developer to try and work out precisely what it is doing.

Incidentally, Opera also have a good mobile web optimisation guide.

Testing

Testing for mobile is notoriously difficult. There are hundreds of different devices, operating systems and browsers out there, with radically differing capabilities. Testing every possible combination is even more impossible for mobile. It makes designing for desktops look like a piece of cake.

The book Mobile Web Design by Cameron Moll contains a highly interesting section about Yahoo!’s procedure for testing their 2006 FIFA World Cup mobile site. By selecting a range of 5-10 devices from top- to bottom-end to test on, they felt that they had covered a wide enough range for the website to work on most mobile browsers. The technique paid off for them as it was a hugely successful website, attracting a peak of 290 million page views in one day. And that was four years ago. Incredible!

We are not aiming for that sort of audience, so our testing has been an even more modest affair. I used my own iPhone to test it in Safari and Opera Mini. But this has been quite frustrating as it is very difficult to get a signal in my office. Upstairs, my colleague has also been testing on an Android emulator.

The Opera Mobile emulator has also been hugely useful, particularly for comparing different screen sizes. How important Opera Mobile actually is, I am not sure. At the end of last semester, around 1% of visits to the University website were on a mobile device. Among those users, Opera does not appear to figure as highly as I had expected.

There is more information about mobile emulators here. These are highly useful tools for finding out how a mobile browser will render a page. But unfortunately they tell us little about how it genuinely feels to use a website on a particular type of device.

First steps into mobile

I thought I would try and take the advice of Brian Kelly who has suggested that web team members write a post a month about their work. It is particularly interesting that after coming back from IWMW I was struck by just how much focus there was on the mobile web. It felt like it was becoming something we would be getting stuck into sooner rather than later.

Sure enough, since my return I have spent around a week working on how web pages are displayed on mobile devices. It has been a tricky problem to solve, not just because of the complexity of developing a website for mobile devices, but also because of the nature of this particular project.

Integration with mobile applications

The part of the website in question is the new web version of the Student Handbook. In this past, the Student Handbook has been produced as a physical booklet. This year, for the first time, the handbook is being offered on the web — and not as a hard copy.

One of the drivers for this has been the development of mSaint, the new mobile application that is due to launch in time for the start of this coming academic session. The application is being designed to give students access to important information any time, any where. The Student Handbook will be one of the guides incorporated into mSaint.

The challenge has been to make the new Student Handbook webpages integrate well with mSaint without compromising the standard version of the webpages. The mSaint application works by linking to the individual webpages, opening up in a new browser window on the mobile device. As such, these pages need to be displayed without the website’s normal navigation, as this is different to the navigational structure of mSaint.

This has provided us with the ideal opportunity to take our first steps into designing for mobile devices. But it has also posed a tricky problem. We need to optimise these webpages for mSaint without it having an adverse effect on the experience of other users.

Foremost in my mind has been the experience of those who are navigating through the website on a mobile browser, rather than accessing these pages through mSaint. It is (relatively) trivial to create a separate stylesheet for mobile devices. But creating an mSaint-specific stylesheet or section that does not impact on other mobile users has been an impossibility so far.

It looks like for the time being we will have to make do with offering a stripped-down version of the Student Handbook to all mobile users. Perhaps we will put a disclaimer about how the Student Handbook should be viewed on a mobile device via mSaint  — but this is far from ideal. Thankfully, the regular ‘desktop version’ (if that is what you can call it) of the Student Handbook will be unaffected.

In a separate post tomorrow I will write about what I had to do to make these webpages more mobile-friendly.

Next steps

This has been a steep learning curve. There is a lot still to learn. Just as you always learn while developing for a desktop environment, there is more than this to keep on top of for mobile.

The mSaint project has brought mobile into focus a bit more quickly than I was perhaps expecting. We are anticipating that a good mobile experience will come to be expected across the University website, and it will become a larger part of our work over time.

The Town and Beyond sections now have content!

After nearly a year and a half of saying that we should do something about it, I’ve just added more content to the previously sadly lacking The Town and Beyond sections within Current Staff and Current Students.

Most of the content is now links to external websites (no use making more work for myself than is necessary) but at least this should now offer a little more guidance to staff and students, particularly those who are new to St Andrews.

One idea possible development will be to display the latest weather update/forecast into the right-hand column … but that’ll have to wait for another day.

Launch of new website design

Screenshot of new website design

Screenshot of new website design

Following consultation with staff and students, and nearly nine months of work we launched the new website design for the University of St Andrews during the early evening of Monday (8 September).

Unlike the website launch in May 2007, which combined for the first time all 27 of the support unit websites into one enterprise-wide site, this re-launch was more of a design update than a radical restructuring of information.

Feedback sessions

Back in February 2008 we meet over the course of three lunchtimes with both staff and students to elicit feedback on what people

  • liked
  • disliked
  • thought was missing (both information and features)

Those sessions were very helpful, and feedback from those were thrown into a melting pot of ideas that had also been compiled from Helpdesk calls received since the launch of the new site in May 2007, as well as our own thoughts and observations from using the site for nearly a year (remember, we had access to it for a few before it went public).

Re-design goals

Our redesign goals were quite clear:

  • Make the site easier to read
  • Offer more variety/flexibility in terms of layout, e.g. 2, 3 and 4 column
  • Ensure that it works in more browsers
  • Add new functionality

On the whole we’ve managed to achieve this, and the feedback during the last month when the site was quietly released to staff and students within a closed preview has been very positive.

The techie bit

When designing and building a new site you have to decide from the start which technologies you will definitely support and which you will try to break as least as possible.

We’ve built the site around a grid-based CSS framework called Blueprint CSS, which offers us a number of advantages such as ensuring that the site is built using accepted Web standards, a well-designed and attractive typography. It also makes it painlessly simple to develop new site designs and layouts.

Much of the new functionality (such as the carousel of images on the homepage, and the tabs on the Current Staff and Students’ pages) is largely provided using the jQuery JavaScript library.

While writing new features using JavaScript can be a long and arduous process the jQuery library allows you to do it in a fraction of the time — some of the functionality added to the site took less than a minute to write! It also works with a lot of modern browsers (Firefox 1.5+, IE6+, Safari 2.0.2+, Opera 9+).

Browsers

Speaking of browsers, based on statistics gathered by our Google Analytics account as well as Yahoo!’s guidelines for Graded Browser Support we settled on ensuring that the latest browsers received the best experience possible.  This included:

  • Firefox 2.0
  • Firefox 3.0
  • Internet Explorer 6
  • Internet Explorer 7
  • Opera 9.x
  • Safari 3.x

We tested the site back to Firefox 1.0, Internet Explorer 5.0, OPera 7.5 and Netscape Navigator 7.0, with varying degrees of success.  On the whole though the site is still usable in these older browsers, even if it doesn’t look exactly as it does in a modern, standards-compliant browser.

One major issue that we have become aware of is that the site crashes when viewed in Safari 2.0.4 (419.3) on a Mac. The issue it would appear is to do with how Safari handles JavaScript.  According to JavaScript expert, and jQuery author John Resig:

“Safari 2 has serious memory issues that are impossible to work around – simply loading and executing too much JavaScript will cause it to crash.” (J Resig, jQuery discussion group)

Our advice, following the graded browser support guideliness, would be to either disable JavaScript or upgrade to a more modern browser, such as Mozilla Firefox (the site works in everything back to Firefox 1.5).

Going live

Going live with a site is a strange experience of mixed emotions. There’s a combination of both elation that the site is going live, mixed with a little anti-climax and the nervousness of waiting for support calls to come in, hoping that we haven’t missed anything obvious.

On the whole, as a Web Team we’re really pleased with the results and the encouraging feedback that we’ve had from users, but we won’t stop there … there’s much still to be done, content to be improved on, sections to be reorganised and even more features to be added.