BlogmyQuery – BMQ

There are different ways to make your website faster: specialized plugins to cache entire rendered HTML pages, plugins to cache all SQL queries and data objects, plugins to minimize JavaScript and CSS files and even some server-side solutions.

But even if you use such plugins, using internal caching methods for objects and database results is a good development practice, so that your plugin doesn’t depend on which cache plugins the end user has. Your plugin needs to be fast on its own, not depending on other plugins to do the dirty work. And if you think you need to write your own cache handling code, you are wrong. WordPress comes with everything you need to quickly implement varying degrees of data caching. Just identify the parts of your code to benefit from optimization, and choose a type of caching.

WordPress implements two different caching methods:

1. Non-persistent
   The data remains in the cache during the loading of the page. (WordPress uses this to cache most database query results.)
2. Persistent
   This depends on the database to work, and cached data can auto-expire after some time. (WordPress uses this to cache RSS feeds, update checks, etc.)

Non-Persistent Cache

When you use functions such as get_posts() or get_post_meta(), WordPress first checks to see whether the data you require is cached. If it is, then you will get data from the cache; if not, then a database query is run to get the data. Once the data is retrieved, it is also cached. A non-persistent cache is recommended for database results that might be reused during the creation of a page.

The code for WordPress’ internal non-persistent cache is located in the cache.php file in the wp-includes directory, and it is handled by the WP_Object_Cache class. We need to use two basic functions: wp_cache_set() and wp_cache_get(), along with the additional functions wp_cache_add(), wp_cache_replace(), wp_cache_flush() and wp_cache_delete(). Cached storage is organized into groups, and each entry needs its own unique key. To avoid mixing with WordPress’ default data, using your own unique group names is best.

Example

For this example, we will a create function named d4p_get_all_post_meta(), which will retrieve all meta data associated with a post. This first version doesn’t involve caching.

function d4p_get_all_post_meta($post_id) {
    global $wpdb;

    $data = array();
    $raw = $wpdb->get_results( "SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id = $post_id", ARRAY_A );

    foreach ( $raw as $row ) {
        $data[$row['meta_key']][] = $row['meta_value'];
    }

    return $data;
}

Every time you call this function for the same post ID, an SQL query will be executed. Here is the modified function that uses WordPress’ non-persistent cache:

function d4p_get_all_post_meta($post_id) {
    global $wpdb;

    if ( ! $data = wp_cache_get( $post_id, 'd4p_post_meta' ) ) {
        $data = array();
        $raw = $wpdb->get_results( "SELECT meta_key, meta_value FROM $wpdb->postmeta WHERE post_id = $post_id", ARRAY_A );

        foreach ( $raw as $row ) {
            $data[$row['meta_key']][] = $row['meta_value'];
        }

        wp_cache_add( $post_id, $data, 'd4p_post_meta' );
    }

    return $data;
}

Here, we are using a cache group named d4p_post_meta, and post_id is the key. With this function, we first check to see whether we need any data from the cache (line 4). If not, we run the normal code to get the data and then add it to the cache in line 13. So, if you call this function more than once, only the first one will run SQL queries; all other calls will get data from the cache. We are using the wp_cache_add function here, so if the key-group combination already exists in the store, it will not be replaced. Compare this with wp_cache_set, which will always overwrite an existing value without checking.

As you can see, we’ve made just a small change to the existing code but potentially saved a lot of repeated database calls during the page’s loading.

Important Notes

1. Non-persistent cache is available only during the loading of the current page; once the next page loads, it will be blank once again.
2. The storage size is limited by the total available memory for PHP on the server. Do not store large data sets, or you might end up with an “Out of memory� message.
3. Using this type of cache makes sense only for operations repeated more than once in the creation of a page.
4. It works with WordPress since version 2.0.

Database-Driven Temporarily Persistent Cache

This type of cache relies on a feature built into WordPress called the Transient API. Transients are stored in the database (similar to most WordPress settings, in the wp_options table). Transients need two records in the database: one to store the expiration time and one to store the data. When cached data is requested, WordPress checks the timestamp and does one of two things. If the expiration time has passed, WordPress removes the data and returns false as a result. If the data has not expired, another query is run to retrieve it. The good thing about this method is that the cache persists even after the page has loaded, and it can be used for other pages for as long as the transient’s expiration time has not passed.

If your database queries are complex and/or produce results that might not change often, then storing them in the transient cache is a good idea. This is an excellent solution for most widgets, menus and other page elements.

Example

Let’s say we wanted an SQL query to retrieve 20 posts from the previous month, along with some basic author data such as name, email address and URL. But we want posts from only the top 10 authors (sorted by their total number of posts in that month). The results will be displayed in a widget.

When tested on my local machine, this SQL query took 0.1710 seconds to run. If we had 1000 page views per day, this one query would take 171 seconds every 24 hours, or 5130 seconds per month. Relatively speaking, that is not much time, but we could do much better by using the transient cache to store these results with an expiration time of 30 days. Because the results of this query will not change during the month, the transient cache is a great way to optimize resources.

Returning to my local machine, the improved SQL query to get data from the transient cache is now only 0.0006 seconds, or 18 seconds per month. The advantage of this method is obvious in this case: we’ve saved 85 minutes each month with this one widget. Not bad at all. There are cases in which you could save much, much more (such as with very complex menus). More complex SQL queries or operations would further optimize resources.

Let’s look at the actual code, both before and after implementing the transient cache. Below is the normal function to get the data. In this example, the SQL query is empty (because it is long and would take too much space here), but the entire widget is linked to at the end of this article.

function d4p_get_query_results() {
    global $wpdb;

    $data = $wpdb->get_results(' // SQL query // ');

    return $data;
}

And here is the function using the transient cache, with a few extra lines to check whether the data is cached.

function d4p_get_query_results() {
    global $wpdb;

    $data = get_transient('my_transient_key');

    if ($data === false) {
        $data = $wpdb->get_results(' // SQL query // ');
        set_transient('my_transient_key', $data, 3600 * 24);
    }

    return $data;
}

The function get_transient (or get_site_transient for a network) needs a name for the transient record key. If the key is not found or the record has expired, then the function will return false. To add a new transient cache record, you will need the record key, the object with the data and the expiration time (in seconds), and you will need to use the set_transient function (or set_site_transient for a network).

If your data changes, you can remove it from the cache. You will need the record key and the delete_transient function (or delete_site_transient for a network). In this example, if the post in the cache is deleted or changed in some way, you could delete the cache record with this:

delete_transient('my_transient_key');

Important Notes

1. The theoretical maximum size of data you can store in this way is 4 GB. But usually you would keep much smaller amounts of data in transient (up to couple of MB).
2. Use this method only for data (or operations) that do not change often, and set the expiration time to match the cycle of data changes.
3. In effect, you are using it to render results that are generated through a series of database queries and storing the resulting HTML in the cache.
4. The name of the transient record may not be longer than 45 characters, or 40 characters for “site transients� (used with multi-sites to store data at the network level).
5. It works with WordPress since version 3.0.

Widget Example: Using Both Types Of Cache

Based on our SQL query, we can create a widget that relies on both caching methods. These are two approaches to the problem, and the two widgets will produce essentially the same output, but using different methods for data retrieval and results caching. As the administrator, you can set a title for the widget and the number of days to keep the results in the cache.

Both versions are simple and can be improved further (such as by selecting the post’s type or by formatting the output), but for this article they are enough.

Raw Widget

The “rawâ€� widget version stores an object with the SQL query results in the transient cache. In this case, the SQL query would return all columns from the wp_posts table and some columns from the wp_users table, along with information about the authors. Every time the widget loads, each post from our results set would get stored in the non-persistent cache object in the standard posts group, which is the same one used to store posts for normal WordPress operations. Because of this, functions such as get_permalink() can use the cached object to generate a URL to post. Information about the authors from the wp_users table is used to generate the URL for the archive of authors’ posts.

This widget is located in the method_raw.php file in the d4p_sa_method_raw class. The function get_data() is the most important part of the widget. It attempts to get data from the transient cache (on line 52). If that fails, get_data_real() is called to run the SQL query and return the data. This data is now saved into the transient cache (line 56). After we have the data, we store each post from the set into the non-persistent cache. The render function is simple; it displays the results as an unordered list.

Rendered Widget

The previous method works well, but it could have one problem. What if your permalink depends on categories (or other taxonomies) or you are running a query for a post type in a hierarchy? If that is the case, then generating a permalink for each post would require additional SQL queries. For example, to display 20 posts, you might need another 20 or more SQL queries. To fix the problem, we’ll change how we get the data and what is stored in the transient cache.

The second widget is located in the method_rendered.php file in the d4p_sa_method_rendered class. Within, the names of class methods are the same, so you can easily see now the difference between the two widgets. In this case, the transient cache is used in the render() method. We’re checking for cached data, and if that fails we use get_data() to get the data set and generate a rendered list of results. Now, we are caching the rendered HTML output! No matter how many extra SQL queries are needed to generate the HTML (for permalinks or whatever else you might need in the widget), they are run only once, and the complete HTML is cached. Until the cache expires, we are always displaying HTML rendered without the need for any additional SQL queries or processing.

Download the Widget

You can download this D4P Smashing Authors plugin, which contains both widgets.

Conclusion

As you can see, implementing one or both caching methods is easy and could significantly improve the performance of your plugin. If a user of your plugin decides to use a specialized caching plugin, all the better, but make sure that your code is optimized.

(al)

© Milan Petrović for Smashing Magazine, 2012.

When working around bugs and different levels of support in various browsers, a common approach is using conditional comments to target certain versions of Internet Explorer. Come to think of it, it’s pretty rare to need to fix something for an older version of any other browser. People who do not use IE tend to upgrade quicker and CSS-related bugs in other browsers tend to be less severe than in IE, especially compared to IE7 and older.

Anyway, while working on a lot of responsive layouts lately I’ve started using an approach that I’ve found reduces the risk of more advanced CSS, especially CSS3, tripping up older browsers. I simply wrap any CSS that I know won't work at all or may only half-work in a very basic media query, like this:

@media only screen {
    /* "Advanced" CSS2 and CSS3 goes here */
}

Read full post

Posted in CSS.

Copyright © Roger Johansson

Whether you build websites as part of a design agency, as a freelancer, or with an internal team, you don’t design in a vacuum; you work with people. To collaborate and develop a shared understanding of goals and assignments, you have meetings. It doesn’t matter what kind of process you have—waterfall, agile, or “jazz improv”—you cannot get to site launch without having had at least a few meetings. In any design process, coming together insures your project against breakdown due to unrealistic expectations, limited resources, and differing definitions of the problem or the solution.

Today’s web design professionals practice any mix of graphic design, information architecture, user interface design, usability testing, user research, and front-end or back-end development skills. The value of the modern web design professional is not those disciplines, however, but the ability to combine them to solve real problems, especially as a group. Effective group work requires structured, strategic meetings, and good facilitation provides that structure.

What does good facilitation look like?

Imagine the most fulfilling, collaborative design meeting you’ve ever had. Hours seemed to fly by, and those hours were productive. Political and mental barriers melted away and in their place were innovative ideas, or realistic solutions for complex problems. For several shining moments the team worked as one; the conversation or the activity was equally fun and productive, and you left the room feeling smart and empowered. It’s highly likely that someone in that meeting was a facilitator, either by design or by accident. If you can’t identify the facilitator, chances are it was you.

To the untrained observer, a great facilitator seems to perform Jedi mind tricks: a skill that we’ve all wished for during a troublesome meeting. Imagine if you could simply wave your hand to reach consensus with a disagreeing counterpart. Projects (and life) would be so much easier. Most of us have seen this happen in meetings. Without aggression or argument, and with seemingly little effort, a meeting Jedi guides the discussion into a productive and beneficial space. Some person in the room manages the process to explore and evolve contentions to reframe understanding around a shared goal. For example:

• At a kickoff meeting for a web redesign project, a member of the team is fixated on putting dozens of Facebook Like buttons on each page, so that users can “like all the things.” The content strategist leads a team-based competitive game where working groups create and ship imaginary digital products that align social interaction to content that users care about. In subsequent discussion, social media becomes content strategy rather than a feature. Attack of the Like buttons averted.
• During the prototype phase of building an iPhone app, a team member becomes obsessed with the typography, (lack of) color, and other graphic design elements. The information architect demonstrates a sequence of transitions from prototype to final design for a number of tangentially similar projects. Obsession dissolves.
• While selecting from graphic design direction options, a client is convinced that the website must “look like my iPad.” The creative director leads the group through a freelisting activity, where the team lists every design problem the iPad solves, then explores the alignment between those problems and the project’s problems. The client associates specific techniques with overlapping problems. Conviction evolves into insight.

These examples share a similar pattern: they begin with dissonance, usually rooted in differing perceptions of a technology or design technique. Then, through a planned activity specifically designed to expose and explore that dissonance, the group develops a more sophisticated, shared vocabulary around the problem. Finally, the group reaches an understanding through persuasion, collaboration, or both. Good facilitation is the tactical skill that empowers you to orchestrate this process, and it’s a skill that anyone can learn.

Facilitation basics for any meeting

First published in 1976, How to Make Meetings Work introduced a role-based process, dubbed “the new interaction method” for improving any kind of meeting. For a successful meeting, someone in the room must assume one of the following roles:

1. a group member (most of the folks involved),
2. an organizational leader,
3. a recorder, and
4. a facilitator.

A facilitator has the right combination of knowledge about the problem, a playbook of meeting protocols to open, explore, and narrow focus on the problem, and prior experience running a group through those protocols. The facilitator plays an entirely neutral role. By adopting neutrality, and not contributing or evaluating ideas, the facilitator creates a locus of trust.

Inspired by How to Make Meetings Work, Sam Kaner and Jenny Lind set out to document the core values, organizational strategies, and a diverse set of solid facilitation methodologies in their 2007 book, The Facilitator’s Guide to Participatory Decision Making. The book argues that for organizations to be effective, they need to involve all members of the organization in the decision making process.

However, the natural dynamic of larger or multi-group discussions often leads to awkward disagreements and dead ends. Solid facilitation methods help you move around, over, or through these situations. A good facilitator “support(s) everyone in doing their best thinking” during a meeting—they build and execute participatory processes. To do so successfully, they serve four functions during a collaboration:

1. Encourage participation. This one’s a no brainer, but it’s harder than it sounds. There are bulls and daffodils in every meeting and it’s the facilitator’s job to elicit and balance everyone’s contributions. One approach is to have participants write down their ideas before speaking them out loud. This technique prevents bigger personalities from dominating by simply being louder, and it forces participants to write approximately the same amount of content. Another technique is to change the order of people called upon for ideas, ensuring that you have a clearly non-biased pattern: go around the table clockwise, then go counterclockwise, then choose randomly. Mix it up.
2. Build a “shared framework,” or understanding of the problem. To build shared understanding, you must define what different concepts mean for different people, and make sure everyone agrees on a single meaning for key concepts. Building shared understanding is one of the toughest things facilitators have to do. One approach is to manage the scope of the discussion by establishing what you are and are not going to talk about in the meeting invitation, and reiterate the discussion’s scope at the beginning of the meeting.
3. Seek inclusive solutions that “work for everyone with a stake in the outcome.” This requires the group to explore the design challenge more than some may be used to, especially senior leadership. (“Can’t we just build a website?”) Touch on the ways in which the website affects every person in the room, and the departments the project represents. It will take more time now, but will save time and headaches later. Early in the process, ensure everyone has voiced their ideas/feedback/concerns and make sure those concerns are clearly documented for everyone to see. Then, when someone hammers the same point repeatedly, it’s easy to point to the documentation and say This has been documented, and will be addressed.
4. Finally, design solutions based upon shared responsibilities. If you’ve designed an amazing collaborative session and assigned all the work to a single party, you’ve wasted your time and your participants’ time. Good strategies depend on everyone involved participating. For web design, this translates into some simple best practices. Involve the developers in the early meetings. Make sure the information architects are part of the quality assurance scrums. Generally, be less siloed about the design approach based on discipline, and offer the option to participate whenever someone MAY have something to add.

Facilitation basics for design collaborations

Being neutral and designing solid participatory processes will help you facilitate effective discussions. These four additional concepts have been invaluable in helping me connect with clients in meeting scenarios unique to the web and application design process.

1. Provide clear guidance through a series of steps intended to reach an agreed-upon end result.

   Select the best activity for the problem at hand. The good news is there’s been a renaissance of fantastic resources that will help you build that playbook. Books like Gamestorming, Visual Meetings, Back of the Napkin, and Business Model Generation provide pre-built, engaging collaborative activities for design and beyond, built upon ideas found in game theory and sketch facilitation. These resources will help you align activities to the specific parts of your web design process, whether you are at the beginning, middle, or end. They also organize activities based on additional constraints such as time, materials, environment, and the number of people involved in the process. With a few sticky notes and a whiteboard, you can accomplish just about anything.

2. Always follow this pattern: allow for divergence of opinion, permit participants to explore those opinions within constraints, and then force ideas to converge.

   Divergence — Exploration — Convergence is a simple but powerful pattern, prominent throughout meeting and facilitation literature. For more productive meetings, workshops, and conversations, always follow that sequence.

   Ever been in a kickoff meeting where someone says “That’s a terrible idea!” in the first five minutes? It felt awkward and perhaps even hostile, because someone has jumped right to the end of the pattern (convergence) before you've had a chance to diverge and explore. By designing your kickoff interaction to embrace diversity in the beginning of the meeting, it establishes trust. That trust makes it safe for people to want to participate. As long as the subsequent prioritization process is transparent, people will feel like they were heard AND they participated in the outcome.

   On the surface, the kickoff meeting’s goal seems straightforward—we need to agree on what we will—and will not—be doing for a particular project or sprint. But for even the simplest website redesign with a small client team, there could be half a dozen versions of that “what” in the room. Therefore you must elicit each version of what’s expected right at the beginning of the meeting. Establish the level of diversity in expectations—remember, as a facilitator, you’re not judging those expectations at this point. Once expectations are out on the table, explore the relative merits of each one. Then provide some methodology to prioritize, and if appropriate, eliminate options.

   “The bookend” is a great technique I use to elicit expectations. At the beginning of a meeting, ask the group a grounding question about their expectations for the meeting. “Write this down: What do you want get out of the next two hours?” Have them put it aside for later. Before you leave, give anyone whose expectations have not been addressed during the meeting a chance to express their concerns. Collect those expectations, document them in a shared location, and address them in future collaborations or subsequent project work.

3. Provide a real-time representation of what’s going on during the meeting where people can see it.

   One person—not a facilitator—must take notes during the meeting. Fail to assign a note taker and you flush any detailed insights gained during the meeting down the toilet. In addition, a facilitator should provide a visual representation of the discussion in a format that everyone in the room can quickly and easily reference.

   There are lots of ways to do this. Use an easel with large, adhesive-backed paper. When you start a topic, label the top of the paper with that topic and number it (starting with number one) with a nice big Sharpie. Once the team fills the sheet with ideas, pull it off, stick it on the wall, and start a new piece, labelled number two. At the end of the meeting, pull all the sheets off the wall, roll them up, and transcribe them as an outline of the key issues raised. The note taker has the transcript, but this is the discussion’s larger narrative and a great way to remind folks of the key insights gained during a discussion.

   As a facilitator, be effective at paraphrasing the essence of the ideas raised. When someone makes an important point (important either to the project, or simply important to them), take the time to verbally echo their point back to them with greatly reduced wording. Ask “Is this what you mean?” If you get a yes, Sharpie that idea large on one of those big sheets of easel paper. Keep capturing those mini-ideas, and display them where everyone can see them. Soon people will cut down on repeating themselves, be more to the point, and hit the discussion with new ideas faster.

   This is also a powerful way to course-correct a meeting that has gotten out of hand. If a discussion lacks direction, discreetly get up, go to an easel (or whiteboard), and start capturing the essence of what people are saying. When folks ask “What the hell are you doing?!,” just say “This helps me follow the discussion.” I’ve introduced this ambush note-taking technique to people in both agencies and in-house teams. I’ve heard stories where people stand up and applaud when someone starts capturing the conversation in a visible way. People are much more careful about what they say when it’s being written down, and it’s a great way to focus people’s attention.

4. Keep in mind that everyone in the room, no matter what they say, believes that their recommended action equates to doing the right thing.

   I can’t count the times I’ve been facilitating meetings where someone, out of the blue, has said the most ridiculous thing you could possibly imagine. “You know, I love that black and white image. Let’s make everything black and white. Everything, everywhere.”

   After suppressing anger, or laughter, I always keep this in mind: we all have different perspectives on the process we’re involved in. But anyone who takes the time contribute truly believes that their idea is going to make things better. It may be off the mark, misinformed, or even crazy, but it’s more important for you as a facilitator to understand why that idea surfaced in their brain, and how it relates back to the value they hope to add to the project. The more you understand those values as the individual contributors perceive them, the easier it will be to design a project strategy that will not just be adopted, but embraced.

Use the force, Luke

Great web design is perceived as appropriate and enjoyable by users and clients alike. To get there, you have to have a process. To build consensus about where that process should go, you have to facilitate understanding of the myriad overlaps between business and user needs, art direction and brand, and innovation and ease-of-use. Great design is facilitating these forces.

May the forces be with you.

Translations:
Italian

RSS readers: Don't forget to join the discussion!

Every client/vendor relationship is based on a set of expectations, whether they’re stated or not. When you hire a painter, the act of applying paint is only part of the gig. All the steps that lead to the finished job are where the details lie.

I expect the painter to:

• Get to my house on time.
• Move any furniture that’s in the way.
• Put down drop cloths.
• Refrain from smoking in my house.
• Refrain from rinsing brushes in my kitchen sink.
• Be respectful and professional.
• Finish the job on time.
• Leave the house in the shape it was in before the job started.

I don’t expect the painter to:

• Feed my dog while I’m at work.
• Set my alarm system.
• Paint areas I didn’t specify.
• Apply three coats of paint.

A lot can go unsaid or unspecified for any project, large and small. Not being specific can lead to disagreements, quarrels, and high blood pressure.

For my day job, I’m on the other side of the fence. At Happy Cog, we work with dozens of clients each year. Over the years, you learn a thing or two about a thing or two, usually as a result of the mistakes you’ve made along the way. A business relationship is governed by what you mutually agree to. A Statement of Work (SOW) or Statement of Services (SOS) is one tool used to align expectations. We used to use SOW and SOS synonymously with the words “contract” or “proposal,” but they’re actually a little different. Whatever you call them, they will save your bacon.

SOWs and MSAs

A Statement of Work (SOW) is usually a document that accompanies yet another document, often referred to as a Master Services Agreement (MSA). They’re the Lenny and Squiggy of legal agreements. The MSA is usually the governing document for the entire relationship, while the SOW usually deals with the specifics of a single project or scope of work. Our larger scale clients usually prefer to lead with an MSA, even though we’d rather lead with our own agreement, which we call a Project Service Agreement (PSA). The acronyms are already making me loopy.

An MSA will typically address relationship-governing topics such as:

• General Services—In general terms, what you’ll provide the client (web design services, content strategy, etc.).
• Project Management—What the roles for project managers on both sides will be.
• Deliverables—How deliverables will be provided to and accepted by the client.
• Support/Deployment—What assistance you’ll provide the client with implementation, and what additional support you’ll provide moving forward.
• Payment/Expenses—How you’ll get paid, which expenses are covered and which aren’t.
• Audits—How the client can ask you to prove you’re doing your job.
• Confidentiality—What you can’t say about the work, and what your client can do if you blab.
• License Grants—What client-owned information you’re allowed to use, and for how long.
• Proprietary Rights—Who owns the work (even the individual elements of it) when the job’s done.
• Term and Termination—How long the agreement lasts, who can end the agreement, and for what reason.
• Representations and Warranties—Ensures you can do the work, you’re not in conflict with other agreements, and that you’ll fix what’s broken if it’s your fault.
• Indemnification—To guarantee against any loss which another might suffer.
• Insurance—The types and amounts of insurance coverage you’re required to carry to perform the work.

A SOW, on the other hand, typically addresses such things as:

• Requested Services—Describing what the project actually is.
• Project Phase Descriptions—Detailing how many phases, and what goes into them.
• Project Duration and Milestones—Estimating how long the project will take and what milestones occur along the way.
• Resource Hours—How many hours are allocated to each phase.
• Billing Rates—What you’re charging for each practitioner in your company.
• Proposed Tasks & Deliverables—What you’ll do and deliver, and when.
• Commencement and Completion Dates—When you’ll start, and if all goes well, when you’ll finish.
• Service Fees—How much you’re charging for the entire engagement.
• Payment Schedule and Terms—How much you’ll get paid, and when.
• Listing of Representatives—Who the primary players are on each side, or at least what their roles are.

As you can see, it’s all quite invigorating.

If the MSA and the SOW have similar or conflicting language, the MSA is usually the agreement that takes precedence. Some lawyers will tell you it should be the other way around, and will fight for that stipulation. After all, the details the SOW captures are more project focused and granular, and therefore may provide more context. An SOW is created for each specific project, and is highly specific to the current work at hand.

Be careful: don’t lock in to a long-term MSA

We usually don’t sign MSAs that carry a term longer than a year. Why? Well, say you sign an MSA with a two-year term that states that the client can terminate the relationship whenever they want, but you can’t. You sign the MSA anyway, because you were too lazy to consult a lawyer to slap some sense into you. Then, you execute a SOW for a big project that takes a year to finish, and everything goes smoothly. Based upon that positive experience, you agree to sign another SOW for an even bigger project. Remember, you’re still governed by the MSA you originally signed a year ago. Say that during the second project, the person you loved working with on the client side leaves, and is replaced with someone who is impossible to work with. After trying everything you can to make the project work, you decide you want to get out. Well, too bad. The MSA says you can’t. Have fun with that!

The bottom line is this: you're always learning, and your needs change. Don’t lock yourself into things. It’s the same reason you don't want to sign a three-year contract when you sign up with a mobile carrier.

I’m not the first to say this, as it applies to both MSAs and SOWs: everything is negotiable. Don’t simply take an MSA from a company, and because you might need the dough, sign it without scrutinizing it. Get yourself a lawyer and go through it. Track changes. Your client will expect that, and you won’t be a jerk for putting it under a microscope. We once had a prospective client try to slip a non-compete clause in the MSA that stated we couldn't consider any opportunities in their industry for a period of five years. Um, no. Be sure to look closely.

PSAs

At Happy Cog, our preferred starting point when defining a business relationship isn’t the MSA/SOW combo many of our potential clients enjoy so much. As I mentioned above, we lead with our own Project Service Agreement (PSA). It’s specific to the project at hand like a SOW, but it also contains all of the relationship-governing legal stuff like an MSA. It’s an MSA, SOW, proposal, and agency résumé in a neat, elegantly designed package (MSAs and SOWs are usually ugly legal documents, so we like to construct/design our own that better communicates our brand).

Our PSA starts with the information our prospective clients want to see the most: the cost. We save them from the page flipping/PDF scrolling. There it is, our price tag, right on page two in big, bold numbers. On the same page, we detail our proposed payment schedule, and how we prefer to be paid. On the surface, it sounds like the wrong thing to do, but after considerable testing, our prospects appreciate it.

Next, the PSA provides an overview of the history of our company, talks about our differentiators, and includes bios of our people. Next, there are several paragraphs that introduce the problems we’re trying to solve. At a very high level, we describe how we propose to solve them. We then detail the phases involved with our effort, including the number of hours we expect to expend on each phase.

After all of the prose comes the legalese. It is a bit jargony, but it has to be. Every time we tried to convey legal language in an easy-to-understand way, we were doing ourselves more harm than good. Know your audience. Lawyers expect to read things a certain way.

Be vague (you heard me)

This is subtle, but important: don’t try to solve what you don’t understand yet.

Reflecting on many years, even before my role at Happy Cog, I think we tended to consider projects a bit too “one-size-fits-all-ish.” Up front, we would establish which tasks we were going to perform, which artifacts we were going to produce, how many comps we were going to design, and how many revisions we would offer. It usually consisted of a site map with three rounds of revisions, 10-12 wireframes with three rounds of revisions, three different design comps created by three different designers revised three times, and HTML/CSS templates for 10-12 pages. For just about every project. This created a bunch of issues.

First, we were prescribing solutions before really understanding the problems. And the only way you can be 100% confident about what you should be delivering is to do your research and to have in-depth conversations. But how do you articulate how you’ll solve problems you don’t fully understand yet? You’re still trying to be asked to the dance. There are no signatures on contracts yet. And we didn’t want to do a bunch of unpaid fact-finding to achieve clarity for the sake of a contract.

We needed to solve that issue. Two ideas came to mind. We could choose to:

• Change our approach to simply pitch a project research/definition phase for a fraction of the total project cost, and allow the findings from that effort to provide the ammo we needed to put together a detailed contract for the rest of the work.
• Be a bit more vague with what we say we’ll do.

That second bullet point looks ridiculous when you read it. Shouldn’t you be getting more specific, not less? I’d argue no. Instead of prematurely committing to a course of action that may or may not be appropriate for the project, we identify all of the possible artifacts we could produce in each phase. Then we commit to zero of them.

The specific deliverables Happy Cog will provide will consist of one or more (in any combination) of the following, to be selected based upon their appropriateness for the project...

Then, we list them. For example, the types of deliverables we could provide for information architecture work includes:

• Taxonomy creation
• Persona development
• Content outline
• Content genre classifications
• Site outline
• Site map
• Wireframes
• Page description diagrams
• User/process flow diagrams
• Comprehensive experience document

Your client’s role in selecting a vendor includes performing the necessary due diligence to feel confident with your work, your people, and your process. This includes checking references. If your client has faith in your abilities, you’ll have no problems being less prescriptive with your PSA or SOW. In fact, you’re actually being responsible. You don’t know what you don’t know, right? Don’t suggest the wrong stuff just to tie your agreement up with a pretty bow. Be honest, and say that you’ll do what is the most appropriate. Most of our prospective clients, when reading our PSA, don’t bat an eye over our purposeful lack of specificity.

Bucket those hours

Back when we’d prescribe exactly what we would deliver ahead of time, we’d run into another conundrum. Clients wanting more.

We once had a client that wasn’t happy with the designs we created for them. We promised them three variations, with the winning idea revised twice more until we had the perfect design. We felt strongly about the work, but it wasn’t resonating with the client. Shortly thereafter, we exhausted our specified number of comps and revisions. We let the client know that. And to that, they responded, “That’s too bad. But we still don’t have our design, and that’s not our fault.”

That’s a fun spot to be in.

You could issue a change request/order, sure. But that will make your client breathe fire. So in addition to abandoning prescribing specific tasks and deliverables up front, we switched our model to use “buckets of hours.” We price our jobs at a fixed fee, but we also know how many hours we’ve allocated for each phase of the project. Upon exhausting 75% of a phase’s hours, we’ll fire a shot across the bow to let the client know that. Then, if they hit 100% and use all the hours, we stop work and they need to buy more. We won’t steal hours from another phase to fund the shortfall. This way, if a client wants five designs iterated five times, that’s cool with us. The hours are used how the hours are best used. Freedom.

Documenting requirements

Whether you’re hiring a painter, a builder, or a creative company, you need to think about requirements, which also set expectations. In our world, there are business requirements, content requirements, and technical requirements, to name a few. And you might think that a contract is the right place to document those requirements. I know I’ve tried to identify as many of those details as early on as possible to minimize risk and ambiguity. It’s tough to do. I’d argue that the contract is not the appropriate vehicle for articulating requirements. However, the contract should specify a process by which requirements will be gathered, evaluated, and prioritized. What you can ultimately execute upon will be dictated by your project budget and timeline.

Translations:
Italian

RSS readers: Don't forget to join the discussion!

With so many architectural marvels all around us, photographers often turn their lenses towards these structural models, and the results are often as wondrous as the architectural artistry they are capturing. So much tone and mood can be given to these lifeless constructs through the photographers’ skillful compositions or knowledgeable enhancements. Which is what we are showcasing today.

Below we have a brand new showcase of architectural photography that honors generations of builders and architects who have fashioned so many of the inspired structures that populate the landscapes. We hope you find the same creative charge from the collection as we did putting it together for you. Enjoy.

Architectural Artistry

Castle Neuschwanstein III by pingallery

Fushimi Inari Taisha Torii by imladris517

glasklar by icarus-ica

purple haze by Pete1987

Munich, Candidplatz by alierturk

…drawning… by felizuko

Essay Quedlinburg 2 by matze-end

Kollhoff Tower by MatthiasHaltenhof

Interwined by T1sup

in the transition by HeretyczkaA

Castle Ruins and Old Bridge in Heidelberg by pingallery

dubai lightstream by Fersy

Williams Hall by Metal-Bender

Lights above by lostknightkg

urban_0.1 by mekemee

Washington Metro by basvdheuvel

Beautiful Italy by Antoniettaa

Minimalism by Einsilbig

Lindesnes fyr, Lindesnes, Vest-Agder, Norway by Berg52

stairs by HeretyczkaA

elevator by Fersy

The Tide by paikan07

Tower by Top4

midnight church by DoWhoRanZone

Guangzhou Museum by WiDoWm4k3r

Venice Academica by A-Motive

Aireys Inlet Lighthouse by andrisinung

Palais Lobkowitz by focusgallery

From Dome to Dome by RealFantasy1

Bauhaus Museum 2 by MatthiasHaltenhof

Messe – Prater by Zouberi

domes of Zachatievsky monastery by Lyutik966

Flux Capacitor by Sllyvain

To Conclude

That finishes off the showcase, but your input is still needed to complete this architectural photographic journey. Let us know which of the pics were your favorites, or point us in the direction of some that you feel we may have overlooked.

(rb)