TNT8: On your mark, get set, mobile

Tiffany Broadbent 
Web Programmer, College of William & Mary

Doug Gapinski 
Creative Director, mStoner

The audio for this podcast can be downloaded at

Announcer: This is one in a series of podcasts from the HighEdWeb Conference in Austin 2011.

Doug Gapinski: Thanks for coming to the early session. We're here today to obviously talk about mobile. We're talking about challenges and opportunities in higher and secondary education.

We always like to lead where we're going to end up, so just so you know, you don't have to take notes. This presentation is downloadable at the link above. That's  The back channel, we put up the appropriate tags. And then if you want to get in touch after the presentation with either one of us, my email's on the screen, our Twitter handles are on the screen. You can get in touch that way. Or just come up after the presentation is over.

Tiffany Broadbent: Question: Why am I here? I was the lead web developer for our mobile site and also for our mobile app that I'll talk about in a little bit. We released this in late August 2010 so we've got a good solid year's worth of data that I'll talk to you about.


Doug Gapinski: Why am I here talking about mobile today? As of Q4 of last year, we got asked to work on our first mobile project at mStoner. Since then, we've touched about nine different mobile projects. Most notably, the two that have launched are Trinity College in Hartford's mobile site, that's, and UIC's mobile site. We partnered with their communications team to get that live. That's

I've got to say, I've been with mStoner for about five years and this is hands down the piece of the Web that I'm most excited about working on. It's a lot of fun, it's different. It has a Wild West feel to it in that a lot of the conventions that are being worked out now for higher education are brand new.

Here is the outline for our presentation. We're going to talk about the opportunity itself, the content piece of it, the design piece of mobile, the coding challenge, and then finally, measuring it, so setting some goals and metrics at the beginning of a project that you can use to measure success as time goes on.


One of the reasons that I talked about being excited about mobile is this idea of what it's doing. It's this strategic level of technology. Mobile technology is helping people find what they need wherever they are when they need it. It's very transactional. It's really about utility.

The second reason is that there is something happening, a shift happening right now in how people look at the internet. We're still on the front end of it, but so you guys know, in Quarter4 of last year, the sales of smartphones and tablets eclipsed the sales of desktop machines, so I think that segment was the kind of shift that we're going to see an exponential rise in use of mobile devices and mobile visits to websites.


A little piece of data from January of this year is that only 9% of Carnegie Classification institutions out of about 4,500 in the United States, only about 9% actually have mobile sites at all. So that's another reason you guys should be interested in this is, as the people working on this, you have an opportunity to get into this year and be one of the first people to the table with a mobile site. Ninety-one percent of institutions or professionals at schools don't actually have a mobile-friendly site yet.

Another reason to really be interested in this is mobile includes probably several things that you're already good at. So if in some capacity in your job you probably touch the strategic end of things, you probably touch the design end of things, you probably touch content in some way, and you probably touch technology in some way, you're thinking about issues already that touch the mobile sphere and can influence the work that you do as you dive into this.


Tiffany Broadbent: Like I said, we launched in August of 2010, so we have about 14 months of stats that we can throw up at you here.

We have about 130,000 visits to the site, over 100,000 unique visitors, and everybody spends about a minute or so on the page visiting two or three pages. And that was one of the things that we really wanted to focus on was that we have an automatic redirect.

If you go on your mobile phone to, it kicks you to our mobile site first. If you go to any internal page, you get to the internal page, but for the homepage, we wanted to take you to the mobile site and try and offer you content that we thought you might be interested in first. But luckily, not everybody's just clicking go 'Full Mobile Site' and leave the page, so we were glad to see that.

Another interesting stat we've come across since we've launched this is we've seen an almost 80% increase in mobile traffic to our mobile site over the past year. So it's growing, it's coming, and it's not stopping anytime soon.


Another thing that we've been taking a look at is what devices have been visiting our mobile site. About half of them are iDevices of some flavor or another and another third are Android devices. This really helped us to figure out what was going to give us the most bang for our buck, what we were looking for to either develop mobile apps for and want to make sure that we're supporting all of these different browsers with our mobile site itself. We want to make sure that it looks OK on a text-only Blackberry in addition to looking nice on the latest iPhone.

To compare that with some of our main site statistics, we get about eight million visits a year on our main site with about two-and-a-half million unique visitors. Of all of that, the mobile traffic is a pretty small percentage of it. It started out in 2009 being, Google couldn't even figure out how much it was, to 2010, it was about 2% of the traffic, and last month it was about 5%. So it's doubling every year. And as it keeps going, I think it could easily be 10% or 15% of the traffic in the next couple of years.


Another really interesting fact is we were worried that maybe the new mobile site would take away mobile traffic to our main site, but it doesn't. It's actually the second-largest source of traffic after Google. So it's good to see that this content is relevant and it's also providing more references into the main site.

Doug Gapinski: Yeah, I think that last statistic is one to really pay attention to, because we led with that idea that you're still on the front end of mobile site development, but I think that acceleration is something to take note of. That's about a 50-fold increase over a period of two years in traffic. I think that number's really going to explode over the next five or 10 years. Now is really the time to be thinking about this.

Let's talk a little bit about content as it relates to mobile.


Based on our keynote speaker yesterday, I went ahead and pulled some of the mobile content guidelines on the W3C site. They lead with the strategic layer of what mobile content should look like.

Mobile page content should be suitable. So ensuring that your context and length is appropriate for smartphone. It should be clear, using clear and simple language, and using an appropriate length. A general rule of thumb that I found by looking around at some different sites is about 175 words is appropriate for a smartphone.

Also thinking about content as it relates to an app versus a site, a lot of the questions that we get from current clients still relate to this issue of, 'Should we dive into an app first or a site, or both?' The thing is, it doesn't have to be an 'either-or'. It could be a 'both'.


I would say that, generally speaking, you always want to lead with the site development. The reason is, doing the site first, what you're saying is you're acknowledging that people will likely investigate by launching the browser on their smartphone first. So rather than go out to the app store and seek your institution, they're probably just going to fire up their browser, look up the name of your institution, and go straight to your site.

But there are pros and cons to each, so we made this little neat matrix to take a look at that.

The pros of doing a site versus an app are that you get immediacy. You get no special download required. You get delivery for a transactional and timely content, like RSS feeds. And this is, again, probably the first place that the casual user is going to look for you on a tablet or device.

The cons to a site are you can't provide a robust interactive experience. You're limited to the phone's bandwidth. You're limited by the current network. If people are on Verizon or AT&T and you're in a remote location, maybe they can't get access to it at all.


And then, you've got to give them a reason to check back. A lot of the mobile sites that are being developed right now are very lightweight, so incorporating timely content is a way to give them a reason to come back and check on the site.

Why you would dive into an app is that you have much more robust interactive possibilities. We're going to take a look at something that Creative Services at William & Mary built in a second. The files are stored on the phone instead of downloaded by the browser. It's better suited for diehard users who are going to actively go out and seek the institution in an application store.

And on the cons, of course, there's a special download required. You have to develop the application for multiple platforms. So if instead of developing one set of HTML5, CSS3, you have to develop the application for multiple platforms. And then, the last lead, the casual user, such as maybe the new prospective student, is not as likely to go and seek you out and download an app.


Tiffany Broadbent: As Doug mentioned, our first foray into the actual mobile app was something called Dress the Griffin. One of our more famous alumni, Jon Stewart on the Daily Show, when he learned in 2010 that we had picked a new mascot and it was the Griffin, he decided to call it a "rare pantless, tailed eagle," so we decided that we would solve this pants problem by giving him a shirt and shoes and pants and swords and hats and all kinds of stuff like that.

Since we released this in February, we've had about 5,000 iOS downloads and over 2,500 Android downloads, which, when I first saw those stats, I was like, 'Oh, that's kind of sad. That's not really that many.' But considering that our active alumni and current student base is probably about 100,000 people, maybe a third of them have smartphones, to have 8% of those people downloading something actually turned out to be pretty good. So we were pleased with how this turned out.


Doug Gapinski: A great example of app development, because the user takes the time to download this and they get access to all of these different rich graphics and they can build all kinds of different combinations of outfits and locations. So not something that you can easily accomplish just by building on a site.

Tiffany Broadbent: But we did have to build it twice, which was, well, one of the downsides, as I mentioned before.

But back to the mobile site. When I first joined the Creative Services team, there was definitely a sense of urgency that we did want to have a mobile version of our site. We sat around the table, we all whipped out our mobile phones, and we're looking at our main site, we're like, 'Actually, this doesn't look all that bad. It doesn't horribly break or anything like that,' so if someone is really looking for a particular piece of information, they can find that on our main site. But we still wanted to have something offered that was optimized for mobile.


One of our team members, Tina Coleman, had just gone to a web managers' meeting at Gettysburg College and had heard about the work that Dave Olsen was doing with West Virginia University and the Mobile Web OSP. So that ultimately was what we decided to end up picking, and I'll tell you a little bit more about that in a minute.

To walk through the site a little bit, most of it is driven by RSS. I love RSS for this. It's perfect. It helps you keep updated content. You just set it and forget it and you're good. We have our News feeds, our Athletic feeds, our Alumni news are all fed through this, and they're constantly updated every three minutes.

And if the user wants, they can click on that and get the full story. We just give them a little snippet so they can decide if it's interesting or not, and if it is, then they can go and spend the extra time to go to the full site and see the full story.


Another thing that we wanted to really focus on was the branding content that we have. Our main website has a big photo banner right at the top, so we really wanted to focus on having photos as featured in our mobile site as well. We also wanted to focus on our student research that is our Ideation magazine, it's a research magazine that we publish every couple of months, so we wanted to bring those stories, again, from RSS.

And then the last is our student blogs that Mallory Wood mentioned yesterday morning, and those are really popular content. It's a really great way to help prospective students relate to the current students that we have and they've been a very popular bit of content, so we wanted to make sure that we're taking this well-established, well-received content and providing that on the mobile site.

Another thing that we have a lot of is social media stuff. We have YouTube, Twitter, Facebook, Foursquare are all linked on there, and we pull, again, through RSS, I'm a big fan of that, and people can see the latest photos that we have, the latest videos that we've had.


If we have an event going on, we'll stream those photos to Flickr and those photos end up straight on our mobile site. So if someone's just sitting around waiting for convocation to start, they can look at the photos of the graduate students walking in and stuff like that. It's a great way to keep the content really fresh.

Last but not least, there's some utilities that we've thrown in here. There's a map which you can search for any building on campus. You can search for services in this. You can't really quite see it, but it says 'Campus Post Office'. Some of the various cafeterias are all in this one place that you've picked and you can click and it will give you directions using Google Maps.

We have an 'About' section which is pretty much the only static content on the entire site. It's just a little blurb about William & Mary and then some links that go back to our main site for information about applying and some stats and rankings and things like that.

We also have our campus directory, so all the public information that you could find on a directory you can also find on the mobile site. If a student's looking for, 'Where is my professor's office?' 'What's his phone number?' they can look it up here.


And the last thing that we added, about a month ago, was search. It was actually kind of me being lazy, because I wanted to use search and I didn't want to go and I was on my mobile phone, so I decided, 'Well, it's a lot easier to just build it and skin it to be a mobile version rather than trying to go to the full site for this.' So I put it up there, and that's actually become a relatively popular little bit of content there, so I'm glad that we decided to do it.

Doug Gapinski: What you just saw was a great simple framework for a low-maintenance mobile site. Tiffany mentioned how much of that content is fed by RSS or social media platforms.

One of the other hot trends in mobile design right now is to do a responsive design, and what that means is you employing coding practices that scale down for a tablet or a smartphone. You're using media queries to detect the width of the browser and to reposition elements.


What you see on the left here is a great example of a site that launched recently, done internally by AgencyND, Notre Dame. These guys launched a great responsive design for the main Notre Dame site. If you look at the site on a tablet, it scales to the width of a tablet. If you look at it on a smartphone, it scales down as well.

Another example where you can see this responsive design in place is Loyola University Chicago, so that's They actually do it a little differently than Notre Dame.

If you look at it on your phone versus a desktop computer and then you check out the code, you're going to see that what Loyola does is they use JavaScript to detect the browser, and if it's mobile, there's a second set of JavaScript that fires, that turns off page elements like large images. So what it's saying is, 'I know that you're on iOS5' or 'I know that you're on Android. I'm going to turn off all of these heavy elements that are going to slow you down as you try to get to content.'


This is something that I really see as a content strategy issue, in the same way that Tiffany is saying we're going to try to provide the top utility, we're going to try to provide the top RSS content. In these examples, what you see is they're saying, 'We're going to provide you with exactly the same content on the mobile platform that you get on the desktop computer.' So this is a little different.

There is kind of a third strategy, and this is a project that we have in flight right now at mStoner for FIT, Fashion Institute of Technology, and that's a hybrid where you're setting up multiple publishing targets in the content management system.

What you'll notice if you compare FIT's mobile site to, which actually will be live in the next few months, but you can check out the presentation and see where we're going with this, it's the idea that we're borrowing a lot of the navigational elements from the main site and that we're configuring the CMS to publish a lot of the navigation elements and the content on pages to two targets.


Top to bottom on the mobile site compared to the regular site, you have a lot of the same things. You have a masthead, you have a task base navigation, you have audience gateways, and you have information for prospective students, the standard navigation for higher education about Academics, Admissions, Campus Life. And then we have niche interests for mobile audience at the bottom, so that's pieces like linking to the Museum at FIT, News and Events, Library, and then the Gallery.

The way that multiple publishing targets works is that they actually have two instances of the site set up, but open text is getting configured to publish assets to both the mobile site and to the main site.

So it's a way of getting, we set up a complicated system of galleries that they can tag with different tags in their main site and they said, 'We're such a visual place, we want to make sure that that transmits to the mobile device.' So we're configuring all of the galleries on mobiles to pick up the same assets from open text.


This is another site that's now live. This is This is one that we've recently helped Trinity College with. The thing I like about the content strategy for these guys is when we sat down with them, we looked at their main site architecture, we thought about several of the examples that are live in higher ed, and we said, 'What is the information that's most relevant to everybody?' so not just prospective students but current students and faculty.

And we created a new architecture that's based on finding places through that 'Campus' item, finding people, which is fed by PeopleSoft. They're a database for tracking faculty members. We have courses integrated with their Moodle system, so a prospective student can use that tab to check out what the offerings are in Anthropology, and that's all fed by Moodle that they've already built.


They can check out news in 'Trinity Today'. They can go straight to the 'Athletics' site. There's a little bit of investigative content in 'About' and 'Why Trinity?' And then, finally, to show alumni that they're valued, we created an 'Alumni' tab.

But you compare this to a typical site architecture for a main university site, this is the bare essentials. This is the information that's really most useful to the broadest audience, and I really like that part of it, simplifying it down to the bare minimum that's needed.

Let's talk a little bit about design in the mobile sphere. This, for me, when I was first getting into mobile last year, I was thinking about this as one of the best things that I was most excited about is a lot of the best practices for web design that you've already learned are the same for mobile. It's also HTML and CSS; it's just smaller. So a lot of the things that you know about containers and div tags, all that stuff applies.


Most universities and colleges are required by law to be compliant. Everything you know about color compliance still applies to the mobile.

And then the last thing, descriptive links begin or end every page. One of the things that you notice, more so outside of higher ed, is that the location of navigation varies. And higher ed typically is at the top, though. But you want to make sure that you consider that you either want to lead a page with navigation or you want to finish it. An example of finishing a page with navigation would be something like Yelp.

And then what to avoid. Some of the things that are a little bit different in mobile design.


Avoid very small clickable areas. Again, these practices are referenced to the W3 site, if you want to go and check out their principles of mobile design. Avoid very small clickable areas. About 30 to 40 pixels is what you need to approximate a human fingertip, and that's what you're going for in a mobile site design.

You want to avoid large images scaling down. If you have a large image that's being scaled by the browser, you're limiting the bandwidth of the phone.

And then finally, be ready to serve a text-only mode. If somebody does have one that in bandwidth that the site isn't loading properly, if you follow the best coding practices, your alt tags are going to load the right language to allow people to navigate the site.

Tiffany Broadbent: The way that William & Mary ended up approaching the mobile stuff was that we wanted it to really be a complement to our main site. As I've mentioned before, we've got the big photo at the top and we have some fun fonts and a lot of really graphical elements, so for the mobile version, we wanted to carry those through, the same colors, the tans and the grays and stuff.


We have some in-house designers that made some fantastic little graphics for us, and we also managed to pull in all of the photos from the news feeds and things like that to make sure that we could display those.

So people can get a feel that they are still on the same site. You don't want them to all of a sudden feel like they accidentally went to Yelp when really it's supposed to be your university site.

Doug Gapinski: Tiffany's idea there is really integrating with the main site and extending the brand into the mobile sphere, and I think for FIT, you can see where we're going with that.

The FIT site, we used a lot of dewy tones when we designed the main site to reflect this global urban brand, and we're translating that into the mobile sphere by picking up a JavaScript that randomly fires anytime somebody comes to the site and it will either pick up the purple, the blue, the green or the yellow. So just a really nice finish that relates it back to a prominent visual on the main site.


I think there's another thing to consider when you're designing, and that's always going for currency. You're dealing with rapidly-changing trends and design constantly, and one of the things that's hot right now is big type. It's all over the Web. And I think that trend happens to be particularly appropriate for mobile because you're creating big tags for people to click on, 40 pixels or larger, with large typography.

These two sites are not sites that mStoner worked on, but I thought they were great examples of sticking to that trend of keeping the type nice and big, really legible, really pops off of the page. That's University of Southern California and Oregon State, both great examples of that really current look in mobile.


Last piece of the design puzzle for me is always making sure that you're getting audience feedback, so not just relying on whims of, 'We think this is the right way to do it,' but putting this in front of audiences to say, 'We'll give you a few critical paths to follow. Show me how you're going to get there.' Getting open-ended feedback from them, putting the design in front of them and saying, 'What do you think of this? What do you like about it? What do you not like about it?'

And then lastly, comparative feedback. Putting your mobile site up against your peers, if they actually have one, and saying, 'What do you think of our site versus theirs? What do you like better about theirs? What do you like better about ours?'

And then just listening to audiences post-launch. As Tiffany would probably tell you, people always have comments about how things are working or not working, and just making sure that you carefully consider what people say about the mobile site after it goes live.


Another thing to consider is there's increased support for web fonts in the different operating systems. As of iOS 4.2, we're on 5 now, but as of 4.2, they added support for web fonts, and that represents such a great opportunity for design because all of the sudden you're not limited to Arial and Verdana. You can go with Ziggurat and these beautiful sophisticated different fonts.

Tiffany Broadbent: Now delving into the coding a little bit. Put the propeller hat on and go down 15 floors.

It's the same thing with coding as design. The best practices for coding carry through from the standard size to mobile. You just need to remember that you have a very small screen with very small bandwidth and very low processing power compared to a desktop machine.


The more code that you throw at this browser, the longer it's going to take for the person to download it, and the less enjoyable of an experience they have. If they have to wait 10 seconds for your page to download, they're going to be gone. They're going to go find somewhere else to look up the information.

So just to keep in mind, if you don't need it, don't add it. Don't add scripting if you don't have to, don't add gigantic CSS files if there's only two or three lines that you really need, and just make sure to keep it simple. It's one of those adages that you hear all the time.

Once you have cleaned up all of your files and made them as small as you think you can, have a tool like Yahoo!'s YSlow or Google's Page Speed to check it again, because there's usually something, you can optimize another image, you can compress another file and have stuff load even faster than before.

A couple little technical tricks. Something to always make sure you do with mobile sites is to use the viewport meta tag. You can definitely Google it and see all the proper syntax and things, but essentially it makes sure that it zooms all the way into your page when it's loaded in a mobile browser.


And it's not a little tiny thing that's way up in the corner that no one can read and then you have to double-tap and zoom. It just makes things a lot easier and it makes it look like this is what you're meant to be doing when you made the mobile site.

Another one is browser detection. You're going to be handling devices that are Blackberry that are just text-only all the way up to iOS5 with the mobile Safari, so you've got a range of support of graphics and CSS and scripting and all that kind of stuff and you can detect what kind of browser it is and serve up to them the appropriate content and give them the best experience that they can.

One fun thing in HTML 5 is something called 'form input types'. Normally you have 'input equals text'. Well, now instead of just text you can have a date, you can have a telephone number, you can have a URL or you can have an email address.


And when you do these on a mobile browser, if you tap in there to fill in your telephone number, it will pop up a virtual keyboard that just has numbers. It's that few, fewer clicks just makes the experience so much more pleasant for the user.

Another telephone-related one is, instead of linking to a web page, you can link to a telephone number, and if you click on that, it will open it up in your dialer on the mobile phone. So it's just one less thing that people have to copy and paste or try to remember the number and then mis-dial it and all that kind of stuff.

These four things are just fun little extra touches that really make the experience more pleasant for the user.

As I had mentioned before, we ended up with an open source product. One of the first ones that we've looked at was, MIT had released an open source product that was geared towards mobile sites, and it was one of the first ones that was really geared towards educational institutions.


The benefits with open source is it's free. If you have a developer that is comfortable enough with working with an open source product, this is the easiest way to get a mobile site online.

You can modify the code to suit your needs, and if you do, you can contribute it back. And it's a mutually beneficial project for everybody that works on it, that if you figured out something cool you can pass it on to somebody else, and they pass another interesting bit back to you. So I'm a big proponent of open source.

What we ended up deciding to use was actually Dave Olsen's Mobile Web OSP, which was a fork off of the original MIT branch. This had a bit more documentation, a little bit more of an active community. So if you're ever using open source stuff, the documentation is really important, unless the code is magically perfect, which never really happens especially in open source.


Within a day, in half a day, even, we had the site set up. Downloaded the code, set it up on a virtual host, and plugged in RSS feeds. And we could've launched that day if we wanted it to be blue and gray and stuff, but then we spent the other 90% of our time probably changing the design and updating the graphics and all that kind of stuff. But using the Mobile Web OSP is a great and pretty straightforward way to get something up quickly.

Doug Gapinski: Last resource, she mentioned Dave Olsen, the developer who created Mobile Web OSP several times. He has a blog, it's, and it's probably one of the best resources for mobile knowledge in higher ed right now. That is definitely something that we would recommend checking out and bookmarking. He's done a lot of surveys. It's just really great content about mobile development in higher ed.


Tiffany Broadbent: Now into the Google Analytics a little bit. They recently added another visitor view that is mobile, which is, it will tell you it's an iOS device, or it's an iPhone actually, or it's an iPad or an Android device, and so it's a great way to really get a quick insight into what's going on.

And it was a good way for us, as I mentioned before, to determine that we really should make sure that we have Blackberry covered in addition to an iPhone and an Android, and it also helped us to realize that when we developed our mobile app that we needed to have both Android and iOS because we'd be alienating a third of our user base if we didn't present an Android device.

Another thing was measuring the different traffic sources. What was the most popular content? We realized that Athletics was quite a popular one and it would spike like crazy on game days, especially for football. So we wanted to sit there, and I think, before, we just had the news feed from the Athletics website, so it was recaps of the games and what was coming up next, but we realized that people were probably going on game days to find out what the score was.


The Athletics Department has a Twitter feed which does do live updates for games, so we interleaved the Twitter feed with the RSS from their news site. In that way, you get some context for previous games and you're getting live updates while you're sitting there at work, or maybe not at work, watching the game.

Looking at the analytics and looking at what the most popular content really helps you decide, 'OK, we can probably pull this back off of one of the prominent spots on the page,' or 'We need to add something else to this to make it more relevant to the user.'

Doug Gapinski: I think this was one of the pieces of data that fascinated me the most, because if you look at where people are going on the main William & Mary site versus where they're going on the mobile site, it's totally different, and I think that, to me, is possibly an argument against the responsive design approach, because the responsive design simply resizes the main site.


And what this data suggests from William & Mary is that people use those two different things, the desktop site and the mobile site, in a completely different way. People are not going to investigate a content as much on the mobile site. They're sticking to that transactional  content of finding a place or finding a person, whereas on the main site, about 30% of the hits are to investigative content.

So I think that is a good argument for doing a custom mobile site that you direct people to, because the data suggests that people would use it completely differently than when they use your main site.

Tiffany Broadbent: Another thing to support this was, recently we added some 'Special Event' buttons, so it was for orientation, for commencement, for homecoming that we had last weekend. And that has been the most popular content that we've had on the site. It's had the most traffic and it just emphasizes that people are looking for relevant information to their current situation.


On Moving Day, it was a Friday, we had five times the normal traffic that we would normally have on our mobile site. And of that traffic, most of it was looking at event schedules. It was parents going, 'Oh, my gosh, where am I supposed to be? Where is my kid supposed to be at two o'clock?' So being able to present that relevant information to them right when they needed it and not having to look through their PDF or finding that sheet of paper that got buried under their kid's clothes when they were moving in is a real benefit that mobile offers over a regular website.

A couple little interesting things were, social media didn't really do so well. It was less than 5% of our traffic. When we needed to add buttons to our homepage, it had been that each social media got their own button on the homepage. We consolidated all of those down and put them behind one additional layer, so they were sacrificed a little bit.

But I think the reason for that is people already have Facebook on their phones, they already have Twitter on their phones. They're not going to go to your website to find your Twitter to then read your Twitter feed. They're going to go to Twitter to read your Twitter feed. So we weren't too worried about that. It was a little bit disappointing, but we still have lots of engagement on social media, so it was OK.


Another interesting one was where the traffic came from for us. Just looking at the on-campus network, about a third of the traffic usually goes for the main site is about a third of the normal traffic. So it's students and faculty, everybody looking at our main site.

But for mobile traffic, it was only 11%, which gives us a good indication that it's people that don't have access to our wireless network. So it's parents, it's tourists from Colonial Williamsburg that's nearby, it's prospective students. So realizing that we have a significantly bigger audience for our mobile site than our main site is just another way that would help you shape the content that you have there.

And then one of the things that I learned recently was that where your mobile phone says it is according to its IP addresses is not necessarily really where it's from.


I was sitting in my office at William & Mary, so I was in Williamsburg, Virginia, and there were a couple of sites out there that will tell you what your IP address is and where it's supposed to be located. It said I was 150 miles north in Alexandria, Virginia, so, not quite accurate.

So you need to take a lot of the Google Analytics location stuff with a grain of salt. Just remember that it's not really necessarily 14% of your mobile traffic is coming from the city. It might actually be significantly more, it might be significantly less. But you just have to keep that in mind.

For us, the next step is releasing mobile sites for all of our graduate schools. We're using the same Mobile Web OSP stuff and the same framework that we've set up before. We're just styling it a little bit differently and having it be a custom style for each one, which, the benefit of CSS, all we're doing is tweaking the style sheets, so it's great.

Doug Gapinski: Well, this about wraps it up. We have a couple of minutes for questions, but I think the closing thought for me comes back to that idea of only about 9% of institutions in higher and secondary education have mobile sites.


That really means that you guys are the future. You're here, you're interested in this. I'm excited to see what happens with this. And I would love to hear stories. So if you guys have launched a successful mobile site, please come up and talk to me afterwards. Or if you're planning it over the next year, I'd just love to hear how it goes.

Again, you can download this presentation. We had a lot of links running along the bottoms of the slides with the visual examples. That's the URL to download it. If you want to comment, I'm sure some of you were tweeting us, hopefully all good, but the back channel again is right there for the conference and for this track. And then there's our personal information. If you prefer phone, just come up and talk to us afterwards.

Tiffany Broadbent: I think we have a few minutes for questions, if anybody has one.


Audience 1: Early on, you showed the Notre Dame and the Loyola websites, and you mentioned that on the Loyola one, they were running JavaScript to hide elements that are heavy. Well, they would still have to download those elements for the JavaScript, though, wouldn't they?

Tiffany Broadbent: Yeah. It's still a little bit heavyweight, but when you're using JavaScript, it's just not something you can avoid because it has to be client side.

Audience 1: Right. And Tiffany, you mentioned that on your main homepage, you're doing automatic redirect to your mobile site?

Tiffany Broadbent: Right.

Audience 1: What criteria do you use to do that? And how do you handle a smartphone user that comes to visit your main pages?

Tiffany Broadbent: We have the browser detection going, so if it says that it's an iPhone or an Android device, then that's when we determine when we're going to send it.

And anybody that just goes to the main homepage, if it's '/anything else', they go straight to that page on our main site, but if it's only direct homepage traffic, we send them to the mobile site first. But there's a link that they can just go back to the main site if they want.


Audience 1: So, like, on an iPad, you can't go directly to your homepage?

Tiffany Broadbent: On the iPad, we don't do the mobile redirect at all. It's not considered a mobile device as much because it has a significantly bigger screen and stuff like that.

Audience 1: So that's why I was wondering what the criteria is, because that's the same, unless detection would kick that, too.

Tiffany Broadbent: With the browser detection, it will say that it's an iPad or not. I don't remember exactly what the technical criteria is, but we can determine if it's iPad versus not. There's code in the Mobile Web OSP that helps you out with that.

Doug Gapinski: The second part of that is the usability thing. Most mobile sites that we're designing now, we've put a 'Full Site' button prominent either at the top or the bottom, because some people do want to opt out and they want to get to content that they know how to get to on the main site. So the 'Full Site' button is a way to offer users an opportunity to opt out.

Audience 2: We're kind of still debating on that, trying to figure a way around on what detects that device, still keep you on that page but then provide a prominent button that wouldn't otherwise deploy?


Tiffany Broadbent: Right.

Audience 2: You over there, it's just a matter of preferences.

Tiffany Broadbent: Anybody else?

Audience 3: If someone lands on an internal page, would they see those style sheets?

Tiffany Broadbent: Not yet. We're working on it.

Doug Gapinski: That's kind of a newer approach that we are starting to do is the conditional style sheet. Because in a framework like the William & Mary site or the Trinity site, past about the fourth level you are usually pointing people to content that's on the main site with the 'Back' button. So you want a conditional catch-all style sheet that's going to render content from the main site in the same kind of style as the mobile device.

Did that make sense?

Audience 3: Yes.

Tiffany Broadbent: All the way in the back?

Audience 4: How do you survey your alumni at all about usage of mobile devices? And second, do you plan to at all integrate with, you have an alumni community that has log-in sort of features and to integrate those two together?


Tiffany Broadbent: We have an 'Alumni' button that's just the RSS feed from the Alumni site itself. They're a total separate entity from us. They have an app that, it is an iOS app, that's 'my1693', that is specific content just for alumni. We don't do anything else with that.

We haven't done any surveys of what the alumni think yet of the mobile site, but I'm sure that would be very interesting because they have lots to say.

Audience 4: Just a follow-up, you're OK with multiple apps getting developed for different purposes across the university?

Tiffany Broadbent: In cases where it's appropriate. That's sort of an evasive answer, but for the 'my1693' thing, it's a log-in-based thing where they can see things that are just very specific to the Alumni Association, whereas if it was just general content that maybe we could just pull into the site, then we'd be happy to do that and would love to have more rich content that's just available not behind a log-in.


Audience 5: The search tool that you just recently added, is that search mobile content?

Tiffany Broadbent: It searches the main website, which is the source of all of our mobile content. It's just the Google custom search skinned prettily. It's another fast tool for doing the search.

Audience 6: On the map side of things, are you using Geolocation services in it so that it locates where you are?

Tiffany Broadbent: We're not right now. The link that takes you to Google Maps, it passes along what the address is of the building that you were looking at and the name of it, and then you can use, from Google Maps, just utilize the stuff that they've already built that has some Geolocation stuff in it to help them find what they're looking for.

Anybody else?

Doug Gapinski: OK, guys. Thanks a lot. I really appreciate your time.

Tiffany Broadbent: Thanks.