Moving the University website to HTML9 Responsive Boilerstrap JS

H9RBS.js (v0.0001) is a flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone kitchensink tweetybirds.

H9RBS.js (v0.0001) is a flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone kitchensink tweetybirds.

When we redesigned the University website in 2008 we adopted the Blueprint CSS framework which greatly cut down our CSS development time. It offered us a solid, cross-browser compatible foundation on which to build our site.

With the advent of HTML5 and responsive web design we started using the Bootstrap framework which offered not only a mobile-friendly grid but also at least 12 JavaScript plugins to provide design patterns such as modal windows, carousels, tabs and accordions.

As you are probably aware the web is now developing at an astonishing rate. Browsers are updated now on a six-weekly basis, HTML5 is nearing completion, and CSS4 is already being discussed. So we are looking to the future for a new framework that will support our needs and the requirements of our ever more mobile-friendly users for the next few years to come.

In consultation with Prof. Ailol from the University’s School of Computer Science we will be planning a migration to the HTML9 Responsive Boilerstrap JS starting today.

The framework describes itself as

a flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone […]

In other words: it meets our needs perfectly. Or as the developer of the infamous “All your base are belong to us” might say: All proof I.

A few of the many reasons we’ve selected this framework:

  1. It is entirely suited to today’s web.
  2. Unlike many other frameworks this uses a poor fill rather than a polyfil.
  3. It supports the new JavaScript flair loop.
  4. It is compatible with the forthcoming Commodore 64, Spectrum 48 and BBC B platforms, as well as popular browsers such as IE 6, Netscape Navigator 4 and Mosaic.
  5. No polar bears were harmed in its creation; in other words it is in keeping with our IT strategy for green computing.
  6. It is 100% compatible with JaxelScrobd 8.1.π.

From a usability point of view the only difference you may experience is a mild sense of foolishness.

New framework for responsive HTML emails

Quickly create responsive HTML emails that work on any device & client. Even Outlook.

Quickly create responsive HTML emails that work on any device & client. Even Outlook.

Ink is a fairly new framework from Zurb, who brought us the Foundation CSS framework, for creating responsive HTML emails.

It’s been a while since I’ve been asked to help put together an HTML email but as news of this new HTML email framework dropped into my inbox this morning I thought it would be useful to share it.

As anyone who has been charged with creating HTML emails, and told that they must look equally good in Google Mail, Outlook and any other client, will attest it’s not entirely straight-forward. Not least because, well, who wants to go back to using tables for layout?!

Newer versions of Outlook (2007 and 2010, I’m looking at you) don’t help either as they use… wait for it… Microsoft Word to render the HTML!?

I don’t have any need for creating HTML email at the moment, but this really looks interesting. I may just have a play with it one lunchtime.

Download Ink from Zurb

A scalable and modular approach to writing CSS

Scalable and Modular Architecture for CSS

Something that I’ve been keen to introduce to the web team for quite a while is a coding standard: a style guide, a consistent way for the whole team to write and format their code (whether HTML, CSS, JavaScript or PHP) and name their assets (documents, images, videos, etc.) so we spend less time trying to figure out what the last person did and more time being productive.

I actually started work on one after a meeting we had with a few developers and project managers back in October 2010 but I kept getting interrupted. I kept getting taken off ‘just writing documentation’ and put on other projects because they were seen as more important.

The importance of code conventions

Interestingly the last JavaScript Jabber podcast (#075) features a long conversation with Nicholas Zakas, author of Maintainable JavaScript, who talks about the importance of writing code that others can immediately understand and work with without needing to reformat or rewrite it.

The idea behind maintainable JavaScript. Or really maintainable anything is that somebody other than you has a fighting chance at maintaining it later on. […]

There are a few things that go along with that: […] When you look at the code it’s laid out nicely; you’re playing by the rules that have been set down at your company or on your team.

One of the biggest things that annoyed me in my career is that you go some place and you’d have five people on the team and they are all writing code slightly different. How many times have you ever opened up a file and before you did anything you’ve reset all of the formatting?

The discussion then moves on to the importance of code formatting issues. One of the co-hosts confesses that he has often become more incensed by co-workers using inconsistent formatting than by anything else because it adds needless extra mental effort.

Zakas agrees and refers to the work of Daniel Kahneman’s book Thinking, Fast and Slow explaining that our brains get used to particular patterns, and when you detect an anomaly in that patterns that you’re used to you switch into a different mode in your brain and that upsets you.

Zakas explains that when he worked as a consultant he used to go into companies to help them sort out their coding conventions:

I’m a very big believer in the broken windows theory where you need to do the small things right if you have any chance to get the big things right.

Jonathan Snook: SMACSS

One approach to organising CSS code that I’ve been investigating and trying out is SMACSS (scalable and modular architecture for CSS) which has been developed by Canadian developer Jonathan Snook.

In his book he talks about structuring your CSS not only in terms of how to organise the code but also the naming convention that he uses for classes and IDs.

What I’ve found immediately helpful, however, is the way that he categorises CSS rules into five groups:

  1. Base
    These are the defaults, usually single element selectors such as a, input or li.
  2. Layout
    These rules divide the page into sections.
  3. Modules
    These rules introduce reusable blocks, such as sidebar sections, product lists, carousels, tabs.
  4. State
    This was a new way of thinking for me, which I find particularly useful: how do things look in a particular state, e.g. when something is hidden or expanded, active or inactive. I especially like his class naming conventions for state which makes them readable, for example: .is-pressed, .is-disabled.
  5. Themes
    Themes are something that we use already on the University website: we often have a common core of page styles and elements but which are themed or skinned differently, for example compare Current Staff with Current Students.

I’ve used this approach in a few stylesheets now and the clarity it brings to organising my code has been very welcome. I’ve found myself asking “what is this to do with?” This is layout so the code needs to go in this section, that is a module so it needs to go into this other section. It has allowed me to offer a generic theme within the module itself, and over-rule it with a particular theme, if required. Very useful.

My next task is to explore Snook’s naming rules (he uses prefixes such as l- for layouts, is- for states) and compare it against the BEM (block-element-modifier) approach advocated by Yandex.

No doubt I will report back.

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.

Developing a new theme for Moodle 2.0

At the start of the current academic session (2010-2011) the University introduced Moodle as its preferred learning management system (LMS), also called a ‘virtual learning environment’ (VLE) and began the move away from WebCT (which is now owned by former rival Blackboard).

Moodle (which I discovered is an acronym for Modular Object-Oriented Dynamic Learning Environment) is an open-source application which of course means that it’s free… up to a point: you still need to install it, configure it and create a new visual theme for it should you require. And that’s exactly what I’ve been doing this week.


A dream to work with

Over the last few years I’ve worked on the redesign of quite a few third-party Web applications. Some have been easier than others. One quite literally drove me to tears with frustration. Moodle 2.0, though, has been an absolute dream to work with.

Moodle 2.0 is written in PHP which I have quite a bit of experience with, so that greatly helped. Having the right mental model of how something works really helps when you’re only working with one aspect of an application.

It also helped that we have a very helpful and responsive Moodle development team located within the School of Computer Science who have been great to work alongside.

Great documentation

The way that Moodle have organised how their themes work is logical and pretty clean, and the documentation on developing Moodle 2.0 themes is really good.

And I mean really good: it’s usable. I spent an hour or so carefully reading through the documentation and then got stuck in.

I did what many advise and started with an existing core theme and adapted it for our use, which took me about half a day. The rest of my time was spent working on icons.


I didn’t really like the default icons in Moodle, they looked quite pre-Windows 3.1. So I decided that I’d try to replace them using the excellent Silk icons set by FamFamFam.

Well, lo and behold if Moodle doesn’t also have an excellent document on how to use images within your theme as well as an example silk icons theme! Someone has already done the work for me!

I discovered that the example theme doesn’t contain all the icons we’re using and it didn’t customize the smilies so I complimented Silk with two other 16 x 16 pixels sets:

All-in-all that gave me over 4,500 icons from which to choose.

Moodle logic for icons, example 1

Something that really helped me was understanding the logic that Moodle uses to determine which icon to use. I was helped by this thread on the Moodle forum.

I discovered pretty early on that if your theme doesn’t provide a particular icon then Moodle will just use its own default icon. You include your own icons within three sub-directories within your theme folder:

  • /pix
  • /pix_core
  • /pix_plugins

Using Firebug or Chrome’s Web developer tools look at the URL of the icon you want to replace.  You’ll see that it looks something like this:

The important bits are in bold which are, in order of appearance:

  • newtheme is the name of your theme.
  • icon is the filename of the icon file without the filetype suffix, e.g. icon.gif, icon.jpg or icon.png.
  • qtype is the name of the sub-directory. In this case (I think!) because it’s a ‘&component=’ it is a sub-directory within the pix_plugins directory.
  • multianswer is the name of the sub-directory within the above sub-directory!

In other words, that URL is for an image within this directory:


Moodle logic for icons, example 2

Similarly, the following code

<img alt=”” class=”smallicon navicon” title=”” src=”;image=i%2Fsettings&amp;rev=235″&gt;

will look for a replacement icon in this directory:


You can glean that from ‘i%2Fsettings’, as ‘%2F’ is the URL encoding (also called percent-encoding) for a forward-slash (‘/’), and the word that appears beyond that is the filename of the icon, in this case ‘settings’. As far as I can tell you can use any format you like from GIF, JPG and PNG.

Clearing the cache

The way that our installation is set up, every time I made an HTML or CSS change I had to clear the theme cache which was as simple as logging into Moodle 2.0 and navigating to Administration > Appearance > Themes > Theme selector then clicking on the button at the top of the page: “Clear theme cache”.

Later on in the development I discovered that Moodle was also caching the information about the themes, such as the theme name and any information that appears once you’ve activated a particular theme. I needed to get the Moodle administrator to clear that for me.


This has been a surprisingly fun project to work on. Surprising only because of my experience with other less-well designed systems. I wish all Web applications were this fun and this easy to edit.


A number of people have emailed me asking for the theme and icon set that I developed/extended. Feel free to download the file below, on the understanding that I can offer no technical support on it.

This theme is released under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.


University of St Andrews is a fluid-width, three-column theme for Moodle 2.0 that was adapted by the University of St Andrews web team, based on a theme called Leatherbound created by Patrick Malley.


This theme is built upon both Base and Canvas, two parent themes included in the Moodle core. If you want to modify this theme, we recommend that you first duplicate it then rename it before making your changes. This will prevent your customized theme from being overwritten by future Moodle upgrades, and you\’ll still have the original files if you make a mess. More information on modifying themes can be found in the MoodleDocs.



This, and all other themes included in the Moodle core, are licensed under the GNU General Public License.

The following zip file is hosted at Let’s Crate.

Download (190 KB)

Saying goodbye to Internet Explorer 6

Today, Microsoft launched a big push aimed at “Moving the world off Internet Explorer 6”. IE6 Countdown aims to educate people about why they need to upgrade their browsers. The target is for IE6 to account for less than 1% of global share.

Web developers have long bemoaned the amount of work it takes to make modern-day websites work properly in IE6. It is a 10 year old browser — almost half as old as the web itself — but it is only in the past year or two that many web developers have begun to feel that it is reasonable to drop support for IE6.

Even so, even to have a website that does not work well for 1% of visitors may be deemed to be unacceptably high. While it is unreasonable to expect a website to work on a stone tablet as well as it does on an Apple iPad, if enough people are using certain software to surf the web — no matter how old it is — we need to make sure it works.

Worldwide usage of IE6

Internet Explorer 6 usage around the world In February 2011, 3.5% of UK users were using Internet Explorer 6. Worldwide, 12% of users still use this decade-old browser. Most staggeringly of all, over a third of web users in China are still using IE6.

It looks like Nordic sufers are particularly savvy. Norway and Finland are the only two countries coloured green on Microsoft’s map, signalling that they have gone below the target of 1%.

St Andrews poised to go green

I have just checked the statistics for visits to the University of St Andrews website, and the percentage of IE6 users stands at 1.01%. This is a tiny smidge above Microsoft’s target of 1%. While the UK is still painted blue on Microsoft’s map, it looks like the University of St Andrews will go green soon!

Although most pages on the University website should work adequately on IE6, we have begun to stop supporting IE6 for some of the fancier, newer designs. There comes a point where supporting IE6 just becomes a waste of time — time that we really don’t have.

Why upgrade?

IE6 was a revolutionary browser for its time. But that was ten years ago, which is an absolute eternity in terms of the web. Not only are IE6 users unable to visit many websites as the designers intended, the continued prevalence of this ancient browser is discouraging developers from innovating more — making all web users worse off. Using a 10 year old web browser is also seen as a security risk.

Microsoft have been criticised for being too slow to update their browser. It was five years until Internet Explorer 7 came out. In comparison, Mozilla are poised to release Firefox 4, two and a half years after Firefox 3 was launched. Google Chrome has reached version 10 just over two years after the first ever version.

Now even Microsoft finds the continued prevalence of IE6 to be an embarrassment. Today, Microsoft are playing catch-up with other browser vendors, but have made great leaps to improve their browser in recent years.

As such, we fully support all initiatives to encourage users to upgrade from IE6. If you still use IE6, please upgrade to the latest version of Internet Explorer.

Better still, you could opt to switch to a different browser altogether. The future version of Internet Explorer — IE9 — is a vast improvement, but is still not perfect. Only today, I worked on some new code that works perfectly in every other major browser, but does not work in IE9 due to its relatively poor support of CSS3.

If you have held off before, I can promise you that switching browsers it is rather pain-free. You will probably end up being much happier with your browsing experiences.

I suggest you consider the following browsers:

Printing out webpages

Did you know that all University webpages print out in a print-friendly format automatically? From time to time we are asked if we can add ‘print-friendly’ pages to the website. But this functionality has always been on the website, using a technique that is over a decade old.

In modern web design, the visual look and feel of a webpage (determined by cascading style sheets or CSS) is kept separate from the structure and the content (built using HTML). This provides a great deal of flexibility, allowing us to present the same document in different formats without the need to maintain multiple separate webpages.

When you view a webpage in your web browser on a desktop computer (and, increasingly, a mobile phone), you will typically be presented with the webpage with a CSS style designed for screen media. This allows us to show off a bit and use the freedom of the screen to the full to create the rich, interactive webpages we are all familiar with.

A style sheet designed for print media can remove many of the elements of a webpage that just don’t make sense on a printout. So most colour is removed and all text is displayed as black on white, saving on ink. Navigation menus are removed because the clickable printout still hasn’t been invented yet. And in place of hyperlinks in the main content area, we display the URLs of all links so that you don’t have to refer back to the webpage to work out what the link is to.

What you have left is a clean, streamlined document that can be printed off perfectly — almost as though it was never a webpage in the first place. And we didn’t need to create a ‘print friendly’ version — it was generated automatically.

We are planning on publicising this feature more in the future, as it seems that many are still unaware of it, even though it has been a standard web technique for some time now.

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.


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.


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 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.