Back in April we mentioned that we were working on a new responsive design for the main W&M website (www.wm.edu), and after a few browser fights (thanks Internet Explorer), a dozen test devices and many hours coding and tweaking, we launched our new design on July 23, 2013. (Grad school sites will follow suit in the coming months.) Now every office, every academic department and every other page on the W&M site adjusts its layout to best accommodate how you are viewing the site, regardless of what device you’re using (desktop, laptop, tablet or mobile).

The announcement

To announce the launch our office made a little stop-motion video (our first!) starring the computers, phones and tablets of various Creative Services staff members:

The motivation

Desktop/laptop view of the W&M website. The green bar on the left is the page navigation, center light tan area is the main content, and the darker tan boxes down the right side are the supplementary content.

The idea behind this change was spurred in large part by the fact that our mobile and tablet visits have gone from less than 2% of our site traffic in 2009 to over 17% of our traffic this summer. With so many mobile and tablet visitors (and more sure to come) we wanted to ensure everyone could easily navigate and view all of the content on our website, not just our homepage (which we made responsive last year).

Prioritizing

So what was involved in this redesign? Up first was evaluating which parts of any given page are the most important, and it is, unsurprisingly, the main content. That main content is why you search Google, click a link in a social media post, or work your way through navigation menus. This needs to be front and center (and top) regardless of how you are looking at the website. So, after our global site navigation and header, the most prominent thing you will see is always the main content. We then ordered the rest of the content: page navigation, supplementary content, etc.

The major changes

Tablet view. Here the right column has been moved below the main content area and the top “global” site navigation has been adjusted from one row to three.

As you begin decreasing the width of your browser window we adjust the global navigation to become three columns rather than one row (since the single row will no longer fit).

We then move the right column, which contains “widgets” with photos, Twitter feeds, related links and other supplementary content, down below the main content area.

So, with this first batch of changes nothing is removed, only rearranged to best showcase the content (this is a key feature of responsive design). Once the page width is even narrower, the menu on the left side of the page drops down below the main content as well (keeping its familiar green background for continuity). However, keeping in mind that page navigation is a useful and important part of the page, we provide a “Site Menu” link so you can quickly get to that area when you need to. In between all of these steps the content is stretched to fit the width of the page, and photos and tables are resized to be as visible as possible.

Those with a careful eye may also notice a few style tweaks, all made to enhance the user experience. We removed busy lines from the menus, adjusted the color and size of the content headings, and increased the font size and line height of the content. All of these updates were made to give the site a bit more space to “breathe” and to make things easier to read. We also ensured that our treatment of text links is consistent throughout the site, helping with the overall usability of the site—if a word is bright green (underlined or not) it is always a link.

Cheap as free “mobile version” for all, no app needed

Mobile view. A link to the site menu replaces the menu itself and the main content comes up front and center, with supplementary content following.

One of the best parts about a responsive design is that it is a seamless improvement for the folks creating the web content. Nothing changed in Cascade (our web content management system) from the web editor’s perspective. They still enter their page title, content, photos, links and so forth, just as they always have, except now the content they entered is mobile (and tablet and desktop) “friendly.”

What’s next

Currently our team is focusing on updating our four graduate school sites with their own responsive designs. Along the way we’ll also be making a variety of supporting sites responsive (those W&M sites not hosted in Cascade, like the directory, W&M Experts and W&M Events).

What do you think of our new design?

Mashable named QR codes one of the 8 Big Trends That Shaped the Mobile Phone Industry in 2011, and being in on the latest trends is always tempting. I am all for exploring the latest technology, but I think a key step to take before using them (or any new technology) in your organization is familiarizing yourself with the technology beforehand. Sign up for that new social media site and use it personally for a while, or in the case of QR codes, how many times have you scanned a QR code with your phone? Or known others who have? When have you found it helpful?

Scott Stratten‘s UnMarketing Keynote at the National Arts Marketing Project conference offers some (rather humorous) examples of how not to use QR codes:

If you get past the step of concluding a QR code would be a useful addition to something your organization is doing, there are a few things to keep in mind:

Is the web site linked in the QR code optimized for mobile devices?

People are using their mobile phones for viewing whatever the QR code sends them to. You need to make sure the destination website is at least a mobile-friendly site (so the page is navigable on a small screen with no Flash, giant images, heavy Javascript or other visual effects), if not totally mobile-optimized.

Since your users are on mobile devices with smaller screens and slower download and processing speeds you must consider the structure of your content. Does the page require filling in a lot of information? Or downloading a large document? Or viewing a large amount of text or photos? If so, that’s probably not the best suited to viewing on a mobile site or interacting with on a, typically slower, mobile network.

Is the content useful in a mobile setting?

Another thing to think about is whether the information you’re linking to is something that a person who is on a mobile phone would find useful and interesting. The link could utilize the fact they are on a mobile phone to add your organizations event to their personal calendar, or a contact to their address book. Or you could offer additional photos or videos related to something you’re advertising; “exclusive” content that’s just for folks who scanned the QR code. However, if you’re simply directing them to a page on a website that they could just as easily see on their computer, that’s not really rewarding the scanner for their time and effort (however minimal) to scan the QR code.

Is there a reward/motivation for scanning the code?

Something to keep in mind for higher education institutions in particular, a recent survey reported that most (75%) of college students won’t scan QR codes, so whatever the content is, it needs to be something that motivates the students enough to be willing to download a QR code reader (if they don’t already have one) to find out the information.

Learn More

Intrigued? Hubspot offers a quick 4 step setup guide that can get you started. Plus, here are a few more good tidbits about QR code use:

“QR codes function as context portals, enhancing our in-person experience with related digital information — for example, a flyer for a career workshop with a code driving you to a basic (mobile-friendly!) registration form or an advertisement for a concert featuring a code linking to a short video preview. There’s a lot of debate about the future of QR codes, but whether they stay or or go these types of informational way stations will be critical connectors in this new landscape, delivering contextually-relevant content.”
-Georgy Cohen, Aligning Content Online and Offline, Meet Content

“QR codes do enjoy a high-level of awareness among college students yet only a fraction (21%) could properly scan and activate the code. Why the discrepancy? According to our findings, students simply struggled with the process. Some didn’t know a 3rd party app was needed, many mistakenly assumed it could be activated with their camera, and others just lost interest, saying the activity took too long.”
-Don Agguire, QR Codes Go to College, Archrival Youth Marketing

“Employ simple language around the code itself.  Not necessarily every user knows what a QR code is or that you must download the app prior to using.  An example ‘Scan this code with your smartphone to watch these stories’ and be as specific as you can as to what the viewer will see.”
-Nicole O’Connell, To Scan or Not to Scan: Use of QR codes in Enrollment Marketing

Another interesting read is Mashable’s Why QR Codes Won’t Last which drummed up a lot of discussion in the comments.

Have you successfully (or unsuccessfully) used a QR code in a campaign? What was your experience?

I presented alongside Doug Gapinski from mStoner about mobile strategy for higher education. The talk was well received on Twitter (tracked via hashtags for each session, ours was #tnt8) and I’m excited that folks were so interested in our topic. HighEdWeb’s magazine Link summarized our talk summarized our talk twice (!) if you’re curious about what we discussed.

I attended a lot of great talks and have some great ideas to bring back to campus. Here are their Twitter hashtag commentary (with a quick-and-dirty archive courtesy of Twitter RSS) and summaries courtesy of Link:

• #mmp1 – Creative Services anyone?
• #soc2 – Beyond blogging: Create and integrated online student ambassador program
• #aps3 – What students want in their mobile application
• #tnt4 – Lost in a map: Understanding the direction of your campus map
• #soc5 – Engaging your global audience with real-time event coverage (best in track)
• #aps9 – The politics of doing higher ed IA (best in track)
• #soc10 – E-Expectations 2011: The online expectations of prospective college students and their parents (only saw a small part of this one)
• #mmp11 – How to break things really good
• #aps12 – One calendar to rule them all
• #mmp12 – What colleges can learn from the Insane Clown Posse (best in track)
• #tnt3 – Carrying the Banner: Reinventing News on Your University Web Site (best in track and best in conference)

As always this is a great conference with great speakers and networking opportunities, looking forward to HighEdWeb 2012 in Milwaukee!

What we wanted to do for W&M’s Dress the Griffin app was, when a button was pressed, open a video fullscreen, automatically play it, and when the video completes, return to the previous screen. It took me a while to find the correct Android widget to use, but once I did, things were pretty straightforward (I went off-track for a bit trying to get a MediaPlayer to work, but it turns out there’s a VideoView explicitly for doing what I was looking to accomplish).

The two main files you’ll need for a full-screen video player are a new Activity class that will create a VideoView and set it as the main content view until the video playback has completed:

package yourpkg;

import android.app.Activity;
import android.media.MediaPlayer;
import android.media.MediaPlayer.OnCompletionListener;
import android.net.Uri;
import android.os.Bundle;
import android.widget.VideoView;

public class VideoPlayer extends Activity
   implements OnCompletionListener {

	private VideoView mVideoView;

	@Override
	public void onCreate(Bundle b) {
		super.onCreate(b);
		// Bring the video player to the front
		setContentView(R.layout.videoplayer);
		// Get a handle on the VideoView
		mVideoView =
			(VideoView)findViewById(R.id.surfacevideoview);
		// Load in the video file
		mVideoView.setVideoURI(
			Uri.parse("android.resource://yourpkg/raw/videoname"));
		// Handle when the video finishes playing
		mVideoView.setOnCompletionListener(this);
		// Start playing the video
		mVideoView.start();
	}

	@Override
	public void onCompletion(MediaPlayer mp) {
		// The video has finished, return from this activity
		finish();
	}
}

And a layout XML file to show your video fullscreen:

<?xml version="1.0" encoding="utf-8"?>
<!-- Create a full-screen layout
	The video I'm playing back is portrait/vertical so
	set the orientation accordingly.
-->
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >

<!-- Create a full-screen VideoView -->
    <VideoView
        android:id="@+id/surfacevideoview"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
    />

</LinearLayout>

Once these are set up you are pretty much ready to go, all you’ll need to do is start the video playback activity, spurred by a button press or something similar:

Intent videoPlaybackActivity =
	new Intent(v.getContext(), VideoPlayer.class);
startActivity(videoPlaybackActivity);

and you’re off.

The three main things you have to be aware of are file size, aspect ratio, and video encoding.

File Size: Try and make your video the smallest file size and lowest resolution that you can tolerate, since this will be played back on a myriad of devices with a wide range of memory limitations.

Aspect Ratio: Keep in mind your video will be letterboxed to fit the screen dimensions of each device, so make sure you can handle the smallest size and screen density that you can (depending on what devices you plan on supporting). For more about supporting multiple screen sizes the Android documentation offers a pretty nice overview.

Video Encoding: This caused me more problems than anything else. I was presented with a lot of “Sorry this video cannot be played” messages, blank screens that would immediately kick back to the main screen, or blank screens that would only play the audio and not the video on my way to finding the correct video encoding (and all of those symptoms are frequently, if not exclusively, caused by incorrect video encoding).

The Android documentation’s list of supported media formats was a good start, but even when I thought I had the correct encoding I was still having major issues with playback. Luckily a great open-source multi-platform video transcoder app called Handbrake came to the rescue. After tweaking seemingly every possible combination of controls in Handbrake I ended up back on what was essentially the “iPhone and iPod Touch” preset. So here are the video export settings for Handbrake that worked for me for video playback for Android:

• MP4 format (so end up with a .m4v file)
• MPEG-4 video codec (with “constant quality” setting QP 14)
• AAC audio codec, 128 kbps

The only change from the “iPhone and iPod Touch” preset is that the video codec is changed from H.264 to MPEG-4. This tweak wasn’t really intuitive from the documentation (which made it seem like either H.264 or MPEG-4 should’ve been fine) but this is what ultimately worked for me.

Happy full-screen video playing!

/* Action taken when the "Save" button (saveAsImageButton) is pressed in the app */
- (IBAction)saveScreenshot {

   // Define the dimensions of the screenshot you want to take (the entire screen in this case)
   CGSize size =  [[UIScreen mainScreen] bounds].size;

   // Create the screenshot
   UIGraphicsBeginImageContext(size);
   // Put everything in the current view into the screenshot
   [[self.view layer] renderInContext:UIGraphicsGetCurrentContext()];
   // Save the current image context info into a UIImage
   UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
   UIGraphicsEndImageContext();

   // Save the screenshot to the device's photo album
   UIImageWriteToSavedPhotosAlbum(newImage, self,
      @selector(image:didFinishSavingWithError:contextInfo:), nil);
}

// callback for UIImageWriteToSavedPhotosAlbum
- (void)image:(UIImage *)image didFinishSavingWithError:(NSError *)error contextInfo:(void *)contextInfo {

   if (error) {
       // Handle if the image could not be saved to the photo album
   }
   else {
      // The save was successful and all is well
   }
}

Note: The bulk of these functions are out of Apple’s UIKit framework so check out their documentation for even more information.