skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters


Responsive Images for 60 Million Websites

Last fall I joined the W3C‘s Responsive Images Community Group after being inspired by (and having lunch with) Mat “Wilto” Marquis, the group’s chair, when he spoke at An Event Apart in Austin. The RICG calls itself “a group of independent designers and developers working toward new web standards that will build fast, accessible, responsive websites.” Mostly my contributions have been limited to fixing typos on Github and making wisecracks on IRC, but I’m pleased to have contributed to the newly-released RICG Responsive Images WordPress plugin. (Technically, I added support for PHP 5.3 and below, versions which don’t support function array dereferencing.)

The RICG’s first achievement was to push through a new HTML element – picture – along with its friends srcset and sizes. These allow web developers to offer images in various sizes and let the browser decide the best one to use. A retina phone can display the 2X retina image, an older feature phone can display a little 200px image, and your ultra-wide monitor can display a full-bleed 1920×1080 image. Best of all, the browser only downloads the image it needs – no double download.

I consider responsive images a perfect example of progressive enhancement  – fully supported on Chrome and Opera, and partially supported in Webkit and Firefox. Even Microsoft is working on adding these features to Internet Explorer its new browser. And the Picturefill script adds responsive images capabilities to any browser. Until now, responsive web developers like me have been sending oversized images to be squeezed onto little phones, wasting much of our users’ bandwidth. Mat Marquis says that people in Africa actually have to keep lists of which websites they can’t visit without draining their entire monthly bandwidth. So if we use responsive images when someone’s mobile browser doesn’t support them, the user experience will be no worse off. But if the browser does, his or her experience will be much faster and more pleasant. An image on a mobile phone might only need to be 1/5 the size in kilobytes of an image on a typical laptop.

The WordPress plugin is a first step to adding responsive images to the core of WordPress itself. When that happens, webmasters of 60 million websites can upload large, clear images, and their visitors will only download the image size they need. The plugin comes bundled with Picturefill, and since WordPress already keeps track of multiple image sizes automatically, the future looks good.

Resources for responsive images:
Responsive Images in Practice – Eric Portis
Responsive Images – RICG
Why Responsive Images Matter – Mat Marquis

Wednesday, January 21st, 2015 Accessibility, Mobile Web, Programming No Comments

Do Frameworks, Libraries, and Themes Speed Up Your Development?

Web developers can be funny (in case that’s news to you). Myself, I get tickled by the Vanilla JS website. According to the Vanilla JS team, “Vanilla JS is already used on more websites than jQuery, Prototype JS, MooTools, YUI, and Google Web Toolkit – combined… It is the most lightweight framework available anywhere… your users’ browsers will have Vanilla JS loaded into memory before it even requests your site.”

How can it do that? Because they’re joking – vanilla.js is an empty file (or an empty line in production sites). It reminds you that if you want to fade out elements or make an Ajax call, you can use plain vanilla Javascript – you don’t need jQuery. In fact, jQuery takes more lines of code to do the same thing as Javascript (well, if you include some newlines).

Yes, frameworks and libraries can speed up common web development tasks. But you have to learn how to use them first. And then, what about tasks that are not so common? Then you have to figure out the “jQuery way”  or the “SASS way”  to solve the problem.  Or the “Zend way” or the “Node.js way” or the “AngularJS way.”

I have the same problem with WordPress themes and plugins. They offer widgets to do common tasks, but if they don’t do what you want, you have to figure out what they are doing – what function you have to fix, in what file.  The other day, I felt a little challenged because I couldn’t find some of the CSS for our new Canvas-themed WordPress site.  “But wasn’t it in your stylesheet, Michael?” No, since themes are “highly customizable,” the options panel was generating a separate set of styles. (Note to team: the options panel can be disabled.)

Veteran Linux users will recognize the underlying problem. That’s why they like to use the command line, because it does exactly what you want – as long as you don’t mistype anything. When people who feared code started to blog, they often remained prisoners of their fears. For example, simply to change <?php echo get_the_title(); ?> to <?php echo get_the_title()," | My Blog"; ?>, they would have to install a WordPress plugin. They had to do things the hard way because they didn’t know an easier way. Part of being a professional web developer, of course, is knowing the easier way – working directly with HTML, CSS, etc.

Handholding is fine as long as you can get your hand loose when you need to.

Thursday, July 17th, 2014 Programming No Comments

Should we continue to support IE7?

While looking through the analytics for yesterday’s post, I decided to take a look at browser use and see how many of our visitors are still using IE7.  We have been doing a lot of behind-the-scenes work on templating style sheets, and to be honest IE7 compatibility has been the last thing on our list — we build the site for everything else and then come back in and add a hacks file to make it work in CSS.  Now that we are spending more of our time working on things like mobile views, I have to ask whether keeping sites working under IE7 is still worth the effort.

The numbers show that we are pretty much inline with national usage figures — about 4.5% of our traffic comes from IE7.  On one hand I would love to say that is enough of a minority that we don’t have to worry about it, but in absolute numbers that is more than 30,000 page visits per month.

I think it might be enough, though, to warrant taking a middle-ground approach.  Do all sites need to look the same in every browser? (correct answer)  We can therefore move forward with our project and realize that we can still design our site to meet current-generation browsers without completely leaving behind IE7.  We can design our sites so that IE7 users don’t get all the bells and whistles, but still get the heart of the content that you are trying to convey.  This is the difference between supporting a browser and optimizing for it.  We can do one without doing the other, make sure that everyone can use our site, but reserving the majority of our time on the experience that will be shared by the vast majority.

Thoughts?  Where does everyone else stand on the issue?

Wednesday, August 15th, 2012 CSS, HTML, Programming 2 Comments

Calendar Events Web Service

As we work on some of our larger projects, we are producing tools for them that might be useful to others of you on campus as well. The virtual tours and the next generation of the mobile site will rely heavily on web services to retrieve the data that gets presented on the page. We see this method as preferable to hard-coded database lookups because it separates data retrieval from presentation. We will be able to change the back end however we want and all we’ll have to do to keep the application running is rewrite the web service to pull the same data in the same format from the new location. This then lets us write several client applications that pull from the same web service and know that a single change won’t require us to rewrite them all.

It also means that we can share more content with the rest of you on campus. In many ways these web services will act as data feeds that allow you to consume our data. The first of these comes from our work on the virtual tour site. It enables us to pull calendar event links for particular buildings on campus. Right now the information is limited, but it could easily be expanded if need be. Feel free to try the service, and use it wherever it could be helpful.

Friday, April 27th, 2012 Programming No Comments – Gutted & Rebuilt in PHP is Texas A&M University’s Flickr presence on steroids. Combining the powerhouses of content around campus into one unified resource. Aimed at proving a solid media outlet for journalists and content providers alike, this refined tool started in .NET and is now completely built in PHP. My goal as the lead developer of this project was to migrate version one’s cover to a framework that could be easily maintained throughout the webmaster office. Although version one was an alright start, it failed at meeting customer requirements and was quite error prone.

Some larger improvements I have made to the system include:

  • “Search” now indexes all A&M Flickr accounts, instead of just one at a time. Check out Reveille.
  • A functioning CMS with integrated approval process and notifications for departments & organizations interested in joining the system.
  • Jeff provided the system with an excellent library for integrating CAS 3 into our login panel.
  • “Media Contacts” are now available for each Flickr account. Need to find out who to contact about a photo? Look no further.
  • Photo was re-structured using the Zend framework, a delightful tool I might add.

Some small improvements include:

  • Random homepage photo is now selectable. Before you had to guess where it resided 🙁
  • Top-level menus have been cleaned up and now reflect the pages that are currently loaded.
  • The drop-down list floats currently selected Flickr accounts to the top of the list.
  • Photo tags link to search appliance. Now you can compare tags of all Flickr accounts simultaneously.
  • URL’s now make sense.
  • Context menus have been added at the individual photo viewing level.
  • Terms “image”, and “photo” were littered all over the site. Let it be known, the site will only state “photo” now. This switch avoids confusion in the long run… or Your dose of url marketing for the day 😉

As always, we appreciate your input. Email us your thoughts and opinions, or post up in the comments.

Tags: , , ,

Friday, July 2nd, 2010 Image repository, News, Programming 2 Comments

Feeds Based Web Design

As we have gone through the road show for the new university website project I have repeatedly stressed the fact that the new site, and indeed almost everything that we now produce, will be heavily dependent on RSS feeds.   Often, however, these discussions will gloss over what a feed is, the value of using feeds, and how the data is processed.

At its most basic, a feed is a data file that is placed online to be downloaded and processed by remote applications.  This allows your content to be displayed and used on other sites across campus, widening the exposure for your information.  In order to be read and processed by applications, feeds are formatted with a specific syntax.

There are several different feed syntaxes, including XML, RSS, Atom, JSON, and many more.  Which one you use depends mostly on the type of information you want distributed.  XML and JSON are both open ended and can contain pretty much any information you want.  RSS was developed specifically for a limited payload, primarily things like title, URL, and description.  This makes it perfect for transferring news article information.  It has, in fact, become the industry standard in this area and is the format that we have settled on for processing news articles into

So how do you process these files once they have been provided?  The widespread use of these file formats has made our life easy in this respect.  Many programming languages have functions for processing them built into the core language.  Many will also have third-party suites of classes/functions that you can include into your code and make life easier.  For example, we use the simplepie PHP code suite for processing most of our RSS feeds.  It is well documented, easy to download and install, and simple to use.  It is the same code that powers WordPress feed processing, so is a well maintained and supported package.

One caveat that we have found – never completely trust the source of the data feed.  If it is not valid syntax it often will not be properly processed by your script.  You also have to watch out for non-legal characters.  Most often these will be the curly-quotes or n-dashes, or other such characters that Microsoft products use.  You will want to create a function that you can pass the feed through to strip out these illegal characters and replace them with their proper values before continue to process and display the content from the data feed.

Creating the feed in the first place is a completely different ballgame.  If you have a good Content Management System or use a blogging platform like WordPress then RSS is built into the system and sharing feeds becomes easy.  If not, you can create your own feed fairly easily.  Just have a look at the RSS specifications, and create a program that will take your content data and write it to a file (or as an online web service response) that is formatted according to the proper RSS syntax.

Tags: , ,

Monday, June 7th, 2010 Programming 1 Comment

Lessons Learned

I think it’s important to use events like last week’s weather advisory posting as a report card for how we are doing.  In this case, the incident revealed a few weaknesses in our procedure and server configurations that we need to shore up.

Within two minutes of the weather advisory being posted on we noticed the TAMU News server start to page incessantly, and within another minute it failed altogether.  This was largely the result of not devoting enough RAM to the virtual machine hosting the site.  We quickly changed the settings and the site did fine for the rest of the day.  This did alert us that we needed to check all of our other sites, especially, and make sure that they all were set to withstand traffic spikes.

It also made us re-evaluate how some of our pages are stitched together.  The TAMU News site, for example, generates much of its content from RSS feeds from across campus.  Assembling all of this dynamically slows the page down enough without having to take into consideration high traffic volumes.  I have therefore changed a lot of the code to pull the information into the page through scheduled jobs rather than on each page load.  I have also started introducing caching to the site to speed the overall load time.  Hopefully these will have noticeable benefits for everyday use as well as keeping the site viable while under heavy load.

Tags: , ,

Monday, March 1st, 2010 News, Ongoing Projects, Programming No Comments

Calendar test and validators down for a bit

Just a quick note to those of you all who might be using the new calendar or who maybe taking advantage of the campus validator (RSS/Atom feeds, X/HTML and CSS). These services will go offline at 3:30pm today (June 3) for about an hour in order to give our admins the opportunity to move the machines. We apologize for any inconvenience.

TechRepublic Top 10 Developer Skills Article

Justin James has written many good articles about development, and has done it again with a recent article titled 10 skills developers will need in the next five years. His list includes some big languages (.NET/Java/PHP), Rich Internet Applications (RIAs), web services, agile methodologies, and mobile development to name a few.

I think the article is spot on with what I’ve been seeing in the industry, and in our shop, we are looking at (or using) many of these technologies already. I like to think that helps reassert our position as a leader in application/web development at A&M. The ones we area actively using are .NET, PHP, agile development practices, web services (REST/SOAP), a bug tracking system (JIRA), and a source control system (Subversion). Soon we will be playing with some RIA and mobile development technologies, something I’m particularly looking forward to.

Tags: ,

Friday, April 10th, 2009 Programming No Comments