doteduguru

I promised a followup to the mobile site roundup, and by jimminy I deliver. If you follow me on Twitter, you’ve probably caught wind of the release of Pittsburg State University’s new mobile web site. This has been a big step for us for a number of reasons. Our deployment isn’t perfect, we aren’t as feature rich as some, but what we have done is create a great foundation to move forward on. Here’s how we did it.

First, a couple thoughts. If you are waiting to work on the mobile web, you’re already behind. You should be planning now, at the very least. Higher education is notorious for playing catch up on technology issues, don’t let that happen here. Don’t make excuses. The mobile web is not going away. It’s not a fad. It’s not something that you want to sit and wait to “see what happens.” In the brief history of the web, we’ve seen only a couple major paradigm shifts in the Internet. The first was the shift from a small, infantile web where a few companies had staked territory, to one where anyone and everyone could have a site. Suddenly the web flattened out. The second shift was to the read-write web, a place where not only can you have your site, but you can contribute to others. The web socialized, it began to get a personality, and it was your personality. Now, we are moving to mobile devices - the next shift. I don’t look at this as a technological shift (by itself) because the change occurring isn’t just about the hardware, it’s about how we design, architect, and consume information. The ubiquity of mobile devices and the rapidity with which they are penetrating society is something entirely different from what we’ve dealt with before.

So, the good stuff. First off, let me be clear. I’m a one man army, like many of you. This project wasn’t the result of the effort of a team of a dozen people over 6 months. It was me, a couple weeks, and a lot of lost sleep. To do this, I committed to the idea that it would be a pet project. I went home, and lived mobile data and code until 1:00 or 2:00AM every morning (as my wife would probably angrily attest to). I did this because I understood that in terms of priorities, it just didn’t really fit in the 9 to 5 for me right now, but it was also something that I believed couldn’t sit around and wait for my normal project schedule to lighten up. Maybe you’re luckier. If you’re not, do what you have to do. But like I said, don’t make excuses, don’t tell me that you don’t have enough resources to get this done, because you do (you just might need to keep a little extra coffee on hand). Besides, it’ll make you look great to your boss, assuming your boss doesn’t mind you going off all maverick and coming back with cool new tools. And I won’t lie to you, you might have to take a chance on this that people will see it and be on board with launching it, especially if you’re doing it like I did as a side project. Part of me feels that you have to be willing to take those risks though when you’re in web development. Playing it safe means you’ll only ever be average.

Mobile Analytics Stats

I started with analytics, because strategy starts with informed planning. For a while now, Google Analytics has had built in visitor segmenting by mobile devices or carrier. Mobile web is still very much in a maturing phase, and one of the big questions you should consider is how to target users needs. Now, here’s quotable quote #1: Yesa well coded, properly built site should be able to be used on any device. That is the ideal, and it is not unreasonable to say “this is what I want to strive for.” But, this project isn’t about converting your normal site into a mobile friendly template so it works everywhere. In my case, I saw that over 83% of my users were on devices with WebKit based browsers. Based on that fact, I decided to take a slightly different route, and I’ll explain why as we go on.  I started with the idea that users coming to our site were coming for specific tasks, and I was able to back that up with analytics (logins and email the big two). Now I had a starting place to build around, knowing that I had certain things to cover that mobile users were definitely doing. . That’s not to say it’s okay to ignore that other 17%. What I’m doing is trying to provide a killer experience to the biggest audience I can, with the goal to roll the rest in as best we can over time. Rather than taking a long time to get everyone, I’ll take a little time to get most people, and deal with the long tail.

jQTouch is a jQuery plugin for websites that allows you to rapidly deploy mobile sites that are feature and function rich. The catch is that it really only works in WebKit browsers. So, question number one you need to answer is if the feature tradeoff is worth it. In my case, I said yes. I was willing to sacrifice the 17%, not just because of the features, but because jQTouch gives you the added bonus of allowing you to build and deploy a site relatively rapidly. But, there are also other platforms, such as the MIT Mobile Web framework that would similarly enable you with somewhat better compatibility, albeit lest whizbang factor out of the box (plus we aren’t a PHP shop).

Another benefit of jQTouch is that it can effectively allow you to build an entire site in one HTML file (obviously including CSS and JS includes, which add a not insignificant amount of overhead, I recommend compressing them all). Once the page has loaded, it can give you access to a large amount of information very quickly, without page load delays in between. I use this for most of the core navigation and pages, then use the built in AJAX detection to handle things like the news feeds and events which change frequently. I should note that our content management system, dotCMS, allows me to be extremely flexible with dynamic content reuse on our site. Doing custom things with content used elsewhere on the website is an extremely painless process for us. I hope you are just as lucky in that case, because it will dramatically improve your development process. If not, RSS feeds can be your friend.

What it amounts to is jQTouch lets you design a mobile site that can behave very much like an iPhone application. Why would you want that? Because it’s not about pages anymore. Mobile usability is a completely different realm from our normal websites, so it’s not good enough to just do a mobile compatible layout (this goes back to the earlier point). It’s the information that is important. You have to take into account how people are using your site from a mobile device, because their activities will be substantially more action and goal driven than they would be sitting behind a PC. We are stewards of information, and webpages are the vessel. But the terrain is changing, and that means we need a new vessel for our information. It’s about the content, the context, and the motives

Now, quotable quote #2: Never stop improving! Ever. Our initial feature set was based on two things: what our analytics told me about where on the site people were going while using mobile devices, and what I could easily integrate without polluting the interface (news and calendar). From within the mobile site and from the site’s PC based about page, there are links to recommend features or report bugs. Believe it or not, the people using your site will tell you what does and doesn’t work for them. You just have to be listening. And once in a while you might have to get out and ask. My point is, don’t make guesses about what your users need, let them inform you. Over time, you might discover certain features go stale as user tastes, trends, and expectations change. Be prepared to cut away things that didn’t work or don’t work anymore to make room for better tools. User needs will change. But you have to be paying attention in order to address it.

Along with that, you need to set some kind of goals, so that you know what to strive towards. But be realistic. Don’t come out saying you want to do something that would completely require a change in the fundamental way someone expects to use the site: for instance, getting 10% of admission applications from mobile devices isn’t exactly realistic, because that’s not an activity you would expect people to be doing from a mobile device anyway (or maybe they are, if that’s what your analytics tells you, in which case that’s pretty awesome on its own). Start with reinforcing anticipated behavior and building expected behavior.

So, to recap:

1. Start checking your analytics, get out and ask people, find out what mobile users are doing on your site now.
2. Figure out what you can easily, and rapidly get out to those users from that list, plus anything else that could be valuable.
3. Pick some kind of framework or model to base your site on. Don’t reinvent the wheel. Don’t run before you can walk.
4. Change how you think about “web content.” Consider how and where it is to be used.
5. Set up a couple goals, something simple, something realistic.
6. Build it. Include analytics in it.
7. Watch. Listen. Measure.
8. Improve it. Make new goals.
9. Repeat steps 7 and 8 until you die.

Once your site is out in the world, you can start to really refine the experience. If you have the developer backing, you can even easily turn that site into an actual mobile app using tools like PhoneGap, letting you kill two birds with one stone. Suddenly, not only are you maintaining a mobile site, but you’re covering five different mobile app markets, with barely more overhead than the initial site.

I will be presenting on mobile web strategy with HigherEdHero.com July 29th at 12:00PM CDT, so mark your calendars if you want to get more information on this topic.