Posts About Web Work
Why We Don’t Deliver Photoshop Files
Occasionally a potential client will ask us to give them Photoshop comps as the final deliverable, to be coded either by an internal implementation team or a technical partner. We don’t do that. Here’s why.
A website is code. Sure, it’s images and copy, too, and those images and copy are placed in the code only after careful consideration of the client’s strategy for the site. But a website is code. Even if you just saved all the comps as JPGs and made image maps out of them (funny story there, but later), you still need code to make those image maps work.
Our design process is not short and it is not simple. We spend significant time and effort doing research and visual design before we even get to the code. That process results in a set of sample pages that demonstrate all the pieces of the visual system for the new design. Depending on the project, we’ll either create all of those pages in Photoshop or do a few in Photoshop and build out the rest in code. But all the comps are delivered as code.
That code is two things:
- It is the final culmination and proof of all the work that we’ve done with and on behalf of the client.
- It is the basis of a design system that will be used by the implementation team to build the rest of of the site.
When we take a website’s design all the way through code, it means that we have spent the time to test the solutions proposed by our strategy, IA, and visual design work. We have made some potentially difficult decisions about whether a particular aspect illustrated in the PSD can actually be implemented in a way that benefits the site, not just code something because it’s in the PSDs.
Finally, it ensures that the code that forms the basis of the entire design system and website is clean, conformant, and tested. We don’t just slice up our PSDs and export them through ImageReady. We code our final pages by hand. What goes in the code is only what should be in the code.
As Mike is fond of saying, “A PSD is a painting of a website.” We don’t spend weeks or months understanding a client’s complex needs and issues to make them paintings. We spend all that time to solve problems, and paintings don’t solve problems. They may illustrate potential solutions, but there’s a lot of room left for interpretation, and that poor interpretation of a solution is often what has led the client to our office in the first place. So we don’t do it.
Written by David McCreath on August 26, 2010 with 27 comments | 
Tips On Buying Design
I sell design for a living. I also design things, but right now that’s beside the point except inasmuch that if I can’t sell it, there’s really no need for me to make it. As with all transactions, you need a seller and a buyer. And because I enjoy selling design, I really want you to enjoy buying. (I also want you to buy it from me, but let’s not focus on that right now.)
Some people we talk to are nervous about the process because they aren’t designers themselves. This makes them feel as though they are at a disadvantage. We want to help with this. We want clients to feel terrific about having an opportunity to work on a design project with skilled professionals (even if they are skilled professionals other than us).
By the end of this piece you should know enough to be reasonably good at buying design (especially from me) because I’m going to show you that you already know how to do it. You probably make purchase decisions several times a day. Design doesn’t have to be a great mystery. Those same tools you use to buy other things can be used to buy design.
Let’s start at the top:
Written by Mike Monteiro on August 12, 2010 with 14 comments |
Serious Eats Recipes
Anytime I need a good, solid recipe, I turn to Serious Eats. Their recipes are always carefully chosen, nitpicked over, and written with a serious love for food. They’re never afraid to experiment, whether they’re making something they’ve invented themselves or a dish that we’ve all made at home a hundred times before. The important thing is that they test, and retest—Alton Brown and Cook’s Illustrated style—to make sure their readers get the best possible recipe.
But the best thing about Serious Eats is that they keep it real. Their style of writing makes recipes, even ones that take hours slaving in the kitchen, approachable to cooks of all levels. Their articles, all accompanied by photos taken outside of a studio, show glorious result at the end, but only after going through the same failure after failure that we’ve all experienced at home. Their directions are honest, and unlike most food bloggers that only harp about the joys of cooking with ramps and organic eggs, they’re totally OK testing supermarket kettle chip brands or recreating the In-N-Out Double Double burger, Animal Style. Needless to say, Serious Eats rocks my world.
Serious Eats started out with a strong focus on food writing, and occasionally added on recipes to their articles. As time went on, more and more readers turned to Serious Eats as a resource for recipes, but had a difficult time finding them. So, they called us up to help them build a recipes section from the ground up, as well as redesign their individual recipe pages.
As a big Serious Eats fan, I couldn’t be more excited about the new Recipes section that launched this week.
Written by paula on July 29, 2010 with 1 comments |
Content Strategy, Animal-style
I finally watched Fantastic Mr. Fox. I love Wes Anderson like any other liberal arts kid from Texas, but I missed this soft epic in theaters. The delightful George Clooney needs no elaboration.
Everything is executed perfectly. Anderson has a plan, but edits himself. The film is dreamy and imaginative without being forced. It is relatable, engaging, and satisfying.
Since watching the film, I’ve been focusing on work. Some of that work includes reading and attending events about content strategy.
The most popular question this week was, “How does a content strategist fit on a Web team?”
People are really asking:
- “Why do we need a content strategist?”
- “How am I supposed to do my job with another person involved?”
When you get a bunch of different animals in a room, there will be confusion and conflict. But, with a mission and flexibility, great things can happen.
Wes Anderson gets this, and is optimistic. When Mr. Fox looks at his misfit gang of colleagues and friends, he says he sees them in their roles. He adds:
I also see a room full of wild animals. Wild animals with true natures and pure talents.
Wild animals with scientific sounding Latin names… that mean something about our DNA.
Wild animals, each with his or her own strengths and weaknesses due to his or her species.
Anyway, I think it may very well be all the beautiful differences among us that just might give us the tiniest glimmer of a chance…
It’s like content strategy, animal-style. Well, more like how an optimistic content strategist envisions Web teams working. We do it here at Mule. (I’ll talk more about our process in a later post.)
Everyone has their own strengths and weaknesses; our differences make it possible for us to collaborate, disagree, contribute, create, and do good work for our clients.
We’re all designers; we’re all different. But there’s something kind of fantastic about that, isn’t there?
As Mr. Fox says, “It’s just a thought.”
Written by nicole on July 2, 2010 with 2 comments |
The Web is Not Content. The Web is People.
This week, I had the pleasure of attending the Web Content 2010 Conference in Chicago. Ben Brown’s session (Building and Running an Online Community) was my favorite.
Ben talked about his experience with building online communities. He said:
Community is not about forums, social media campaigns, or user-generated content. Community is people talking and doing things together.
[K]eep in mind that people are out there wanting to talk to each other on your site.
If you have an audience, you have a community.
Ben reminds us that community is not about networks, tools, or features. It’s about people, and people have a natural, human need for conversation.
People want to share and relate. This is why we have language. This is why we speak, read, and write.
This is why we work hard to connect our clients with people. After all, the web isn’t content. The web isn’t documents, experiences, and stuff. The web is people, and people want to connect.
Your users are your customers, but your customers are people.
Written by nicole on June 10, 2010 with 1 comments |
The Customer Experience is the User Experience
Everyone at Mule has experience in a customer service job. It takes humility and care to focus on the customer at all times.
I’ve been serving customers, whether in food, retail, or tech, since I was fourteen.
A critical part of helping people is understanding their needs. This takes research.
What you can’t learn through research, you learn over time. This is where experience comes in.
Below are some rewarding tips, free of charge:
Listen to your customer. You have to know what they need.
Speak clearly and use plain language.
Set clear expectations and keep your word. Only make offers you can afford to honor.
When you make a mistake, say you’re sorry and fix the problem. Don’t cop-out or be defensive. Apologize for your mistake (i.e., the action), not how you made the customer feel (e.g., confused, frustrated, inconvenienced).
Be honest.
Know your products and services.
Leave your personal problems at home.
Written by nicole on June 1, 2010 with 0 comments |
Writing CSS Efficiently
For the last few projects we’ve done at Mule, I’ve been able to work closer with the clients’ implementation teams than I sometimes do. They were building the site (or application) as I coded, which meant I got nearly instant feedback about whether or not a particular technique was going to work in their environment and could go back and change things on the fly. As a result I had to be particularly organized about how I set up my code — so I could find things quickly — and really careful about how I used classes vs IDs and how tricky I got with my code. These are just a few little observations that I made and have changed or not changed my habits accordingly.
Note: This is about writing your CSS in a text editor, not a CSS-specific editor.
I’ve always opted for a minimum number of stylesheets, versus splitting things like fonts and colors into separate stylesheets, for a couple of reasons. First, I think for the most part the combination of today’s average Internet connection speed and the average person’s browser cache settings, one large HTTP request is better than several small ones. Secondly, I don’t like jumping from document to document. I’d rather have it all right there in front of me in one big chunk (with the exception of IE-specific style overrides).
The organization of that big chunk is something I still tweak on every project: For the most part I put styles for basic HTML tags (no classes or IDs) at the very top, then the big content sections (wrappers, banner, content, footer), then break it out into sections by the name or type of template. That’s mostly for my own cognitive convenience, and it’s worked really well for me for years.
However a couple months back I saw a tip on some site (that I’ve unfortunately forgotten now, so I can’t give credit) that made a huge difference in how I work, given how laughably obvious it is in hindsight:
Alphabetize your CSS properties within your selectors.
Duh, right? In the past, I would just tack properties on to the end as I went, although I would sometimes group things in a way that made some kind of internal sense like this.
a {
color:#ff0;
text-decoration:none;
display:block;
width:100px;
height:15px;
padding:2px;
}Then when I went looking for something I’d always spend time digging through lists of properties that would be in whatever order made sense at the time that I wrote them.
Now I know exactly where “height” is going to show up not only in relation to “width”, but to “color”, “position”, and “z-index”. (If I use any of the -moz or -webkit properties, they go at the end of the list.)
I was amazed and chagrined at how much sense that one practice made, but there’s a secondary effect to using it:
Keep all your properties for a given selector on one line.
I can now easily keep all my properties on one line instead of having a line-break and a tab for each property, which makes the far left column of my stylesheet a breeze to scan.
a { color:#ff0;display:block;height:15px;padding:2px;text-decoration:none;width:100px; }Indent descendent selectors beneath their ancestors for some visual grouping.
If I have a bunch of styles specific to the footer (for example), I’ll format them like this:
#footer { ...properties... }
#footer ul { ...properties... }
#footer p { ...properties... }I only ever indent one level because more than that and the indenting starts to become less efficient. This isn’t something that’s going to have complicated nesting like HTML can; it’s just a way to chunk up the stylesheet for scanability.
Code for IE6 as you go.
I’m happy to say that as a team, we at Mule are pretty darn good at designing sites that look fantastic while maintaining cross-browser consistency without getting into a bunch of stupid hacks. Sure, I’d love to say we’ve just stopped supporting or at least coddling IE6, but the sites we build have audiences that still use that browser in large numbers. Plus, most of the things that I end up having to fix for IE6 are required for its almost-as-bad sibling, IE7. So between those two, yeah, I end up having a few things that go into stylesheets loaded with conditional comments.
On one of our recent projects I decided to take the approach of “Make it right, then make it work in IE”. While that absolutely sped up the “make it right” period, the “make it work in IE” period was kind of drag because we had to go back and change some HTML that the dev team had already incorporated into their CMS. In this case it was a fairly easy fix, and it was only in one place, but if I had followed my usual rule, we wouldn’t have had to do it all.
So keep your problem children handy and if you do something in your code that you’re not sure about, check them right away.
If you have separate stylesheets for Internet Explorer, keep your selectors in the same order as the main stylesheet.
As with the alphabetizing of properities, this might seem like a no-brainer, but my habit has been to just add selectors to the bottom of the IE stylesheet(s) as I go (at least in those cases where the cascade wasn’t important). And while these stylesheets are rarely more than 10 or 15 lines, it’s more about handing things off to someone else in a way that doesn’t look like I just dumped a bunch of stuff in a box at the last minute.
These probably won’t save hours on any given project, but they will allow to think about something besides “Where the hell is that rule?” and it will definitely be easier to hand things off to the client at the end of the project.
Written by mccreath on May 26, 2009 with 3 comments |
WordPress Plugin for Six Apart Services
We were happy to learn that friend of Mule Art Wells worked with our friends at Six Apart to develop a new WordPress plugin that gives WordPress users access to several Six Apart services: TypePad AntiSpam, TypePad Connect (6A’s commenting and community tools), Six Apart Media (6A’s advertising network), and Blogs.com (6A’s blog directory).
If you know our work, you know we’ve done a lot of work with Six Apart: we’ve worked on their corporate site and the most recent versions of both TypePad and Movable Type, plus we’ve built a lot of sites using both of those products. We’ve also worked spent our fair share of time working on sites powered by WordPress. We think both platforms are great, and we’re happy to have both of them in our arsenal of tools. This kind of integration strengthens both and we think it’s a really fantastic move for Six Apart to make.
And nice work, Art!
Written by mccreath on May 16, 2009 with 1 comments |
