BlogmyQuery – BMQ

The business of building websites is one of constant change, adaptation and strategy. The way designers and developers build websites is often informed by the methods of others and their own trial and error. In light of this, we can draw a number of parallels — some philosophical, to a certain extent — between Web professionals and one of the oldest and most popular board games of all time (counting traditional and digital games). This game is chess.

Image credit

In this article, we’ll explore the relationship between the game of chess and the Web industry. We’ll learn fundamental lessons from the pawn, rook, knight, bishop, queen and king, and we’ll highlight the factors — both offline and online — that determine best practices. The game is beloved by many professionals, so it seems fitting to apply its great strategy and elegance to the digital age; certain practices might help you lead a more successful working life.

[Offtopic: by the way, did you know that there is a Smashing eBook Series? Book #1 is Professional Web Design, 242 pages for just $9,90.]

Pawns

Of all the pieces on a chessboard, the most abundant and least strategically useful are the pawns. Acting as soldiers on the front line, these men of honor advance across the board in an attempt to reach the end of the opponent’s side and transform into a more useful piece (i.e. another queen). While this doesn’t happen often, pawns nevertheless play a fundamental role in shielding higher-ranking pieces from attack, and these simple pieces are also used at the outset to gain positions of advantage.

Always Move Forward

Pawns can only move forward. They can get a quick start; players have the option of moving the pawns up to two spaces on their first move and subsequently moving them one space at a time. When you work on projects in a business environment, the principle of moving forward without back-tracking is an inspirational perspective. If you cease to constantly drive your ideas forward, they can become stagnant; progress is critical to a website’s development.

Here are some tips you can use to adopt this mindset:

• Don’t get stuck using deprecated practices when structuring website code.
• Examine your community to determine needed features for future upgrades.
• Change a website’s interface only if it would benefit the user experience.

Be Willing to Sacrifice

The ideal of giving something up in exchange for a greater good is realized by pawns, which, though limited in function, are plentiful and can protect others. In design, shielding the end user from issues that can damage the usability of the website is a worthwhile sacrifice. Having to let go of something that took time and energy is always unfortunate, but knowing when to say goodbye could mean the difference between success and failure.

Here are some tips for internalizing this attitude:

• Ensure that your Web layouts are flexible enough to meet the needs of various devices.
• Weigh the benefits of features against their pitfalls before eliminating them.
• Content is more valuable than design; never dilute its quality for eye candy.

Aim for Change

The pawn’s greatest moment is arriving at the opponent’s side of the board. Striving for betterment and aiming for your goals are behavioral ideals firmly upheld by professionals. This requires dedication and careful planning. When undertaking a creative project, it’s important to think beyond the current ask and consider the long-term project.

Here are some tips to get into this mode:

• The website-building process is never complete; ensure that you maintain a steady flow of updates.
• Think of ways to enhance the website to better cater to your visitors’ changing needs.
• It never hurts to have a business plan when scoping out a Web-based project.

Rooks

Rooks (or castles, as some people call them) are fortresses of strength that move across the board either horizontally or vertically. Their nature is similar to that of bishops in that they move in a straight line (although bishops move diagonally). Progress can be hindered by barriers, and interaction with other pieces is sometimes required, but the rook’s overall benefit is stamina and longevity.

When working on Web projects, we often put a great deal of thought into things like conventions and patterns and their theory and implementation. The nature of semantics and following recognized pathways in order to structure a document properly is reminiscent of the way that chess pieces such as the rook have a particular function and invariably carry out unique tasks. Only with logical thought can we hope to change the ultimate goals of an event and avoid obstruction.

Structure With Purpose

A rook represents strength and structure. The castle of stone might be restricted in its interactions on the chessboard, but its value is in its character. Websites need to be constructed well in order to survive the trials of everyday use. Considering how such needs should be met will ensure a sturdy and durable display of data. Take great care when structuring your work to reduce “illegal moves” and syntax.

Here are some tips for strengthening your outlook and code:

• Always validate your code; it will reduce the number of bugs.
• Use the right element for the job to improve your code’s semantic value.
• Keep code minimal to reduce file size and loading time.

Assist Those in Need

Like the other pieces on a chessboard, the rook is always on hand to help out by attacking or defending. Working with others to accomplish a task is only part of their job. In a Web environment, the same is true: if you take the time to assist those who use your website or service, not only will you increase your value, but you will gain the gratitude of the visitors, whom your website requires in order to keep running.

Here are some tips that might be of assistance:

• Providing ways for people to contact you is important to maintaining trust.
• Negative feedback can still be constructive; don’t dismiss it as “bashing.â€�
• Provide social interaction aids to help visitors feel involved in your community.

Take Precautions

Sometimes things don’t go as planned, in which case you’ll want to hold the strongest position possible. Rooks, like all other critical pieces, are only tools to protect other pieces in play, but caution is fundamental to remaining in a position of power. Thinking of how future scenarios might challenge your strategy can help future-proof your work from obvious flaws. You don’t want visitors to encounter obstacles that make them miss out on the benefits of your website!

Below are some tips for fortifying your website:

• Turn off scripts and styles to test whether your website is still usable.
• Test your websites on mobile devices, a market that is proliferating.

Knights

Knights are unique in their movement, going forward two spaces and then taking a single side-step. This means they can weave past other pieces and take up positions of singular advantage. Strategically, knights are most often used to pin hard-to-reach pieces in place through a clever attack. While this unique movement has its advantages, the knight does not replace the other pieces, which have their own strategic benefits.

Our uniqueness, whether as it is applies to our creative process, our products or our ability to solve common problems, is something we as professionals take for granted. We are able to incorporate creative flourishes when we forge applications, flourishes that can be tracked through the code (such as conditional comments, which give stylistic flavor to Internet Explorer). Like a white knight saving our sanity, our uniqueness helps us side-step issues that could otherwise become complicated.

Be Brave in Adversity

Mythology has taught us the familiar attributes of the knight: bravery, strength and honor. Thoughtful reflection on the Web-building process teaches us to be courteous to others and brave, while sticking to our guns when faced with the prospect of compromising in order to gain market share.

Here are some tips to make yourself more knight-like:

• Never take criticism personally; negative feedback is often the most useful kind.
• Don’t resign in the face of competition; the only failure in life is to quit trying.
• Try to rally support for your project; there’s strength in numbers.

Have a Selling Point

The knight is the only chess piece that move in two directions in one turn; even the queen can’t do this! This attribute teaches us the value of having a selling point. Selling points give visitors a reason to choose one product or service over others that perform the same function.

Here are some tips on finding your selling point:

• Draw from other people’s work, but never steal anything outright.
• Improving on existing services is a kind of innovation in its own right.
• Be focused in what you offer; reinventing too much increases complexity.

Avoid Barriers to Access

The knight is the only piece that can pass over others in its movement. This ability to navigate past barriers is somewhat reminiscent of standard recommendations for accessibility, which ask us to remove barriers to access on our websites. The goal is to allow freedom of movement and access to content.

Below are some tips on removing barriers:

• Consider the types of people who are not as able as you are online.
• Testing your work on an audience is better than going solo.
• Make sure your website works in different browsers to avoid serious breakages.

Bishops

The bishop is a piece that moves diagonally across the chessboard. The bishop scans the board for its next move, minding pieces that block its path, in the same way that a visitor scans content until a barrier prevent their progress. A bishop cannot step off the tile color to which it was initially assigned, ensuring a kind of vendor lock-in.

As Web professionals, we tend to get caught up in arguments about whether frameworks are useful, given their disadvantages (and even with graceful degradation, for example). The benefits of frameworks for certain situations occasionally outweigh their downsides (like trapping users in the environment), so make the most of what you have; dismissing less powerful options is not always the best way to go — in fact it could increase the amount of work required.

Have Faith in Your Work

The bishop, of course, is religious in nature, an agent in the battle between two sides. Faith in a religious sense is not needed to practice Web design, but as a quality of character it does play a part in one’s identity. Faith affects motivation and makes you believe in the project you’re spending so much time and effort on. If you have no faith in your craft, the job is doomed from the outset.

Here are some tips for building faith in your work:

• Create a list of benefits to focus on your website’s potential.
• Set realistic, structured goals to achieve success.
• Encourage visitors to recommend your work to people they know.

Know Your Limits

It may seem frustrating that each bishop is trapped on its own color, limited in impact. But if you make the most of it, bishops can still be useful. Know your own strengths and limitations, so that you don’t attempt the impossible or unachievable — if you do, the result will surely be flawed.

Here are some tips on knowing your limits:

• Get external support or advice when you hit a wall.
• If something can’t be achieved the way you hoped, look for alternatives.
• Reduce your weaknesses by learning new skills regularly.

Stick to Your Guns

While being able only to move diagonally may seem like a disadvantage, this can prove useful on occasion. Having sheer determination to carry out a job in a certain way is admirable. We humans are sometimes stubborn, and we stick to our guns when possible. This can cause us to make mistakes… or motivate us to persevere.

Here are some tips on being determined:

• Reflect on a project’s overall goals whenever possible in order to reassess a plan’s feasibility.
• Mistakes happen, and no one is perfect, but that’s no reason to stop trying.

The Queen

The queen is the second-most important piece on the chessboard. She can move horizontally, vertically and diagonally across any distance, and her power spans the entire board. She is the king’s most agile bodyguard, and losing her can be devastating. You have to use your power responsibly, both on the chessboard and in your profession; misusing your tools could cause you to lose visitors to the competition.

Sometimes we find ourselves swatting a fly off a nuclear warhead. Knowing exactly what to use, when to use it and how to use it appropriately is what ultimately distinguishes professionals from amateurs. In addition, taking advantage of the powerful tools at our disposal can speed up progress and eliminate the complexities that come with attempting the impossible with simple tools.

Realize Your Potential

A potent force, the queen moves freely about the chessboard, with few restrictions. The queen is a powerful piece and reminds us to exert the greatest effort to reach our potential. Rather than staying in our comfort zone, we must always learn new skills and achieve more than what is expected of us.

Here are some tips to stretch your skills:

• Everyone has the capacity to learn; keep your skill set up to date.
• Push yourself to become a better professional and to exceed your own expectations.
• Try not to let any of your skills go to waste when creating something.

Cover All Bases

In our work, we try to minimize error by viewing every situation from multiple angles — this is important. In chess, players use the queen in much the same way, exploiting her power yet shielding her from harm. In the creative process, your only real limitation is being blind to critical elements, which is why getting some perspective from outside testers and users never hurts.

Here are some tips to cover your bases:

• The more time you spend planning a project, the better the results usually will be.
• Information architecture is your friend; make use of wireframes and mock-ups.
• Spend time testing your website intensively for critical flaws.

Strategy and Learning

You have two knights, two rooks, two bishops and many pawns, but only one queen. Her value lies in her singularity; each move of the queen requires strategy and consideration of consequences. We become better players — and professionals — through trial and error, constant learning and foresight. Being cautious in the game teaches us to be wise in business.

Here are some tips to help you strategize:

• Read blogs, books, tutorials, magazines and anything else that can help guide you.
• Analyze your target audience to get ideas on what your website might need in future.
• Researching the competition gives you a sense of what potential visitors need.

The King

No piece is as important as the king; it is the one piece that must evade capture. The king moves only one space at a time, in any direction, and whenever it is in immediate danger, either a piece must be moved to block the attack or the king must be moved to avoid it. The king has no equal and cannot be restored by a pawn — sacrifice, and so prevention is imperative.

Web professionals have to protect what is important, too. We deal with payment details, databases, passwords and other sensitive information. If we lose any of that through carelessness or a lack of preventative measures, we end up losing something greater: the customer. Establishing trust takes time, but it can be lost as quickly as a surprise checkmate!

Avoid Traps

Protecting the king is the primary concern of every chess player. Gaining advantage to prevent loss is important. While Web professionals usually have no reason to evade capture (unless they’re doing something wrong), the benefit of avoiding common traps (the equivalent of “foolsmate” in chess) becomes apparent when testing the cross-browser functionality of a website.

Here are some tips on avoiding traps:

• Try to reduce the intrusiveness and obtrusiveness of your website to enhance the visitor’s experience.
• Actively seek out errors in your work to improve your service.
• Internet Explorer is a pain. Watch out for its rendering faults.

Value and Importance

A common tactic in chess is to weigh the value of the pieces against the benefits they represent. The king is critical because the game is lost without it. Comparing value has an important role in the Web industry, too, especially when losing mission-critical features would undermine the entire process. Comparing value also helps when prioritizing maintenance work or scheduling upgrades.

Here are some ways to tip the scale:

• Accurately pinpoint the value of your service.
• Upgrades are avoidable, but reduce downtime as much as possible.
• Price your service fairly; prices that are either too high or too low create problems.

Know When to Resign

Sometimes we get so excited — or stressed, as the case may be — about complex or next-to-impossible projects that we forget the option of saying “no.� We never like to resign or throw down our sword; we feel as though we have failed because we couldn’t meet the client’s needs. But firing bad clients and knowing when to scrap weak ideas is a part of being a professional. You can’t win every fight.

Here are some tips on recognizing when to throw in the towel:

• Trust your instincts when deciding whether to undertake a project.
• Salvage something from anything you work on.
• Learn how to deal with “clients from hell.â€�

Chessboard

Chess players focus on the pieces in play and on capturing the king, but they must also understand the chessboard as a battleground on which this drama plays out. This relates to the website-creation process (and to a lesser extent, the Web industry): lessons are to be learned from the chessboard itself.

Image credit

Light and Dark

Like a chessboard, the Web industry is full of light and dark, good and bad. We weigh benefits and pitfalls when performing our roles. A chess game tells a story; likewise, the fruits of our labor and our highlights and disappointments all appear online.

Think Ahead

One of chess’ biggest lessons is to think ahead, instead of in the moment. Being able to predict how your opponent will move helps you gain advantage. This is also true of the website-building process. Unjustified decision-making leads to problems, whereas well-planned strategies that entice people to visit and use your service lead to faster results and greater rewards.

Weigh Your Options

In chess, there are literally millions of ways a game can play out, and with every move the number of potential outcomes decreases. Knowing your options and which route affords the best opportunity for success is a critical skill. Website creators have many different methods of production and implementation as well, but missing the mark with scalability or usability can diminish a website’s user-friendliness and jeopardize its success.

Make Your Move

Decision-making can be tricky; in chess, a wrong move can cause you to lose a piece, a good position, an advantage or even the game. The same could be said of building a website. Preparing for different projects, services and eventualities is one thing, but having the courage, skill and understanding to carry them out successfully takes practice. After examining your options, make your move: put all your careful planning into action.

Checkmate!

So many useful lessons can be learned from chess. If you haven’t played it before, visualizing what we’ve gone over might be hard, but the fundamental principles of the game — how the pieces interact and the role of strategy in the big picture — should not be ignored. The game actively promotes logical thinking and strategy — both useful skills.

More lessons could certainly be drawn from the game, but hopefully this article will serve as a source of inspiration, especially if you feel your goals are out of reach. We often learn the most from making mistakes, losing a battle and then returning to win the war. Nowhere is this been truer than in chess, where a mixture of practice, skill and occasional luck is required to become the grandmaster.

So many aspects of the Web industry (such as syntax, design and ideals) change constantly, but the fundamental principles of learning, growing and trying your best often mean the difference between failure and success. Try to incorporate lessons from the chessboard into your own work; while having all the pieces doesn’t guarantee victory, having the basic skills will give you the confidence and awareness that you need to succeed.

(al)

© Alexander Dawson for Smashing Magazine, 2010. | Permalink | Post a comment | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags:

With the huge popularity of mobile touch devices and the current major drive to make everything web related compatible with these devices, today’s Design Reviver Answers discussion is certainly relevant with current development trends. The question that was asked was “Will Touchscreen devices make hover states a thing of the past?”

You can leave your thoughts and point-of-view below, or you can leave your answer on the original question on Answers here: Will Touchscreen devices make hover states a thing of the past?

Will Touchscreen devices make hover states a thing of the past?

This question was originally asked by Mpstud.

The best answer comes from Darrell Estabrook :

Thanks to everyone who asked a question, but most importantly thanks to everyone that took the time and effort to offer helpful and useful answers.

Everybody wants to use CSS 3 now that even Internet Explorer will support parts of it once IE 9 is out. But since parts of CSS 3 are still subject to change, most browsers use a vendor prefix for many CSS 3 properties to signal that their implemenation is “experimental� and may change in a later version of the browser.

This means that for a property like border-radius to work cross-browser you need to specify it several times with different vendor prefixes, like this:

1. .box {
2. -moz-border-radius:10px;
3. -webkit-border-radius:10px;
4. border-radius:10px;
5. }

Read full post

Posted in Browsers, CSS.

The new and revitalized CSS3 properties have not only opened up many, many marvelous development solutions for web designers, it has also allowed talented developers to push the boat out further and showcase there CSS skills by building and styling in ways that were never ever thought possible previously.

In today’s news round-up we take a look at some of these amazing experimental pure CSS3 creations…

Please note, you will need either the latest version of Safari or the Chrome browser to fully experience these CSS3 experiments.

iOS Icons Made in Pure CSS

iOS Icons Made in Pure CSS

iPhone CSS3

iPhone CSS3

Pure CSS Twitter Fail Whale

Pure CSS Twitter Fail Whale

Pure CSS Animated 3D Super Mario Icon

Pure CSS Animated 3D Super Mario Icon

By Paul Andrew (Speckyboyand speckyboy@twitter).

In celebrating the merits of free software and the excitement over this radical networked production method, an important truth is left unspoken. Networked collaboration shines in the low levels of network protocols, server software and memory allocation, but user interface has consistently been a point of failure. How come the networked collaboration that transformed code production and encyclopedia-writing fails to translate to graphic and interface design?

The following is an investigation into the difficulties of extending the open-source collaboration model from coding to its next logical step: interface design. While we’ll dive deep into the practical difference between these two professional fields, the article might also serve as a note of caution to think before rushing to declare the rise of “open-source architecture,” “open-source university,” “open-source democracy” and so on.

[By the way, did you know we have a free Email Newsletter? Subscribe now and get fresh short tips and tricks in your inbox!]

The Challenges

Scratching an Itch

By going open-source, coders are fulfilling a need to change software, to make it their own. They might have different motivations, but if you’re already modifying something for yourself, answering the “Why share?� question is really easy with “Why not?� By the time the code executes correctly, the immediate users of the software—that is, the coders themselves—are already familiar with the software and can operate it even without a delicately crafted user interface.

Therefore, the motivation to take an extra step and invest in a usable interface that would extend the user base beyond the original geek-pool is not obvious. The interface already works for me, so what itch am I scratching by working hard to make it usable for others who can’t help me code it?

For the designers themselves, what is their incentive to make the design process more collaborative? Will others make my design better? Will they be able to communicate my ideas better than I can?

Beyond that, open-source interface design suffers from a chicken-and-egg problem: most designers don’t use open-source tools, and so it doesn’t occur to them that they could make the software better. As a result, open-source software suffers from an inferior interface that makes designers shy away from it and stick to their proprietary tools. The cycle repeats…

Granularity

Both software and wikis are made of granular building blocks, namely characters. This makes every typo an invitation to collaborate. My first Wikipedia edit was a typo correction, my second was adding a reference link, my third was writing a whole paragraph, and that led me to more substantial contributions, like adding a whole new article and so on.

Each granular step gets you closer to the next granular step. This ladder of participation makes each successive step easier. It also allows you to compare changes easily, giving you transparency, accountability, moderation and an open license to try and possibly fail, knowing you can always revert to the previous version.

You don’t get that with design, because the changes are not granular and are not as easily traceable. The first step is steep, and a ladder is nowhere to be found.

Encoding/Decoding

In his 1980 article “Encoding/Decoding,� cultural theorist Stuart Hall defines communication in terms of code. To describe it briefly, let’s imagine a spoken conversation between Alice and Bob. Alice encodes her framework of knowledge into the communicable medium of speech. Assuming Bob can hear the sounds and understand the spoken language, he then decodes the sounds into a framework of knowledge.

Both encoding and decoding are creative processes. Ideas are transformed into messages that are then transformed into ideas again. The code that Alice uses for encoding is different than the one Bob uses for decoding. Alice could never telepathically upload ideas into Bob’s brain. (We can all agree that that is a good thing.)

Let’s entertain Hall’s ideas of encoding and decoding in software. Alice is an open-source hacker, and Bob is collaborating with her as a designer. Alice is writing software code; she knows when it executes and when it doesn’t because the program communicates that through error messages. When she is happy with the result, she uploads the code to an online repository.

Bob then downloads the code to his computer, and because it has executed on Alice’s computer, it also executes on his. When Alice and Bob collaborate through a programming language, they are literally using the same code for encoding and decoding.

Alice always chooses one of her three favorite programming languages. Being a designer, to communicate a message visually Bob starts by defining a visual language—graphics, color, layout, animation, interaction… If Alice or any other developer had to reinvent a new programming language on every single project we would not be speaking about FLOSS now.

Bob needs to define a graphic language, a standard for the collaboration. Doing that is already a major part, possibly the most important part of the creative work. Whoever works with Bob will need to accept and follow these standards, relinquish control and conform to Bob’s predefined graphic language. These artificial constraints are harder to learn and conform to than the constraints of a programming language. While constraints and standards in technology are the mother of creativity, in design they can often feel artificial and oppressive.

Beyond that, within a collaboration, when Bob tries to argue for the merits of his design, unlike in the case of Alice’s code he cannot prove that it executes flawlessly, or that it is faster or more resource efficient. The metrics are not as clear.

It is important to remember, in collaboration on code Alice and Bob have a third collaborator, one that cannot be reasoned with – the computer. This collaborator will simply not execute anything that doesn’t fit its way of work. On the other hand, as long as it is syntactically correct and satisfies the inflexible collaborator even “ugly codeâ€� executes and muddles through.  And so, the different voices expressed in code are flattened into a single coherent executed application.

For better or worse, we lack this inflexible collaborator in design. It doesn’t care about our communicative message and it doesn’t level the playing field for communicative collaboration. And so, the different voices in design simply spell inconsistent multiplicity that dilutes the communicative message.

One might turn to Wikipedia as a testament to successful non-code-based collaboration, but Wikipedia enforces very strict and rational guidelines. There is no room for poetry or subjectivity within its pages.

Is It Simply Impossible?

Not necessarily. If we step out of the technical construct of the open-source methodology, we can identify quite a few networked collaborations that are transforming and often improving on the design process.

Viewing free culture and the free sharing of media as evidence of collaboration is tempting, but the availability of work to be remixed and re-appropriated does not necessarily imply collaboration. Sharing is essential to collaboration but is not enough.

WordPress, the leading free blogging software, is an interesting example. Looking to redesign the WordPress administration interface, Automattic, the company leading the WordPress community, hired HappyCog, a prominent Web design firm. And in March 2008, WordPress 2.5 launched with a much improved interface. Through a traditional design process, HappyCog developed a strong direction for the admin interface. Eight months later, Automattic released another major revision to the design that relied on HappyCog’s initial foundation but that extended it far beyond.

One of the interesting methodologies that Automattic used to get the WordPress community involved in the design process was a call for icon designers to provide a new icon set for the interface. Within two weeks, the six leading icon sets were up for voting by the community.

But rather than just casting a blanket “Like� or “Dislike� vote, community members were invited to provide a detailed assessment of consistency, metaphor coherence and so on. Some icon designers in the running even acknowledged the superiority of other contributions and voted against their own sets. The icon set that was ultimately chosen, though, was a collaborative effort, because some of the icons changed based on inspiration from the other sets.

Another example is the evolution of grid systems for Web design. Half a century after the rise of Swiss-style graphic design, some design bloggers suggested that some of its principles might apply to Web design. Those suggestions evolved into best practices, and from there into Blueprint CSS, an actual style sheet framework. The framework became popular and inspired other frameworks, such as 960.gs.

Similar processes happen in interaction design. One example is the pop-up window evolving into the elegant lightbox or modal window modules, and then changing and being modified again and again in open-source code libraries.

Other design-oriented experiments in free software, such as the ShiftSpace platform, challenge the Web interface power structure. ShiftSpace allows users to interact with a website on their own terms by renegotiating the interface and proposing different interactions on top of the page. Projects like ShiftSpace aim to expand the limited participatory paradigm of the Web beyond user-generated content to include user-generated interfaces.

Make It Happen!

There are ways to make open-source design work without falling into the traps often characterized as “design by committee.� We are already seeing designers scratching their own itch and contributing creative work to the commons.

Lecturing designers (or users) and demanding that they use bad tools for ideological reasons is counter-productive. Designers often use free tools (or use proprietary tools in unauthorized ways) only because they are free as in free beer. So, to win over new users, free software should be pitched on the full range of its merits rather than on ethics alone. While the ethics of “free as in free speech� are convincing to those who can “speak� code, the openness of the source to those who lack the skill to modify the code is a weaker selling point.

Free software tools have won on their broad merits many times, and not only on low-level system and network fronts. Wikis and blogging software (which are interaction and communication tools) that have been invented by the free software community have maintained a lead over proprietary competitors. Networking and collaboration are the bread and butter of free software, and the community should leverage these advantages.

Just as Wikipedia extends the free-software collaboration model by leveraging the granularity of characters, so can design. When possible, using code for design collaboration is preferable. Beyond that, collaborators should adopt distributed version control systems for both code and image files. Rather than trying to compete with proprietary software by creating open clones, the Free Software community can leverage its experience as an advantage and focus on new collaborative paradigms for version control and collaboration.

Finally, There are ways for us to better analyze the encoding and decoding of the communicated message. We can formalize processes of collaborative encoding. We can start by conducting networked design research using existing research tools; in this way, we might come up with design decisions collaboratively. We can define modular and extensible languages that embody design decisions but still allow for flexibility and special cases (like Cascading Style Sheets). We should also learn how to document our design decisions so that they serve other collaborators. Designers have been doing this for many years in more traditional and hierarchical design contexts when they have compiled documents such as branding books or design guides.

For the decoding part, we should realize that many design patterns are rational or standardized and can leverage common ground without compromising the creative output. For example, underlined text on the Web almost always implies a hyperlink. We could choose to indicate a link otherwise, but if we try to use this underline styling, say, for emphasis, we can expect users will try to click on it.

User experience research, technical aspects of design, best practices in typography, icon use, interaction paradigm—these are all aspects of design that can be researched and assessed according to measurable parameters. Thorough research of these can provide a basis for consensus for shared expectations of how a message will be interpreted. A lot of this work is already taking place on design blogs, which have published a lot of research on the subject over the past few years.

Finally, the substantial parts of design that still cannot be easily quantified or assessed on shared rational ground should be managed through trust and leadership. A resilient community of practice must be able to develop design leadership whose work and guidance is respected and appreciated even without the convenient meter of coding meritocracy.

Scaling Subjectivity

It comes down to the deep paradox at the heart of design (whether for interface, architecture, product, etc.). We are trying to create a subjective experience that scales—a single personal scenario that can be multiplied repeatedly to fit a wide array of changing needs by a vast majority of users. The thing is, subjectivity cannot be scaled—that’s what makes it subjective—therefore, the attempts to create a one-size-fits-all solution are bound to fail, along with the attempts to customize the solution to each individual user in each individual use case.

Chris Messina gives a great example for this paradox by comparing Apple’s Magic Mouse to the OpenOffice mouse. While Apple’s solution is a slick, clean one-button device, the OOMouse has “18 programmable mouse buttons with double-click functionality; analog Xbox 360-style joystick with optional 4-, 8- and 16-key command modes; 63 on-mouse application profiles with hardware, software and autoswitching capability…� and more. While the Magic Mouse embodies Apple’s commitment to design leadership at the price of user choice, the OOMouse embodies the free software community’s preference for openness and customization over unified leadership.

Successful open-source projects have always benefited from a mix of the two approaches, a combination of openness and leadership. Finding a similarly nuanced approach in other fields is required if we ever hope to extend the open-source model beyond code. We cannot sprinkle the pixie dust of open source on everything and expect wonders. The same goes for design. Hopefully, though, we can make some progress by demystifying the process and by collaborating wisely when it makes sense and coming up with new ways when it doesn’t.

“Can Design By Committee Work?� by Collaborative Futures is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at www.booki.cc. This essay is also featured in the Collaborative Futures book, written collaboratively, published for free and released under the CC-BY-SA license.

(al)

© Mushon Zer-Aviv for Smashing Magazine, 2010. | Permalink | Post a comment | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: