But it didn’t end there.

I attended Penn State from 1999 to 2004, and I had an excellent experience. In these last few days I’ve found myself wishing that my time in State College had been stained by a painful set of revelations about a sexual scandal that had taken place in our football department, that was being reported to the authorities and handled completely and appropriately by our university. But none of that happened. We went along eating pizza from the Big Onion in East Halls, studying in the Paterno library, and measuring our most annoying experiences by how long we had to listen to the Willard preacher warn us of coming hellfire and damnation. He was right, in a way.

As more boys were hurt, it looks like my university decided to keep it quiet to protect itself from a heap of sickening shame. They rolled the dice, and they lost, and now those boys aren’t the only victims of this awful mess. And this new batch of consequences—the current team of football players, the current Penn State students and faculty, the potential beneficiaries of Penn State research who won’t be helped because donors will pull their money—these ones are the university’s responsibility. Every person who looked the other way for so long is responsible for the compounded shame that will hang over Happy Valley for a very long time.

A lot of my fellow alumni are responding to this with sadness, but also with a reaffirmation about what makes Penn State great. I understand why, but I disagree with it. Our university spent years trying to duck this shame; I think it’s our duty now to wear it for a time.

Reaching into my 1-year-old son’s dresser this morning, I happened to pull out a pair of navy blue Penn State sweat pants that I immediately shoved back into the bottom of the drawer. I hope State College gets this right, and that they come out with the truth, no matter how awful, and that they do everything in their power and more to make amends—first to the victims and then to the community. But for right now, I don’t want my son to be any part of Penn State tradition. I’m not even sure if I want to be part of it myself.

A quick way to fix this is to just append a query string at the end of the URL, like this:

http://myamazing.url.com/mypage?wiourasefj

Doesn’t matter what the variable is, but if it’s there, the server might redownload the page’s assets. Well, see, being a programmer, I’m lazy. Typing those query string variables over and over was tedious. So I made CACHESMACK to do it for me.

Use it if you’re lazy like me.

CACHESMACK »

If you haven’t heard about Brooklyn Beta, the Analog and Fictive Kin organizing duo describe it as “a friendly, intimate web conference in the heart of Brooklyn with some of our favorite web designers, developers, and business people.” Being small and focused on encouraging attendees to use their magical abilities to bring ideas to life, it generated a lot of, let’s say “eventbuzz”.

What’s “eventbuzz”? As I’m writing this, the following Twitter exchange appeared in my Timeline in the span of about 30 to 40 seconds.

No speakers have been mentioned, no schedule posted, almost no information is available at all except the date and the venue, and the (update: first day’s quota) tickets sold out in 45 seconds, max. That’s some fine looking eventbuzz right there.

Of course, I can’t say for sure why anyone bought a ticket to “the Beta”, as they call it*. I know there are plenty of reasons to want to spend a weekend with brilliant, creative web people, talking about creating excellent things. (Take a look at Chris Shiflett’s blog or Cameron Koczon’s Gimmebar preview if you need proof of brilliance.)

*Nobody calls it that.

But no matter how brilliant an event is, eventbuzz is a potential poison that can turn the greatest of gatherings into a sad, self-congrulationfest where brilliant speakers run from professional networkers and good-hearted nobodies watch silently from the corners.

Hopefully that doesn’t happen to Brooklyn Beta. The Analog|FK duo is almost certainly taking precautions against that kind of disaster. But there’s only so much they can do.

The rest is kind of up to us. We ruin things by liking them for the wrong reasons. Here’s what I think we can do.

Let’s start separating networking and business-building from sharing ideas and making great things. Let’s get together and talk about what we’re doing without inviting celebrity guest speakers. Let’s find ways to involve more people, and not just by offering free pizza. Let’s make our gatherings an exciting place to be because we’re talking about exciting things right in our own neighborhoods. No, you probably won’t find a job or a pitch or a connection at this kind of get together — but you might find inspiration to make something of your own.

Matthew Smith is talking about this kind of thing already with his Grok idea (check it out if you haven’t already). Groks are an interesting idea, but Matthew is at a disadvantage — he’s one of the celebrities that can easily draw people in for the wrong reasons. In this case, we “good-hearted nobodies” are in a great position to create something interesting that attracts just the right crowd, if we figure out how to do it.

The trick will be getting people’s attention, and finding ways to gather and share great ideas about making great things in our own communities without turning those gatherings into sub-standard networking sales-pitch parades. If we can do that, maybe we won’t need to be glued to a screen punching “refresh” 1000 times a minute, desperately hoping we’ll be lucky enough to score a ticket to the next eventbuzzed un-conference. We’ll be too busy planning our own.

1. The original article: Responsive Web Design, by Ethan Marcotte (A List Apart)
2. A case against: Not a mobile web, merely 320px-wide one, by James Pearce
3. Start with mobile (slides): Rethinking the mobile web, by Bryan Rieger and Yiibu
4. Another case against, sort of: Making Mobile Mistakes, by Paul Boag (the comments on this post are outstanding)
5. Recent defense/explanation: Sea change, by Jeremy Keith

Ethan, the guy who kicked off the craziness, defines responsive design in part by @media queries—I think they count as necessary but maybe not sufficient. Responsive design is all about how we build a site to respond to information. And I think we’re confused about what kind of information we have, how we get it, and the relationship between it all. So here’s a pretty picture to get us started.

This colorful table demonstrates two ways a site can respond, based on two types of information.

When layout responds, we adjust how the content is displayed, ordered, or styled.

When content responds, we adjust what’s being pulled from the server and displayed by the client (usually a browser).

Capability is information about what can be done, based on the device, the internet connection, the browser, etc.

User intent is information about what should be done to meet the users’ needs as best as we can.

We’re getting all these things mixed up.

Layout by capability

This is the genius of Ethan’s A List Apart article. We can use CSS to determine a few things about the width of the viewport, the orientation, etc. and build our sites to respond to that information by adjusting the layout accordingly. This is the heart of responsive design right now because this is the information we’re most accurately able to gather with the tools we have.

Of course, @media queries are ignored by Internet Explorer and many of the browsers found on mobile phones. To fix this, the smart folks at Filament Group have developed some JavaScript to endow many older browsers with the power to process @media queries. As a failsafe, Bryan Rieger suggests we build the default stylesheet for a small-screen layout and use @media queries to adjust the layout up from there.

Still, the 17 users with a decently large-screen device running a sufficiently old browser with JavaScript disabled may have to deal with a funky looking layout. Otherwise, this part of responsive design should work for everybody.

Content by capability

This seems to be a big reason why people fight against responsive design. Sure, we can push some pixels around the page, but what good does it do if we’re shrinking down 1300×900 pixel images for a 320px wide screen? Using @media queries can optimize layout, but what about optimizing the content, too?

We can’t do much with this yet. Those Filament Group go-getters are working on some crazy JavaScript voodoo for serving different size images, but good information about bandwidth, upload/download speed, etc. is hard to come by, for now. Which doesn’t mean we can’t optimize content at all (we might think about whether we need those 1300x900px images at all). More on that later.

This is probably the area with the most room for responsive innovation, and until that innovation happens, people are suggesting we optimize content based on what the user wants. Which is really a conversation about intent, and not capability. See? It’s confusing.

Layout by intent

User intent is the holy grail of user experience design. We make a series of guesses (some more educated than others) about what people might want to find on our site, how they might want to find it, and how to organize and label everything so it’s easy to find.

But here’s where the biggest mix-up almost always happens.

We can’t reliably determine a user’s intention based on the capability information we collect from her device or internet connection.

By pretending we can, we’re like a shop owner who rearranges his entire store every time a car pulls into his empty parking lot. He notes the make and model of the customer’s car and makes a few appropriate changes. Mini-van drivers want milk and gum and mac and cheese, of course, so these get pushed to the front. And of course they don’t want to see those nudey magazines in the display racks, so they get stashed away in the stock room. And so on.

Even if those things were true in the shop owner’s case, he could achieve a similar effect by keeping those magazines out of direct plain sight and making sure the food aisles are neatly labeled for people to find. It’s easy to forget that the mini-van driver pulled into your parking lot, so they obviously intend to shop at your store. It’s probably not necessary to guess exactly what they want to do on each individual visit, especially when a wrong guess can hinder them from doing what they want to do (Uncle James may have taken the mini-van to the store to pick up his nudey magazine, after all).

Content by intent

If we assume we can accurately guess the user’s intentions based on capability information, we might be tempted to remove irrelevant content from that user’s view. Jeremy Keith responds to this kind of assumption better than I can, so I won’t try to duplicate it.

We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.

More and more people are using mobile devices as a primary means of accessing the web. The number is already huge and it’s increasing every day. I don’t think they’re all using their devices just to look up the opening times of restaurants. They are looking for the same breadth and richness of experience that they’ve come to expect from the web on other devices.

Hence the frustration with mobile-optimised sites that remove content that’s available on the desktop-optimised version.

–Jeremy Keith, Context

Making drastic changes to content based on what we assume a user wants on any particular visit gives more credibility to our assumptions than I want to give.

The point about user intent: it’s design, stupid

We can be responsive to what our users want, but we do it at the point of design, not at the point of visit. In other words, when a user visits a site, we can gather information about the capabilities that user has available to him, and rearrange layout and content accordingly. But we can’t reliably and accurately use that information to determine what the user wants, enough so that we can remove content that we assume he doesn’t need.

Again, a pretty picture, this time with a few more words.

Some people go so far as to say that all web design is responsive design, which is hard to argue with, but there are subtle differences. Build a site that works for your users (design) and build it with enough flexibility to adapt, subtly, to various capability levels (responsive design). The semantic difference is trivial, but the end result is the same: we need more responsive design, not less.

One web to rule them all

You either build for a device or you build for the web. You can’t build a web-app that’s just for the iMac. If you try, people will access it from other devices and rightfully expect to be able to use it, because that’s what the web is. When we build for the web, our initial design should respond to what we know about our users, and the layout and content should be able to subtly respond to a user’s capabilities on the fly.

That’s how we build a more responsive web. Not a mobile web, or a desktop web, or an iPad web, or any other kind of web we might try to predict.

Inspired by Chris Shiflett’s plea for more blogging, along with some really interesting conversations I’ve been having, I’m pledging to figure out a way to write more. My new job at Johns Hopkins leaves me busier than I’ve ever been in my entire life, but excuses be damned—I’d like to contribute more than 140 characters to a few conversations here and there.

Mike Brenner, Baltimore start-up extraordinaire, asked a question on Twitter about WordPress. I responded, we had a conversation, and before I knew it I’d agreed to build them a plugin that would do what they wanted to do for a new site he and Myke Nahorniak were working on.

BaltimoreTech.net has since launched, and serves as an up and coming directory for Baltimore’s tech community based loosely on the WeAreNYTech and a few other city-based tech directory sites.

Figure 2: The plugin I built, in admin and how the data is used

The plugin I built allows BaltimoreTech admin users to see a new meta box of 3 tabs of lists (see Figure 2) beside the new post/edit post page, listing other posts that were marked in categories People, Startups, and Meetups. This way, the admin can link a person to a startup, to a meetup, or a startup to a person, etc.

The trickiest part was making sure that when you check something in that meta box, it should automagically make the complementary link for you. For example, if you create a post called “Jane Doe” that’s in the “People” category, and you link her to “Super Hot Startup”, if you then went to the “Super Hot Startup” post’s edit page, the “Jane Doe” link should already be there.

I got it set up for them on a 2 day turnaround and it seems to be working great. If you haven’t yet signed up for BaltimoreTech.net and you’re a Baltimorean who does any kind of tech work, head over and sign up. And if you’re looking for custom WordPress development, contact me at hello@jasonthings.com!

A pastor in Pennsylvania approached me with an ambitious project. He and his wife were going to visit missionaries all over the world, give them Flip video cameras, and teach them how to set up a video blog about their experiences.

He hired a designer and we all met in PA to map out our ideas. I ran everyone through a few exercises to prioritize user groups and come up with the content they wanted for the main site. Then the designer went to work on the visual design for the main site.

WordPress Multisite

I installed WordPress 3.0 and used the newly core multisite feature (formerly a separate product called WordPress MU) and we created networked blogs for each of the beta stage missionaries using a WordPress child theme of the main site’s theme.

YouTube Manager Plugin

The client was concerned that the upload video/blog process would be too complicated for non-technical users. I looked through the WordPress plugin repository but nothing I found was complete enough, so I built them a YouTube management plugin that allows them to upload their videos from inside of their WordPress blog account as seen in Figure 2.

In addition, the plugin allows the users to manage their videos from inside the site, deleting them or linking directly to the YouTube edit page for further editing, and to link a blog post to a specific video making that post a video post which is styled uniquely using CSS. Management and video selection are shown in Figure 3.

Responsive Design, Sort Of

The site also uses a semi-responsive design. The images and videos are flexible, but object and embed tags have a hard time scaling without adding strange horizontal bars to the video player at inconsistent times. I opted to hardcode the heights and let the widths expand at media query intervals. I think Ethan Marcotte calls this “switchy” (see also: his follow-up explanation).

At any rate, the site shrinks and expands to different resolutions, but it’s not fully mobile-ready as it isn’t built for mobile first, so any older mobile device that doesn’t understand media queries might have a difficult time with it.

The CMS allowed non-technical Habitat employees to edit and preview the site right from their pages.

The CMS also allowed users to create blog posts, create events, and keep track of their front page featured images and captions easily.

Soon after I turned the site over to them WordPress 3.0 became available. I use WordPress a lot and had determined that it wasn’t the right fit for Habitat, but this new version resolved all of those issues and made it the best choice for them moving forward. So I ported my system into WordPress for them, and the new WordPress site will launch in 2011.

Here are a few examples of the WordPress features I’ve used in developing for Habitat so far.

Custom Post Types

I created the “Events” type and the “Features” type so that users can add these as easily as possible.

Sidebars

WordPress gives you the option to register multiple sidebars, but I wanted to give these users the ability to create new sidebars on the fly and assign them to a page without having to know any PHP or custom code. They can create a sidebar from the Sidebars page.

And they can assign them per page by choosing from a dropdown box of available sidebars.

We tossed around a bunch of ideas, but I had just read Ethan Marcotte’s life-changing ALA article on Responsive Design and I knew I wanted to make this mini specialty site as responsive as possible. It had been 95 years since Gilman originally opened, so we decided to create 95 scenes featuring photos, videos, and sounds of the building and the people who helped shape it.

I immediately got to work on an idea for the layout of the site.

Original layout idea for the Gilman tribute site

I mocked this up to demonstrate how the layout would work (big thanks to the Muppets—images were quickly pulled together from Google Images, for example only). In most standard sized browsers, the image grid would fill the screen like above. If your screen was bigger than 1500px, though, you’d see something a little different.

When the screen is bigger than 1500px

The grid stops expanding but keeps its shape. Up to now, this is all accomplished using flexible images¹ and percentage widths for columns in the layout. But when the screen gets smaller, things start to get a little more magical. Using CSS3 media queries, I changed the percentages of the columns for smaller screens like, say, mobile² screens.

CSS3 media queries change the column widths for smaller screens

I set up this layout in WordPress and we created a post for each scene, resulting in a flexible grid of images telling the story of Gilman Hall.

Each scene linked to a larger story, audio file, video, etc.

These inner pages were also adjusted, via CSS3 media queries, for smaller screens.

You can see the Gilman site live at http://krieger.jhu.edu/gilman.

If you’d like to check out the muppet-based prototype in the browser, you can see the demo here.