Fast forward a year and a half (and quite a few arguments)… I’ve now worked on one responsive project, I’ve watched a number of other responsive projects come out of our department, and I’ve come to appreciate where and when responsive web design works and works well. On top of that I’ve learned how helpful front-end projects like Modernizr, MicroJS, and YepNope.js can be to any developer. That being said, it’s tough to teach an old dog new tricks and, to me, it still seemed as if their was something not quite right about responsive web design.

At this point I won’t rehash the arguments. Yes, dear dead horse, you can have a rest. Instead, I’ll focus on an article Luke Wroblewski (@lukew) wrote entitled, Responsive Design + Server Side Components.

RESS: Responsive Design + Server Side Components

For a while now I’ve felt like I was somehow out of touch for still preferring browser-detection over responsive design (like I said, I’m an old dog). I’m assuming it’s because I tend to follow front-end folks on Twitter who are very much on the responsive web design bandwagon. But between Luke’s article, Yiibu’s talk, Adaptation, as well as their Profile tool, and the news that 82% of Alexa’s top 100 properties used server-side detection to modify some amount of their content I started to feel a little less out of touch.

The principle concept that I found so intriguing in Luke’s article, as well as the work done by Yiibu, is that browser-detection can be used to help inform an overall responsive design as opposed to being the be-all-end-all for templating. By this I mean that partial pieces of content can be inserted intelligently and where appropriate (think images) into a larger layout that’s given to all browsers and is governed by responsive design principles. Hence the combining of “responsive design” and “server side components” in Luke’s name for the technique.

This isn’t something that I should consider revolutionary. On the face of it’s sort of “Duh!” but sometimes even the obvious has to be pointed out. It’s nice to see a bridge of sorts form between these two competing concepts. Their is value on both sides of the fence and they can and should work together. The question is “How?”

Implementing a RESS Solution

Luke does a good job of taking a reader through a theoretical(?) RESS solution that is based on his experiences at his start-up, Bagcheck. He shows,  quite clearly, how the server-defined partials fit in nicely with an overall responsive design. One thing that the original RESS example fails to review is how content is classified for browsers though there is a nod towards user agent detection. I was curious to see how that part of a RESS solution worked so I put together one of my own that used Mustache just like in his example and Detector.

My implementation of a RESS solution is very simple. I didn’t explore much beyond modifying some markup, adaptive images, and CSS. The first thing that I realized when I started tackling the “how” was that I was going to have to categorize browsers into classes (to be fair, Luke does mention classes). For the purposes of the example I set the browser classes to be desktop, mobile-advanced, and mobile-basic. The desktop class has “regular-sized” images, the mobile-advanced class has smaller images as well as some modified CSS, and the mobile-basic class has a very simple layout that utilizes accesskeys.

If you’re interested in how I set-up the demo and how it all works please check out the tutorial and the source. What I’d like to talk about now is how I ended up with my classifications and how I think it points to more responsive solutions on the server and not just in the browser.

Taking Feature-Detection Server-Side

Developers have been using server-side libraries & services like WURFL, DeviceAtlas, and 51Degrees.mobi to provide mobile device characteristics for ages. In that respect, server-side feature-detection is nothing new. I would propose that we update our terminology a bit though. “Device detection” seems anachronistic and, frankly, misguided to me. Who cares what a device can do if the browser, the bit we as developers actually interact with, can’t access them?  This is not to suggest that these device databases don’t contain that kind of information but rather that they include details that, for the most part, might not matter to developers. In order to get more relevant data there is one technique that server-side developers should appropriate from our front-end brethren and it’s browser feature-detection.

In his article, Cutting the Interrogation Short, Alex Russell (@slightlylate) makes an interesting proposal. He suggests, “feature tests should only ever be run when you don’t know what UA you’re running in.” This is a proposal I wholeheartedly agree with. So where to store the results of these feature tests that you want to run only once per user-agent? Alex suggests a few methods that rely on the front-end detection libraries but I would suggest that the results get stored in a server-side cache (but, hey, I’m biased). Feature test results stored on the server, using the user agent as a key, gives server-side code the ability to act on them making the server-side code that much smarter about what should be delivered. If necessary, the server-side code can always pass the list of features for a particular user agent to the browser as a cookie or a JavaScript include. Also, if tests are stored server-side the initial set of tests can be extremely robust. The developer would capture a lot of details but still have control over what gets delivered to the browser thereby optimizing the experience for their visitors. Hopefully, it could make for a “best of both worlds” scenario.

And server-side feature-detection is what is being done in my RESS demo and helping me classify browsers… well, sort of. The demo was created to help put my browser- and feature-detection library, Detector, through its paces. One of its core features is offering browser families based on definitions that combine information from traditional user agent parsing (via ua-parser-php) and information from Modernizr-based tests (full list). The families in the demo are not based purely on browser features as determined feature-detection but that’s not to say that Detector couldn’t (and it probably should) be expanded to include more information on, say, browser-window width (which is currently one of the few things it doesn’t capture) and could then rely almost exclusively on feature tests. But there’s actually one area where these cached feature tests would offer a lot of help…

It’s Not Just About Mobile Versus Desktop

RESS, server-side feature-detection, and Detector are not mobile solutions. Yes, they come from people focused on mobile-related issues but any of these options can be used in helping deliver optimized experiences to any browser. In the same way that Modernizr helps polyfill for older browsers, server-side feature-detection and RESS can and do offer similar capabilities. I’d hate to see them get pigeonholed as solutions that are only implemented by mobile developers. I believe that the combination of these techniques can offer a very robust platform for building future friendly websites and apps. That said, there is still work to do to make these solutions as robust as possible.

RESS Doesn’t Solve the Dumb Content Problem… Yet

In Next Steps of Responsive Web Design Jon Arnes Sæterås (@jonarnes) writes, “It is not only the design of the web site and the layout of content that needs to be adapted of enhanced; the idea of being responsive, adaptive and enhancing, must be implemented in the whole value chain.” His value chain contains four parts:

• Stupid Editor
• Stupid CMS
• Stupid Web Server
• Device (I’d suggest browser) assumed to be intelligent

RESS and storing feature-detection results on the server  can go a long way in making the web server smarter and giving us a better idea of just how intelligent that browser is. But even addressing those two things only means that the output is smarter. Neither solutions address how content enters the system (e.g. the editor) and how it’s stored (e.g. the CMS). For example, in the mobile-advanced layout of the demo on whom or what does it fall to properly crop & size the images?

In the same way that responsive web design made designers and front-end developers think more about how to be both mobile and future friendly I’m hopeful that RESS and server-side feature-detection can start a conversation amongst those of us focused on the server end of things (especially content management systems!) about how we can better deliver content to make those responsive web designs that much better. Can we help responsive web design evolve that much more?

About Detector

Detector is a simple, PHP- and JavaScript-based browser- and feature-detection library that can adapt to new devices & browsers on its own without the need to pull from a central database of browser information. Detector dynamically creates profiles using a browser’s (mainly) unique user-agent string as a key. Using Modernizr it records the HTML5 & CSS3 features a requesting browser may or may not support. ua-parser-php is used to collect and record any useful information (like OS or device name) the user-agent string may contain.

With Detector a developer can serve the appropriate markup, stylesheets, and JavaScript to a requesting browser without being completely dependent on a front-end-only resource loader nor a browser-detection library being up-to-date. Detector can be used with a solution like Mustache to provide robust templating support.

The following are the major changes in this release:

ua-parser-php Integration

I was unhappy with the original browser detection library in Detector so I created a PHP-based pseudo-fork of the ua-parser project called ua-parser-php. It is included as a submodule of Detector and provides a much more robust classification system for browsers and mobile devices. Because of the number of attributes it parses out of a user-agent string it should give developers more flexibility when developing solutions.

Browser Families

With the new families feature in Detector developers can organize browsers that share certain traits into groupings. With families a developer can test for a browser’s grouping rather than each individual feature that browser may support when displaying content. This might be especially useful for templating solutions.

Expanded Feature Tests

Modernizr 2.5.2 has been included with this release as well as an expanded set of features including tests for cssremunit, deviceorientation, devicemotion, and lowbandwidth support. See the full list of Detector’s core tests.

Detector Wiki Added

I’ve attempted to grow the documentation for Detector beyond the original, limited README by using the wiki that comes with a GitHub repository. Content includes:

• How Detector Works
• Adding & Using Detector With Your Application
• Detector Test Tutorial
• Detector Family Tutorial
• Templating with Detector & Mustache Tutorial

Other Changes

Those are the big changes but their are a few other, minor changes:

• a configuration file for setting debug mode as well of locations of files & directories is now included
• both core and extended profiles can now be versioned
• the original layout of the files has been cleaned up some
• two simple demos, one for including a YouTube video and the other for templating, are now included
• while not a change in Detector per se, the archive of user agents now contains 170+ user agents and their associated feature tests

If you have any questions about the project please feel free to drop a line in the comments.

When talking “mobile” apps seem to get all of the attention but a mobile-optimized website is a necessity for many businesses. Any company that relies on email or social media to help spread the word about their offerings (think “web links”) really should make sure their website is easily viewable on a phone. Jason and Lyza do a fantastic job of taking a “new to mobile” developer through the various options that are available for making a website mobile-optimized (their are many!).

The book includes hands-on lessons with each chapter (including code you can download) and useful “case studies” to make it clear how each technique should be used. By covering the latest trends like Responsive Web Design and HTML5 APIs and some old school techniques like device detection and CSS-MP “Head First Mobile Web” makes a great resource for anyone looking to get into mobile web development or, like myself, looking to brush up on their skills.

What I think I appreciate most about the book, beyond the depth & practicality of the information, is Jason’s and Lyza’s frankness in the pros and cons of each solution and being clear how each can be useful. I was most struck by this in the WURFL section. A lot of time is spent talking device detection (one of my favorite mobile techniques) but they’re very clear about some of the licensing downsides to the product. They don’t just gloss over that very important issue.

It’s a surprisingly quick read considering the thickness of the book. That’s probably because, rather than being big blocks of text talking theory, it has a lot of practical examples, tips & tricks and uses a great conversational tone. This book really is designed to be, above all, practical and easy to learn from. If you’re at the start of a project and want to know what is available to you with mobile web or using web technologies (they also cover PhoneGap for making HTML-based apps) you should really pick this one up.

ua-parser-php is a PHP-based pseudo-port of the ua-parser project. ua-parser-php is designed to parse a user agent string and return certain properties like browser name, OS version, and, in some cases, device name. ua-parser-php utilizes the user agents regex YAML file from ua-parser but otherwise uses its own set of properties to describe a browser, OS, and device. ua-parser-php was created as a new browser-detection library for the browser- and feature-detection library Detector.

If you want, you can test your browser against ua-parser-php. As usual, the code is available on GitHub.

Usage

Using ua-parser-php is straightforward. Simply include it in your project, make the call to parse the user agent and you’ll be returned an object with various properties of the user agent. Examples follow:

<?php

    require("UAParser.php");
    $result = UA::parse();

    print $result->full;
    // -> Chrome 16.0.912/Mac OS X 10.6.8

    print $result->browserFull;
    // -> "Chrome 16.0.912"

    print $result->browser;
    // -> "Chrome"

    print $result->version;
    // -> "16.0.912"

    print $result->major;
    // -> 16 (minor, build, & revision also available)

    print $result->osFull;
    // -> "Mac OS X 10.6.8"

    print $result->os;
    // -> "Mac OS X"

    print $result->osVersion;
    // -> "10.6.8"

    print $result->osMajor;
    // -> 10 (osMinor, osBuild, & osRevision also available)

    /* 
     * in select cases the device information will also be captured
     */

    print $result->deviceFull;
    // -> "Palm Pixi 1.0"
       
    print $result->device;
    // -> "Palm Pixi"

    print $result->deviceVersion
    // -> "1.0"

    print $result->deviceMajor;
    // -> 1 (deviceMinor also available)

    /*
     * Some other generic boolean options
     */

    print $result->isMobile;
    // -> (would return true if the browser met the criteria of a mobile browser based on the user agent information)

    print $result->isMobileDevice;
    // -> (would return true if the device met the criteria of a mobile device based on the user agent information)

    print $result->isTablet;
    // -> (would return true if the device was a tablet according to the user agent information)

    print $result->isSpider;
    // -> (would return true if the device was a spider according to the user agent information)

    print $result->isComputer;
    // -> (would return true if the device was a computer according to the user agent information)

    print $result->isUIWebview;
    // -> (would return true if the user agent was from a uiwebview in ios)
?>

If you want to grab a copy of the YAML data from ua-parser each night you can use a cron job and point it at the following bit of code:

<?php

   require("UAParser.php");
   $result = UA::get();

?>

NOTE: Using this feature will overwrite a number of changes I’ve made to the user_agents_regex.yaml file included with the ua-parser-php distribution.

Credits

Thanks to the ua-parser team for making the core data available to others so we can build our own solutions.

The full note from Karine regarding her survey is below:

Hello,

I’d like to invite you to complete this short survey about the state of the mobile web (mobile websites, apps, etc.) at your institution:
higheredanalytics.com/mobile

This is the second edition of this survey and 105 of your colleagues already completed it but we need more. Its goal is to assess how colleges and universities respond to the needs of the increasing population of mobile device owners.

Please take the survey whether or not your institution has a mobile solution - as I’m trying to evaluate the current state for higher education as a whole – and not just for early adopters.

The results of this survey will be used for presentations and articles. Anybody who completes the survey will receive a copy of the executive summary of the survey report as well.

If you have any questions, please let me know. Thanks for your time and your help.

Karine

Higher Ed Mobile Web Summit
http://higheredexperts.com/mobile

With the initial release of Yiibu’s Profile, Detector is already YABFDL (Yet Another Browser- and Feature-Detection Library). The main question behind Detector, “How does one go about intelligently combining browser- and feature-detection into one package?,” has been floating around in my head ever since I heard Yiibu’s talk, Adaptation. Because of two recent events, our holiday card project and the OpenDDR/WURFL/ScientiaMobile kerfuffle, I decided to finally tackle that question and see what I could come up with to answer it.

Introducing Detector

Detector (demo & code)  is a simple, PHP- and JavaScript-based browser- and feature-detection library that is still in its infancy. Detector gives server-side developers information about what types of devices may be requesting their content as well as the HTML5 & CSS3 features a requesting browser on that device may or may not support. With Detector a developer can serve the appropriate markup, stylesheets, and JavaScript to a requesting browser without being completely dependent on a browser-detection library being up-to-date nor completely dependent on a front-end-only script loader. Detector is based on Modernizr, modernizr-server, and the browser-detection library from Mobile Web OSP. It also benefits from a healthy dose of inspiration from Yiibu’s Profile. Want more of the gory, technical details? Check out the README for more information.

Why Create Detector?

With Yiibu’s Profile, Luke Wroblewski’s (@lukew) article, “RESS: Responsive Design + Server Side Components,” and the Future Friendly movement I think that more and more folks are accepting that server-side technologies still have a large part to play in delivering mobile-optimized solutions. That being said, browser-detection cheerleaders like myself can learn a thing or two from the responsive design/feature-detection folks. Detector was created as a way of, hopefully, combining the best of both browser- and feature-detection and giving server-side developers a lot of power and flexibility in developing cross-browser, as well as mobile, solutions.

Flexible & Future Friendly

I wanted to address two primary goals when developing Detector. The first goal was to create a solution that was forward looking and could adapt to new devices and browsers on its own. I didn’t want a developer to have to worry that their website might break if a new a browser came out with a different user-agent than those already being tracked. This is one of the real strengths of using feature-detection as a solution. A feature is either available or it isn’t. The first time Detector gets a visit from a new user-agent string it tests that browser for all of its available features and saves that profile to disk for future use with other browsers with that same user-agent. In this way Detector can grow and adapt to changes in the browser & mobile landscape. Also, because Modernizr (and it’s long list of pre-built tests) serves as the core feature-detection library of Detector a developer can add and track their own tests just by using the Modernizer.addTest() plug-in API.

Open Browser & Device Knowledge

My second goal was to see if I could find a way to capture and share device knowledge. While Detector is focused on browser knowledge as opposed to device knowledge I think the information is still useful overall. Especially to web developers who are, for the most part, only ever going to interact with the browser anyway. I feel very strongly that their should be a central, open resource for developers to rely upon to not only learn what browsers support what features but a way to use that data within their applications. Because of that I have signed onto the Open Device Knowledge Collaborative. Detector is not nearly stable enough to help create that resource now but I do hope that it can in the future. At some point I will create a central repository of browser profiles that anyone can use in their applications (with or without Detector!) and, via Git, developers will be able to submit their own profiles back to the central repository for others to use. It’s an ambitious idea and their are a lot of hurdles yet to overcome but I do think it’s an important goal for Detector and the community at large.

Where Detector is Going

Detector is far from perfect as a solution. As I said, it’s in its infancy. I’d love to see the following get addressed:

• New profiles could contain bad data that, in its current incarnation, wouldn’t get updated by more “reliable” browser visits in the future. Basically, is there a sampling and/or confidence metrics that could be used to re-test browsers?
• Modernizr-based media query tests seem to be really flaky and it’s obviously a problem with Detector itself. When I use the media queries outside of Detector they work as expected.
• Versioning of profiles as well as creating that central repository so profiles can be used by anyone.
• Most importantly, Detector needs more browsers to use it to really test its capabilities and accuracy.

While it is still early days for Detector hopefully lessons can be learned from its implementation for others developing similar solutions.

Helping Me Test Detector

If you can, please hit the Detector demo (http://detector.dmolsen.com/) on, preferably, your mobile device of choice and see if Detector works as expected. If it doesn’t please shoot me a note from the contact link under the Browser Profile information.

Examples of Syncing Events

To get an idea of what I mean by “syncing web page events with an embedded YouTube video” it might be good to check out two examples. The first example is very simple and it’s the one I created as a proof of concept for our holiday card project. The example page explains what you should see. The second example is the holiday card itself. The holiday card example will only work on Safari, Chrome and Firefox because of the CSS3 animations we used.

The main thing we did with the holiday card project to make the experience seem seamless was to hide the text and other traditional page “chrome” when the video started playing. We did this with a simple opacity transition and then moved those elements far off the screen. Once these elements are removed the viewer is left with the video playing and the background. The background, an overview of our campus, is not a static though. The main character in the holiday card video was a sprite visiting and bringing holiday magic to various locations around campus. As the sprite visits places like our freshman dorms or our football stadium the location of the sprite is highlighted on the page background with those same locations changing color. It’s a subtle effect because we didn’t want to distract too much from the video itself. My favorite part is the sprite rising into the air from downtown Morgantown (only viewable in Safari & Chrome because of a specific type of CSS3 animation).

So how did we do it?

YouTube’s JavaScript Player API

I think many folks are familiar with the various parameters that one can set on an embedded YouTube video to control how it looks & behaves (e.g. turn off related links). If you aren’t familiar with them go check them out now. They can give you a lot of control, especially from a branding perspective. One step beyond that though is the YouTube JavaScript Player API. It allows developers to control the player itself. It’s important to note that the YouTube JavaScript Player API only works with the older embed code. An API for the iFrame embed is currently experimental.

The YouTube JavaScript Player API allows you to use, you guessed it, JavaScript, to control things like starting a video, stopping a video, changing what video is playing in the player, playback quality, and even the player volume. While those things are useful, the best feature of the YouTube JavaScript Player API, especially when looking at syncing actions between a web page and video, is the event onStateChange. It is fired every time the video is started, paused, buffered, or ended. Luckily, there’s a simple YouTube JavaScript Player API wrapper, YouTubePlayer (originally created by Anurag Mishra), that makes it easy to quickly embed a video (via SWFObject) and then listen for these onStateChange events.

Using onStateChange & YouTubePlayer

Using YouTubePlayer to listen to these onStateChange events is actually quite straightforward. As with any video the first thing you’ll want to do is embed it. All you need to know is the ID of the <div> where your video will be embedded and the ID of the YouTube video.

var vidId 	= 'videoEmbed';	 // the ID of the div holding the video
var vidYTId	= 'XhLrlhFzAjA'; // the ID of the video from YouTube

var YTVideo = new YoutubePlayer(vidId, vidYTId,{
    width: 640,
    height: 360,
    objparams: { allowFullscreen: "true" },
    ytparams: { rel: 0, showsearch: 0, showinfo: 0, modestbranding: 1  }
});

// objparams are the parameters that might get included in the old embed code (e.g. fullscreen)
// ytparams are the youtube player parameters

Once that’s done you can set-up event listeners that do something when the event you want to track is fired. For example, let’s listen for when a viewer starts playing a video and then listen for when the video ends. It’s important to note that ‘playing‘ is fired after a user pauses and then restarts a video. There’s no differentiation between starting a video for the first time and after pausing the video.

// listen for when the viewer decides to start playing the video
// hide the intro & outro text divs as well as "lower the lights"
YTVideo.on('playing', function() {
	document.getElementById('intro').setAttribute('class', 'text hide');
	document.getElementById('outro').setAttribute('class', 'text hide');
	document.getElementById('lights').setAttribute('class', 'darken');
});

// listen for when the video ends
// show the outro text div as well as "bring up the lights"
YTVideo.on('ended', function() {
	document.getElementById('outro').setAttribute('class', 'text show');
	document.getElementById('lights').setAttribute('class', 'lighten');
});

YouTubePlayer gives really easy access to these events via the .on() function. But what about timing events like the fireworks in the original example?

Timed Events with YouTubePlayer

I  added the .at() alias and expanded the .on() functionality for YouTubePlayer to make it really easy to add timed events. Using the fireworks as a quick example:

// between 13secs and 17secs shoot off a firework every half a second (500ms)
YTVideo.at('13000-16500', function() {
	createFirework(14,73,3,2,null,null,null,20,true,true);
}, 500);

Essentially the .at() function registers events with the browser with a certain name based on the time the event should take place (e.g. 1100). These events are then fired by a setInterval() function that tracks time once the viewer starts watching the video. Every time the tracked time is incremented (e.g. from 1000ms to 1100ms) a corresponding event is fired (e.g. 1100). Thanks to onStateChange, if the video is paused or buffering the tracked time isn’t incremented and no event is fired. If a video is scrubbed the tracked time is updated appropriately and incremented again.

For the most part timed events can be fairly straightforward as shown in the source for the simple example. It can also get a little complicated as seen in the source for the holiday card timed events JavaScript. With the latter I was trying to make sure, because buildings stay highlighted after their event is fired, that if a user scrubbed backwards in time that buildings would be hidden again if appropriate.

A Warning About Timed Events

There is one very important thing to keep in mind when working with timed events. Because the tracked video time is sort of faked by using the setInterval() function (e.g. we’re not polling the video directly for the current time in the video. that’s just not a good idea nor accurate) the tracked time can fall behind the real video time. The main culprit for this is heavy JavaScript that gets called by your timed events and then causes the execution of the setInterval() to be blocked until the heavy JavaScript finishes running. Keep whatever you launch via the timed events as light as possible. Simple manipulations of the DOM might be best. That way, if you have a longer video, the timed events will play when they’re supposed to.

Conclusion

I always find it difficult to explain something like this without saying “Just look at the code.” Hopefully you were able to get a reasonable idea of how easy it is to use timed events to sync web page content with your embedded YouTube videos. I think there are a lot of opportunities to create richer experiences for viewers with this technique.

Making it Snow

In order to make it snow in our project I modified some CSS created by Estelle Weyl (@estellevw) for a SXSW talk she gave. The talk does a great job explaining the ins-and-outs of the CSS that gets used (e.g. animations, border-radius, timing) so I won’t repeat that here. The main contribution I made, beyond tweaking the CSS some to have the snowflakes look the way I wanted, was to create an easy way with JavaScript to:

• randomly places N amount of snow across the web page
• randomly assign classes to each snowflake to randomize their look (e.g. size, speed, delay, opacity)
• properly detect the height of a web page when snowflakes are created and update the animation keyframe so they fall an appropriate distance instead of a “one size fits all”-style. Unfortunately, window.onresize is not accounted for.

You can view a demo of the CSS3 snowflakes in action. If you think it’s interesting you can grab the code (CSS & JavaScript) on GitHub to use on your own site. Directions on how to get it snowing are in the README.

Dependencies & Browser Support

There aren’t any real dependencies for this project other than browsers that support animations. This means this project can be used with Safari, Chrome, and FireFox. If the appropriate -ms- extensions were added it would probably work with Internet Explorer 10 as well. In the demo I use domReady to include the JavaScript in the <head> but that’s not necessary if you instead put the code before the </body> tag.

Dave Olsen – Developing a Progressive Mobile Strategy – BD Conf, Sept 2011 from Breaking Development on Vimeo.

The folks at Breaking Development are slowly sharing the videos of the other talks at the September event. I highly, highly encourage you to check them out. Many thanks to them for sharing mine and the others.

Those who work in a university setting are aware of mobile devices and their potential for enhancing campus life. In response, vendors are offering mobility solutions that claim they can address the needs of a typical university. This sounds appealing, but in reality a solid mobility strategy will likely consist of a suite of tools, approaches, and partnerships. This webinar will identify some of the big questions surrounding mobility and describe the approach that the University of Mississippi is taking for each. Examples are selecting scenarios that are good candidates for mobility, targeting native programming efforts to get the biggest bang for the buck, determining when to outsource and when to “do it yourself,” and employing successful mobility strategies from other industries. Also included will be highlights from a recent mobility survey. For Ole Miss, a solid mobility strategy has evolved from focused study and struggle, yielding valuable insights for other institutions.

To attend the event you’ll need to register.

Related to this webinar is the ECAR report, Mobile IT in Higher Education. There’s an infographic that sums up the report. It’s always good to get more insight into how mobile is being used in higher education.