Developing a Progressive Mobile Strategy (J. Boye edition)

Editor's Notes

• #2: \n
• #3: This presentation is already available on SlideShare at the address shown here. My entire script for the talk is included as notes for each slide. So all the numbers and anything else I mention is on slideshare.\n
• #4: Again, my name is Dave Olsen and for the last eight and a half years I've worked at West Virginia University as a programmer and sometimes project manager. I work in the web unit of University Relations. So that's a technical unit within our marketing and communications group. I've been working on mobile websites for the last two years and those include not only our main site m.wvu.edu but quite a few marketing focused mobile websites. For scale to compare against your institution WVU is a land grand university with 32,0000 students.\n
• #5: I want to be clear, this is a talk about strategy and as such it’s coming from a very 30,000 foot level…\n\n
• #6: …and I’m distilling two years of experience watching mobile grow on our campus. So I won’t be diving too much into implementation details but if you have questions feel free to interrupt me.\n
• #7: So what will I be talking about today... I’m going to start off by reviewing some terms I use in the presentation that folks might not be familiar with, then some reasons why you would want to think about pursuing a mobile strategy for your institution, followed by the meat of the presentation where we'll discuss how I think you should lay out your strategy, and then, lastly, some tools you can use to pursue that strategy.\n
• #8: So the glossary of terms…\n
• #9: “Native apps” tends to be the most confusing term that I use with clients. Everyone wants one and they don’t necessarily see the difference between an app and a mobile website. A native app is an application developed to run natively on the targeted device. Usually written in a device specific language like Objective-C or Java. The simplest way to think about it is if you can go to the iTunes store or the Android Marketplace and download an application from there it’s a native app.\n
• #10: \n
• #11: Mobile web refers to browser-based access to the internet from mobile devices. It may be more correct to refer to it as the mobile-optimized web. And the desktop web is just my way of referring to non-mobile-friendly sites. \n
• #12: \n
• #13: \n
• #14: a layout engine that powers a number of popular mobile browsers including Mobile Safari. In the same way that we have different versions of internet explorer there are different versions of WebKit. They’re not all created equal.\n
• #15: With the definitions out of the way let's look at why you'd want to pursue a mobile strategy for your campus. \n
• #16: According to the Pew Internet and American Life Project, in May 2010, 65% of mobile users in the 18-29 demographic, part of the demographic we target, reported that they had used the mobile internet. \n
• #17: According to the E-Expectations report from Noel Levitz that came out in July of last year, 23% of prospects had searched a college site from a mobile device. I’m not positive how much stock I put in that number since I don’t know how they were classifying mobile devices but it’s still pretty staggering.\n
• #18: And, finally, according to Comscore roughly 30% of Americans owned smartphones at the end of October 2010. That’s up from 18% the year previous. The kicker, by the start of 2012, 6 short months away, half of the US population is forecasted to be using smartphones.\n
• #19: \n
• #20: \n
• #21: The very first thing I stress? That there’s a difference between a strategy and a tactic and that what they’re looking for is really a strategy to deal with mobile.\n
• #22: So that app you want? \n\n
• #23: Yeah, not a strategy. Possibly a tactic but definitely not a strategy.\n
• #24: Ok, so how ‘bout we add a mobile website to the mix. We’ll have all devices mostly covered with the website and then we have the slick iphone app. So that's a strategy, right? \n\n
• #25: Unfortunately, no. You can see that coming, right? You’re a smart bunch.\n
• #26: \n
• #27: \n
• #28: And remember all that content that we already have out there that Google and the other search engines have already indexed for us to give to that user when they search to get the answer to their urgent need? And the user probably already knows it’s out there?\n\nSo that’s reason #1.\n
• #29: So how has mobile grown on our campus and what kind of technologies have we implemented. Well, it started in August 2009 with the launch of a student-developed iPhone app, iWVU, as well as our mobile portal built with the original MIT mobile framework. Both offer central services like campus calendar, campus map, and directory. \n
• #30: …from there we added device detection & mobile template support to our in-house CMS,\n
• #31: we’ve rolled out marketing efforts, like our Big East tournaments projects, that include mobile components and have been great test-beds for pushing our technical expertise. \n
• #32: And, finally, our designers are starting to also use responsive design for departmental websites. \n\nSo with all that experience, our very public embrace of mobile for our campus, and a modicum of success we’re hearing from more and more groups on our campus who are interested in mobile. And the following sums up our initial interactions…\n
• #33: Here is the semester-to-semester growth in traffic. I've left out summer just because it's an obvious lagging metric and I don't have another summer semester to compare against. It’s pretty obvious from these numbers that more and more users are accessing our content with mobile devices. To me, more page views equals more devices. \n
• #34: There are a lot of options out there. Maybe an app or mobile website does fit. Maybe more than one solution fits. Just look at our school, we already have a lot out there and we’re barely scratching the surface. \n
• #35: So if that’s what we, as institutions, will grow into or become how do we get there, with all that stuff, from here, where we’re basically starting at nothing. So with that it’s time to introduce…\n
• #36: …a progressive mobile strategy. And I think their are three words that sort of sum up what a progressive mobile strategy means and helps get our clients on board.\n
• #37: The first is prioritize. There may be a lot of things that they want to accomplish, and we can work towards that, but we want them to understand what mobile really means and make sure we’re tackling the correct problems first.\n
• #38: The second is iterate. Again, we can implement, evaluate, and either clean up what we had previously, change the next priority or move onto the next priority.\n
• #39: And third, like the swiss, we should try to stay neutral. And what that means is we shouldn’t let tech be our focus.\n
• #40: Summing it up...\n
• #41: And to bludgeon this point to death. We want to approach mobile with small bites. Focus on one topic/task/site whatever, implement that, and go after the next topic/task/site. Small bites and iteration are very important. There’s a ton to learn.\n
• #42: So a progressive mobile strategy consists of three parts.\n
• #43: First, an audience strategy, meaning which audiences you’ll focus on first, what we know about them and their use cases. So the audience then, in turn, helps define and inform…\n
• #44: …a content strategy. Basically, which bits of content will you focus on first to deliver to that audience based on the use cases. And once those two things are out of the way we’ll look at…\n
• #45: …a platform strategy, which focuses on the underlying technology and tactics, e.g. mobile web and native apps, to properly deliver the content that you’ve selected for your audience.\n
• #46: This is probably a decent way to think of the strategy from a graphic perspective.\n
• #47: Ok, so the first thing we have to understand as we develop our strategy is our audience. Or audiences.\n\n
• #48: Now in higher ed we seem to have some pretty well-defined audiences. \n
• #49: Now in higher ed we seem to have some pretty well-defined audiences. \n
• #50: Now those audiences definitely exist in mobile but we can flesh them out a little bit more based on what we know about mobile-device using users. And that’s an important distinction to make. \n
• #51: When Google evaluates a new mobile application one of the first things they evaluate it against are these three classes of users and tries to see how it fits in.\n
• #52: The "repetitive now" user is someone checking for the same piece of information over and over again, like checking the same stock quotes or weather. \n
• #53: The "bored now" are users who have time on their hands. People on trains or waiting in airports or sitting in cafes. Mobile users in this behavior group look a lot more like casual Web surfers without much user input since mobile devices still suck at that. \n
• #54: And The "urgent now" is a request to find something specific fast, like the location of a bakery or directions to the airport.\n
• #55: I would argue, without almost any supporting evidence, that most of our users or rather the main users we should be catering to in higher ed fall into the "urgent now" category. Or, rather, that as we use our tradition audiences we should stick “with an urgent need” after it. \n
• #56: For example, “current student… urgent.” That’s what I mean about constraining users.\n\nWhy only urgent? The only content we have that fits into "bored now" content are press releases and someone has to be very bored to read those. News & YouTube are some of our worst performing sections. Actually, they are. And we don't have a ton of repetitive content. \n
• #57: this sums up just some of the questions a current student may have “in the moment” and attempt to address from their mobile device.\n
• #58: Along with those activities our users are likely to take we can actually think about location with mobile when defining them. According to Google's report "The Mobile Movement," released in April of this year, 95% of users who were using Google search were looking for local content. So, beyond need, this notion of needing content for my general vicinity becomes a constraint. So if you’re thinking alumni think visiting alumni. \n
• #59: In the same report 88% of smartphone users reported that they took action on their internet searches within a day. Actually, the same day of the search. So there is this compressed timeframe that people have when looking for content. These audiences are trying to do tasks that make sense in the short term. I guess this sort of reinforces that “urgent now” constraint.\n
• #60: And a quick, interesting point that I found. 61% of folks made a phone call. This is one of those easy, go back to the office and make a quick change to make your content more mobile friendly and useful. Add that telephone numbers clickable with tel:.\n
• #61: And lastly, the sort of standard comment about context and mobile audiences is that they’re out and about and it turns out that that isn’t the true. 30% surf from their couch while watching TV and the vast majority of users have at least used it from the home. Mobile isn’t so much about on-the-go as it is about physical limitations in the device size, network limitations, and “access whenever you need it.”\n
• #62: \n
• #63: So to quickly review, when identifying and prioritizing your audiences…\n
• #64: focus on those with urgent needs like those I mentioned earlier. \n
• #65: Focus on your local constituencies before external audiences with one exception that I’ll get to in a little bit. \n
• #66: focus on needs that address really short-term activities.\n
• #67: and, finally, don’t fall into the trap of thinking your audience has to be out and about or even will be out and about when accessing content. It helps but it’s not required.\n
• #68: The next part of developing a progressive mobile strategy is the content strategy. Now that we know who we might engage with and what they might be looking for based on their circumstances or those constraints we reviewed we can figure out what they want access too…\n
• #69: Users have a specific task they want to accomplish, and frankly I think this view bleeds over to your regular website, and your mobile tools and tech has to reflect those tasks a user wants to accomplish. Finding a departments phone number easily totally outweighs reading the message from the dean. Make your content match those questions.\n
• #70: This is a nice representation of content delivery, which i might think of more as bullshit content delivery, versus content that is actually useful to users. Hat tip to Steve Lewis for the suggestion on the inclusion of this graphic for properly showing the difference.\n
• #71: Use this as an opportunity to create rather than just simply converting. Developing a mobile solution isn’t about just converting your home page with all of its politically dictated myriad of links or, say, your president’s message and making that available to mobile users in some slimmed down method. It’s really about creating a whole new organization and interface for services that make sense for mobile use. Even in a smaller form factor there are a lot of opportunities that will open for you.\n
• #72: The best mobile solutions are going to be the ones that stress user needs above those of the org (within reason). Combining data and services should be done in a way that makes sense to the user as opposed to how they fit into the org.\n
• #73: be able to answer the question, “What value will they gain from your content & services?“ I think that’s always the hope with any type of content be it mobile- or desktop-focused.\n
• #74: So now we’re hitting the part where everyone, including me frankly, wants to start. But once you got the other two parts done, well, once you have them done in an ideal world, you can then match up platform strategy to properly implement what your audience needs and what your content supplies.\n
• #75: So now we’re down to it, which comes first? Native or mobile web?\n\n
• #76: The unfortunate thing for you is that issue is already dead. \n
• #77: The question is no longer “Which, between mobile web or native, do we develop for?” \n
• #78: It’s “How do we develop solutions to handle both mobile web and native now and of the future that deliver the content our users are expecting?” I think we’re already headed into the second phase of mobile development in higher ed. Maybe we’ll call it mobile dev 2.0. It’s the acceptance of the fact that there are going to be a lot of different solutions.\n
• #79: There are a lot of options out there. Maybe an app or mobile website does fit. Maybe more than one solution fits. Just look at our school, we already have a lot out there and we’re barely scratching the surface. \n
• #80: In an absolute ideal world your implementation of your campus' mobile platform strategy would probably follow a trend like this. And, yes, I’m completely embarrassed by this graphic.\n
• #81: \nWe'd start with the building blocks for a flexible strategy by developing APIs. \n\n\n
• #82: Then we'd build our mobile web solutions on top of these APIs to deliver information to as many devices as possible using the tools & techniques that your staff are familiar with or, at the very least, their shouldn’t to terribly much of a learning curve.\n\nAnd note that there is even a progressive path through mobile web starting with adaptive design at the bottom through to… \n \n…mobile portals with lots of interactivity & content all designed specifically for a mobile device and using device detection to modify the look server-side making it really adaptable to the client requesting the site. \n\n
• #83: Then we could focus on native solutions to refine and provide the best quality solutions on a per operating system basis. And native apps would leverage the API as well. \n
• #84: So, in a nutshell, that's the ideal platform strategy for an institution in my opinion. Even if it’s a little ugly looking. So let’s start with the core and base part of the platform strategy, the APIs.\n\n
• #85: APIs are the infrastructure we need to create, the plumbing or the highways as it were, that will not only handle mobile but any future content-delivery format needs we have. Say, TVs or digital signage for example? At the end of the day, APIs allow us to create once and publish everywhere. I can’t stress enough how important APIs will be to your institution in terms of delivering viable, maintainable, and useful mobile solutions.\n
• #86: So a quick example of how we're using APIs at WVU for our PRT system. WVU is split into three campuses and to connect them we have this little tram system, the PRT, which students can take to get from one campus to another. It was built in the 60s and, unfortunately, it's showing it's age. It'll break down every now and then. Now, in the past, a student only learned that the PRT was down by going to the station. Based on a student idea we worked with the PRT folks to gather that data to display on our mobile website. So we created an API for it. Transportation folks update it in one spot and, via JSON & XML it gets published to all of these locations instantly. And if we need to bring in another site or digital signage we just point it at the JSON or XML feed and we’re good to go. \n\n
• #87: Obviously that's the ideal and that's not going to be the way most schools work right from the get go. We certainly didn't. That being said, learn from our experience it's much tougher to retrofit APIs to these kind of things than it is to just know you have to do that from the start.\n\nOnce we move from APIs and look at the next step in our platform strategy, which, for me, is mobile web. I know I said earlier that a platform strategy wasn’t an either/or but you have to start somewhere. It just happens to start in the place that I happen to value, mobile web.\n
• #88: As I noted earlier there is actually a progressive strategy for mobile web as well moving from adaptive designs to CMS-based mobile templates and finally to standalone mobile sites. \n
• #89: As I noted earlier there is actually a progressive strategy for mobile web as well moving from adaptive designs to CMS-based mobile templates and finally to standalone mobile sites. \n
• #90: As I noted earlier there is actually a progressive strategy for mobile web as well moving from adaptive designs to CMS-based mobile templates and finally to standalone mobile sites. \n
• #91: As I noted earlier there is actually a progressive strategy for mobile web as well moving from adaptive designs to CMS-based mobile templates and finally to standalone mobile sites. \n
• #92: \n
• #93: As I noted earlier there is actually a progressive strategy for mobile web as well moving from adaptive designs to CMS-based mobile templates and finally to standalone mobile sites. \n
• #94: \n
• #95: So then the next step in a mobile platform are native apps. Again, these are the apps you’re going to download through the iTunes Store or Android Marketplace.\nI’m not naïve enough to think that mobile web can handle every need a school will have. \n
• #96: Frankly, vendors for systems like your learning management system are going to be the ones to bring native apps to your school. Or at least the most likely avenue for that. You may also have an opportunity to bring this kind of work in-house but I have a feeling that vendors will drive native app adoption at schools. \n\n
• #97: The other place I see native apps being leveraged more than mobile web are in the absolute, bleeding edge cases for transforming how business is done on campus. More revolutionary than evolutionary. A decent example of this might be replacing student Ids with mobile devices equipped with near field communications or NFC technology.\n\n
• #98: So that’s our mobile platform strategy that’s a part of our larger progressive mobile strategy. Start working on or planning to work on your infrastructure now. So read that as APIs. We already have a lot of content that has been crawled by search engines and users will be looking for it. There is no right mobile solution platform-wise for higher ed. You’re going to end up using all of them.\n
• #99: So I guess I should make the case for mobile web first and I think I have two pretty good reasons. And, again, this isn’t an argument for a standalone mobile website, this is an argument for anyone of the viable mobile web solutions I just reviewed.\n
• #100: One thing that I think gets overlooked when developing mobile solutions is understanding how users actually discover our offerings and service and what drives them.\n
• #101: \n
• #102: \n
• #103: \n
• #104: \n
• #105: \n
• #106: \n
• #107: \n
• #108: \n
• #109: \n
• #110: \n
• #111: \n
• #112: \n
• #113: Ok, so to wrap all of this up we’ll go through a quick example…\n
• #114: \n
• #115: \n
• #116: \n
• #117: \n
• #118: I couldn’t come up with a decent way to lay this out but... the notion is to prioritize audiences you want to deliver to in the left column. Then the types of content that make sense to them based on what we learned about audience. And then, finally, figure out what type of platform best fits that content to maeks ure we propersly deliver it.\n
• #119: I couldn’t come up with a decent way to lay this out but... the notion is to prioritize audiences you want to deliver to in the left column. Then the types of content that make sense to them based on what we learned about audience. And then, finally, figure out what type of platform best fits that content to maeks ure we propersly deliver it.\n
• #120: I couldn’t come up with a decent way to lay this out but... the notion is to prioritize audiences you want to deliver to in the left column. Then the types of content that make sense to them based on what we learned about audience. And then, finally, figure out what type of platform best fits that content to maeks ure we propersly deliver it.\n
• #121: \n
• #122: \n
• #123: \n
• #124: \n
• #125: \n
• #126: \n
• #127: thanks\n