TNT10: A Utility Belt Approach to Mobilized Content

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

Doug Beck: My name is Doug. This is Roger.

[Laughter]

Doug Beck: He's my Project Manager. Sorry, this slide's wrong.

[Laughter]

Doug Beck: Yeah, there it is.

Roger Wolf: Quit messing around.

All right, here's the thing. We're really serious about content. Both of us are really working on the IT side, but the content is really essential, and we're going to talk pretty seriously about generating good content that all of the IT projects that we're working on, the Web, mobile, apps, anything, at its root, at its lifeblood, is the content. That's what people really want.

The delivery mechanism is just a gadget. It's just a tool. We really want to get at good content, shaping that good content, and preparing ourselves for not just mobile, not just apps, not iPads, not tablets, but whatever is coming next.

Especially for the content generators, we're asking a lot from you. We're asking you to really take a look at the content, cut it, omit, edit, get it down to its very core, and then we'll work with you to try and store it and put it together in a presentation mode that will deliver it out to any number of devices and be used all over the place. So this is really at the core of more than mobile.

We work for Strategy, Marketing Communications & Admissions. This division is important in relation to understanding exactly how we came up with this approach and why we think it works.

UCF is huge. If anyone is here from Arizona State or Ohio State, they're the only two schools that are really the same size as we are. We're about 58,000 students. A lot of students. About 4,000 faculty, staff.

The number of people we're talking about, the scale of what we're operating on when it comes to an IT project, when it comes to a marketing endeavor, it's pretty huge. So when we have problems, we have big problems, and we try to solve them with solid solutions that will work over and over again so that we don't have to continue to revisit problems.

We hope that some of the wounds that we've gotten in this fight will help you guys get along and find easier ways to deal with your IT people, your content, and get it out to users, because that's what this is really about.

If you get nothing else from this presentation, please remember these things:

Mobile is for the users. Not for your boss, not for you, not for the board of trustees. It's for the users. If you can get the content into their hands, they will use it. And they will be happy.

Master the content first, worry about the technology later. The technology is going to continue to change and grow, but at the end of the day, we're talking about words, pictures, some very limited medium, and you really want to get great at that first. And then have somebody come up with a technology solution that delivers that.

Create legendary data sources. Doug is going to help you with that and he's going to talk from the IT side about how you can take content and put it together into a publicly available data source that can be used any number of ways.

Never give up. This is a fight, and it's a long fight. And if you ever feel like giving up and you're tired of working with IT, give us a call. We promise we will help you through it and find some silver lining that makes this worthwhile. And if nothing else, refer back to Point 1. It's for the users; do it for them, if for nothing else.

Once upon a time, Doug and I both worked for central IT. We were cubicle jockeys. We worked in the big machine that's infrastructure, that's coding, that's really just getting at keeping the machine moving.

I was a project manager. I got the call about 2009, there was a lot of stuff going on. I don't know if any of you, there was an article that came out about Dave Olsen. West Virginia University had put together a mobile site in 19 days. He really got at the core of just getting mobile done, and it sparked a lot of conversations on the IT side about how we really weren't doing that.

We're a young university. We like to be energetic, we like to be bold. Being trumped by West Virginia University, by other universities, wasn't something we really liked. We thought, 'We can do this! We're smart, we're young, we're moving fast. Let's do this!'

So it was addressed and attacked as an IT project. We're going to do mobile. And the exchange was odd. I got an email, it said to move forward with this. I was asked to do a couple of things.

One was to drop a project brief that's dealt with the cost, the justifications, the different tools that were out there.

Another was really a report on different vender products, open source solutions, trying to get a grasp for what the different technologies were and which ones we could piggyback on and use.

The last was to build a prototype, something that was working that could be passed around to build energy and show that 'We can do this.' I said, "We can do this. Nineteen days? Sure, we've got really clever people."

So I approached the programmers, and the exchange was pretty loose. I had a project brief in hand, but at the end of the day, the conversation went like this:

I walk in to Doug's cubicle and I'm like, 'We got a green light. We're going to do mobile. I want to build out a prototype.'

Doug Beck: 'OK, so what are some specs? What's our goal?'

Roger Wolf: 'To do mobile!'

Doug Beck: 'Uh...what?'

Roger Wolf: 'I take ucf.edu and our web content and then package it so the people can see it on a mobile device.'

Doug Beck: 'No, mobile's just a means to an end. What's our goal here, Roger?'

Roger Wolf: 'We're going to just drop it into a framework and show people that we can do it, we can do mobile. We take the usable parts of our web content and then we give it to people on a device.'

Doug Beck: 'Oh, OK. We could put something together. But I need some, do you have a list of data sources?'

Roger Wolf: 'Data sources?'

[Laughter]

Roger Wolf: We didn't have a reliable way of getting this content delivered, not even on mobile but just to other users, other web developers on campus.

Central IT had just about everything in large massive repositories that you couldn't get access to. It was a ticket request if you wanted to get a piece of content. It was a data mining request if you wanted to get something else. We just didn't have the stuff publicly available. So when I approach a developer and say, "Let's do mobile," it just wasn't going to work.

So I had the project brief in hand and I had a mission, and I had already basically said that we can do this. I was going to do it as well as we possibly could.

The thing is, we built out a totally working mobile site. The thing was, it was empty. I cut and paste contents. It had nothing fresh. It had no dedicated content that was specific and useful to a mobile user.

The thing was that it worked, so we kind of created a monster whereby it was passed around, they talked about it in committee meetings, the people wrote emails and memos and said, 'Hey, we can do mobile.'

Fortunately, there's a huge bureaucracy that powers the machine that we work for, so it kind of just stalled at that point because no one can make any decisions. Everyone said that their content was the most important and they needed to get into it. No one had any data sources. No one had a strategy.

Flash forward. About six to nine months later, the university in general is going through some changes. We've grown really, really fast. Doug and I both end up leaving the circus of IT and ending up in university marketing.

And I said we work in Strategy, Marketing Communications & Admissions. As far as we knew from most of our conversations with people, this was like being shifted over to live with your crazy eccentric uncle. Nobody really entirely understood that marketing was driving almost all of the content on campus. These guys were out there everyday, and it's a really, really small team, really, really dedicated, who's working with a huge university to try and come up with a consistent message and deliver it to the users.

It turns out that they're brilliant and that working with them makes for great IT projects. They care, they understand the content, and they gave us a unique opportunity as IT people to become inculturated and to understand more about the university in general.

One of the things that they do, and I highly recommend this if you're on the content side, is become kind of road shows. We take products out there. We talk to the other people who are making content, we give them access to it, we talk about how we can make it better. We provide tool kits, useful resources, simple exercises they can do to make their content better.

It's not an authoritarian approach. It's not dictating what needs to be done. It's instead trying to guide them along a pathway, giving them someone to look up to and letting them know there's someone who can help them.

We got to go on some of these ride-alongs; they walk people through these presentations and they give them some material. I got a couple of slides that are from brand and marketing presentations, and this helped shape our approach.

Know thy audience. Again, this is about the users. In a lot of cases, you've got to get into their head and understand what they want, because there's a lot of other noise on campus about what's important. You've got to get back to the users and the audience.

You are not the audience. It's really easy to fall into the trap of thinking that because you think it's good or because you wanted it that everyone else is going to want it.

Ask stupid questions. Ask questions. Find out exactly what somebody's trying to get at, and then help them really get at it. But ask the stupid questions because you'll find out, in a lot of cases, there's no good answer. But you've got to work through it, and it's a process. The communication will really help you generate the right kind of content.

Don't offer the answer until you have identified the question. This is a consistent one, at least on the marketing side. "I need a brochure" is not a question. When somebody sits down and they say, "I need a website," that's not something you can work through with them.

You need to understand what it is they're trying to accomplish and then work backwards: generate the right kind of content, find a reliable way to deliver it, and then put it out into a piece of technology. Again, the medium is the last thing in this whole process.

These are our watchwords. Be brief. Be bright. Be done. This is especially true when it comes to generating content. If you can say it in less words or with a single image and strike the same point home, do it.

Here's the other thing about that. It will take up less space when it comes to storing it as data. It also will make it a lot easier for someone else who's having to look at it and trying to deliver it as data to make sense of it. The simpler it is for your user to understand it, the simpler it's going to be for someone in IT to understand it, and then organize it, and then deliver it.

So that was our 'A-ha!' moment when it came to mobile. What we really wanted to do was step away from the technology, step away from the framework, step away from the app/native question, the mobile/web question, and get at what kind of content is useful on a mobile device and how do we shape all of our content so that it's available for us when we decide to put it on a mobile device.

At the end of the day, you don't need to do mobile. You need to mobilize your content.

The utility-belt approach to mobile. We went with this Batman theme. The utility belt is the last thing you strap on. You need to get all the stuff themed and ready to go to fit in those pouches, and then you'll be able to grab from an arsenal of things and bring it out with you wherever you need to go.

It will change based on the mission, it will change over time, but at the end of the day, if you have your stuff ready and organized, if you've done your homework, if you've really shaped the theme and the ideas, you'll be instantly ready to strap it on and get out there and deliver it to people.

Before you go messing with the content, and we're going to continue to be very serious about the content, set some goals. You want to set some boundaries to defining the content that you want to deliver.

Again, there is an infinite number of things that you can say about your university. How many work for a smaller department, not necessarily for top-level marketing? So you have a defined mission. It's important to focus on that mission and deliver the best content for everyone else in the university of your particular mission.

Somebody else is going to have to worry about a whole bunch of other things, and you'll want to be able to work with them and help them shape their content as well with the strategies that you use, but at the end of the day, if you deliver exceptional heroic content for your particular division, it raises the entire university up. It's all about that solid brand and bringing it all together.

Again, know your target audience. If you work in a smaller department and you just are targeting that particular college, focus on them. Speak to them. Speak their language.

Describe the user experience before you try and build anything or shape any content. Now what I like to use is user stories. It's a really simple strategy. You just sit down and say, 'I am an X and I want to do Y, or 'I want to know Y.'

A simple one is, 'I'm a new student on campus and I need to find where to go eat,' and then write out how they would go about finding that information on campus. It will help you shape the content and it will help you find where you need to deliver it.

Understand your limitations to overcome them. You're not going to be able to do everything. Everyone has limited resources. Make the most of them. You're going to want to prioritize things and partner as much as possible.

Now you're going to generate the good content. Always go back to your goals. If the content doesn't support your goals or isn't quite getting at the point, reshape it. One of the things that we have the benefit of doing a lot of times is reshaping things over time.

We also are not necessarily driven by a lot of deadlines. There's a lot of flexibility. People raise their fist and say, 'We've got to get this done.' If the deadline slides, and I hate to say this as a project manager, there's very little consequence, because at the end of the day we're really about the users. We're about delivering something that's slightly different than, again, a product to market. So if you need to take that extra time to make the content that much better, fight for that, and do it.

Throughout this entire process, be honest. One of the things with this heroic theme was, be honest about this stuff and be honest with other people. If you're a small department or a large department, scope what you do and be honest about what its impact is. At the end of the day, hopefully nobody lives or dies by the work that we do.

Now, again, the content is important and it's serious, but don't take yourself too seriously and be really honest about what the value of this is.

How to get at prioritizing what content to make. Again, you've got some limitations, you've got some limitations in resources, you're not going to get everything you want immediately, this is a long-term fight, so prioritizing is important.

Do some research.

Now here's an aside, and hopefully you won't judge me for this, but don't trust anybody who comes at you with numbers, especially when it comes to mobile. They're probably trying to sell you something. Now here's the other thing, and it's kind of a dirty secret: your mobile numbers are going to go up no matter what you do.

Again, we want to get back to the content. Because more users with more mobile devices, more people using that as their primary means of accessing content. You could have the worst, bulkiest, slowest-loading site on campus; if it has a piece of content that users want to get to, they're going to get to it on whatever device they've got handy.

So when somebody says their mobile numbers went up 300%, I'm guessing there are 300% more mobile devices on their campus.

Another thing to consider is that when people define mobile devices or those numbers, sometimes they're also talking about tablets, and that's a whole other thing. So if they're selling you a package that deals with delivering it on a handheld device, that's a different experience than the one that you'll get on a tablet. And a lot of tablet users actually want... It's a full browser. It's a touch screen, but it's a full browser. There's a lot they can do on that tablet device.

[Applause]

[Laughter]

Roger Wolf: So you don't need to shape that content and make it smaller or more defined for that experience.

So when somebody says their mobile numbers are huge, they're also talking about iOS tablet devices, they're talking about Android tablet devices, so it artificially inflates those numbers.

Again, focus on the good content, deliver it to the users, worry about the technology last.

Check your stats. One of the things we did is we just looked and saw how people were already going to our content on mobile devices. We just tracked it as they were looking at it. We said, 'Users are trying to get at parking and transportation information. They're doing it on a mobile device. Let's make that content better, and then package it and give it to them on a specific format so that it's really, really easy on a mobile device.' We already knew some of the things to prioritize and attack based on just looking at our stats.

Inventory available resources around campus. Find the content that you like. As well, ask them if you can get access to it. Don't recreate it. Try and build again these data sources. Encourage sharing of the content. Ask them to be great and show them what great is, and they will deliver nine times out of 10.

Observe users. One of the things we did is we just went out and watched people. They are on their mobile devices all the time. They are on tablets all the time. You can ask them what they're doing. If they're in the library, find out how they're using the devices. You'll gain a lot of insight and you can find places that you wouldn't have expected them to need or to use a mobile device to access university resources. Again, talk to the users.

Know thy competition. This is a big one for us. Look at what other people are doing. It's not that you want to copy them necessarily, it's just you want to understand from whatever it is that they've done. So if somebody has done something really great, they've already drilled down and gotten to the meat of something, leverage that. Again, let somebody else do the hard work if you can.

It also helps because, again, sometimes, if you're competitive, you can be driven by that and it can motivate sometimes your higher-ups to say, 'We should get on this.'

Again, I'm a project manager. I'm big on lists. I'm big on checking them off when they're done. I'm even bigger on letting other people check them off when they're done. Make a list and keep to it, again, just to find the priority things that you want to get access to. Some of them are pie-in-the-sky. Make the list, refer back to it, find opportunities to extend it.

When we came to our sort of first list when we were just addressing content type that we knew we wanted to deliver to users on a mobile device, we picked out phonebook, the map, parking and shuttles, news, events, and emergency information. This is content we were pretty darn sure we could get access to and that users were asking for. This is about the users.

Write it down. If you don't keep track of stuff in Project Management Suite, some kind of software, then just come up with your own system, if it's a bulletin board, however it is, so that people can look back on it and go, 'Yes, I need to shape that content so it's easier to deliver it to the users.'

I'm kind of breaking down the content that we try to get access down into two things. It's either use what you've got, which is the stuff that you already own. If you have it in hand, again, this gets down to editing. If you're not good at editing your own work, find someone else who is cool and critical like me who has a red pen who will do it for you.

Or find places online. I don't honestly know of some, but there are probably places online that you can post something and say, "Take a look at this. Is this the right kind of content?" Again, usability is another way you could do is ask people to scan over the content and ask them what the gist of what they got out of a particular piece was and see if it matches with what your goal was.

This is about getting in shape. This is about, again, you taking some level of responsibility for what you've got, working on it, working on it all the time, making it better.

Here's a real big one. This gets into the other side of the content, the stuff that you don't necessarily have, but it also deals with your content. You've going to want to be really responsible. And I also mean accountable.

At the end of the day, it's very unlikely that someone is going to sweep in as a Superman or a Wonderwoman and fix all of your content problems or provide you all the stuff you want access to. It's probably buried deep down in the recesses of some database or is in somebody's office somewhere on campus. So you're going to have to step up and probably lead some of these initiatives.

A great thing that we do is, in the absence of leadership, just be bold. Just step out in front of this and start asking people to make their content better. Show them how hard it is to read on a mobile device on the existing site. Talk about what the core was.

It can be messy business, it's politics too, but if you're at a university and you don't deal with any politics, I would like to know what job you have.

It's also an opportunity to work with your friends in IT, make friends in IT. In a lot of cases, they have access to some database that someone has asked them to store something in. When we went searching through to find good content, we found the strangest sets of things stored as data.

Ask them how you can get access to it, what format it's stored in, how it can be imported back out. Doug will talk to you more about recommendations on how you want it delivered so that you can talk to an IT person and say, "I want to include this in my stuff. I want it dynamically included in my stuff to supplement my stuff."

It will build a stronger overall university presence and, again, is an opportunity to connect yourself with friends in IT. Sort of a 'dynamic duo'.

This gets into hunting down the rest. We again started just auditing content across campus. We just took a couple of days and started digging through everything. One of our developers actually built an application and it crawls all of our web content and has a little search bar. It can hunt through code for references to just about any kind of data.

It was a useful tool. If you have a search appliance, it would just sit on it and type in "most popular majors" or anything else and find out if somebody's listed on their site. If they have, they may have a data source. If you've got a data source, you're gold. That's really where we're getting at.

What we're really talking about is logistics. It's about planning the movement of the stuff you need from one place to another, how to deliver it where you need it, when you need it, getting it in the shape it needs to be in. There's lots of work that can be done to this. It's a long, long process to get it perfect and right. But keep working at it. Again, never give up. And if you feel like giving up, give us a call because we are never going to give up.

A brief definition of logistics. You guys can look that up for yourself.

Now it's time to mobilize. Now this is really where Doug can help you. He's going to talk a little bit about the IT side, but mostly he's going to talk about how to get this content from great content into the data sources that you're going to need so that it's usable everywhere.

Doug Beck: If I can have the content people again raise their hands? I'm curious: of you guys, who has complete control of their technology? All right. One guy, that's awesome.

And then the technology guys, raise your hands again, too. Which one of you guys have control over all your content?

So there's three people in this room over both. That's pretty good.

If you're one of the content people, you're going to have to deal with tech guys like myself, and if you're a tech guy, you're generally, unless you're one of those three, going to have to deal with a content person like Roger.

Roger Wolf: Sorry about that.

Doug Beck: And when we talk about mobile, we see this content differently, and for us to communicate, we're going to need data sources.

On one hand you have good quality content, and then the other, you have a tech guy who might not care about the content and he's caring about the technology. But what he does care about is data sources, and I'm going to define a data source as good quality content that is computer-readable.

If your university has its act together, you already provide that content in a computer-readable format. Most of you guys probably know RSS, APIs, JSON. If you have, like Roger said, you'd take some of his points and you have lean mean content and it's computer-readable, you have a damn good tool for your mobile utility belt, and you've already done the heavy lifting for mobile.

So we begin our hunt for data sources. And we start with the easy ones. We have news. We put all of our news in WordPress. WordPress is great at sharing, gives us an RSS feed. With our good news content and a computer-readable format, we have our data source. It's done.

Events, same way. Exports iCal. Have that content, plus it's computer-readable, data source. Done.

Photos, same way. Our photographers take phenomenal pictures and they upload them into Flickr. Flickr understands sharing, provides an RSS feed, tech guys understand how to use that, and we now have a data source from the photographers that we can use.

Emergency management. They provide an RSS feed. I hope you start to see a pattern here. Content plus a computer-readable format equals a data source.

Same with our campus map. We built a new campus map earlier this year, so implementing an API was a simple matter. Once we had the API in place, we now have a data source for that campus map, and we're done.

These were our low-hanging fruit. These were the places were we had good-quality, lean, awesome content with a computer-readable source.

If you're a content provider and that data's computer-readable, you're pretty much done worrying about mobile. Your tech guys can really take it from there.

If you're a tech guy and you have someone coming to you saying, "I want my content in mobile," this is when you really have to do the hard work in turning their content into a data source. And that's the hard part. It was the hard part for us is transforming that content into a data source.

We looked at Alumni, Online Learning, and Parking and Transportation.

We began with Alumni, and not everything goes according to plan. They had their own designs on mobile, so we had to part ways.

[Laughter]

Doug Beck: Next was Online Learning. We knew our users really wanted this in their mobile experience, but this turned out to be a huge political snake pit, and we didn't want to get bit. So that's one we had to avoid.

Next was Parking and Transportation. This was incredibly important to our user experience. If anyone was in the presentation before, and I'm insanely jealous, you were able to see Shuttle Zoomogram] on your mobile device in real time. This is what we wanted. This is what a bunch of you guys here have already talked about. UCF needs this and we wanted it. We were dying to get it.

All of our shuttles already have a tracking device on each and every one, so we knew there had to be data for these shuttles. We fought for the data, and we got it. We thought we were on our way, but then the data was terrible. There is a huge delay. It was completely unusable.

So shuttles were lost.

Roger Wolf: Well, not entirely lost. See, it was lost from an IT side. We couldn't get access to the data in the way that we wanted and we knew it should be delivered. But we worked with Parking and Transportation Services on their brochures and their website.

We didn't have exactly the data we wanted to provide the dynamic user experience, but we did have a solid, reliable resource for just putting up where the shuttles go and what times they'll be there. It's just a list, but we knew we had it available. So sometimes you compromise. You don't find the right technology solution, but the users can still get shuttle information on our mobile site because we have that content in a simpler format.

We'll eventually get shuttles zooming around on our map, but for now, we wanted the users to at least have access to that basic information.

Doug Beck: As the tech guy, the lesson I learned, though, was without a data source, I have nothing. So you content creators have a responsibility not only to make awesome content but make sure that you provide it in such a way that's computer-readable. When you do that, you're then providing data sources.

This is a responsibility that holds true for us tech guys as well, because a lot of us hold data, but that doesn't mean it's a data source.

So the tech guys, I wanted to ask: who here holds data such as directory information, academics, maps, library catalog? Is there anyone in this room that has access or is responsible for that data? OK. And how do you provide it? How do people get access to it?

Audience 1: Well, they are numbered different APIs. They have these signals,, whatever.

Doug Beck: I'm curious about you specifically, though. What data do you have, though, that you hold on to? Do you have one of these sources?

Audience 1: We have the directory phonebook information.

Doug Beck: OK. Well, that's good. Do you have an API or a way that people are able to search and get access to your directory information?

Audience 1: I believe so.

Doug Beck: You believe. I hear no. You monster.

[Laughter]

Doug Beck: Yes?

Audience 2: For our campus map, XML, JSON.

Doug Beck: Oh, my God. My hero. Here. Here's a utility belt for you.

[Laughter]

Doug Beck: So for us, you hold data, but you don't necessarily have a data source. And we learned this the really, really hard way.

Because our users, again, for their mobile experience, big item on the checklist was phonebook, so we needed access to that directory information. And no longer being in IT and in Marketing, I didn't have access to that information anymore. So I gave IT a call and I asked them for the directory information. And they stalled. They didn't say no; they just stalled. And stalled.

They eventually got tired of us asking, and we got a single export of our directory information. They gave us a package of data. And good gosh, Batman, the data's terrible.

[Laughter]

Doug Beck: It turns out that there was not only several duplicates, but some of it was laughable. There was one professor listed eight different times, same guy but eight different people in the information. So we had this data but by far didn't have a data source.

So we started a new directory search project. We threw it into this, we wrote a wrapper around it. It tried to catch most of the duplicates, cleaned it up, but it now exports it in JSON, and we were able to give JSON search results on this data. We had, finally, a data source for the directory information. And this is where data sources can go beyond mobile.

Because we're able to then plug it into our campus map, and when you search on the campus map, it's no longer giving you just buildings but organizations as well. Even though the data was bad, the data now had more eyes on it, and people were seeing it and actually submitting corrections and updates. And even though they were complaining to us, it was at least getting fixed.

So now our information was a little bit cleaner. Gotham is a little bit cleaner.

Up next was the Library. Our Library website, like many of you guys' is, has a lot of data-driven information on there. We really hoped that there was actual data sources for this, so we went looking for it. And we found an ally.

There was a guy, a programmer, just sitting in the bottom of the library doing all of this development, a lot of crime-fighting. We actually learned a little bit about the library system in Florida, and turns out, it's all integrated. Or, in HighEdWeb terms, is confusing as hell.

He deciphered all of this stuff and wrote wrappers for it and made usable tools, and we just had to ask him, "Hey, all these tools that you made, how about you just make them public for us and let us access it?" And he was cool with that.

So not only did he give us a really good mobile tool, but he said, "I have more," and turns out he also had an XML feed for the status of which computers were in use or not in use for the whole library. And we're like, 'This is awesome. This is totally unexpected data source. This is great.'

Again, the efforts of mobilizing your content, turning them into data source, will help you out through creating your whole user experience, because that guy, our ally, he was an expert on maps and was able to really help us in some of our other projects.

So for us, the hard part was done. We have our mobile content, and not only that but we have data sources for them. We've made them lean and mean and computer-readable. So we were ready now.

Now that we've talked a lot about these data sources, I've not talked at all about implementing them into a mobile solution. And I've done this on purpose and I've left it for the end of the presentation, because it's really important to save this decision for the end of your mobile journey.

Any mobile solution will work as long as you have data sources. Most of them are 'plug and play'. They're empty utility belts without tools. And this is the key to our mobile utility approach. Do the hard part first and worry about your content. Pick your mobile solution last.

And for us, when we had everything ready and we were about to roll out the content, that's when IT stepped in and said, "You guys don't know what you're doing. We're here to do mobile," and we're like, 'Ahh!' And they said, "Not only that, but we're going to purchase an enterprise solution for the entire university." Oh!

[Laughter]

Doug Beck: We said, "No, don't do it!"

Mobile is not a technology that you just buy. It's not something you just do. It's the content that matters. Spend the time and effort improving the quality of your data. Make it publicly accessible. Make it computer-readable and easy to access. Stop worrying about the technology and fight for the content.

Fast-forward a few months, and we now have Blackboard Mobile Central.

[Laughter]

Doug Beck: But it turns out it wasn't too bad. It's actually written by some terribly clever folks, because soon we had IT coming back to us and saying, "Hey, we need access to the data sources." "We told you! You have nothing without the content."

It's the data sources you have to worry about first. Concern yourself with the mobile solution last.

I added this slide this morning. The Notre Dame guys, their presentation was really awesome. I know they're running through APIs, and talking about that, they made a quick note about mobile. And just so you guys know I'm not feeding you a bunch of BS, all of their mobile modules are coming from data sources. Again, their framework is going out, pulling that content from somewhere else, and implemented in their mobile solution.

So this is the end of our presentation. Just to wrap up: Make sure that it's for your users. You make that content lean and mean. You worry about data sources over the technology. And you choose your mobile solution last.

Thank you.

Roger Wolf: Questions?

[Applause]

Roger Wolf: We ran a little bit long. We have a couple of minutes for questions.

Doug Beck: Yes, sir.

Audience 3: 'Keeping up with the Joneses' dilemma, because position is for everybody, they see a billboard and somebody saying, 'Download our app' and they are trying to make everybody understand that the first part everybody should do are global app, events, map directions and everybody's trying to get on the path of, 'Well, we want a map that does this,' 'We want a map that does that.' How do you prepare them for what might be the next phase? A global app that's specialized, you can log into MySpace, with these functions?

Doug Beck: One thing that I really like that I've seen a couple of times here at HighEdWeb this year is that maybe it's going to be not so much about creating mobile things to do specific goals but really, you just shape your websites and your content to be mobile first, and then you actually work to the desktop later.

I think the conversation is and is already shifting to where, let's not talk about mobile as something special, but just talk about your content.  Once you just make your content for mobile, then you're no longer thinking of it as some special thing but just how you approach your communication as a whole.

Roger Wolf: You can also talk about maximizing that activity at the university first. Do they actually have the resources to take in that information? Are they really thinking about what that process should be?

Because what we're talking about, you're talking about filling out forms or you're talking about interacting with their data, so have you really thought through how to make that process good, absent of mobile? Because if it's crap on a desktop, it's going to be crap on mobile.

So work through the workflow, define somebody who's an expert in that process, and then figure out how mobile can solve some of the bottlenecks in that process and just map out the three steps they need to do, as well as require them to bring content to the table before you really have a conversation with them.

Doug Beck: All right, it's lunch time and I don't want to hold any of you guys longer than that, so thank you.

Roger Wolf: If you want to talk to us about anything, just come on up.

Doug Beck: Yeah. Just come up.

Moderator: Thank you, guys!

[Applause]