Modo Labs, the vendor for our university mobile app, has created a new blog series talking about how their client schools are using the product. Texas A&M was selected to be the first university profile in this series. They interviewed our local Marcomm team and asked about how we are using the app, what the most popular links are, how we partner with campus, and much more.
We have launched what I would deem to be a mini-release of the campus mobile app this week. This release is intended to circle back and get some of the content that was not ready for the Phase I launch, as well as to add some timely information.
- Modo has updated our app to the latest version of the software framework. This will give us slightly more flexibility in how content is managed.
- A Move In Day module will be added to the home page (coming later this week.) Content was coordinated through Residence Life and Parking & Transportation, along with others having input or providing services during that time. This module will be removed once Move In Day is past.
- Aggie Works will be added as a link in the Report a Concern issue. This will be a link to their responsive website.
- Aggie Print will be added as a linked icon on the On Campus persona. This will be a link to their responsive web application.
- A Perspective Student persona will be added, with content created in cooperation with the Office of Admission
- An Important Phone Numbers page will be added to both the Welcome and the On Campus personas.
- While not technically part of the app update, we will also be updating the software powering calendar.tamu.edu. This update, which will be done in early August will affect the Events section of the app
The biggest project we have been working on for the last year is not even a website, it is a complete overhaul of our university mobile app. We began this process over a year ago, and it finally went live on Monday.
It is available on the app stores now, either as an update to the previous app or a new download if you do not already have it installed. If you don’t, I highly encourage you to go and give it a look.
The new app, based on the Kurogo platform, will be a significant improvement over the previous version. Our guiding principle in the project has been to identify content that will be useful for our campus users and get it within the app. The Kurogo platform helps us in this by providing the concept of personas – instead of trying to cram all of the content onto a single dashboard the users can select their audience type and see a screen with content relevant to them.
We do not see this as a one-and-done project. While Phase I consisted largely of replicating the content from the previous version of the app into the new platform, the entire project will be a multi-phase process where we continually bring in more content, more services, and more audiences.
Our hope is that this can become an important content platform that is embraced and wholeheartedly used by our campus community.
Last fall I joined the W3C‘s Responsive Images Community Group after being inspired by (and having lunch with) Mat “Wilto” Marquis, the group’s chair, when he spoke at An Event Apart in Austin. The RICG calls itself “a group of independent designers and developers working toward new web standards that will build fast, accessible, responsive websites.” Mostly my contributions have been limited to fixing typos on Github and making wisecracks on IRC, but I’m pleased to have contributed to the newly-released RICG Responsive Images WordPress plugin. (Technically, I added support for PHP 5.3 and below, versions which don’t support function array dereferencing.)
The RICG’s first achievement was to push through a new HTML element –
picture – along with its friends
sizes. These allow web developers to offer images in various sizes and let the browser decide the best one to use. A retina phone can display the 2X retina image, an older feature phone can display a little 200px image, and your ultra-wide monitor can display a full-bleed 1920×1080 image. Best of all, the browser only downloads the image it needs – no double download.
I consider responsive images a perfect example of progressive enhancement – fully supported on Chrome and Opera, and partially supported in Webkit and Firefox. Even Microsoft is working on adding these features to
Internet Explorer its new browser. And the Picturefill script adds responsive images capabilities to any browser. Until now, responsive web developers like me have been sending oversized images to be squeezed onto little phones, wasting much of our users’ bandwidth. Mat Marquis says that people in Africa actually have to keep lists of which websites they can’t visit without draining their entire monthly bandwidth. So if we use responsive images when someone’s mobile browser doesn’t support them, the user experience will be no worse off. But if the browser does, his or her experience will be much faster and more pleasant. An image on a mobile phone might only need to be 1/5 the size in kilobytes of an image on a typical laptop.
The WordPress plugin is a first step to adding responsive images to the core of WordPress itself. When that happens, webmasters of 60 million websites can upload large, clear images, and their visitors will only download the image size they need. The plugin comes bundled with Picturefill, and since WordPress already keeps track of multiple image sizes automatically, the future looks good.
Google made a big announcement on Monday regarding search returns for mobile devices. They recognize the growing importance of mobile and are taking steps to make mobile search more user friendly. People grow frustrated with they click through to a site and can’t read its content, so Google will begin posting notices on the search return page for entries that contain primarily technologies that may not work on mobile devices. The prime example would be Adobe Flash, since it does not run on iOS devices. Here is an example of what they say it might look like:
It may be some time before we see how this actually plays out. I did a quick search for sites that I know contain flash — even those which are 100% flash driven — and I am not seeing the notice in my search results. My Android phone does support Flash, but even on an iPad I couldn’t find an example of a site with a notice. In doing this search I noticed that many sites are already moving from Flash to HTML5 animations anyway. Even those which haven’t are starting to do a better job of replacing the Flash content with at least static image content. Still, I think the fact that Google is taking this step is a clear signal that we need to meet our users’ needs however they come to our sites.
After plenty of work, and even more delays, we have launched the new version of the university mobile website.
This version is focused on usability. We took a long look at the content that people were actually clicking on and tried to make that much more visible and easy to access. This resulted in the removal of over half of the links that we had in the previous version. We hope that this then makes the site more user friendly and gets people quickly to where they want to go.
In addition to the interface redesign, we also rebuilt the entire back end. The new framework was designed to allow flexibility into the future. We now are able to use the same data sources for the mobile website and the TAMUmobile apps, which makes ongoing maintenance much easier. It also allows us to look down the road at unifying the website and the apps into a common graphical design.
Since everybody is getting new smartphones except me, I need to add high-resolution images to the sites I design – but until now, I couldn’t see what they looked like on a high-resolution device without borrowing somebody’s phone. We use media queries to serve larger images to retina devices, and zooming my browser won’t trigger these media queries.
- Go to “about:config”
- Find “layout.css.devPixelsPerPx
- Change it to your desired ratio (1 for normal, 2 for retina, etc.)
When I run these tests, the pages get so big it’s hard to use Firefox for anything else, but I can quickly tell which images will work on retina (the crisp ones) and which images need to be swapped out (the blurry ones).
I learned another retina solution from Monty Dickerson: use larger images that have half the quality (Photoshop 50) but four times the pixels (100 x 100 instead of 50 x 50). It’s counter-intuitive, but they aren’t much heavier than traditionally-sized images, yet look much better, even on normal monitors.
Using Monty’s solution, you can check for blurry images by just zooming your browser 200%.
(This article also posted on GoMobile!)
Over the next year our group plans to rebuild both the university main web site and the mobile web site. One of the discussions that came up was whether to detect the user’s device on both sites and route mobile devices hitting www.tamu.edu to the mobile site and desktop users hitting m.tamu.edu to the full site. Based on the behavior that I have seen on many university sites this is a discussion that takes place throughout higher ed. Many get it wrong. The answer, of course, is an emphatic NO!
For the philosophic reasoning, let me first go back to what I consider the central truism of our job. Visitors come to our sites for a reason, which is to find a particular bit of information. People no longer “browse” sites, following links from one to another to see what is there, like we did back in the early days of the internet. They want to find out something, and it is our job to help them find it quickly and easily. Any interruption or delay in this process represents a bad user experience, and we know from dozens of studies that dissatisfied users will leave and not come back.
Redirects are a perfect example of such an interruption. We as developers have been trapped by the proverbial box. We see that users come to the site from a particular device so we cleverly think that we should “make it easier for them” by redirecting them to where they “really” wanted to go. But is our assumption of where they want to go valid? Probably not. Most university mobile sites are not simply the mobile version of the full site. They are instead designed to feature content that is useful mainly to people on campus who are themselves on-the-go. Two years ago that would have described what most people with a mobile device would be looking for. Today, though, the majority are causal users who expect to be able to see all of the content of the sites they are visiting…which is to say the responsive view of the full site. Redirecting mobile devices from the full site to the mobile site, then, is today more likely to give them the wrong information than helping them find what they were looking for.
Our team discussion went further than this, with one side advocating redirecting devices to the mobile site even if the full site is responsive. The problem with this method is that it fails to see the paradigm shift that has taken place in the last couple of years. It argues that if you use a mobile device you should get the mobile site (i.e. the site designed for on-the-go users) and that if you really wanted the full site you can link back to it. That is a dangerous assumption because it not only fails to take into account the intent of the user but actually mis-identifies their intent and points them to the wrong location.
From a pragmatic standpoint we should avoid redirects because their time is simply over. Responsive design has answered the question of how content should best be served to a mobile device. Two or three years ago it might have been understandable to redirect a mobile device to a mobile site since the full site probably was not mobile friendly. Today there is no excuse for the full version not to be responsive. That, then, should be what people on mobile devices are allowed to see.
What about the case of redirecting desktop users? When many mobile sites today detect a desktop user they redirect them to a special landing page telling about how the site was built, what features are included, and (maybe) a link to actually view the site content. Why? When we visit a site we want to read its contents, not learn about the framework that created it. We don’t build special pages on our full sites telling how we built it, and mobile sites shouldn’t be any different. If somebody visits a mobile website from a desktop browser, send them straight to the site content.
A quick glance at our mobile site’s analytics shows that many on-campus staff regularly use the mobile site in their day-to-day jobs from their office desktops. They have very similar needs to on-the-go users and prefer going to the mobile web site to get all of that information in one place rather than going to a dozen different full sites to get it all. In this way we get them the information they were looking for quickly and easily. If we had instigated a redirect on the site they probably would have turned away on their first visit, never came back, and therefore never gained the benefit of using the mobile site.
In summation… leave the user’s choice of where they are going up to them. When we as developers start assuming that we know better than the user what they themselves are looking for we are generally going to be wrong, and in turn create a bad user experience and a frustrated user.
The Go Mobile website has been improved to help Texas A&M University meet mobile web demands.
- New Resource Center blog for learning mobile web best practices
- Mobile-ready web templates that are university brand compliant
The Resource Center blog (http://gomobile.tamu.edu/resource-center) allows users to comment and engage with authors about their posts. Authors are members of the university’s Mobile Team, which is tasked with guiding the campus strategy to maximize mobile’s potential (http://gomobile.tamu.edu/about).
The responsive web design templates are available at the Go Mobile Resource Center by selecting the Downloads icon. Responsive websites automatically rearrange content based on the visitor’s screen size, allowing one website to work on smartphones, tablets, and laptop and desktop computers.
To help remove barriers to engaging key audiences and become a higher education leader in mobile implementation, the team’s focus is facilitating mobile-friendly websites for colleges and academic departments. View the Go Mobile progress report for this objective at http://gomobile.tamu.edu/texas-am-mobile-strategy#tab_tab4.
The Mobile Team will be scheduling new outreach and training events. Join the GOMOBILE-L Listserv to receive updates (http://gomobile.tamu.edu/join-the-listserv).
Send questions or comments to Allison Oslund (firstname.lastname@example.org), Texas A&M Information Technology assistant director and Mobile Team leader.
PRESENTATION FEBRUARY 28
On February 28 at 3:30 in GSC 101A, join the Texas A&M Mobile Team for a presentation on implementing a mobile-friendly website. This follow up to January’s Go Mobile presentation will provide more in-depth technical information for web developers and designers. Buster Neece, Division of Student Affairs, will be the presenter. A panel of Mobile Technical Team members will be available to answer questions on going mobile.