Posts About Web Work
Advertising on a Responsive Web
I’m unabashedly excited about responsive design (see my review of Ethan Marcotte’s book). I believe that it has the potential to take web design in directions we haven’t considered. At Mule we’ve been applying some of the principles to recent project, seeing where things work and where they don’t, and we’ve run into one big hurdle that we haven’t yet figured out how to clear:
Advertising.
Advertising online has been pretty much the same since day one:
- Take a block of space on the page
- Put something eye-catching (animated and/or garishly colored) in that block
- Count the clicks
- Count your money
The only things that have changed are the size and delivery technologies to take advantage of bigger screens and bigger pipes. And that’s the problem. The general pitch behind web advertising depends on there being a block of certain pixel dimensions that is sold along with position and number of clicks. The web advertising world is not set up to deal in percentage widths, and they’re certainly not going to deal with ads that may or may not show up depending on the width of a user’s browser window.
Continue reading "Advertising on a Responsive Web" »
Written by David McCreath on January 17, 2012 with 4 comments | 
Always Be Disclosing
We have had the good fortune to work with many terrific, absolutely stellar clients over the years. Every one of these client relationships began with an initial contact as part of a “business development” process (while I am a fan of plain language, the whole interaction seems too nuanced and mutual to call it “sales”). We understand that clients want the best design that helps them meet their goals within their budget while working with a compatible team. In turn, we look for clients who want to accomplish something meaningful, will pay us adequately, and act as a good partner for the course of the project.
As with all things, clear communication is essential.
We tell our clients that a design project boils down to a series of decisions. Business development is a series of questions. Fundamentally, the client is asking, “Should I hire you?” and the designers are asking, “Should I work with you?”. This is truly the first phase of Discovery. Our research people often get involved to help think through the approach.
Depending on the client and the project, the time from saying “hi” to signing on the line can take anywhere from 3 days to over a year. You’d think that timeframe correlates with the scope and scale of the project, but it doesn’t. Sometimes, organizations are in the early exploration stages of doing a project when they contact us. Sometimes more pressing concerns pop up and push out the schedule. This is perfectly fine. We just ask that folks let us know and we adjust our expectations accordingly. We like to talk to people as early in their planning as possible.
Another of our handy maxims is,
“The way people behave during the sales process is the way they will behave over the course of the project.”
In general, this mindset helps us better prepare for the communication and decision-making style of a particular organization or individual once work is underway, making everything proceed more smoothly. In a few cases, it has allowed us to walk away from otherwise appealing projects with a clear conscience. Whatever the actual design challenge, the attitude and behavior of the individual humans involved make or break a project.
Continue reading "Always Be Disclosing" »
Written by Erika Hall on November 21, 2011 with 2 comments |
Book Review: DOM Scripting, Second Edition by Jeremy Keith with Jeffrey Sambells
I was very excited when I learned there was going to be a second edition of DOM Scripting. It was the book that enabled me to finally form a few years of copy-paste pseudo-coding into an actual chunk of reusable knowledge, and I have a tremendous amount of respect for Jeremy Keith, who wrote the first edition. Now I’m in the position of helping one or two other people learn how to use JavaScript the right way, and I wanted to start them with this book. This edition is both good and bad, and ironically, for a book that actively promotes the separation of content, presentation, and functionality, the good and bad is split right down the line between content and presentation.
Well, as Jeremy himself points out, he wasn’t actually involved in the second edition. That’s a little disappointing, but it’s still based on his first edition, and the ideas and concepts still carry through, so no harm, no foul.
The content of this book is still unbeatable. If you have messed a bit with JavaScript but needs to take the next step, this is the first book you should read. The fundamentals of using client-side script to work with the Document Object Model are the core, and every chapter builds on that. The book is one of the best primers on best practices I’ve ever read. Every decision is explained, every piece of code is in there for a reason. The additional HTML5 stuff is nice, too.
BUT this book is terrible to read. The typesetting is truly a mess. A tiny, cramped font is paired with tight leading and other poor spacing decisions, making it hard not only to scan, but hard to focus on in the first place. It’s really disappointing. I haven’t seen the ebook version, so I don’t know if it’s different than the print one. If someone has seen both, leave a comment and let us know.
I still think the book is worth the $35, because the knowledge it imparts is invaluable. Just be prepared to have to make yourself read it.
(The full title of the book is DOM Scripting - Web Design with JavaScript and the Document Object Model, Second Edition)
Written by David McCreath on July 12, 2011 with 1 comment |
Book Review: Responsive Web Design by Ethan Marcotte
Ever since the folks at A Book Apart started publishing books, it was a pretty sure thing that the material and product would both be good. That has borne out.
All of the books have been valuable. But this one is the one that gave me the old lightning bolt of clarity that I used to get when my job meant learning something brand new every week. Not that I don’t still learn new things, but very few of them make me rethink my entire approach to how I work.
Ethan’s book did.
The ideas behind responsive design have been out there for a while now, all the way back to the first standards groundswell. Lots of people who understood the problems with using tables as layout tools also believed that fixing the width of a web page was unacceptable and counter to the medium. And lots of other people agreed in principle (Hi! I was one!) but felt like that was a bridge too far. We had enough work getting well-designed sites to work reliably across browsers without also having to worry about how the site would look at any old random resolution or width. So we gritted our teeth and did the best we could.
Fortunately, there were people who never gave up on those ideals. And now we have the tools (HTML5, CSS 3, various JavaScript libraries) to create this more perfect web, as well as a slew of highly compliant web browsers (even one from Microsoft!) to use them. And there are people who have been figuring out how to pull all these tools together.
What’s been lacking has been that one clear, concise overview for those of us who see the value of responsive design but haven’t had time to put all the pieces together in practice. That’s what this book does. Ethan lays out his methodology with great clarity, starting with a Photoshop comp and some familiar HTML and CSS and walking through the steps of turning a fixed-width layout into something that has been carefully crafted to look good on everything from smartphones to giant flatscreen monitors. The mechanics of it hinge on one linchpin formula, which is where the lightning bolt came for me. (I don’t want to spoil the surprise. You’ll have to read the book.) By the time you finish, you might be thinking differently about how you approach projects.
Which is not to say that Ethan’s book is everything you need to know about responsive design. It’s enough to get you off the ground. As soon as you start applying his methodology, you’ll see where you still have work to do. At Mule we have two projects in-house right now that are really good candidates for responsive design. Both are more complex than the sample site that Ethan builds in his book, so learning where, when, and how to apply responsive principles to a complex, site-wide layout has proved an interesting exercise for the whole studio. It requires you to think expansively in both directions of your project flow: all the way back to the IA (“Does this flow change if we have 1200 pixels of width to work with?”) and all the way ahead to implementation and use (“How will this navigation work on a smartphone?”).
So far it’s been a great exercise for us. I bet it will be for you, too.
Buy Responsive Web Design from A Book Apart.
Written by David McCreath on July 6, 2011 with 2 comments |
Tart Up Your Startup!
We’ve worked with a lot of early-stage companies over the years. Some of those engagements have gone swimmingly and some—well, we have taken the lesson and moved forward. Recently, the notorious Dave McClure, super angel, has become a terrific champion for the value of design to startups. I even had the extreme pleasure of speaking at Startonomics a couple of years ago on a related topic. (Video: See me looking squat next to Jeff Veen.)
We thought it would be helpful to share a few quick insights to those of you thinking, “I have some engineers and some cash. Now, I want some of that sweet design magic.”
Before you read further, I’ll have to ask you repeat aloud: “Design* is not magic. Design is not art. Design is a set of considered, goal-oriented decisions.”
Thanks.
Continue reading "Tart Up Your Startup!" »
Written by Erika Hall on April 11, 2011 with 2 comments |
It's a Matter of Time: Massively Accelerating Design Projects
Yesterday.
That’s the all-too-common answer when we ask a potential client, “When do you need to have this done?”
We are big fans of physics. As such, we have chosen to work within its laws. And while our level of experience makes us fairly quick, good design does require a non-negative amount of time.
So, what can you do to goose the P in ASAP? For any given user experience design project (that is to say, work of some complexity involving a team or three), there are quite a few things.
Unfortunately, these things are boring and mostly have to do with organization and communication rather than creative magic. But they are effective. If you are planning a design project and want to propel it to success, read on.
I’ll try to keep this short.
Continue reading "It's a Matter of Time: Massively Accelerating Design Projects" »
Written by Erika Hall on March 30, 2011 with 3 comments |
Designer, at Your Mercy
As regular readers know, we have a stake in the ongoing discussions of gender and career advancement in design and technology. So, it was with interest that we read Where Are the Women in Type Design? by Verena Gerlach. It’s a timely perspective on the topic given the ascendence of type-awareness driven by web fonts.
However, it was an assumption buried in a comment by the venerable Erik Spiekermann that caught my eye.
So [female designers] may want to reduce their work week to 30 hours or need to be home exactly on time every day. None of that makes them bad designers, but it tends to preclude them from certain responsibilities like running complex projects where they are at the mercy of clients and schedules.
Emphasis mine.
This is a weirdly pervasive attitude that bears examining. And let’s not call it a “woman thing.” At least women tend to get more of a family-care pass. I’ve seen guys get the stink eye in response to saying “I have a hard stop at 5:30 because I have to pick up my kid.”
That is not right. Neither is giving lip service to work-life balance only to send e-mail out at 1 am. Even the childless deserve personal time.
If you are, in fact, running complex projects as described above. If you do, in fact, have any hand in running things at all, the schedule should actually be at your mercy. A good project plan assumes that at the stroke of 6 pm all “resources” turn back into “people” like Cinderella’s coachmen into mice.
And clients and designers should work in partnership. The hostage mentality does no one any good. Good fences make good neighbors, and good boundaries based in mutual respect make for high-quality work.
We have a few rules here at Mule. I’ll divulge.
- Our office hours are Monday through Friday 9–6. We start booting people at 6.
- We do not answer the phone or e-mail outside of those times, unless we are working with people in other time zones.
- We do not hand out our cell phone numbers.
- On the weekend, we cease to exist.
Of course, being human, we have occasional crunch times that require longer days. And any of us might get in a little early or stay late to crank something out at a personally productive and quiet time. That is up to the individual. But if one of us feels the only time work gets done is after hours, that is a problem we work together to solve—since we are by description professional problem solvers.
It’s not about being perfect, by any means. It’s about having a standard we strive to live up to.
So, I encourage anyone stuck in Stockholm to question their circumstances. Whose mercy are you at, and why? Is it a very good reason? In that complex equation of getting big things done well, why not value a good night’s sleep, time with your family, or a drink with a friend?
It’s the responsible thing to do.
Written by Erika Hall on March 1, 2011 with 10 comments |
Project Managers, Not Calendar Monkeys
This post is the second in a series. Read Part I: The Chokehold of Calendars by Mike Monteiro.
My job is to protect my team. That’s every project manager’s #1 job. Make your team’s work possible. Provide the structure to allow a project to run smoothly. So why don’t our tools reflect that cooperative enterprise?
I’m not the only one who chafes at standard project management processes and applications. Many companies are structured in such a way that the only interaction the team has with their project manager is seeing meetings pop up on their calendar. That dynamic can only result in the team seeing their project manager as a calendar monkey and resenting them for interrupting time they need to work. That’s not how any project manager wants to be perceived, and certainly not the purpose we’re dedicated to.
Continue reading "Project Managers, Not Calendar Monkeys" »
Written by Shawna Seth on October 13, 2010 with 6 comments |
Developing Relationships: Working Well With Coders
Most of our projects at Mule involve working with other developers, whether it’s the client’s internal team or another contractor. Either way, because our design process goes all the way through front-end code, we do everything we can to make sure the transition from design to implementation goes smoothly and that the implementation team has everything they need.
Over the years, we’ve found that it takes three essential elements to have a successful relationship with an external development team. Obviously, your code needs to be of high quality. But respect and trust are just as important. If you establish those up front, everything else will flow easily.
Continue reading "Developing Relationships: Working Well With Coders" »
Written by David McCreath on September 21, 2010 with 1 comment |
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.
Continue reading "Why We Don’t Deliver Photoshop Files" »
Written by David McCreath on August 26, 2010 with 38 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:
Continue reading "Tips On Buying Design" »
Written by Mike Monteiro on August 12, 2010 with 20 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.
Continue reading "Serious Eats Recipes" »
Written by Paula Chang on July 29, 2010 with 1 comment |
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 Jones 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 Jones on June 10, 2010 with 1 comment |
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 Jones 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 David 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 David McCreath on May 16, 2009 with 1 comment |
