APS6: A Mobile Web Framework for the University of California System

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

Brett Pollak: Yeah, I'm excited to be here. Actually, I'm obviously UC San Diego, I'm from the West Coast. Show of hands, anyone else from the West Coast. Yes! Found you guys, finally. Yeah, it seems like a lot of northern representation, East Coast, Midwest. But I'm real excited to be out here.

This is just a little bit of my background, my experience. I feel like mobile has really re-energized me in terms of what I do on a day-to-day basis and it's re-energized my team. It felt like a couple of years ago that the Web was getting a little stale for us. It was the same thing, designing for 960 pixels and you did the best you could with making it fancy in the middle.

But when mobile came on the scene, I think it re-energized us knowing that this is a whole other frontier, really, that is really unexplored especially in the higher ed area. And a couple of the presentations that I've seen already today with Ohio State and a couple of the others, we're all taking different approaches, and I really think it's great seeing the different points of view. I think there's going to be a lot of takebacks, at least for me.

The UC System. This is a collection of 10 universities up and down California. It is a very decentralized environment, as with most higher ed institutions.

As also with most higher ed institutions, especially those that are state-run, the budgets have been cut, so we've had to collaborate a lot more than we ever have before. Really, there was zero collaboration before a couple of years, and now there's a lot more collaboration.

Can I see by a show of hands how many people have had layoffs in your institution over the past couple of years? That's more than half. We're the same way. Our budgets have been cut, so we've had to do more with less, especially if we're looking at supporting mobile. This is something new that we have to take on.

Audience participation part, yay. Whoever has a smartphone, please plug your favorite smartphone device and fire up your scanner and go ahead and scan that.

If you don't know what I'm talking about, I think there's actually a session going on right now that's talking all about QR codes, but please, don't leave this session for that. We can talk about it maybe after the fact. But if you don't have a scanner, you could go...

Is that working? Are you guys able to get it? Yeah? No? It's too bright? Some got it, some didn't? If you can't get it, you can hit the URL down here. I love this. This is great. Come on up.

[Laughter]

Brett Pollak: Yeah, it seems like it. I tested it before I got here.

Well, if you can't get it, again, the URL is down here, and the next few slides will have the URL so if you type it in you can go to it.

What this is is an online poll using the mobile web framework, and this application is built by UCLA using the mobile web framework, which I'm going to talk a little bit about in a few minutes. Essentially what it's designed to do is potentially replace the clicker devices that are used in a lot of classes right now.

We realized that the devices tend to break or it's an extra cost, so everyone really has, all the students, at least, have the smartphone, so why not just use that device and then use software that we can build using the mobile web framework?

At the end I'll go ahead and show the results of the poll to see what the feedback is.

So where is the mobile web today? Well, it's on desktops, it's on laptops, it's on tablets. And it's obviously progressing really quick. We all know that.

Tomorrow, this is where the mobile web today will be. It could be on watches, it could be on refrigerators. Maybe it's on a treadmill. It's already inside a lot of cars right now.

We know it's a very fast-paced industry and we have to keep up with it, so we're doing a lot of research about what's coming around the next corner. So that's taking up obviously a lot of time.

In six months from now, the Web may be somewhere where we never anticipated, so we want to try to do the best we can knowing there are certain limitations that we have just based on the constraints that we have in higher ed.

Just a few stats. Mobile devices now outnumber the U.S. population. That really resonated with me. I thought, 'Well, how could that be?' Over 307 million mobile devices are sold out there. So if you think about it, people will have a device that they use for personal use, they'll have maybe one that they use for business, maybe they'll have a tablet or another device on top of that.

I guess devices are becoming more and more specialized so that people need multiple devices. Maybe they have an eReader as well. So this really is unprecedented in terms of technology.

Mobile data traffic. There was 111% from this year to last. The culmination of all these different devices is generating more and more data traffic, and obviously companies like Verizon and AT&T need to try to keep up with this demand for bandwidth. So this is something that obviously is going to be an issue going forward.

Smartphone usage. This is obviously the biggest slice of the pie. Well, one in three in the U.S. population has a smartphone today, and that number is predicted to grow to 50% by October of 2012. One out of every two people in the entire U.S. population is going to have a mobile smartphone. That's pretty amazing, to me at least.

Now if you think about a little closer to home, think about our target audience, prospective students. This number seems relatively low, but 14% of prospective students access the admissions sites from their mobile devices.

This is not something I would tend to do. If I'm going to sit down and research a college, I don't know if I'd do it on my mobile device. But I'm not the demographic. So they are doing this, and this is going to continue to increase.

If I think about what our admissions site looks like on a mobile phone, it's not that great an experience, and many of you may be in the same boat right now. But this is something that obviously weighs into a student's decision to come to your university or not. Studies show that your Web presence has some level of effect on whether the student is going to accept admission into your university.

Thinking about current students. Sixty-five percent in this demographic have access to mobile internet. Within the next year, that's predicted to jump to 90%. So basically all current students really are using the mobile web.

Now thinking about the next generation. These kids are growing up with these devices in their hands. My five-year-old is teaching my two-and-a-half-year-old how to navigate around an iPad. He's also teaching my wife as well.

[Laughter]

Brett Pollak: Don't tell her I said that. But it's true. I mean, they gravitate to these things and they take them and they just know how to use them. It's amazing how ingrained it is in their DNA.

I want to show you a little video. This is a one-and-a-half, two-year-old. It's showing her how she's navigating through an iPad, and then what her expectations are for picking up a magazine, and how that works.

[Video]

Brett Pollak: Oh, sorry. I'm ruining it.

Regardless of what you might think about that, I know there is a lot of, if you look at the comments on that video, there's a lot of people saying, 'What the heck are you doing giving your kid an iPad?' But then half of it is like, 'Oh, my gosh, it's amazing that young children are perceiving the world like this. It's just ingrained in them as they're learning to use these things.'

All right, so how do we get out of this? How do we keep up? Proliferation of devices. We need to be agile. Now, if we think about the higher ed landscape, it's very decentralized, at least it is in our campus, and from some of the presentations I'm hearing today, it's the same at your place, too.

We've got multiple audiences to serve. It's not just the students. They are the ones primarily using the cutting-edge devices, but at least for our office, we've got to serve parents, faculty, staff. These are all folks that are now starting to gravitate towards using mobile devices.

So we've got students with the latest gadgets, they're on the cutting edge. Then we have faculty and staff. They've got some older phones.

[Laughter]

Brett Pollak: We don't support these phones, if that's what you're asking.

But regardless, they may not be at the cutting edge, or the bulk of the people that we're serving, but a lot of these people are really important people. They may be 10-year professors or esteemed staff members. They may be using an older device, but they could be pretty noisy if stuff's not working on their phone.

And then we've got deans. We've got some of the higher-ups. And basically what they're hearing from their kids is you've got to have an iPhone app because that's what they have, so they'll basically take that and come back to you and say, 'We need an iPhone app.' So that's definitely something that you have to consider.

We have very decentralized IT. The group that owns the data for the student applications will be very different from the group that own the data from the maps. And in order to do courses that plot to maps, you've got to get those things to marry up.

What we find is that people, they hold on tight to their data and they don't necessarily want to expose their data, so we could provide a centralized offering. So we definitely consider that in considering our mobile solution.

Talking with a lot of the other UCs, we all had the same problem, so we started to come together to try to solve the problem. Specifically, a little background on UCSD's implementation and our mobile presence.

In June of '09, we launched an iPhone app, and we worked with a company called TerriblyClever at the time, which was a bunch of Stanford undergrads. They basically created an iPhone app for Stanford, and their CIO knows our CIO at the time really well so he was asking about, could they do the same thing for UCSD at a reduced cost.

He said sure, so basically we spent a couple of months just producing data feeds, and then those guys ended up building us a little iPhone app, and it had things like the maps, directory, courses, some sports stuff, and it pulled in our YouTube feed. It was pretty cool, and we claimed to be the first public university to have an iPhone app. I don't know if that's really the case, but our marketing people say we are.

So that was our overall presence. And we got a lot of good feedback. Students really liked it, and it kind of showcased that we were cutting-edge, if you will.

We worked with them to produce a Blackberry app after that. And then we launched a mobile website that was pretty rudimentary that had some of the functionality but not all of it.

But then, in 2010, TerriblyClever was bought out by Blackboard, which made all those little undergrads terribly rich, which basically redirected their efforts to getting more clients rather than working with us on enhancing our offering.

So that's the position we were in at the time.

So we started to investigate what the options were. We knew what we wanted to do more. We had all this data on campus and we wanted to try to unlock it. So what could we do?

Well, we thought the mobile web was going to be our target solution. If we thought specifically about apps, we didn't have a wealth of resources out there. We knew we had some web programmers, so if we focused on the mobile web as our core piece, we feel like we could extend that out, serving all those audiences and all those different devices that we had on campus.

We looked at a lot of higher ed IT packages. We liked MIT. Kurogo was kind of an offshoot of MIT. And those needed to be centrally hosted, so we thought that those met a lot of the requirements, but the fact that they need to be centrally-hosted and consume data feeds, we didn't feel like that was necessarily going to be a great fit. But we put it on the radar.

We looked at some front-end frameworks, things like Sencha. They were pretty Javascript-heavy, but they were actually on the roadmap because they met our needs from a technical perspective.

jQuery Mobile was getting a lot of attention at the time. It was an alpha when we were doing our research, so we put it on the roadmap and said this is something we probably would want to integrate in at some point in time.

And then at UCLA, we started talking with them about what they were doing in building the mobile web framework, and they were, again, trying to solve a lot of the same problems that we were. UCLA was very lightweight, so that was real attractive to us. It seemed like the learning curve was really minimal to getting it up and running, so we definitely took a hard look at that as well.

In terms of our process, we started involving all these IT shops on campus that had all this data that needed to be unlocked and got them to help us do the research on the framework that would make sense for our campus.

We defined some selection criteria. We knew this was a real fast-moving industry. It would sustain over a couple of years' period of time. We could augment or replace it at some point in time.

We wanted to be technology-agnostic because all these different IT shops on campus programmed in different technologies, .Net, PHP, Java, Ruby on Rails. We ran the gamut pretty much.

And then we reviewed the framework. We basically took all the frameworks, we scored them, and then based on that, we had everyone come back and then evaluate their perception of the framework just reading through the documentation.

UCLA mobile ended up winning out for us, for the reasons the ease of use, the learning curve, documentation, and a lot of it was this ability to now collaborate at the UC level, to really steer this in the direction that we think we all need to go.

So what's our strategy? Well, our strategy is to develop for the mobile web, develop once, and then deploy everywhere. So deploy to the mobile web, and then deploy to the app stores because we knew that apps have cache, I think, was what was said earlier. It's true. And we also had a presence in the App Store already with the TerriblyClever app that we knew we had to replace, because we didn't want to keep paying that vender license agreement.

This was not just our strategy. We developed this UC-wide. So we really felt like not only we were coming together as a campus but we were coming together across the UC system.

We created some guiding principles for the mobile web framework when we started looking at expanding this out across the UCs.

We wanted it be device-agnostic because we wanted to serve these multiple audiences.

A federated architecture. We knew it had to be hosted centrally, and then we could have the different units on campus tap into that framework to build the mobile web apps.

A unified UI presence was actually really important, I thought, too, because anyone that used the framework should be using the same UI elements that are available within the framework. We have a proliferation of websites on campus, just like probably all you have, and there's been no top-down governance on how things looked and how they were tied together. We felt like this was at its infancy and we could do it the right way to start with, so that was kind of our guiding principle.

We wanted it to be language- and environment-independent, and we want to use web standards so that would allow us to augment or change out the framework at any point in time.

What's the secret sauce? Well, it's really not that much. Like I said, it's very lightweight.

Essentially the framework is doing three things. It's doing device-detection, so it's detecting the type of device that's accessing your application. It's doing it through dynamic Javascript and CSS.

And the other big part of it is image compression. Based on the size of the device that's accessing the images that are being served up, they'll compress them down at the server level before they're served up to the web browser, which is actually really important for the speed of the system. So that was real attractive to us.

So how do UCSD developers use it? Well, basically the only thing they have to do is they create a mobile view of their application, and then in a head they just conclude these two lines, one for the CSS and one for the Javascript. And basically, from there they just use the UI elements that are available via our 'kitchen sink', as what we call it, which is a selection of all the different UI elements they can choose from to build their application.

This is another view, a little more technical. Basically this is showing, maybe this is the student tour's application built in .NET, maybe this is the course's application that's built in Javascript, a couple of other applications. Through those two lines of code, they basically are accessing the mobile framework, and it's doing everything else itself. So they really don't have to do anything other than that.

We have a documentation site. It basically describes what the framework is, how to use it. The technical part is the easy part for us out of the gate. The hard part has been working with people to figure out what's the right content to expose in your application.

You really can't just take this desktop view of an application and then apply the mobile framework and it works. You really have to think about, from a usability perspective, how are people going to access the type of content on different devices, not to mention to use the things that are available on the phone such as geolocation, perhaps the camera? These are things you need to think about when you're building a mobile web application.

You can go to m.ucsd.edu to see all the publicly available stuff, but I wanted to show you My TritonLink, which is this one down here.

By the way, we're the Tritons at UCSD, so My TritonLink is our student portal. If you click on that, you'll get a single sign-on screen, so we've actually provided the mobile web framework on our single sign-on. We use Civola. So it's living on that server as well.

So they'll sign in, and basically they'll see a profile. It's kind of washed out, but they see their major, if they have an account balance, if there is any holds, if they have direct deposit. There's a few things in the profile information that are exposed to them.

And the biggest hit was the courses. They receive a personalized view of their courses. And if they click on the course location, they basically get shuttled over to the campus map, which then will plot that on a Google map, so they'll get through GPS.

Well, they can click on 'More Information' so they can get information about the facility itself, so you picture, 'Am I in the right location? Am I not?' They can click on 'Driving' or ' Walking'. And then through Geolocation, it will give them plotted driving or walking directions directly to the class.

This was a big hit for first day of classes. This was our Summer project this Summer, and we knew that the registrar gets a ton of foot traffic the first day of classes. We wanted to try to reduce that, so we worked closely with them to try to get this online before first day of classes this year, and they were infinitely thankful because it really helped out.

Yeah?

Audience 1: [Indiscernible]

Brett Pollak: Yeah. The GPS signal obviously varies, depending on where you are.

Audience 1: [Indiscernible]

Brett Pollak: It's true, yeah. The GPS work pretty well. In a few slides, I'll show you what our analytics show, and predominantly were iPhone and Android, which obviously are the meat of what the students are using, too, and those are pretty reliable for the most part.

Another big hit, too, and I think this is infinitely cool is that we have podcasting available for most of the courses at UCSD now. Those are all RSS-enabled. Basically we were just able to include that in the framework so they can listen to a lecture, so students can look back, they can navigate to a lecture to review the notes and things like that if they missed anything in the lecture, or if they just didn't go. It just brings up the native player.

So that's great, we're focusing on the mobile web. But we know that we needed to have an iPhone app as well because it has cache and we already have an App Store presence. So what do we do? Well, this is our mobile website. And this is our mobile app. See the change? Mobile website, mobile app?

What we did was, in Titanium, we just built an app wrapper and just deployed m.ucsd.edu within the wrapper. Now there is a lot of people saying, 'Oh, you can't do that. Apple's never going to approve it.' Well, they approved it. So it kind of sets a precedent, I think, for a lot of the other UCs to do the same thing now. They're doing the same thing with their mobile app. UC Berkeley just launched theirs using our Titanium, so that's very cool.

iPad apps. We had to have an iPad app out, too. This is in testing right now, so it's exactly the same thing. We just saved it off as iPad using Titanium.

This is where you can see it in the App Store. This is the Apple view. We saved one off as an Android app, too, so you can download this from Android as well. So far the Android has gotten pretty good feedback.

The one thing we noticed, too, because our app replaced an existing app that was using a lot of native Objective-C components within the iPhone App Store, we were getting dinged on performance. The mobile web isn't going to be as fast as native UI elements.

Since then, we've done a lot of things such as image compression. We did application caching. We started to really focus on performance the last few weeks, and it's gotten a lot better, so we're getting a lot of good feedback now.

Go ahead.

Audience 2: [Indiscernible]

Brett Pollak: They would see the same thing if they were trying to view an app that wasn't a wrapper, which was no data.

Audience 2: [Indiscernible]

Brett Pollak: No. There's nothing stored within the application itself. Yeah. And there wasn't with the previous version.

Right now, we've got five out of the 10 UCs live with the mobile web framework, and the rest of them are in process, soon to launch or within the next couple of months. So we've gotten a lot of good interest.

The other nice thing is we're all contributing back to the framework now, so we're using Git as a repository. You basically can do development checking into Git, and any other UC could pull any other person to application to jumpstart their development.

This is the site. If you go to m.mwf.ucla.edu, you could get more information on the mobile web framework. And people say, 'Well, can we use it?' Well, yes you can.

Audience 3: [Indiscernible]

Brett Pollak: Yeah, it's source-available, is the license, which is kind of a weird license. We're looking at that again to see whether that's a good fit or not. But, yeah, it's source-available, meaning that you can download it, but you can't yet be a contributor back to it. We're determining what we want to do there.

Some statistics. You were asking about the types of phones that are accessing it. I've got to throw this up there. The UCSD mobile homepage gets about 4,000 page views per day. Really that's about 17% of what our campus homepage gets.

That may seem like a pretty small number, but realistically, that's gone up about 2% per month so far this year.

Go ahead.

Audience 4: [Indiscernible]

Brett Pollak: Gosh, we have 45,000? I'll go back and check, but it's somewhere around there, yeah.

It's not huge, so some administrators would look at the stats and say, 'Well, that's a very small number. It's so much less than our homepage.' But the fact that it's growing at such a great rate, I think it supports the fact that this is where things are moving.

In terms of the devices that are accessing the mobile site, we're really IOS-heavy. iPod Touch, iPad, iPhone, that makes up the bulk of it. Android has been growing by leaps and bounds, though, so it's definitely something we have a lot on our radar. Windows is really very small. It really hasn't taken off much at all. And then Blackberry is about 1%.

And then there are phones that are less than 1%. I just didn't put them up there. But things like Nokia and some Symbian, some of the older operating systems are really small. Nevertheless, it still works on them, so we're still serving them.

Our top applications. The My TritonLink application, which had the student courses and everything, that's 34%. That's our most heavily-hit. We had a Welcome Week application that our student affairs team built, which was really popular. So for the first week, they have all these events, kind of a  'welcome back to campus' type thing, and that got a lot of hits and it really was good exposure, I think, to our mobile solution.

The tours. The courses. Courses has really gotten down significantly since we launched My TritonLink, because that's the personalized course view. Our maps. Dining. And then podcast and the rest of them.

We're probably adding maybe one app every month or so just because now folks are able to take their framework and use it across campus, so we're getting a lot of submissions. So governance is a whole other conversation.

We basically put out a survey, tt was at the beginning of the year, about what students would want to see on their mobile device. We're serving a lot of them actually now with our solution and where it is today. Class locations, we have that. The class list is also available. The campus restaurants, we've got now. And then the holds, that's part of the My TritonLink.

We're working on class enrollment, so being able to enroll in classes online, which has been a really interesting experience in trying to figure out how you do it correctly on a mobile device. Basically, they can go in and they can add things to an Outlook-type calendar and then basically use that to enroll in classes. Trying to figure out how to dummy that down for mobile devices has been a little bit of a challenge, but it's something we're in process with right now.

And then grades is another big one. They of course want their grades at the end of the semester. It sounds like other folks have done that already.

Triton Cash Balance is they can load the card with cash and they could pay for it across campus. That's a vender solution, so we're going to start talking with them in the next couple of months.

Well, what about our websites? How much time do I have? 3:59?

People are asking about our websites and if this will work for that, too. The thing is, with the mobile solution, we were able to start from the ground up with the mobile web. We just did it and we replaced our apps in the app stores and we're good to go.

But the thing is, we just have this proliferation of content that we have in our central CMS, so we're trying to figure out how we can mobile-optimize these as well. The thing we're finding is that our content owners aren't necessarily thoughtful about the type of content they want to make available via mobile solution.

They're just saying, 'Well, I don't know, you tell us.' And we have over 65 sites in the CMS right now and we do about one or two a month, so it would be really difficult for us to work with each person to figure out how to integrate that within the CMS.

So we're taking another approach. We're looking at this 'One Web' philosophy that seems to be getting a lot of interest right now from the Web's perspective. Basically what it means is it's using, as far as is reasonable, one set of markup. That starts with the desktop and moves all the way down to a mobile device.

We don't want to necessarily make this our mobile best practice. We want to make it our web best practice for all of our web content.

Essentially we take one set of markup. It's used for all the devices. And there's a couple different ways you can go about doing this. There's one philosophy called Progressive Enhancement, where you start with the core content, you add your presentation there, so your CSS, and then you may do some client-side Javascripting.

This is great if you are starting from scratch. But the fact of the matter is, we have all these sites already, and our CMS, using wyswyg editors, and the code's probably not the greatest. This isn't going to work for us.

So we need to provide an axiom. Basically we said people aren't going to do anything different than they do today. This is just going to work behind the scenes. So we have another option, which is called Graceful Degradation. Instead of starting with the core and building out, we're starting with what we have and we're trying to degrade it down gracefully.

We start with a full version of the content, we add CSS and JS for the browsers that can handle it, and then we have our sites. And this is going to work for us. We're in the phase right now of basically proving this out. It's under construction. But I have some screenshots.

We're redesigning our News Center site right now. This would be the desktop version of that site. You can see we have a big hero in a news image here, we have a scroller, so if you click on one of these, it will populate this area, our social media area, and then the rest of the news stories' down here, athletics, and then some callout boxes.

If you size this down, and basically this is our view for, say, an iPad kind of that portrait, what that does is it takes that social media that was on that side over there and now moves it below so it's sized down appropriately for that view port.

And then if you look at what this would look like, say, on a 40-pixel iPhone, it shrinks it down even further. So what we did was we took the navigation that was at the top, kind of horizontal, we basically created boxes for that, so when you size it down to that width, you will get the streamlined approach.

Rhat was our approach in terms of bucketing, and we were using Javascript and media queries for this solution. Now we're doing this with all the CMS websites. This one was a new one. We can do it from scratch, but now we're retrofitting all of our sites with this approach.

Does that make sense? Yeah?

Poll results. Let's see. Did you guys take the poll? Yeah? All right. "What time zone do you live in?" Eastern seems to be the biggest one. Well, here we are, at Central. "Does your university have a mobile-optimized homepage?" Yes, most of you do. That's good.

"Does your university have an app in the App Store?" Most of you as well. There we go. "Do you have a mobile strategy?" Pretty mixed on that. Looks like a lot do, so that's good.

But, yeah, coming up with solutions is one thing; having an overall architecture and strategy is definitely something new that you have to try to jump on while you're doing your work.

[Laughter]

Brett Pollak: "Who's going to win the World Series?" "They're still playing baseball?" I felt the same way, too. Someone said, "Yeah, have you been watching the World Series?" and I thought, 'Isn't it football season?' So that's interesting.

Audience 5: [Indiscernible]

Brett Pollak: You definitely fall in that yellow category, then.

OK. I've seen a lot of pictures, a lot of rock pictures. I had to throw in a rock picture myself out there. So I was thinking back to when I was in college. Who was in college in maybe the '80s or '90s? Yeah, some. '70s? Somewhat? OK. Basically I was thinking back to my first day of classes. I had my campus map and my book bag and I'm trying to find classes and I can't do it. Now the kids have this thing. They have it pretty easy.

I was thinking about whenever I was trying to study for a test, and maybe I lost the notes for the teacher's lecture. What did I do? I basically called my friend from a payphone or something like that and tried to borrow his notes and read his chicken scratch. I just did the best I can. So it made me realize that students got it pretty easy these days.

What we did is create a little promotional video that kind of showcases what it was like being a student back in the '80s and then what it's like being a student now, and I want to share that with you guys here at the end of the presentation. So I hope you enjoy the video. And I hope the audio works. It's definitely not working. Oh, I'm so bummed.

[Video Music]

Video 1: Hey, aren't you late for class?

Video 2: No, the show's going to be in like five minutes.

[Video Music]

Video 2: Hey, guys, I'm going to be a little late, but I'll be there soon. See you.

[Video Music]

Video 3: Hey, it's me! Yeah, oh, my God, I'm totally running late! I'll be there soon. OK. Bye.

[Video Music]

Video 1: Did you understand what the professor was talking about in today's lecture?

Video 2: I really didn't, but I'm listening to the podcast again, and so hopefully I'll get it this time.

Video 1: Where can you get the podcast?

Video 2: It's actually on the new UCSD mobile.

[Video Music]

Video 4: Did you understand what the professor was talking about in today's lecture?

Video 3: I mean, I think I did, but now I can't find my notes anywhere. It's like they disappeared, and I'm re-reading the entire chapter and I don't think I understood anything. No.

[Video Music]

Video 1: Where do you want to go to eat?

Video 2: Well, I just checked the app, and Goody's is open and they have specials on burritos today.

Video 1: Let's go.

Video 2: All right.

[Video Music]

Video 3: Shoot, it's closed.

[Video Music]

Brett Pollak: All right. Do we have any time for questions or are we good? Five minutes? OK. Any other questions?

Audience 6: [Indiscernible]

Brett Pollak: No, that's on my site. If you go to cwo.ucsd.edu, you'll see 'Mobile Web' and it's on there. Yeah.

Any other questions?

Audience 7: [Indiscernible]

Brett Pollak: Yeah. We have something every year called Share Case, which is our, I don't know, business affairs. Basically everyone in business affairs gets together to talk about what they're doing. That was part of our, I did a keynote speech there. I showed the video at the end. We just use it to promote it. Every time we go out to speak, each one of us will play it at the end.

That was done in three days, by the way, [Laughter] so production quality, low.

Anything else?

Audience 8: [Indiscernible]

Brett Pollak: It's a good question. No, the framework actually handles the degradation behind the scenes, and I'd be happy to show you a little bit more, but on our site basically it's showing you that there's a WebKit view, and it degrades down. So if you don't have, say, for example on your device you can't handle doing rounded corners or something like that, basically it just automatically degrades what the device can handle.

Audience 9: [Indiscernible]

Brett Pollak: Yeah. It's not really that bad. We use the Progressive Enhancement philosophy out of the gate with the CSS, so if your device can handle it, it will show it.

Audience 9: [Indiscernible]

Brett Pollak: It really wasn't. Basically the framework is handling things like image compression, so you don't have to worry about sizing images and things like that correctly. It handles all that at the server level. I'd be happy to talk to you more about it, too, if you want.

Anything else?

Audience 10: You said you used Accelerator Titanium to create the data. Did you guys look at any other like PhoneGap?

Brett Pollak: We did. We did look at PhoneGap. UCLA actually took a deep dive into PhoneGap and we basically came back and compared notes. It seemed like PhoneGap just was a bit buggy, it was buggier, I guess, than Titanium was. So we just decided to go with Titanium.

There may be something else that comes out that we'll use later on, but it just seemed to work for us for now. It had a relatively low learning curve. And we were able to get in the root code if we needed to, and we had to a couple of times.

Audience 11: [Indiscernible]

Brett Pollak: There are plans to potentially use the app as that kind of the core that can access things like the phone. We want to do kind of a virtual reality app. That's the future I think is if you put your phone up and you scan it across the campus, like what's in buildings, what's open, what's not open, I really think that's the future of where we need to go, so we'll probably use the app as the basis for communicating with the phone in a lot of cases on the apps, or maybe some other hardware device capability features that are maybe other than GPS that's not in HTML5.

Audience 11: [Indiscernible]

Brett Pollak: We can, yeah. There is a user agent string that's different. If you're on the iPhone app, your user agent string will look a little different in Google Analytics.

Audience 11: [Indiscernible]

Brett Pollak: Actually it's 50/50 between mobile web and the app. Yeah, because we redirect people from ucsd.edu that are accessing on the mobile device to m.ucsd.edu.

Audience 11: Sorry, last question. Do you redirect automatically?

Brett Pollak: We redirect automatically, but we provide the user the ability to click back to the full site in the footer. And that sets a cookie, too, so if they go back they'll see the full site again.

Anything else?

Audience 12: [Indiscernible]

Brett Pollak: Yeah. We're redesigning our travel expense system. It's a homegrown system. We're making mobile part of that as well.

So for staff to go on trips like this, for me, being able to do expense reports via your mobile device as you're accumulating the expense reports is something we're working on with those folks as well.

We're not real big, so we're trying to spend our time wisely. But it's definitely on the horizon to do more of that.

OK?

Moderator: Thank you.

Brett Pollak: All right. Thanks a lot, guys.

[Applause]