Episode Transcript

Ethan:

Hi, this is a responsive web design podcast where we interview the people who make responsive designs happen. I’m your host Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

This week, we are incredibly excited to present you with sort of a double-headed episode of sorts, where we have both Cyd Harrell from Code for America and Jeremy Keith from Clearleft. Welcome guys.

Cyd:

Thanks so much.

Ethan:

So Cyd, why don’t you introduce a little bit about yourself and tell us what you’ve been working on lately.

Cyd:

Absolutely. This is Cyd Harrell. I’m head of UX over at Code for America, where our job is to bring technologies together with local governments to basically make cities work better for everyone. And very excitingly, we are just now embarking on a project to address the idea of the main municipal website that every city has, as something that can really be rethought and redesigned.

Ethan:

That’s great. And Jeremy, tell us a little bit about yourself. Why are you here today?

Jeremy:

Yeah, I’m Jeremy. I work at Clearleft. I’m not exactly sure what I do, what I’m supposed to be doing. I think I’m supposed to be overseeing front end development stuff at Clearleft. Let’s say that that’s what I do.

Ethan:

We can go with that. That sounds fine. Let us know if that changes over the course of the call.

Jeremy:

It might well. I might update my job title while we’re talking.

Ethan:

That’s great. Another really great thing is our sponsor, Campaign Monitor. I’m really glad they’re involved with the podcast because they have this new email builder they wanted us to tell you about, called Canvas. It’s based on styles, not canned templates that you have to choose from. What I like about the sound of that is that your content actually drives the design instead of the other way around. You’re not necessarily constrained into these little uncomfortable boxes to silo your information into. Now while they do have several preset pattern layouts to choose from, they also have this really well-executed drag-and-drop functionality that’s core to the tool. I’ve been a big fan of Campaign Monitor for years, they’ve been really great and generous about giving back to the community, in terms of publishing resources to make CSS-driven email much more approachable. Generally speaking, their software is built on top of a decade’s worth of tricks and hacks to make your emails just work across all the millions of email clients out there. Which is another reason I’m really excited they’re part of a Responsive Web Design Podcast.

But Clearleft has been working with Code for America, yeah?

Jeremy:

Yes, indeed. It’s been really fun, it’s been really, really nice working with Code for America.

Ethan:

That’s great.

Cyd:

Absolutely agreed. It’s actually probably the best design project I’ve ever been involved in from either end.

Ethan:

Wow.

Jeremy:

Certainly been a lot of fun from our end. A really nice, smooth project. I’m probably going to jinx it now just by saying that. Something’s going to go horribly wrong.

Cyd:

That’s right. We have another phase coming up, don’t we?

Jeremy:

Yeah, indeed. Now, I’ve just jinxed us. It’s going to be terrible.

Cyd:

It’s over.

Most of the cities that we work with are looking at thirty to forty percent coming in from mobile. So we feel that while our website has its primary purpose as doing our own organizational business online, we also can use it as a smaller experimental platform to look at things that might be appropriate to recommend to our cities.

Ethan:

Cyd, I’d be interested to hear a little bit about, as you started to do more responsive work, was there much selling you had to do with your stakeholders and executives to actually go responsive? What kind of discussions did you have back then?

Cyd:

We were in, like many organizations, a position where we had a largely WordPress-based site. And that had served us okay. We had an interesting angle to sell it, which is that our website actually is not super high traffic and it gets only about fifteen percent from mobile OSes. On the other hand, most of the cities that we work with are looking at thirty to forty percent coming in from mobile. So we feel that while our website has its primary purpose as doing our own organizational business online, we also can use it as a smaller experimental platform to look at things that might be appropriate to recommend to our cities.

Our cities, of course, being very concerned with the needs of the mobile-only internet user, which is coming to be more and more important especially for people from disadvantaged backgrounds and disadvantaged areas where broadband isn’t as common. We wanted to be able to not just tell them, “well this is what people are saying about responsive design.” But, “this is what we’ve experienced and this is what we can recommend to you to handle this.” There wasn’t a lot of push back on that.

But, there was a concern about going to the particular method of publishing the site that we chose. We’re still evolving and working on that. That would be that our site is actually all up on GitHub and Clearleft graciously agreed to publish all of the style work that they did for us as a separate GitHub repo. So that’s all open. We can have a pull request from anywhere and staff who are publishing on our site from Code for America work directly through the GitHub interface to make changes.

It’s very much going to be about the system that you’re delivering rather than individual pages. It’s not about building a page for this, a page for that. It’s going to be really a system of components that can be used pretty much anywhere.

Ethan:

That’s fantastic and the work looks really wonderful. Jeremy, maybe you could say a little bit more about how the project started from your side when you guys were first brought in? How did you start thinking about…

Jeremy:

I remember Mike, at Code for America had already been chatting with Andy from Clearleft about potentially doing some work. And then I happened to be in San Francisco for an event and Mike saw that. He said “come around, we’ll have a coffee and we’ll chat.” As they described what they needed to do in terms of moving away from what they already had, this WordPress-based thing, and moving to something much more modular, it became pretty clear that this is exactly the kind of thing that we like to do. It’s very much going to be about the system that you’re delivering rather than individual pages. It’s not about building a page for this, a page for that. It’s going to be really a system of components that can be used pretty much anywhere.

From then, I think basically most of the work got done by Code for America, and what they had to do was then go through everything they had and kind of audit it, figure out what was staying, what was changing, how the whole information architecture was going to work. And we weren’t really involved in that side of things, and I think that’s where a lot of the work actually happened, you know figuring out how this stuff was going to get moved over. So we kind of came in after all that was done, after all the hard work was done basically.

It turned out that almost all the people that we serve want to take an action that has an impact as soon as they can. And so, we are reorganizing these ideas for our website around getting each of the different constituencies to an appropriate action as soon as possible.

Cyd:

There was a lot of that done, although I remember our first call—it ended up working out great in the end—our first call, evening over in Brighton and early morning here, and you guys were sort of like, “Where are the traditional UX deliverables?” Because we had been working, we’re a very small team working light and fast and we had been spending a lot of our time trying to bring the site information architecture into alignment with an organizational re-architecting that we’re doing—and still in the process of—based on some research that I did last year around how do our constituents actually experience their interactions with the organization. We have a lot of different constituents, from city officials, to just random people who want to get involved in doing a little bit of civic work for a couple of hours a week, to donors. And so we had always sort of presented our business in a traditional non-profit mode where it’s like, “here we are and here are our programs and here’s what you can do to help.”

And we discovered that, probably unsurprisingly and certainly seems unsurprising in retrospect, but was really important at the time, that our constituents are not program-oriented. They don’t really care which one they join. We had thought actually they were sort of movement-oriented and they would want to get closer to the center of us and the open data movement and those things that we’re allied with, but it turned out that almost all the people that we serve want to take an action that has an impact as soon as they can. And so, we are reorganizing these ideas for our website around getting each of the different constituencies to an appropriate action as soon as possible.

Also really pushing the stakeholders to come up with what our design values are as an organization. So we had engaged with another agency, dojo4, around a visual branding project a couple of months before the engagement with Clearleft started. I think we had a fairly clear set of values and goals and then we had really a lot of sketch-level information architecture and an intention to go forward in an agile way, which continues to develop. We just pushed a re-organization of the top nav of last week. And Clearleft was great. Once we got through that initial shock of, “wait, you don’t seem to have formal wireframes,” they said.

Jeremy:

No, it was a relief. It was like, this was great. A great way to work.

Cyd:

We said, ok, if you guys are real about this, let’s just meet at this exact time every day, end of our day, beginning of yours, and we’ll all share what we’ve done each day and before the next team wakes up, we’ll answer any questions and get the next piece ready.

Jeremy:

And that was a really great way to work. It felt very iterative. It felt like every day there was some progress being made and no dead end could ever be that far down. There’s only so far you could go in one day before you could say, “Ok, well, that didn’t work out. Let’s do something different tomorrow.” Whereas if it’s weekly or monthly meetings, then you could really go down the wrong path for quite awhile before getting hauled back on track. So that daily thing worked really well.

Cyd:

I thought it did and we’re actually implementing that with the core team for the first city that we’re working closely on the redesign of the redesign process, which is Oakland, California. So I just came off the 9:30 a.m. call with them. Much like ours, seven to ten minutes.

Jeremy:

Yep.

Cyd:

And it seems to be working really well, too, although it’s a very new practice for them.

Jeremy:

You don’t have the time difference of being in completely different continents.

Cyd:

Yes, it’s 9:30 for everybody, so it doesn’t quite have the step-step, one after the other element, which I do think was great. Just syncing up every morning has been cool.

The idea is that the mobile only—or the mobile primary—user category is often associated actually with people who need more services from their local government. They may need to apply for Head Start, they may need to sign up for housing assistance or food assistance, or some of those really critical services, and so making those things primary is going to be terrifically important on mobile.

Karen:

Cyd, talk to me a little bit about how in this civic design space, people understand what’s a “mobile user” or what’s a “desktop user.” I love what you’re saying around trying to focus your user experience goals and get people to take action. When you’re talking about your user or talking about the constituents these cities serve, is there this sense that mobile users and desktop users need something different?

Cyd:

I think that there is a sense that they are different groups of people and interestingly, when we’re talking about municipal sites, if you looked at one for your local municipality, most of them are not terrifically optimized towards the constituencies that they were already trying to serve. You’ve got one of these interesting problems where they need to shift what they’re doing, and at the same time they also just need to get a lot better at doing what they’ve been intending to be doing all along. The idea is that the mobile only—or the mobile primary—user category is often associated actually with people who need more services from their local government. They may need to apply for Head Start, they may need to sign up for housing assistance or food assistance, or some of those really critical services, and so making those things primary as much as say, building permits or business development stuff, is going to be terrifically important on mobile.

We’re taking a fairly strong position that the mobile web is going to be where they want to be rather than suites of apps. We call it the “digital front door.” In the same way that you could come to city hall and know that you could get whatever service your government might be offering, we want that main municipal website to be the digital front door.

The other interesting thing is that we’re not talking about the iPhone set necessarily, as far as mobile-primary users. While nobody has great stats at a local level, and I have looked all over the place, if you look at some of the work by Pew and Knight on where mobile-only users are filling in the gaps, so that we see close to eighty-five or ninety percent internet access available for almost everybody, but there are some populations where that’s almost all broadband available at home and work and somewhere, twenty or twenty-five percent of that is mobile-only, they are showing that a lot of those are the Android that you can get with a month-to-month phone contract.

Looking at what kind of testing capability our cities are going to need to have to adequately serve these folks, which kinds of phones should they be targeting towards, I think we’re taking a fairly strong position that the mobile web is going to be where they want to be rather than suites of apps. Which has been an idea that’s been a little bit popular for the last couple of years. We call it the “digital front door.” In the same way that you could come to city hall and know that you could get whatever service your government might be offering, we want that main municipal website to be the digital front door. We want the sites to stop being about the cities and start actually being an aspect of the city government the way city hall is, where the government is doing the people’s business right there online.

For it to do that it’s absolutely got to serve people whose one conduit into the internet is a little four-inch screen. It’s a tall order. We think of our site in some ways as a…. We made a commitment and I think we shared with Clearleft right up front that we wouldn’t use any technology that was inaccessible to local governments and we wouldn’t use any practices that we didn’t think they would be able to implement with some work.

Some people call it a front end style guide, pattern library, but essentially it’s breaking down the components of a page or a site into their atomic pieces and making sure that everything stands alone and works by itself and then delivering a collection of all those pieces as the main deliverable.

Ethan:

I love that sentiment. I want to touch on something. Jeremy, you mentioned earlier thinking about this design process as not building pages but as building a pattern library or a style guide. For the listeners who may not be familiar with what a pattern library is, maybe you can talk a little bit about that.

Jeremy:

Sure. It goes by many different names. Some people call it a front end style guide, pattern library, but essentially it’s breaking down the components of a page or a site into their atomic pieces and making sure that everything stands alone and works by itself and then delivering a collection of all those pieces as the main deliverable. You’d still provide pages but the pages would really just be almost like assembling Lego blocks: here’s a few of those patterns put together into one example page and here’s another example page. But the pages really are just examples of the patterns in action and it’s the patterns that count.

There could be various degrees of granularity. I like to begin right down to “here is a link and here is a button and here is a heading and here’s another heading.” I think it’s good to start at that level. You can build up the patterns where you could have things like, “this is a module” or it’s like… the only thing that coming to mind is a carousel which is the worst example. But you know what I mean. Something that’s made up of…

Cyd:

We refuse to have one.

Jeremy:

Yeah, good, exactly, I was trying to think of other examples.

Ethan:

I knew I liked you guys.

Jeremy:

No carousels. No carousels.

Cyd:

Like a tab with a mini form in it, so there’s a big red stripe with a four or five line form.

So the pattern library style guide would contain all of these different patterns and you know, we are also planning to deliver example pages, but it was making it very clear that the pages aren’t the deliverable. The pages are examples of the deliverable in action, so to speak.

Jeremy:

That’s a good example. It’s a standalone thing but itself is made up of more modular things; each one of those form fields, each one of those labels. So the pattern library style guide would contain all of these different patterns and you know, we are also planning to deliver example pages, but it was making it very clear that the pages aren’t the deliverable. The pages are examples of the deliverable in action, so to speak.

And so that’s when we knew we were going to be delivering, we immediately got in touch with Anna Debenham, who’s also here in Brighton and actually used to be an intern in Clearleft and now she’s a freelancer. And she’s written a little book on the front end style guide, so she seemed like the perfect person to bring on for this. And that turned out to be exactly the right choice, because she was absolutely terrific working on the front end side of things.

So generally beginning with the smallest pieces I would say, is how it started, and leaving the more complex stuff for later. It’s more like you’re going simple, simple, simple, slightly less simple, okay now we’re getting complex.

Ethan:

Well that’s great. And just really briefly, what’s the process you usually take for designing a style guide? Are you working from comps and sort of breaking them down? What are you looking for, I guess, to sort of break it apart?

Jeremy:

It was interesting on this one because time was of the essence, normally you do a visual design phase, I guess, before you start on the front end, but we didn’t have that luxury. It’s like, we’re going to just start doing it. John here at Clearleft was doing visual design, and at the same time Anna was starting on the front end guide. But you’d still know the kind of things you’d be using, even if they haven’t been designed yet. So you know you’re going to need buttons, and form fields, and headlines, and all those things, even if you don’t know yet how they’re going to look. So in some ways it’s almost like plugging in the visual designs as you go along.

Things came up during the visual design process that did mean changing some of the patterns, but it actually worked pretty well hand-in-hand. It was a bit more lead on the visual designs, so we could have a pretty good idea of the kind of things we’re going to need, but it worked side by side. But so generally beginning with the smallest pieces I would say, is how it started, and leaving the more complex stuff for later.

Anything that was quite global in scale like navigation, footer, and stuff like that, that wouldn’t need to get done at the start. That kind of stuff can wait. Partly because you want to iterate on the design of that stuff, but also that more complex stuff, it’s kind of better to leave until the end and get the simpler stuff working and test that simpler stuff as you go. And sort of plug in the more complex stuff bit by bit, so you’re not building something really complex to begin with and trying to fix all the bugs. It’s more like you’re going simple, simple, simple, slightly less simple, okay now we’re getting complex.

Ethan:

Heh, that sounds great.

Cyd:

I think we left the homepage until the very last.

Jeremy:

Yes, which is great. I mean, I always advise that with client projects, but very few clients actually follow through on that.

Ethan:

And what was the reasoning for that?

Jeremy:

Well I was going to say from my perception, the homepage on most projects is always just one big glaring exception. Like it’s one something that does-the purpose of it is always going to be different to any other URL, right, it’s not always going to be a straight-forward thing, it’s going to need to do other things. So from my perspective on most projects, I advocate leaving the homepage until later because it’s kind of this exceptional thing.

Cyd:

Yeah, I agree. It was going to be completely different in how to purposely aim for all four or five audiences we’re talking about. It was critically important that we figure out what to do with it on mobile, because that link, codeforamerica.org, is in any article about us, or in anything that somebody might see tweeted, and so we wanted to have a solid base of what the site was going to look and feel like before we started to put that together.

One of the top internal goals was that a person who wants to start civic hacking who has heard of Code for America and who wants to code for America, can get to our site and within a few clicks be working on something.

Karen:

So, I’m fascinated by this development of a design system where you’re defining more granular pieces. And the reason I’m so interested in it is, I can totally see that also has an aspect of how the content is defined, and what granularity you have in the content. Can you talk a little bit about the content process in terms of how you structured it, how you decided what to say, and maybe even talk a little bit about the more modular publishing process that you developed on GitHub?

Cyd:

Yeah. So this was very much seat of the pants. I will very much say right now I don’t think I touched any Adobe product during this entire project, because where we are around here is sending everything around in Google docs. So I sent to Clearleft these rough sketches in Google Draw, which began from this idea of, we knew there were certain types of information that we needed to publish. We had a site that was all structured with all kinds of left and right and boxes, and we wanted to move away from that. Move to something that was easier to do as responsive, so that it was more vertically linear.

But we also—it’s funny, this isn’t my preference for websites in general—but we had some sections of the site that we knew really needed to serve different types of people. For example, one of the top internal goals was that a person who wants to start civic hacking who has heard of Code for America and who wants to code for America, can get to our site and within a few clicks be working on something. Thinking about what needed to happen—and it gets complicated in a design piece—because we have a bunch of local affiliates that serve the people who want to volunteer. We also have some intensive programs that are application processes. We really know that the first journey that locks somebody in is doing a little piece of work that they can see has an actual positive impact in the public sphere.

We knew that the citizens page—you may notice that if you go from citizens on our homepage the URL is actually slash geeks, which we figure only the geeks will notice and will like—is organized to either immediately give someone a list that helps them identify with a local affiliate and just get them on to doing something right away. Then go to a quick highlight module and sign up if they want to, and then go to a little more detailed information, in terms of, what kind of person might you be? If you are a developer, we have these kinds of activities for you. If you are a designer, we have these kinds of activities for you. If you are an activist, we have these kinds of activities for you. From there it goes towards, we have these intensive programs that you can apply for.

Our next phase coming up with Clearleft is probably going to be around simplifying some of the markdown but also making this really more Lego-like. So that you can work on a single module of the page without necessarily feeling like you’re just typing in a box.

Each of those pieces is actually something that Clearleft designed separately. We have a list of cities, we have one of those big red slabs with a form, and I think we changed the highlight several times since it went up. We have these pieces and the three pieces as a three column thing showing for the different kinds of people who might come here. We’ve got below that another set of things that is just all the way across. Those are each separate designs. In this case, it’s a team that owns the content for the page. It’s the team that focuses on that constituency which we call internally, communities. We got citizens, geeks, and communities, all these names for this. Never mind that.

They have a couple of people who were already comfortable with publishing on GitHub and who could look at the code for that page and read, “oh okay I’ve got section tags here, that means everything inside here is something that if I want to change, if I want to change the color of that slab or if I want to change which person on our network is highlighted here, this is where I work.” We have a bunch of people who don’t.

Our next phase coming up with Clearleft is probably going to be around simplifying some of the markdown but also making this really more Lego-like. So that you can work on a single module of the page without necessarily feeling like you’re just typing in a box. You still have a lot of capability to actually work with the design, which is as much part of what you’re conveying as the content, in a way. So you’re not just constrained to say “okay well, I wrote the content and now I put it online.” You can work with the design but within these safe constraints of the style guide so that it comes out looking great when you make little modifications to it. As long as you stick within what we’re offering you.

There is a real pull-and-push sort of tension between having this very modular style guide where all these bits you want them to be stand alone. You can take any bit and you can drop it in anywhere. And then trying to balance that with the needs of the people writing the content, putting the content in.

Jeremy:

This next phase is going to be interesting because there is a real pull-and-push sort of tension between having this very modular style guide where all these bits you want them to be stand alone. You can take any bit and you can drop it in anywhere. And then trying to balance that with the needs of the people writing the content, putting the content in, who don’t want to have to know, memorize, have look up all the different classes they have to put on everything if they want it to look a certain way.

The way things have been done initially is that everything is very self-contained. The class names on the element are all that the CSS needs to know in order to style a certain way. But that means if you’re going to be inputting the content you need to put in all those particular class names to get it to look like that. Whereas what the people putting the content would prefer obviously is to be able to drop in a chunk of content maybe with just one class wrapped around it, right?

It’s going to be really interesting to try and hit that balance, trying to hit that balance of the modularity while still we still want to make life easier for the people writing the content.

Cyd:

Kind of, but I don’t think we should let them get entirely away with that.

Jeremy:

Right, that’s what I mean about this tension. We need to balance it because if we go down that road where everything is all to do with the cascade, you could drop in any markup and it will just be fine, then we’re really, really relying on the context of where the stuff appears. Now that’s much more fragile than the approach we’ve currently got where everything is stand alone and very modular. It’s going to be really interesting to try and hit that balance, trying to hit that balance of the modularity while still we still want to make life easier for the people writing the content.

One of the critical things that we’ve had to add is a preview function for GitHub pages. Because we don’t want to give everybody access to master and really want everybody to be able to look and test before they go.

Cyd:

Yeah, I’ve been sort of treating a bunch of this as user research, actually, as I’ve been sitting with people that were outside the technology team in the organization and watching them go through this process.

For some of them it’s the first time they’ve worked on GitHub or first time they’ve worked directly in HTML. What’s interesting is that for a while, a lot of them doing the thing where you cut and paste, if you understand what piece of a page you want to cut and paste and then fill in all the tags correctly, works pretty well. So it’s like if I’m looking at the actual Geeks page, I’m looking at the source of the Geeks page and I’ve got GitHub open with my new page that I’m making and I want to copy everything I need to make that big red stripe across that’s a highlight of a person. If it’s really clear where that is and what’s doing what within that section, they seem to get through it pretty well.

One of the critical things that we’ve had to add, that Mike and a guy named Mick Thompson who was our engineer in residence last year built, is a preview function for GitHub pages. Because we don’t want to give everybody access to master and really want everybody to be able to look and test before they go, so they built this thing called Jekit, which sort of on top of GitHub Pages and Jekyll allows you to preview what you’ve got on any branch as long as you made the commits. And that’s been really really useful for people. So we’re looking at a way to create a lightweight interface that more right into their flow so that you can sort of have the piece of, “okay so this is what I’m going for, you know, this is where I copied the code from, this is the code I’m working on, and this is what the page I’m working on looks like now.”

We’re constantly trying to think through the implications of any design element. It’s constantly just testing, testing assumptions I guess, just testing what’s this going to cost us. It’s this constant push-and-pull.

Ethan:

That’s fantastic. The one thing that I’m hearing from both of you, it’s really wonderful you’ve got so much of the design that’s been refined in the browser. Jeremy, this is maybe an easy serve for you because it’s a topic that’s near and dear to your heart, but has performance been part of the design process at all? Has this been something that has come up in conversation?

Jeremy:

Oh yeah, very much. You know, we basically try to keep things as small as possible. Again, talk about tension, push-and-pull, it’s always going to be this tradeoff and I know that as it turns out, design issues around wanting to have these certain fonts, then actually when you’ve got the site live, the performance tradeoff is pretty, pretty harsh and so, you know, the needle is probably going to move away from the fonts that we ideally would like to have to fonts that are going to be served up faster. But that’s just one example.

We’re constantly trying to think through the implications of any design element. There’s always that tension between okay, we want to have this bold image, which is fine, but bear in mind that brings with it an associated cost in terms of download speeds, stuff like that. It’s constantly just testing, even if not literally testing in terms of devices, which we try to do as well, but testing assumptions I guess, just testing what’s this going to cost us. It’s this constant push-and-pull.

We talked about setting a performance budget, we didn’t actually do it on this project, I think partly because we weren’t dealing with pages so much. So it was hard to apply that idea of a performance budget for pages, when what we’re building is a system of components. I’m not sure this idea of a performance budget applies so well to the component level.

Ethan:

And you just manage those on a case-by-case basis, basically?

Jeremy:

Yeah, yeah, I mean, don’t have any formal thing figured out for this. Like, we talked about setting a performance budget, we didn’t actually do it on this project, I think partly because we weren’t dealing with pages so much. So it was hard to apply that idea of a performance budget for pages, when what we’re building is a system of components. I’m not sure this idea of a performance budget applies so well to the component level. But to just be aware of it.

There’s certain things you just know, they set off the red flag. Obviously like I said fonts, web fonts, you know straightaway, you need to be careful there. Do you need to have every weight of that font? Can you get away without italics? And like I said before, full-bleed images, photographic images in general, stuff like that, just certain things that can—should—trigger your spidey senses.

I waited until we got it into the browser. Actually I need to stop saying “the browser” like it’s one thing, because the whole point was it was “the browsers” plural.

In terms of testing as well, there’s a few things. So John is doing visual design, Anna is doing the markup, they got their heads down in doing the actual work, whereas I was kind of overseeing it and sort of trying to spot any potential issues before they got too far down the line. And sometimes that might be a performance thing but it might just be an interaction thing. I remember John was working on a pattern for the navigation and hover was involved and that set off my spidey senses like, “wait hang on a second,” but I waited until we got it into the browser. Actually I need to stop saying “the browser” like it’s one thing, because the whole point was it was “the browsers” plural. Went over to the device lab and started trying to do it on a tablet and “This just isn’t going to work. We need to pull back a bit.” Luckily we were only one day, two days down that road and we could pull back fairly easily. But it was good to have that overall sense of “Well, this doesn’t smell right. Let’s test this. Yeah, as I thought. This is going to be tricky. Let’s pull back. Let’s go in another direction.”

And a lot of the city staff are quite web savvy but don’t see themselves as web savvy largely because seem these enterprise-grade tools that they’re given seem like they’re another level of difficult beyond what they might use as consumers in their private life.

Karen:

Do you measure or test or evaluate the success of this redesign?

Cyd:

Yes. We, I think like most people, are working on Google Analytics. Actually one of the things I should mention that we did was as we were worked on this with Clearleft we also redid the information architecture of our older, less modern-looking site to match this, so we were able to confirm some things about, yes, having a button for people associated with governments right on the home page works, gets people to the government page, so we can feel pretty confident about that.

For Code for America, it has a whole bunch of different goals. So far there are analytics pieces, there are also just more qualitative pieces. I’ve been, as we go along, spending a little bit of time with people from our different constituencies and understanding their use of it and where it’s working. That’s part of going back to Clearleft. There are a couple of things that we didn’t quite get right and we’re going to be moving forward. Like I said, we redid the navigation based on some user research that people weren’t… Once again, it’s pulling away from the way we internally organize into programs and showcasing the breadth of our work, which isn’t just producing applications, right in the top level of the site. That’s a research-based change that we’ve made already.

The jury on the secondary, but incredibly important function of serving as a lab for things that we can teach to cities, remains out because we’re just getting into these projects formally. We are starting with Oakland, California. We have a project that has gone through city council but hasn’t yet been fully contracted, but hopefully once it gets through council it’s in good shape, to teach them this process and to evolve it along with them on their site, which is an order of magnitude larger than ours, and is a really good representation of a lot of the issues that cities face in that mid-size city range between 400,000 and 500,000 population. They’re an extremely diverse city, they have a significant proportion of economically disadvantaged citizens, a bunch of whom are on mobile-only. They worked with us in 2013 as a fellowship city, so they had some experience in making change along with us, and are really interested in becoming the most modern city website production shop in the US or in the world. They would be really, really excited to lead that next way forward.

What’s interesting is that they work with Oracle Site Studio, and a lot of our cities work with that or Dot Net Gnu or Vision internet. And a lot of the city staff are quite web savvy but don’t see themselves as web savvy largely because seem these enterprise-grade tools that they’re given seem like they’re another level of difficult beyond what they might use as consumers in their private life. We’re really looking at, how we can take what we learned in this project with Clearleft, take this next step as pushing this design a little farther and pushing the publishing piece a little farther, and then start applying it to things that are bigger than just our little non-profit site.

It’s kind of good that it looks quite different on a four-year-old phone than it does on a one-year-old phone. It would be kind of weird if it looked the same on both, right?

Ethan:

That’s fantastic. I had one last question, something Jeremy mentioned earlier. As you’re talking about interaction challenges on specific modules how do you tend to define support? For not thinking about one single browser, if you’re dealing with something tricky like navigation, how do you actually talk about what you’re supporting in the design?

Jeremy:

When it comes to interaction I guess the support is, “can the user accomplish their task?” On a site like Code for America it’s generally about being able to get from A to B: “can I get to the information I’m interested in?” So, as long as every user can accomplish that we consider that supported.

Now what we don’t consider is that every user needs to have the same experience getting from A to B. That the navigation needs to look the same; that, if there’s animation involved, that every single user gets the animation. Those things are all kind of icing on the cake. The main thing is that the user can get A to B.

Always, always, always making that difference between support and optimization. We support everyone, we don’t optimize for any particular browser.

Also with the front end development work as to how we tend to work is like to start with: ok, what is this? This is a hyperlink to get the user from this page to another page. That’s what goes in the mark of “hyperlink.” Later on we can add in some nice CSS to make it look good. We can add CSS to make it animate. We can do some javascript to position it somewhere completely different to where it actually is in the DOM. But, all of that goes on top of the fundamental nature of the thing. Which is, it’s a hyperlink. It’s just getting someone from A to B. That’s a fairly simple example in this case. Because there isn’t anything too tricky interaction-wise. It was basically links, some forms to be filled out. Fairly straight-forward stuff.

We define support as in, “can you accomplish the task?” And we think we’ve managed to give one hundred percent support to any web browser capable of accessing the internet. That does not mean they all get the same experience. Very, very far from it actually. It’s pulling it up in the device lab and looking in on quite a different range of devices, ancient Android phones, newer Windows phones, iOS devices and stuff. And it looks quite different in those devices. That’s not a bug, that’s a feature. It’s good that it looks quite different on a four-year-old phone than it does on a one-year-old phone. It would be kind of weird if it looked the same on both, right? That would actually be strange. Always, always, always making that difference between support and optimization. We support everyone, we don’t optimize for any particular browser.

Ethan:

Well that is fantastic. With that, I think we’re about at time. I just want to say thanks again, Cyd and Jeremy, thank you so much for taking a half hour to chat with us. I can’t wait to see where the design project goes next.

Jeremy:

Yeah, I’m pretty excited about the next phase. Knowing that people need to be able to cut and paste the source code and understand the HTML and the class names involved, it’s kind of like, wow we’re actually gonna have to need proper semantic markup and class names. How unfashionable.

Ethan:

That’s crazy talk. Crazy.

Jeremy:

Yeah. It goes against everything that all the cool kids are doing. But, I’m looking forward to it.

Cyd:

I’m so excited to do more crazy talk with you Jeremy, and thanks for having me on you guys.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan:

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Karen:

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Ethan:

Thanks again to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.