{"id":948,"date":"2013-09-22T12:32:54","date_gmt":"2013-09-22T11:32:54","guid":{"rendered":"http:\/\/blogs.kent.ac.uk\/webdev\/?p=948"},"modified":"2013-09-22T15:29:34","modified_gmt":"2013-09-22T14:29:34","slug":"the-university-of-kent-student-guide-timetable","status":"publish","type":"post","link":"https:\/\/blogs.kent.ac.uk\/webdev\/2013\/09\/22\/the-university-of-kent-student-guide-timetable\/","title":{"rendered":"The University of Kent Student Guide Timetable"},"content":{"rendered":"

The Student Guide<\/a> is a new University of Kent website offering students a range of information and services. This replaces our old Student Portal, which was first introduced 6 years ago when the web was a very different place. The Student Portal did a good job, but it\u2019s time for it to have a well-earned retirement.<\/p>\n

The Student Guide has links to services such as Moodle, library resources, and student timetables. It\u2019s this last service – timetables – which I\u2019m going to focus on in this post. It\u2019s one of the things the webdev team worked so hard on this summer!<\/p>\n

\"University<\/a><\/p>\n

Timetables<\/h2>\n

Timetables for students existed in the old Student Portal as lists of lectures and seminars. You could also find timetables in our Student Data System, and on the Timetabling Office website (only this time as downloadable iCal files). That was quite a lot of places, presented differently each time.<\/p>\n

While this was all fine and useful it wasn\u2019t necessarily all that immediate to students’ needs. So we thought why not present a calendar in a calendar format. That way people could very quickly and simply visualise when and where their lectures would be. I know, it seems crazy looking back now. A calendar in a calendar format. But that\u2019s just what we did.<\/p>\n

\"A<\/a>
I don’t have many lectures do I…<\/figcaption><\/figure>\n
\"week<\/a>
ok so here’s what it would look like in week view if I did have some lectures…<\/figcaption><\/figure>\n

<\/h2>\n

User needs<\/h2>\n

So what were the user needs?<\/p>\n

We already knew that turning up to lectures at the right place and time is a really key thing that students want to do. Making that process easier was clearly going to be a good thing. Senior managers were on board, and the business case was easy to make.<\/p>\n

Anytime, anywhere<\/h3>\n

User need #1 – I want to view my timetable anywhere on any device.<\/strong><\/p>\n

Most people now are pretty much within constant (emotional) reach of their mobile<\/a>, so anywhere really does mean anywhere.<\/p>\n

\"Mobile<\/a>
Mobile calendar view<\/figcaption><\/figure>\n

Therefore our primary goal was to provide a means of viewing lecture times and details\u00a0in a device agnostic way<\/em>. That is, giving users a good experience of a site no matter what device they\u2019re viewing it on.<\/p>\n

The shift to mobile isn\u2019t just something which affects other websites. Stats for our clearing applications this summer showed there were double<\/em> the number of hits from mobile devices compared with last summer – up to about 20%. Initial stats for the timetable app show an even higher proportion of mobile at around 30%.<\/p>\n

<\/h3>\n

Visual appeal<\/h3>\n

User need #2 – looking up lecture times should be simple and clear.<\/strong><\/p>\n

Showing timetable data on any device anywhere would be fairly simple. We could just give students a big list of dates and lectures and seminars.<\/p>\n

However they\u2019d hate this and no one would use it without resenting the fact that there was no alternative and they were forced to use it by their university. We don\u2019t want that.<\/p>\n

Speed<\/h3>\n

User need #3 – viewing the timetable should be quick.<\/strong><\/p>\n

The key user need these days is that a web page should load very quickly. This is now so key that it\u2019s really an unwritten rule. But we still put it down as a user need to highlight just how important this kind of thing is to people.<\/p>\n

 <\/p>\n

Closing the gaps<\/h2>\n

Closing visual appeal gap<\/h3>\n

Closing the visual appeal gap seemed fairly trivial. The technical challenges of presenting events in a google calendar type way are superficially quite small. There are plenty of clever javascript libraries which convert calendar data into a pleasant calendar. We chose FullCalendar<\/a> – a jQuery plugin.<\/p>\n

So we very quickly prototyped a desktop calendar which looked fairly impressive. Hoorah! We slapped ourselves on our backs and all was good.<\/p>\n

Of course it wasn\u2019t really that simple.<\/p>\n

The initial prototype looked reasonable out the box, but we still needed to do a lot<\/em> of work to turn it into a real, usable application which looked and worked exactly how we wanted. So we took our first steps with backbonejs<\/a>, which we used to control and customise the app. We also used our PHP templating engine to make the app look like a University of Kent web page.<\/p>\n

Closing the \u201canytime, anywhere\u201d gap<\/h3>\n

We\u2019d planned a technical solution and had a prototype. On a desktop. This isn\u2019t much use for meeting the user need of being able to view a timetable anywhere.<\/p>\n

Mobile first is a new approach, and not something we\u2019ve been able to embrace totally yet. However we knew early on that we had<\/em> to get the mobile experience right. Although we didn\u2019t start with a totally device agnostic approach, we very quickly moved to mobile designs.<\/p>\n

In fact the mobile views took up far more<\/em> design and development time than the desktop view.<\/p>\n

Mobile design is actually very hard, because you don\u2019t have the luxury of space. So it forces you to think very hard about what you\u2019re doing. This can only be a good thing, and that\u2019s in part why mobile first design is such a great discipline. It\u2019s tough, time-consuming, but refreshingly rewarding. The most important thing is that you\u2019re giving people a really great experience.<\/p>\n

Closing the speed gap<\/h3>\n

The app itself is almost entirely fast client-side javascript (we chose to code in backbonejs primarily for its speed). This takes a massive toll off our servers, and puts the load onto our users\u2019 relatively powerful devices.<\/p>\n

We did still have to use our rather more server intensive PHP templating engine, although with lots of caching we managed to drastically reduce the footprint on the server.<\/p>\n

Login<\/h4>\n

We had another speed problem to wrestle with. Logging in.<\/p>\n

Timetable data is tailored to each student. It\u2019s personal stuff too. So we had to get people to log in to the app. But the login process was a little out of our direct control because it used the university\u2019s central login system.<\/p>\n

First impressions really count. We could have built the world\u2019s snappiest, smartest app but the user experience would be ruined by a really slow, bad first impression of having to log in. Never<\/em> give your users a bad first experience. A ruined first experience means people dread the second experience, or may not even bother getting that far. That\u2019s just not good enough.<\/p>\n

So we put a lot<\/em> (really, it was a lot) of planning, testing, and heart-felt effort into trying to get the login experience as good and as fast as we could.<\/p>\n

User testing<\/h2>\n

User needs and closing gaps are all very well. But you have to ask people what it is that they want, and adjust the experience accordingly.<\/p>\n

Jonathan – our UX lead – planned a series of user testing sessions to get our app as close to what students wanted in the little time we had available.<\/p>\n

A common beginner technique with user testing is to hold group sessions. This is usually a really bad idea.<\/p>\n

Plenty of studies – the most famous of course being Jakob Nielsen\u2019s<\/a> – show that you can gain as much as 90% of your user needs from just 5 or so people. Interviewing them individually can give you some really rich, and surprisingly consistent, information.<\/p>\n

Jonathan held a series of one-to-one sessions with a handful of students to study their interactions with our prototypes, and get really valuable feedback on the user interface and their general needs from a timetable app.<\/p>\n

Latent needs<\/h2>\n

A latent need is a need which the user isn\u2019t consciously aware of, but which brings a great deal of surprise and satisfaction. It\u2019s the design factor that turned Apple from a failing desktop computer company in the mid 90s into one of the most successful lifestyle brands ever.<\/p>\n

Finding and meeting latent needs is a mercurial art, but it\u2019s really important.<\/p>\n

One need that we discovered students didn\u2019t know they had was the ability to view their calendar data on their device\u2019s native calendar tool.<\/p>\n

How did we know they didn\u2019t know? Because almost by accident we happened to mention this to some of our test users. They were amazed. No one had told them this before. They didn\u2019t even know such a simple thing was possible.<\/p>\n

We therefore tried to make a big deal of these calendar feeds on our app. Not everyone would choose to view their calendar that way, but for some it could be great.<\/p>\n

\"presenting<\/a>
this shows how tricky it is to represent different ways to download\/subscribe to iCal feeds.<\/figcaption><\/figure>\n

In the end we couldn\u2019t find a really succinct<\/em> way of communicating to students exactly how to set up their devices, although we think we came up with a reasonably good attempt. It was sad and frustrating for us not to be able to close this latent need fully. But we will continue to try to improve this based on feedback because it was so clearly something that our test users loved.<\/p>\n

Summary<\/h2>\n

The webdev team spent a lot of time over the summer building a timetable app for the University of Kent Student Guide.<\/p>\n

We could\u2019ve built something simple very quickly, but it wouldn\u2019t have been a good fit for the key user needs of having a fast, visually appealing way of looking up their timetables on the go.<\/p>\n

Instead we put a lot<\/em> of effort into a very lightweight, fast app which works as well on a mobile as it does on a desktop.<\/p>\n

It\u2019s not at all perfect. Nothing ever is. But we believe it\u2019s a great start. As a team we take pride in knowing that we put real effort – and joy – into the app to help make students\u2019 lives at the University of Kent that bit better. I hope it shows.<\/p>\n","protected":false},"excerpt":{"rendered":"

The webdev team spent a lot of time over the summer building a timetable app for the University of Kent Student Guide.<\/p>\n

We could\u2019ve built something simple very quickly, but it wouldn\u2019t have been a good fit for the key user needs of having a fast, visually appealing way of looking up their timetables on the go.<\/p>\n

Instead we put a lot of effort into a very lightweight, fast app which works as well on a mobile as it does on a desktop.<\/p>\n

It\u2019s not at all perfect. Nothing ever is. But we believe it\u2019s a great start. As a team we take pride in knowing that we put real effort – and joy – into the app to help make students\u2019 lives at the University of Kent that bit better. I hope it shows.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8989,125],"tags":[23156,521,79387,843,79386,16750,23157,50782,79384,79459],"_links":{"self":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts\/948"}],"collection":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/comments?post=948"}],"version-history":[{"count":21,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts\/948\/revisions"}],"predecessor-version":[{"id":1019,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/posts\/948\/revisions\/1019"}],"wp:attachment":[{"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/media?parent=948"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/categories?post=948"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.kent.ac.uk\/webdev\/wp-json\/wp\/v2\/tags?post=948"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}