Developing a Progressive Mobile Strategy (BDConf Version)

Editor's Notes

• #2: Thanks for the introduction. So today I'll be presenting on developing a progressive mobile strategy for your institution... \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 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
• #8: …from there we added device detection & mobile template support to our in-house CMS,\n
• #9: 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
• #10: 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
• #11: We need an app. Quickly followed by my terse response…\n\n
• #12: So my first response to this question tends to be “Why?” For anyone who has to field this particular question from clients their reasons should be familiar…\n\n
• #13: Reason #1 is “Marketing.” There is this idea that an app is simply an extension of their website and people will browse, find it, and check it out. \n\n
• #14: Reason #2 can probably be summed up as “App Envy” or even pre-emptive “app envy.” Can we be first to market and make a splash? And to be fair, I’ve used this reasoning myself for things. \n
• #15: And the last reason? Nothing. It’s silence or, since I couldn’t really have a photo of silence, crickets. Basically, they didn’t really think about the implications of an app outside of wanting one.\n\n
• #16: But once the ice is broken on mobile with this question, and this is the part that I really enjoy when talking to clients, when can educate, and frankly should educate, our clients on what mobile really means. \n\n
• #17: \n
• #18: 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
• #19: So that app you want? \n\n
• #20: Yeah, not a strategy. Possibly a tactic but definitely not a strategy.\n
• #21: 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
• #22: Unfortunately, no. You can see that coming, right? You’re a smart bunch.\n
• #23: 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
• #24: 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
• #25: …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
• #26: 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
• #27: 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
• #28: 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
• #29: Summing it up...\n
• #30: So a progressive mobile strategy consists of three parts.\n
• #31: 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
• #32: …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
• #33: …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
• #34: This is probably a decent way to think of the strategy from a graphic perspective.\n
• #35: Ok, so the first thing we have to understand as we develop our strategy is our audience. Or audiences.\n\n
• #36: Now in higher ed we seem to have some pretty well-defined audiences. \n
• #37: 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
• #38: 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
• #39: 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
• #40: 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
• #41: And The "urgent now" is a request to find something specific fast, like the location of a bakery or directions to the airport.\n
• #42: 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
• #43: 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
• #44: 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
• #45: 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
• #46: 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
• #47: 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
• #48: 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
• #49: So to quickly review, when identifying and prioritizing your audiences…\n
• #50: focus on those with urgent needs like those I mentioned earlier. \n
• #51: Focus on your local constituencies before external audiences with one exception that I’ll get to in a little bit. \n
• #52: focus on needs that address really short-term activities.\n
• #53: 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
• #54: 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
• #55: 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
• #56: 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
• #57: 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
• #58: 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
• #59: Do not underestimate the use of location data and how that can be combined with other resources. And specifically I’m talking about campus map data as it relates to something like events. All those relationships become really important and useful. This is one area we’re really focused on. As well as personalization.\n
• #60: 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
• #61: 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
• #62: So now we’re down to it, which comes first? Native or mobile web?\n\n
• #63: The unfortunate thing for you is that issue is already dead. \n
• #64: The question is no longer “Which, between mobile web or native, do we develop for?” \n
• #65: 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
• #66: 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
• #67: \nWe'd start with the building blocks for a flexible strategy by developing APIs. \n\n\n
• #68: 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
• #69: 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
• #70: 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
• #71: 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
• #72: 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
• #73: 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
• #74: 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
• #75: 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
• #76: 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
• #77: This quote is from Jason Grigsby, one of the two guys who led President Obama's 2008 election iPhone app. It hits on the first killer feature of mobile devices and why mobile web comes first because of that feature. \n\nIn that moment of urgent need where will a user turn? Assuming they don't already have your apps, and that’s plural because one app will never be able to handle all your use cases, the user will use their browser to get to the resources they're used to accessing on the desktop. They’re already familiar with the fact that we have that content out there on the web. \n\n
• #78: And a little more support for that anecdotal evidence though… According to Google's report "The Mobile Movement" released in April of this year 77% of smartphone users reported visiting search engine websites. They are the most visited type of website by mobile users.\n
• #79: Remember our urgent users? Think they might go to use search in the heat of the moment in their browser that’s included on the device?\n
• #80: 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
• #81: The second quality quote from Jason is, “Links don’t open apps.”\n
• #82: Does your school send out HTML emails with links to your content? Maybe to prospective students? Ever consider they might try to visit that content from a mobile device? Well, 55% of users with internet-enabled phones check their personal email on them.\n
• #83: Is social media a big component of your marketing efforts. Social networking sites are way up there in terms of use from a mobile device. Those links you share on Facebook or Twitter may have a decent likelihood of being opened on a mobile device.\n
• #84: So combining the browser, especially with it’s all important search box, to the built-in email client and links you might send you can see why it’s so important to provide mobile web-optimized content.\n
• #85: 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
• #86: 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
• #87: 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
• #88: Ok, so to wrap all of this up we’ll go through a quick example…\n
• #89: \n
• #90: \n
• #91: \n
• #92: \n
• #93: 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
• #94: 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
• #95: 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
• #96: \n
• #97: \n
• #98: \n
• #99: \n
• #100: \n
• #101: \n
• #102: thanks\n