Back in November, Chas Grundy wrote about our emergency procedure for ND.edu. When we implemented this feature for ND.edu, we based the functionality on a single-source file. This gave the ability to update the message on both ND.edu and emergency.nd.edu quickly and easily. The added bonus to this approach is that we could then use that same file to build a script that could be used on any Notre Dame site to display the emergency message. But I’m getting ahead of myself.
Last week I attended HighEdWeb which took place in Austin, TX. This was my first trip to this conference, and perhaps feeling a little over-ambitious, I co-presented a talk with programmer extraordinaire Jeremy Friesen titled “Feeding the Beast”, which was about encouraging API use around Notre Dame. I also took part in the poster presentation portion of the conference and presented on how we (Marketing and Communications) use a base theme to build all our sites which gives us a jump-start on accessibility and mobile on each design.
The code for Jeremy’s and my talk and the visuals for my poster presentation are up on my GitHub account Also included are Jeremy’s and my notes for the talks we attended. Slides for the API presentation are on Speaker Deck.
As developers, there’s a number of things we should be sure to include into each site we build to help with accessibility. One of the most basic of these is access keys.
A couple days ago in a post-meeting chat I mentioned to my Project Manager Extraordinaire @GtownNick, that I’d like to extend our development time on custom sites by a couple of hours so we could spend a little more time to focus on responsive web design with each build. He responded that just the other day one of our clients was concerned because they resized the browser window on a recent project and elements of the design started to move around on the page. They stated that they would prefer to see a horizontal scroll-bar, rather than have the approved design change with the width of the window. I was confused by this this statement. Why would they not want the site to respond to different size screens?
After some thought I realized that their concerns and subsequent statement was entirely our fault.
It’s All About Sharing Content
One of the basic tenets behind the internet is sharing data. Initially, that was primarily done with HTML. But with the rise of web applications, sometimes plain HTML just won’t do. That’s where API’s and feeds come in. An application with a proper API allows other applications to query it for content and get that content back in a variety of formats, be it XML, JSON, or HTML. Feeds on the other hand are a one-way distribution of data, usually in XML format.
Repetitive Stress Injury (RSI) and I are long-time enemies. For me, it manifests as pain from the wrist of my right hand moving up to near the elbow. This started my senior year of college. Near the end of graduation I picked up my first ergonomic keyboard (an Adesso model) that followed me to my first post-college job as an audio engineer. Since those early days I’ve tried a half-dozen or so split keyboards and wide variety of ergonomic Logitech mice, all the while searching for that magical combination that would reduce or eliminate the aches and pains that is RSI.
Anyone who owns an iPhone 4 has experienced the beautiful new Retina Display. Text is amazing, colors are vibrant, but apps and sites that are not updated to handle this display usually look less than stellar. This is because the Retina Display, which has a display that is twice the resolution of most devices, scales images up so they appear to be the “correct size”. The solution to this is to target these devices using a media query and replace the graphics with a higher-quality version.
In the last article, we made our print stylesheet. Now we’re going to take that stylesheet and turn it into a basic mobile stylesheet. Now when I say basic, I’m talking VERY basic. This is not what you’re displaying to your iPhone and Android users.
In my last article, I made mention that you should at least include a basic mobile stylesheet for your site. The easiest way to accomplish this is to piggy-back your print style. What? You say you don’t have a print stylesheet? Bad developer. In this article, we’re going to run through the very basics of a print style, and move on to basic mobile in the next.
Over the past year at Notre Dame, we’ve really started to embrace and experiment with offering a mobile experience for a number of the projects that have made their way through our offices. There are a couple of obstacles that make this process difficult.
- A separate “m.” address is not an option
- Creating and testing mobile styles is rarely part of the project budget
This has led to some commonly used shortcuts that have allowed us to, at the very least, provide a serviceable mobile experience with very little effort.