A website is never done. Everyone has worked on a project that changed so much after it launched that they no longer wanted it in their portfolio. One way to help those who take over your projects is to produce a style guide.

Edward Tufte once said: "Great design is not democratic; it comes from great designers. If the standard is lousy, then develop another standard." Although there's no stopping some clients from making their website awful, by creating a style guide, you're effectively establishing rules for those who take over from you.

  

Smashing Editorial: Please notice that the language in some parts of this article may be very informal. If you think you might be offended, please stop reading this article now.

I hate the division represented in this title. It’s the major stumbling block in modern business. Power struggle is never constructive, and it at least doubles workforce effort at a time when streamlined is crucial for a positive ROI. You can spell “team” from the word “marketing,” but I’ve yet to see a sense of it in marketing. What can one spell from “creative”? “Reactive”? I’ve seen plenty of that, and for good reason.

Don’t get me wrong: I love marketing as a practice! Relatively speaking, marketing is a fairly new practice (marketing in the sense of "public", broad mass marketing, applied to products in the modern age — ed.), and one that has to evolve each day to keep up with consumerism and technology. As a designer, coming up with marketing ideas is orgasmic. Guerilla, sabotage and viral marketing are the work of genius, which is why we don’t see them very often. But you are probably thinking horrid thoughts about marketing practitioners right now, so let’s rethink for a second.

Variable naming can be a source of coding angst for humans trying to understand code. Once you’re sure that a human doesn’t need to interpret your JavaScript code, variables simply become generic placeholders for values. Nicholas C. Zakas shows us how to further minify JavaScript by replacing local variable names with the YUI Compressor.

Want to make fancy, interactive, scalable vector graphics (SVGs) that look beautiful at any resolution and degrade with grace? Brian Suda urges you to consider Raphaël for your SVG heavy lifting.

  

Today we are glad to release CMS Icon Set, a set with 12 high quality icons in 48×48px, available in the .png-format. The set was designed to be used in content management systems, but can also be useful for other user interface designs. This goodie was designed by the Russian design studio Pixel-Mixer and released especially for Smashing Magazine and its readers.

Download the icon set for free! You can use the set for all of your projects for free and without any restrictions. You can freely use it for both your private and commercial projects, including software, online services, templates and themes. The set may not be resold, sublicensed or rented. Please link to this article if you want to spread the word.

I was recently reviewing over 500 code check-ins for The Archivist and in the course of my review, a narrative emerged. I could see the evolution of the project: sprint milestones, new features, etc.

Perhaps more interesting (and entertaining) than the narrative was the humor in some of the comments. Now, the vast majority of the comments were informative—and appropriate. But in the heat of the moment, well, some of the comments got more colorful.

Here’s a list of the ten more amusing comments:

1. “more futzing”

2. “don’t f*ck with my connection strings”

3. “fixed wonky export code”

4. “build for legal”

5. “fixed goofy routing logic in mvc controller”

6. “deploy for sprint” then “redeploy for sprint” then “another try” then “ok really the sprint build”

7. “fixed serialization, deserialization crap”

8. “who said dll hell ended with .net?”

9. “remmed out back door”

10. “fixed dirty logic”

Am I totally out of line? If you were my dev lead, would you come flog me? Care to share some of your more amusing check-in comments?

  

CSS3 continues to both excite and frustrate web designers and developers. We are excited about the possibilities that CSS3 brings, and the problems it will solve, but also frustrated by the lack of support in Internet Explorer 8. This article will demonstrate a technique that uses part of CSS3 that is also unsupported by Internet Explorer 8. However, it doesn't matter as one of the most useful places for this module is somewhere that does have a lot of support - small devices such as the iPhone, and Android devices.

In this article I'll explain how, with a few CSS rules, you can create an iPhone version of your site using CSS3, that will work now. We'll have a look at a very simple example and I'll also discuss the process of adding a small screen device stylesheet to my own site to show how easily we can add stylesheets for mobile devices to existing websites.

  

In previous video roundups, we've collected together some interesting videos and presentations from a variety of speakers discussing topics covering usability, graphic design, CSS frameworks, web standards, and more. In this small roundup, we've included seven videos that we think would be of great interest to web app developers in particular, with less focus on design and standards.

These presentations are a little more technically heavy than ones we've featured in the past, but we think they're worth every minute. Check them out, and be sure to comment to include links to any related videos that you feel are worth mentioning.

  

In the Web design scene, the sense of community is extremely strong. We always talk about "giving back" and about how much we learn from those who do. A few names are popular and dropped here and there. But it's all still just a bit too impersonal, isn't it? Here at Smashing Magazine, we've decided to give you a more intimate look at our writers.

Among the people who regularly write for us, 15 agreed to answer our questions. We also challenged them to take a picture of themselves on the spot, with no time for make-up. This interview is not meant to give you any particular professional insight, even though we cover that ground a bit. Rather, it's meant to introduce you to these people on a personal level. The illustrations for this article were created by Andrea Austoni, an illustrator from Poland who we are regularly working with.

  

The word chocolate can be associated with many words: dark, white, milk, hot, sweet, spicy, etc. But have you tried to combine it with the word web design? We did. We searched the Web for websites in any way related to chocolate and what we found is worth to be collected in this showcase. The interesting thing is that you would probably never stumble upon some of the sites, so the overview below may provide you with a unique perspective and get your creative juices flowing.

As one would expect, chocolate website often use an appetizing brown dominant color. If you take time to look at the panel of colors associated with it, you will find out that there is a lot of combination working really well. Apart from this component, each site is unique and features an original identity, depending on product presentation and given information.

  

You may be wondering why you're reading about the good old semantics on Smashing Magazine. Why doesn't this article deal with HTML5 or another fancy new language: anything but plain, clear, tired old semantics. You may even find the subject boring, being a devoted front-end developer. You don't need a lecture on semantics. You've done a good job keeping up with the Web these last 10 years, and you know pretty much all there is to know.

People looking for bananas might think twice before buying these.

I'm writing about HTML semantics because I've noticed that semantic values are often handled sloppily and are sometimes neglected, even today. A huge void remains in semantic consistency and clarity, begging to be filled. We need better and more consistent naming conventions and smarter ways to construct HTML templates, to give us more consistent, clearer and readable HTML code. If that doesn't sound like paradise, I don't know what does.

  

Today we are glad to release gCons, a set of free all-purpose 32×32px icons for designers and web developers (100 icons). The icons come in 12 different colors and are available in PSD, PNG, JPG and GIF formats. This set was designed by Sarfraz Shoukat especially for Smashing Magazine and its readers.

You can use the set for all of your projects for free and without any restrictions. You can freely use it for both your private and commercial projects, including software, online services, templates and themes. The set may not be resold, sublicensed, rented, transferred or otherwise made available for use, Please link to this article if you would like to spread the word.

  

One thing that can be said about human beings is that we are, by and large, creatures of habit. We establish routines, consciously and subconsciously, that help us accomplish tasks or move us more quickly or comfortably through our day. Habits are formed in the design and development community just as they are in nearly every other professional and personal environment, and they serve any number of purposes. In design and development circles, one established habit is seen with the launch of a website or project.

Naturally, each of us has developed a process that we engage in as we wrap up a project, but a few procedures tend to be used over and over again by the masses. We know this because we ran a poll on this very topic on Twitter. We got many great responses, but the community tends towards a few common practices. We could see as we looked through the list of entries that certain wrap procedures seem to have mass appeal (judging by the number of times they were given as answers), so we began to examine the benefits they offered and what they say about those who fall back on them.

In an earlier post I talked about working on The Archivist Desktop version, and how the software began its evolution to the web and the cloud. In this post, part II of a series, I'll take a step back and explain how we concepted and executed The Archivist Web (alpha)and talk about what came before the design and code.

Audience Research

Once we decided to take on the project, we turned to our established group of experts for guidance. We already had a prototype of a similar application in The Archivist Desktop, so we had a cadre of fellow-Microsoft employees, friends and colleagues in other companies, and current users we could tap for solid user-testing. We focused on two primary groups of users: our internal Microsoft team and users of The Archivist Desktop.

Getting Stakeholders and Internal Microsoft Team Members On Board

We started by discussing the project's intricacies and goals with our internal team members and stakeholders. We set up short individual meetings with people, gathered feedback on how they used The Archivist Desktop and asked what new features they wanted to see.

“Conversation” with current users

Again, because we had already released The Archivist Desktop, we had an already-established user-base. Over the years there had been a few “vocal” users – who either wrote in to thank us, or report problems and failures – who we felt could provide valuable feedback from real-world use-cases. At the beginning stages of building The Archivist Web we simply emailed a few of the users with whom we had been in contact and asked them a simple set of questions surrounding specific topics such as types of visualizations they would use, how often the tool needed to update, the way they were using the data and the like. By asking specific questions rather than asking for general feedback, users were able to focus on key issues and needs that we could act upon. Often, by asking a generalized question such as “What would you like to change,” you get very generalized answers that are hard to turn into actionable tasks.

We also communicated our plans openly, which helped us make contacts in other parts of the company and take advantage of Microsoft's existing technologies and knowledge-base. Discussing our plans with the Windows Azure team, for example, helped us overcome some serious hurdles with our data-storage methodology. Without their help, we might have been derailed at the beginning.

What Current Users Want

At the beginning stages of the project, we simply emailed a few of our most vocal users and asked them questions about what types of visualizations they might use, how often the tool needed to update, how they were using data, etc. Asking specific questions instead of relying on general feedback helped us identify key issues and needs we could easily act on.

User personas

From our sit-downs and email conversations, we were able to segment our audience into 'personas', defined as representations of real users, including their habits, goals and motivation.

There are many ways to approach user personas. Some designers spend a long time fleshing out the behaviors and market segmentations of a target audience. We, on the other hand, took a more rudimentary approach, following the example of Smashing Magazine great article on the same subject.

Drive-by vs. Return Users

We know that most users will come by the site once, do a quick search, check out some visualizations, and then leave. That’s just the nature of building websites, and especially one geared toward a niche audience.

We wanted to provide an engaging experience with few barriers to entry for the drive-by user, but it was more important to concentrate on bringing people back. So, we decided to focus on our return users, Marketing Managers and academics.

The Marketing Manager

Marketing Managers primarily care about tracking sentiment—who is tweeting about what, how often, and how people feel about a brand or site over time. But up until recently, there were only a few ways to gain access to targeted Twitter data, most of which was presented in a very raw format that was difficult to extrapolate from.

Our plan was to change all this with The Archivist, and make it easy to find, share and interpret large swaths of data suited to the Marketing Manager's needs.

The Academic

Because of our experience with The Archivist Desktop, we knew that there was a surprisingly large demand for the Archivist in academia. During the last year or so, we’ve talked with with numerous professors and students who have found The Archivist Desktop useful for their research.

Whereas the Marketing Manager wants to track 'sentiment', the academic is interested in raw data that's accurate, easy to access and appropriate for use in research.

Wireframes

I thought it might be useful to provide the full PowerPoint walk-through of our wireframe set, which gave our team an understanding of how different users might come to and interact the site.

What we couldn't do (Feature Scoping)

Coming to agreement on the wireframes was easy, but brought up questions about what data we could actually display to users. As I noted earlier, I spent a lot of time thinking about the frequent requests for filtering by date, secondary keywords and other items. Because of how Twitter works, some of this data wasn't consistently available. Other items were so gnarly we couldn't scope them into this release.

The Visualizations Visualization explorations

As Karsten and I were wrapping up the early Archivist Desktop version, I explored additional visualizations I thought we might be able to incorporate into the downloadable WPF application. Since we were working in WPF at that point, I felt free to explore visualizations that might be useful to our audience. Some that I came up with:

For a few specific reasons, we decided to ship The Archivist using the ASP.NET charting contols, and made the decision to feature the following charts.

• Tweets over time
• Top Users
• Top Words
• Top URLs
• Tweet vs. Retweet
• Top Sources (software)
• Use ASP.Net Charting Controls

In my next post, I'll talk about taking the site from wireframes and explorations to a functional HTML + CSS3 + jQuery site, and how I worked with Karsten, who made the beauty of the backend happen in the cloud.

Do you use the same process as us, moving from problem to persona to wireframes to design? Leave a comment and be sure to follow us on Twitter @Mixonline.

  

  

Sometimes, a picture can be powerful enough to be inspirational material all by itself. To provide you with some inspiration for the upcoming week, this sunday we feature some truly beautiful and impressive images from talented artists and photographers worldwide.

Whether in black and white or in colors, they are all related by a strong sense of composition and an emphasis on lightening and colors work. All images are linked to their sources, which you are encouraged to visit. Other work of the photographers we have featured here is certainly worth discovering as well. Please notice that some images are available as prints as well.

  

Web professionals have to be both flexible and creative to meet the needs of each client — and these characteristics often transcend the design and development process. Each of us has a unique approach to our work. The particular mindset and methods by which each of us turns a mental image into a delightful and usable website is worthy of investigation.

In this article, we'll discuss three approaches taken by many Web designers and developers. While a creative individual usually falls into more than one of the three categories, each of us is still likely more heavily weighted towards one. These approaches might help determine what paths someone is best suited for and might shed light on how they achieve their goals. So, without further ado, we introduce you to the artist, the scientist and the philosopher.

I recently learned something extremely fascinating from a book called Gut Feelings: The Intelligence of the Unconscious. In Greg Gigerenzer's own words:

Intuitions based on only one good reason tend to be accurate when one has to predict the future, when the future is difficult to foresee, and when one has only limited information. They are also more effective in using time and information.

What Gigerenzer means is that people generally rely on one good reason to make decisions when the outcome is truly unknowable. And, that's OK! It's worked wonders for us for thousands of years.

But the more interesting insight hidden in there for us designers is that our best bet at predicting the future for something truly unknowable—say, how an audience will react to a new product, or what'll happen to the price of a certain stock—is often to follow your gut.

Mo Options Mo Problems

Now, this may seem preposterous to our spreadsheet generation, because it runs counter to the currently dominant microeconomic paradigm called Rational Choice Theory. According to it, human beings are rational—Homo Econonomicus—and given a set of alternatives, will weigh the costs and benefits of each to pick the most suitable one. Increase the alternatives, and you increase the chances of finding a more suitable pick, right?

The credo "more options are better" has become a staple in our generation. From supermarkets that carry hundreds of different types of cereals to our propensity to follow thousands of people on Twitter, we've given in to the notion that more choices lead to better outcomes. Sadly—and you know this in your gut—the exact opposite is true in most cases. More options lead to confusion. Not conversion, as many marketers would have you believe.

Gigerenzer's own take on that:

Complex analysis, by contrast, pays when one has to explain the past, when the future is highly predictable, or when there are large amounts of information.

Gigerenzer cites numerous studies in his book supporting this critical point, but there's a classic one we're all too familiar with—Apple.

An Apple a Day

When Jobs took over Apple in 1997, Apple sold over 40 different types of products, from printers to handhelds. Particularly overwhelming was Apple's lineup of computers, which hovered around 50 different models. Which Performa is right for you? The 5200CD or the 5215CD? Jobs later confessed that even he couldn't figure out the answer to that question. So how could customers?

Among the other unpopular restructuring decisions, Apple cut most of its product lines and reduced its computer line to four machines: novice and professional versions of a desktop and a laptop. History will remember it as a key step in facilitating Apple's comeback.

But, why is it that too many options paralyze us while fewer options spring us into action? Entire books have been written on the topic, but if you want a succinct explanation, you need look no further than Miller's Law.

Miller's Law: The Magic Number Seven

Princeton's celebrity cognitive psychologist, George Miller, published the seminal paper on the topic of human cognition in the Psychological Review in 1956. In it, he argued that the average human could hold 7±2 objects in working memory; this is now fondly known as Miller's Law. Miller's insight has had an immeasurable impact on the design of everyday things in the last 50 years.

The classic application of Miller's Law in the software industry is when a designer tries to convince stakeholders that the navigation menu of a web site needs to be limited to seven (give or take two) choices. But more generally, we can credit our subconscious pull towards "keeping things simple" to Miller; at least within the context of user experiences. That is no small feat.

Now if only someone can do the same for the benefits of white space.

KISS my Point

Your users are already overwhelmed. Jonathan Anderson of UXMag illustrated this in a very eye-opening post—These are your users... read and be horrified. But as Gigerenzer writes, even when they're not overwhelmed, they make their choices based on one or two criteria. Providing your users with more options is generally counter-productive. Of course, there are exceptions to this rule of thumb.

The bottom-line? Prune. Cut. Shorten. Simplify.

And once you're done?

Simplify some more.

  

You’ve met with the client, done the creative brief and gotten some kind of written agreement or contract. Work has been creative and progressing nicely. The joy and hope for life slowly return as the scent of money looms. So, with an overdose of sleeping pills no longer your retirement plan, you start to delete your suicide note and dispose of the envelopes containing instructions on terminating your accounts on Twitter, Facebook and LinkedIn.

Then, someone crunches some numbers and realizes that you can’t be paid what was agreed on. Suddenly, your contract becomes either a weapon in a brutal fight or a token to keep the job going in the hope of some pay and a return client.

Many people start an assignment only after a percentage of the job has been paid. 50% is nice, but convincing the big clients that they are not your bank is becoming harder and harder, and the promise of payment in 30 days does not give you a warm feeling inside.

You may be wondering how frequently The Archivist updates archives. Well, the answer to the question is more complicated that it may first appear. Let’s dig in.

The Archivist interacts with Twitter using the Twitter Search API, which it polls at variable intervals based on the frequency with which a particular archive is updated. We call this the elastic degrading polling function. This algorithm helps The Archivist be a good Twitter citizen, allowing us to poll Twitter conservatively while at the same time maintaining archives with the latest tweets.

Here’s how the algorithm works: When a user makes an archive ‘active’, the polling process begins. Every archive is inspected once an hour to determine how ‘hot’ it is. We determine how hot an archive is by recording how many results we get back each time we poll Twitter (the maximum we can pull at any one time is 1500).  We use this number to determine how frequently to poll Twitter for that archive. Depending on the number, we either hold off on polling for a given interval or query again, based on the following buckets:

So, let’s look at an example. Say we have an archive going for the term ‘Wittgenstein’. When the Archivist checks on this archive at 10 AM, it discovers that the last query for Wittgenstein only returned 10 tweets. It also discovers that this archive was last updated at 9 AM. The Archivist won’t poll Twitter for this archive, because the tweet count isn’t high enough and the archive had been queried within 24 hours. Since the archive is in the 24 hour bucket, the same thing will happen when The Archivist checks on this archive each hour.

Once 9 AM rolls around on the next day, since 24 hours have passed, Twitter will be polled for the Wittgenstein archive .

Now, let’s say for some reason there’s a flurry of tweets about Wittgenstein—when that archive was updated at 9am, it pulled 600 tweets. In this case, the archive adjusts because it has become hot. It is now in the 1 hour bucket instead of the 24 hour bucket.  So, when 10 AM rolls around, the Wittgenstein archive gets updated again. 

But let’s say at 10 AM it pulls only 250 tweets. Well, now the archive moves to the 8 hour bucket. So,the Wittengenstein archive will not be polled again again until 6 PM. Let’s say it pulls 1000 tweets. Well, it goes back to the 1 hour bucket, since it appears to be hot. At 7 PM the term is checked again.  This time, the response is only 10 tweets. It seems to have cooled off quickly, so we’ll move it back to the 24 hour bucket.  

Some of you may notice that there’s a chance that The Archivist could possibly miss tweets when a term becomes hot. This is a reality of our architecture and is justified by the following: First, once a term gets hot, the amount of data can grow quickly. Ultimately, in that scenario,The Archivist becomes a statistical sample as opposed to a true historical record.  Second, Twitter itself doesn’t guarantee that all tweets will be returned for a given search. See http://help.twitter.com/entries/66018-my-tweets-or-hashtags-are-missing-from-search and http://dev.twitter.com/doc/get/search for more on this. Consequently there is no way that The Archivist can ever claim to be a true historical record. Third, The Archivist is optimized for following non-trending topics over a long period of time, as opposed to trending topics over a short time.  For a tool optimized for the latter scenario, see Archivist Desktop. Another option would be to run your own instance of The Archivist Web and tweak the polling algorithm, which would be trivial to do. Contact me if you are interested in doing so.