Emptees

Emptees is supposedly a place for the world’s best t-shirt designers to showcase, browse, and talk about tee shirt designs. This site may be too simple for some of you graphics-hungry Photoshop lovers, but I’m personally in love with the use of photography, whitespace, the logo design, and of course the shirts. Design by Indie Labs. Via The big noob.

Original post by Styleboost links

PSDTuts

PSDtuts is a site filled with Photoshop tutorials that teach us about creating great graphics and effects in a friendly, approachable manner. I love the color scheme and shiny details. If this site was a dish, I would eat it.

Original post by Styleboost links

Pixelmator

Image editing for the rest of us. Well not for me, as I’m not a Mac-user. This site is close to perfection on a couple of levels. First of all, it shows us the right way to sell a product; in a clean and delicate wrapping (i.e. site). Beautiful icons and subtle, dark colors combined with striking imagery and a few strong colors. It also takes the style of Mac-related sites (I think you know what I mean by this) to their own place with delicious darkness. The way they present this software makes me really want to try it out, and I think it has a lot to do with the graphics, not the features of the program.

Original post by Styleboost links

Shylands

Steven Hylands of Northern Ireland has developed and designed a crisp and colorful portfolio site with a clear "CSS-feel" to it, if you understand what I’m saying. It looks and works great for its purpose.

Original post by Styleboost links

RBG6

Stockholm-based RBG6 makes some of the most beautiful retro-style video and graphic design work I’ve seen in a while. The work on display truly stands out in a crowd, and the presentation is quite spiffy, too. Via Computerlove™.

Original post by Styleboost links

Lars Bech

Danish Lars Bech’s portfolio is a Flash-folio filled with photographic candy. The prev/next navigation is a bit plain and low on usability for a site like this, but the rest of the presentation is a joy to behold. I love how large type is used.

Original post by Styleboost links

New pyjamas

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

La-la-la-la-la-la!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

La-la-la-la-la-la!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

La-la-la-la-la-la!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

La-la-la-la-la-la!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Nese. Nese. Nese.

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Nese. Nese. Nese.

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Nese. Nese. Nese.

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Nese. Nese. Nese.

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

“Reading”

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

“Reading”

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

“Reading”

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Solveig wants to swim with the ducks

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

High five!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

High five!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

High five!

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Ready to rumble

Johan Bakken posted a photo:

Original post by nobody@flickr.com (Johan Bakken)

Getting a startup right the second time

The idea for ImThere was born in July ‘05 out of necessity—it was a chore finding fun stuff to do around town. Fifteen months and many pots of tea later, we launched a service that we had hardly even tried to use. Soon after, we began questioning if it was what we even wanted.

Last June we finally launched the ImThere we had envisioned over two years ago. We are now finally able to find stuff to do that we wouldn’t have known about otherwise.

And So it Began…

Development of ImThere seemed clear-cut. The functionality was outlined and broken up into the site’s distinct pages. We let our designer and two developers figure out how best to design and architect the site. Once we prioritized the functionality to be developed and the pages to be designed, we created a weekly schedule providing a roadmap to launch. We appeared to be off to a smooth start.

What Our Team Began With

Our first glimpse of ImThere came three weeks later, when our designer uploaded his first pass at the main page. It looked great. That, combined with our excitement seeing ImThere for the first time, resulted in joyous expletives. Once we calmed down and compiled actual feedback, we had a list of items like:

• “The green arrow submit buttons are too bright and distract a little”
• “Let’s change Weekly to Daily on the featured venue/artist”
• “It looks like the View More links for Important Events and Hot Events have different font weights”

Valid feedback, but completely focused on aesthetics and nitpick-y details.

Revisions of the Main Page

As the design progressed, the developers were hard at work on the back-end. From content targeting to popularity algorithms to exotic data handling, we had very lofty goals—all to be included in version 1.0. Even seemingly simple things turned into intricate projects requiring custom code, rather than using what Ruby on Rails, the ImThere platform of choice, provided.

With three months of the back-end work complete, designs began to be applied to the website. Despite the immense back-end functionality, the front-end appeared extremely basic. The event, venue, artist, and user pages were pulling data from the database, and data could be entered through crude forms. But it was a start, and we were thrilled to finally have the developers working on something we could see. However, given the back-end functionality still needed for the launch, the front-end work moved sluggishly.

Logged In Users Saw a Different Main Page

Another three months later, even though the website was shaping up, our position was similar. Entering data was a chore, and there were too few ways to interact with the website. Even so, we felt the time had come to release something. We rushed to flesh out the remaining pages and smooth things out as well as we could. As time ran short, we began cutting the visual elements that were not yet coded. Finally, after a 30-hour marathon coding session, we launched.

Kicking it Out the Door

When a launch finally arrives, an indefinable feeling runs through everyone involved. It’s a mix of excitement, relief, and anxiety over what happens next. In our case, the anxiety turned to eerie silence as we saw people leaving the website soon after arriving. Truthfully, we couldn’t blame them. Since many of the planned interactive features were scrapped to get ImThere out the door, there wasn’t actually much to do. And since we couldn’t add content until right before the launch, there wasn’t much to see either. Our team even struggled to use it and found little value or enjoyment.

Warning Users About What They Were Getting Into

Over the next two months we slaved over the code to add missing features, develop new ideas, and fix up the remaining bugs. The website became unquestionably better, but people still weren’t latching on. Not only that, we were even still forcing ourselves to use it. It was a bad situation; no one was falling in love with it no matter what we tried.

There comes a time when you have to accept things just aren’t working, and you need to take a step back to figure out what’s really wrong. After just a few months, we had reached that point.

Taking a Step Back

At first, we were confused as to what the problem was. We had successfully implemented the functionality we had originally defined, and the few remaining missing elements couldn’t explain the state we were in. The website looked great, so that couldn’t be the problem either. After dragging ourselves away from development for the first time in nearly nine months, it dawned on us what had happened—we had taken a feature list and developed it into a website.

What we built had very little flow to it and felt forced. Each page seemed so disparate from the others that users couldn’t get the big picture, let alone find reasons to use it. It felt like a bunch of random features bundled into the form of a social event-themed service. The problem became even more apparent when we struggled to recall what the original vision was. The feature list not only dictated the design and development, but also became our guide to describing ImThere to others. We were in trouble.

The good news was that it was easy to see everything we had done wrong:

• ImThere was built and designed around a feature list
• Aesthetics were the focus of the design, with little thought put into actual usability
• Coding the high-concept back-end consumed nearly all of developer time
• We tried to do too much for a version 1.0 website, and didn’t have the focus to pull it off
• We never really tried using the website before launch, due in part to its incompleteness

Taking those missteps resulted in a myriad of problems:

• ImThere felt one-dimensional and lacked continuity, preventing it from being useful or fun
• The purpose of ImThere was unclear to users
• Users would have to adapt to using the website since few things were intuitive
• Much of the advanced back-end was left unexposed in the front-end

Our brand new website was fatally flawed. It just felt wrong and no amount of Band-Aids could fix it. Furthermore, in the meantime, a number of other social event services launched. When ImThere was originally envisioned, none existed. Now, in addition to problems with the website, much of our originality was lost. Our next move was obvious.

We had to scrap it.

That was remarkably hard to do after putting so much effort into something that had barely seen the light of day. We knew we would have to reinvent and completely rebuild ImThere, while being cautious not to repeat the same mistakes. Of course all websites iterate and iterate, but we had to do it in an extreme way. And do it we did.

Getting it Right

Before telling the team to scrap everything they had coded and designed, we first wanted a plan that was solid, realistic, and fully thought out. We began by focusing on the useful and fun qualities, which fortunately came together quickly. Our efforts also focused on overcoming the limitations of launching city-by-city, which our initial plan called for. A solution did come to us, and ended up being the cornerstone for the new ImThere. We would support “locationless” events in addition to local ones, which could include things like movie premieres, the release of the iPhone, Talk Like a Pirate Day, and even virtual events. These events could be relevant to anyone, allowing a ‘net-wide launch and providing ImThere an identity distinct from our new competitors.

Feeling confident about our refined and solidified vision, we set out to really plan it. This time we were determined to avoid the same traps. We locked ourselves in 24-hour coffee shops for a couple of weeks and extensively planned out every page. We would keep sketching out each page until we had it just right, and flesh out wireframes in the fantastic OmniGraffle application.

The First ImThere Wireframe

A big theme for the new website was reusability. Many elements like feeds, content streams, listings, and timelines were shared on pages throughout the website. Our event, venue, artist, and user pages shared the same base which was then tweaked for their individual needs. Other pages worked similarly; determine the necessary elements, and then tweak the page for its specific purpose. This process allowed the developers to perfect common elements and rapidly build out pages. It also allowed us to reduce the number of interfaces a user had to become familiar with.

Throughout development, we anticipated the various ways a user might use ImThere. For each page and feature, we thought about how a user would discover it, use it, and continue on through the website. When we were done, ImThere felt fluid, open, purposeful, and fun! We went from thinking “we want to use a service like ImThere” to “we want to use ImThere.” It provided reassurance that we were doing things right this time.

The differences were obvious; this time we had:

• Developed a complete idea, not just a list of features
• Wireframed every page of the website, forcing us to work through the flow and usability
• Took development time into consideration and found ways to avoid spending months on just the back-end
• Took a step back before development started to make sure this we had what we really wanted

We had to build the first version of ImThere to know to do these things. The lessons we learned were worth every second spent and the new ImThere could not exist without them. Looking back can be tough, but you later realize you had to take the steps you did. Fortunately, we realized our mistakes quickly enough to have the time to take our next step.

Take Two

Next came getting the team onboard with the new vision and getting their feedback. Their opinions were extremely valuable, especially since it was completely fresh to them. Everyone on the team was on the same page and embraced the opportunity to have a second shot at making ImThere the service we all wanted.

Both design and development went dramatically smoother the second time around. It was more clear what needed to be built which sped everything up and made for more realistic scheduling. Wireframes allowed for more design time to be spent on usability and less time on what needed to go where. Once the look and feel of the website was nailed down, the remaining pages went through relatively few revisions compared to pages for the first website. We were able to do this not only due to the wireframes, but also to sharing elements across pages. Towards the end of development, we even had the luxury of tweaking the design, which we had no time for even after launching the first ImThere.

Revisions of the New Main Page

Visual results began shortly after coding. We were able to carry over some back-end code, reducing the time it took to start on the front-end. This allowed us to start using the website very early on, which had been one of the biggest problems before. For the first time we could find out what worked and revise what didn’t. On the first version of ImThere we weren’t even able to add events until the last week of development, but now we could begin adding, modifying, and interacting with content months before launching the new ImThere. Around this time a bug tracking service called Lighthouse was released, which made reporting bugs enjoyable and manageable. It allowed us to report, prioritize, and track every little thing that wasn’t quite right.

From 0 to 3 Weeks

We ended up launching this past June, which was later than we had hoped. However, it was to allow us to add little features we wanted and polish the website, not to develop rudimentary functionality. About a month prior to launch, we let a variety of people in for a private beta. This was something we hadn’t even dreamt of doing with the first version. During the final month, we fixed all known bugs, finished the last of the features planned for launch, and tweaked and tweaked everything.

Once Lighthouse reported 0 remaining pre-launch tickets, we launched the new ImThere—the ImThere we all wanted.

Easing it Out the Door

After pushing the elusive launch button and drinking the obligatory champagne, we found ourselves on our laptops, sitting around a table at one of our developer’s houses. We weren’t frantically fixing bugs to keep the website from crashing, nor were we trying to code last-minute features. We were simply using ImThere and enjoying it.

As the first batch of users rolled in, we interacted with them and watched how they were using the website. They filled out their profiles, commented on events, sent messages, just explored around. No one left right away. From a statistical standpoint, our pageview to unique ratio was very favorable. That is a good sign, because even without stellar uniques, having people stick around means you are doing something right. All in all, our launch went as well as we could have hoped, and it seemed that we were finally on track.

Getting the User Page Right (old -> wireframe -> new)

We quickly got off our post-launch high and went back to work. For the first time, we had a solid base to build upon and could begin making forward progress. Our work over the next few months consisted of:

• Gauging initial user response and improving the areas that needed it
• Building the features we had put off until after launch
• Evolving our existing features to make them more useful
• Getting the word out to start building up our userbase

As we worked we would frequently take a step back to ensure we were on track and sticking to our vision. After our first time around, it was very important to make sure we didn’t waste a second working on the wrong thing. We were now focusing our work on strengthening the identity of ImThere, something we had failed to accomplish before. Since ImThere was designed in an open way to support a broad scope of content, it was challenging to make the value of the service immediately apparent to users. That concern drove our early focus on building utility-based features, like an invitation system, so prospective users could quickly find value. The hope is that once they sign up and begin using ImThere, they will see the big picture.

With a few post-launch months under our belt, ImThere was ready for the masses, and our next set of big ideas.

Where We Are Now

Over two years later we finally have the fundamentals in place and can enjoy making ImThere great. We are now faced with a new set of obstacles: reaching more users and demonstrating the value of the service to them. We also must keep looking into the future for ideas to maintain ImThere’s uniqueness and rapidly develop those ideas into realities. No matter how satisfied we are, standing still can never be an option.

Redesigned Signup System Based on User Feedback

The team is already working hard to evolve the very essence of ImThere. At the center of this evolution is the one key idea still missing from the original vision. Implementing this idea couldn’t have happened or even re-entered our minds without building the open, community-driven service we have now. With those fundamentals in place, the idea that began our journey returned, and proved to be a solution for our current obstacles.

ImThere Today

This further demonstrates that if something isn’t working, you need to look back and figure out what got you excited in the first place. That is how we put ImThere back on track and why we have full confidence that it will soon be a success.

Original post by contact@thinkvitamin.com (Carson Systems Ltd)

Meatballs II

Johan Bakken posted a photo:

I gave Solveig a few meatballs to eat, and she decided to lie down and chew. Very strange, indeed.

Original post by nobody@flickr.com (Johan Bakken)

Meatballs I

Johan Bakken posted a photo:

I gave Solveig a few meatballs to eat, and she decided to lie down and chew. Very strange, indeed.

Original post by nobody@flickr.com (Johan Bakken)

(suit)men

Suitmen entertainment is a Japan/US based creative agency. Their site is here for three reasons. First of all, it’s a beauty. Second, it’s making sweet, sweet use of Google Analytics for generating this beauty. Third, and last, there’s some great work in their portfolio.

Original post by Styleboost links

[Articoli e interviste] Intervista a Glenn Moust

Intervista a Glenn Moust
Glenn Moust, Danimarca, è sicuramente già noto ai più attenti lettori di Brain Twisting. Nelle sue immagini mescola tutto ciò che trova intorno a sé, utilizzando tecniche come il collage e la pittura. Grazie alla rete ha avuto molta visibilità e, di conseguenza, la possibilità di collaborare con altri artisti. Le sue immagini rispecchiano bene la sua passione per il vintage, che si fonde sapientemente con una forte componente stilistica proveniente dalla strada.
(Di: Daniele Cascone)

Original post by Brain Twisting

[Articoli e interviste] Black Music Art: reportage

Black Music Art: reportage
Spesso mi chiedo se tutto non sia fatto da forma e sostanza, se ogni elemento di questo mondo non sia la fusione di due aspetti che solo all’apparenza sembrano così distaccati. Con quest’ottica mi incammino verso Le Ciminiere, centro espositivo catanese.
(Di: Giuseppe Occhipinti)

Original post by Brain Twisting

Read more … about progressive disclosure

Progressive disclosure is a method of revealing the details of a feature on an on-demand basis, so that the basic elements of the feature appear by default while the less used or more advanced elements are hidden. These elements are usually just a click or two away, so they remain readily available, but they’re hidden by default to avoid interface clutter for the majority of users who do not need them.

This method is extremely effective for surfacing the right features in an application and hiding the wrong ones. Simply put, progressive disclosure is one of the most effective ways to clean up your application and improve user experiences without sacrificing functionality.

In other words, it’s the solution to one of the software’ industry’s biggest problems. The continuous addition of new features to applications invariably results in a more complicated interface, which in turn makes the user experience less desirable. Progressive disclosure gives us a way to keep building new features without complicating the interface.

In this article, we’ll explore progressive disclosure by looking at long-established conventions from the world of newspaper design, and then look at how to apply the principle to the web.

The Fine Art of Newspaper Design

Newspapers, as you know, have been around for hundreds of years. In this time, newspaper publishers have learned to do quite a few things that seem to make, well, perfect sense. Newspaper designs are obvious, but only because the people who put them together made them obvious.

The actual design of a newspaper varies wildly from one to the next, but newspapers far and wide adhere to a basic conventions.

First, they offer clear, concise headlines that enable readers to quickly scan a page to find whatever is most interesting.

Headlines serve as the first step in accessing more information. Once you choose a headline that looks interesting, you move on to the article itself.

And the article is written using the inverted pyramid method.

The Inverted Pyramid

The inverted pyramid is a style of presentation in which the most important and all-encompassing details are presented first and the rest of the story is told through progressively less significant, but more detailed pieces of the story. Like an inverted pyramid, it starts broad and gets progressively narrower. It’s the way news stories are written.

Journalists everywhere subscribe to this methodology by beginning each story with facts that explain the who, what, when, where, and why of the story. This creates a broad, big picture view of the story so readers can decide whether or not to keep going.

Each subsequent paragraph then offers increasingly specific about the story. Although the additional information helps the reader round out his sense of what happened in the story, each new piece of information decreases in importance.

This is done for a couple of key reasons. First, it enables readers to get the most important information right up front so she can quickly decide whether or not to keep reading. Second, it gives layout designers a way out of sticky design situations. If an article is too long to fit on a single page, but not long enough to warrant a second page, the least important pieces of information - located at the end of the article - can be trimmed to adjust its length. Using the inverted pyramid structure means the article can be made shorter or longer as needed.

This isn’t so much a problem on the web, but take a look at that first reason again. It enables readers to get the most important information up front.

Most newspaper articles start on one page and end on another. Because it’s a printed media, space is limited, so long articles are broken up into multiple parts. The first part can have a “Continued on A14” statement added to the end of it, for example, and the second part can resume with a “Continued from A1”, very much like a “Read more …” link on a web page.

Simple, right? Let’s recap.

First, the opening sentences of a news story are the most important, which is why they’re at the beginning. Second, anything beyond the critical elements can be relegated to another page.

Instead of cramming everything possible into a single space, newspaper designers split things up into logical chunks. And journalists continue the idea by presenting the most important things from each story first.

You can scan a page to find a headline, read the first few paragraphs of an article, and move on without getting bogged down in details you don’t need and that aren’t essential to the story.

This is the essence of progressive disclosure.

Progressive Disclosure on the Web

So how does all this apply to the web?

It applies to the design of individual features, and the architecture of the site or application as a whole. It gives us a way to surface the essential and most-used features and tuck the less-used features away behind a click.

In Google Calendar, for example, you can click an item listed in the calendar view to see the high-level details of an event.

To see more details, you simply click “edit event details”. This takes you to another page that contains all the information available about the event.

Here, you can see the guest list, comments that have been made, and reminder options. You started with just a few details and progressively accessed more information by clicking a link.

On this details page is another progressive disclosure style design. To add guests to an event, you need to click “Add guests”.

Once clicked, a text area is displayed so you can enter the email addresses of people who need to attend the event.

Why wait? Why not show the text area when the page loads instead of waiting for the user to click a link?

This is done so that only the most critical features are shown by default. Not everyone uses the calendar to organize multi-person events, and not every event requires a guest list. Since this feature is used less often than most of the others, it is hidden by default so that the interface can remain clean and simple while still offering a ton of useful functionality.

GrandCentral (a call and messaging management system) also makes use of progressive disclosure, and does so in a very simple way that you’ve probably seen a number of times on the web already. It applies progressive disclosure through a design pattern known as inline expand to reveal more information about a phone message.

By default, messages in the Inbox are shown in a list, and each item contains a small Play button.

When you click the Play button, the area is expanded and a new interface is revealed that enables you to play the message and learn more about the caller.

Functionality is again hidden to keep the interface simple by default. You can quickly glance at the list of messages to see what’s there without the full set of details for each call getting in the way. If you decide to listen to a particular message, you see those details in an on-demand fashion.

Seeing all of the details for all the messages would be overwhelming. Seeing a quick list and expanding select messages to see more is much friendlier.

Thanks - you’ve changed my life

As you can see, applying the concept of progressive disclosure is usually a simple matter of … OK, it’s not that simple.

You have to figure out which screen elements (features or content) are critical and which ones aren’t, and then figure out how to hide the non-critical elements while still providing quick access to them. But once you have that down, you can stop worrying about how to work in all those fancy new features you’ve been wanting to build.

Well, you can worry less anyway.

Kidding aside, don’t view this as an excuse to start cramming everything you can imagine into your application. No matter how well you master progressive disclosure, you still want to show restraint when it comes to adding new features.

More complex software has a funny way of resulting in more complex interfaces. Remember to show some restraint.

Original post by contact@thinkvitamin.com (Carson Systems Ltd)

blog.iso50.com

ISO50 is a portfolio is a blog. Scott Hansen just took his portfolio site ISO50 to a whole new level. Perfect designers’ blogs seem to be all the rage these days. Keeping it simple, while showing off some of Scott’s most breathtaking poster designs in the sidebar seems to be the right recipe for the ISO50 blog. The typography and the colors are all to die for, too.

Original post by Styleboost links

How to price your web application

Pricing is always somewhat of a black art, and a subject about which there is precious little written with regard to web applications. It’s something I’ve always been fascinated by. The question of how to price our web application, Litmus, was subject to countless hours of discussion. Here I’ll discuss some common factors and hopefully help spark some ideas which can help you decide upon the price of your own application.

Billing cycles

Hobbyist, consumer products (think Flickr) often charge annually rather than monthly. If your monthly fee is only $3 it’s going to be easier for everyone involved to charge $35 a year, rather than bill in such small increments. For this article I’ll focus on services billed monthly.

Price plans

Most services have a range of price plans to cater to different customers. This is basic market segmentation — getting the most money from the people who can afford to pay more.

In my opinion it’s good to keep the number of plans down to about 3 or 4. With more than that it becomes more complicated than it needs to be. Harvest do a nice job with three very straightforward plans.

DropSend’s pricing could be considered too complex. The gap between $5 and $9 is very small. As a business purchase, if I’m willing to part with $5 I’ll be willing to spend $9. I’d suggest dropping the $5 plan and just go straight to $9.

Price points

If you look around at other web applications, the monthly fees tend to hover around similar price points:

• $5
• $10
• $20
• $50
• $120

Doubling the price with each plan feels neat. That said, it’s important that the value provided increases proportionally to the price, or better. Take Basecamp: $12 for 3 projects, $24 for 15. Feels like a good deal.

For our service we presently have two price plans — one around $50 and one around $150 (I say “around” because we bill in Euro). Customer feedback seems to indicate that people would appreciate a more limited, lower-priced plan. As a result, we may add something around the $20/month mark. This is in keeping with the price points above, yet keeps our total number of plans straightforwardly small.

Setting the price

Two years ago, when we first launched, we priced ourselves slightly under our main competitor, Browsercam. We pretty much took their price plans and reduced them slightly.

I don’t think that’s the right way to go about it. As other people have said before me, the price sends a message about the quality of your product. We feel ours is better, so in reality we should be charging more (we now are).

Usually for web applications the costs involved are fairly minimal. It doesn’t make sense to use what’s called “cost plus” pricing — setting your prices X% higher than it costs you to deliver the service. Instead, some things can be justifiably more expensive because of the value they add, or the time they save. In our case the target customers are web designers. They might charge in the region of $30-80/hour. A Litmus account will cost them about $50/month, so as long as we’re saving them more than an hour of time each month, it’s definitely a worthwhile purchase.

A friend of mine once told me to make customers feel like heroes. That might be being a hero in front of their boss, their client, or their peers. Tools which help people look more professional are extremely valuable to them. Aspects of a product that enhance the customer’s image in the eyes of someone important to them will in turn cause them to value the product more highly themselves. For us that aspect was our customers’ ability to publish their test results on an elegantly designed web page. That’s something our users can show their clients and feel proud of — it makes them look better. (It’s also something that some of them charge their clients extra for, as part of the total project cost.)

Differentiating price plans

With Litmus, we know from experience that we have two types of users: freelancers and agencies. Freelancers (I used to be one) don’t have as much to spend as agencies, obviously. We needed to segment our pricing in such a way that we extracted the money from agencies who could afford to pay, but still made the service affordable — and usable — for freelancers. The difficult question was how.

Limits

Perhaps you’re lucky and have an obvious limit on the usage of your application which would work to differentiate customers. Or perhaps each time they use your service it directly relates to them making more money (think Blinksale and the number of invoices you send). It’s not always that simple.

We didn’t want to limit the number of tests people could perform. If you’re fixing a site it would be frustrating to run out of tests. We came up with an alternate solution — limit the number of pages or emails you can be working on at one time. Agencies will be working on lots, whereas freelancers will be working on just a handful. When you’ve filled up your “slots” you can delete them to make room for new projects. In a team situation that’s not viable as you’d be constantly asking other people if you could remove their tests. Additionally, agencies would be working on more than a handful of pages or emails at once. Therefore, in theory, we’ve successfully divided our customers into two segments: those who are testing a handful of things at one time, and those who could be testing far more.

Features

High-priced plans can make up a very large portion of overall revenue. I’d suggest having a more expensive plan that suits businesses that have more money to spend (such as design agencies in our case). Here are a few ideas for features you can include in a high-priced plan to help it stand out to those types of buyers:

• Multiple users
• Priority email support (or telephone support)
• SSL security
• Custom branding

We added SSL and functionality for multiple users to our plan aimed at agencies. For you, the other features mentioned may be more or less useful depending on your application.

Summary

I hope some of the above thoughts and ideas are useful. I’d love to discuss them further in the comments. This is an area which often gets overlooked so please do join in the discussion and add your experience.

Original post by contact@thinkvitamin.com (Carson Systems Ltd)

Kimm Saatvedt

Kimm Saatvedt is a Norwegian photographer based in Oslo, the city where I’m located as well. Several of the previous installments of his personal portfolio site have been on Styleboost before. The latest version is no different, and definitely deserves a closer look. The all flash interface works well on a 1280 pixel wide screen as well as on my personal setup, a 1920 pixel wide screen, as it scales the work to the screen size. The navigation is simple and easy to use, while at the same time doing it a little bit different from the others. A nice detail to accompany the amazing photos.

Original post by Styleboost links

Social Networks Aren’t Products

New social networking start-ups are proliferating, often targeted at such narrow markets as to seem implausible. Among them: JewTube, Fuzzster (pet enthusiasts), WeDigYoga (Yoga instructors in New York and L.A.), 18wheelsingles (truck drivers), and there is even Me.com, a Web app for creating other social networks. One need only look to Online Personals Watch or Simple Spark for a litany of new social sites launching almost daily.

I can’t help but wonder, however, if the new flush of starry-eyed social Web entrepreneurs, intoxicated by a desire to follow the gilded paths of companies like MySpace, Facebook, Match.com, and YouTube, are aware of some awkward truths at the heart of the social business model.

My own, admittedly rather niche, social networking company (the first personals site for relationship-minded gay men,) has been going for two years now. If Lovetastic has taught me anything in that time, it is this: social networks aren’t like other Web applications. Social networks can have tremendous value, but they are not themselves “products” in any traditional sense, and they ought to be handled as the special case that they are.

Give me differentiation, or give me death.

As a general principle, the first businesses to define a new market tend to dominate that space as it grows. Unchallenged, Microsofts and Wal-marts will only grow larger with time. In most industries, however, countervailing market forces tend to cause fragmentation and specialization over time. Small niche companies seize territory by catering to a specific subset of users with specific passions.

This is one of the most aesthetically beneficial side-effects of capitalism: the success of a flavorless mass market generally breeds a host of creative, artistic, and specialized sub-markets. Communities of passionate users spring up. Competitors begin to focus on craftsmanship and taste to attract the more discriminating consumers, and the quality of all products in that realm tends to go up. Innovators like Amazon, 37signals, Tom Bihn, and Target have wrought great companies within existing industries out of this elemental economic drive. As the old Business 101 saw goes: differentiate or die.

In a market loomed over by great mountains like MySpace and Match.com, the path of generic mass appeal is now largely closed off to small social networking start-ups. So we would expect to see the same cascade of successful specialization in social networking that we would see in other industries. Except for one little problem. A paradox at the core of the social business model fundamentally breaks the otherwise universal economic mechanism that makes differentiation a valid business strategy.

The cupcake paradox and a taxonomy of Web applications

Nobody wants to be the only person to show up at a party. Not only does it make you look like a loser, but it undermines the whole point of going to a party in the first place. Nobody gives a damn how good the cupcakes are; if scarcely anybody shows up, your party is a failure. Equally, nobody goes to MySpace or Match for the cupcakes—or, to be more precise, the quality of the user experience. People flock there because that’s where everyone else is.

The day that I launched Lovetastic, I knew I had built something that was totally different from any of the other trashy dating sites out there for gay men. It worked elegantly and intuitively; it was beautiful; it had a warm, welcoming aesthetic (in stark contrast to the harsh meat-market feel of our competitors;) and it didn’t reduce its participants to a demeaning set of “stats.” I thought surely guys would jump at the chance to be a part of something like what we were doing.

On launch day, I found that traffic was very strong, but hardly anybody was signing up. I literally got more e-mails from people saying “what a great site!” than I actually got sign-ups. Same for the following few days. So I decided to try an experiment. I put up a preview screen saying we were taking sign-ups and allowing customers to build their profiles, but I hid the page that allowed site visitors to browse other profiles. In this way, nobody was able to see how many (or, more accurately, how few) other members of the site there were at the time. The next day, sign-ups multiplied by several staggering orders of magnitude.

I learned from this experiment early on a lesson that would repeat itself for the next two years: a social network isn’t a product as such. Rather, the product that a social network provides is access to a large pool of other people. Every social network, whether it be a subscription-based dating site or an advertising-funded general community, must grapple with this ineluctable fact. It’s what makes the rules for social networks different from utility applications like Basecamp and BlinkSale.

If a new member signs up for Highrise today, she can use the application, put in some contacts, appreciate the app’s interface and functionality directly and, if she likes it, leave a happy paying customer. Highrise with one customer is a product with one happy client who might just become an evangelist to others. On the other hand, a social network with one customer, even if it were infinitely better than MySpace in every regard, is a company with one bored and angry customer, which is to say: an utter failure. In the taxonomy of Web applications, social and utility applications are entirely different species.

Niche communities will inevitably form within a large social network as a function of its size, but the value of the network itself rests solely on the diversity and number of potential connections a person can make. This is the tragedy of the network effect. Attempting to address a niche from the outside — to provide an alternative to a large existing network — means you have to start at zero in a market where the only things that matter are numbers. If your objective is to use a social network slowly to build a business around a base of happy, paying customers who sincerely care about your product itself (probably the most noble goal in all of business), then, sadly, you’re doomed from the outset.

A race for numbers

And herein lies the tragic paradox for the social networking start-up. If you can’t compete on quality, simplicity, beauty, or ease-of-use, you have to compete on numbers, which often translates to costly advertising and PR. It’s a race to see who can gather and sustain the largest party. This is why the largest social networks are fetching absurd amounts of investment capital, overshadowing the thousands of floundering competitors futilely attempting to climb the lop-sided distribution that characterizes the traffic of social networks.

As of April 2007, MySpace got 80% of social networking traffic, Facebook just over 10%, and the other top ten social networking sites each hover around only 1% each, and the curve only drops way off from there. The thing about large numbers, of course, is that they are incredibly expensive to gather all at once. It’s a very long tail indeed, and it’s going to take any would-be competitor a pretty penny in Google Adwords to climb it.

Now that we have thousands of members instead of none at Lovetastic, people aren’t quite so reticent to put up a profile as they were when I first conducted my early experiment. But we’re still many times smaller than our much larger (and, I would argue, more distasteful) mass-market competitors. We have focused on quality and philosophy rather than building huge numbers fast. Yet we have noted the unfortunate fact that this often leads to a “leaky bucket.” People may sign up, they may love the site, they may write us nice letters telling us what a refreshing and wonderful concept it is, but they often also write a month later to ask us to cancel their account because there just isn’t enough people on the site “yet.”

At Lovetastic, we make some decent money on the sale of what are essentially premium accounts, but in order to keep our numbers-hungry community happy, we have to keep pouring that money back into costly publicity and ads. It’s a vicious circle, and quite frustrating to the entrepreneur who is reluctant to either go into a pit of advertising and publicity debt or to sell out to a larger company who can leverage existing access to the target market and drive them to the site.

To compete with a large competitor like MySpace or Match, you have to differentiate and target a smaller niche. But to be a successful social network you have gather as huge and broad a group of people as possible. The two business needs are fundamentally at odds with each other.

And so what is one to do? Bemoan the death of social networking start-ups and let MySpace define the social landscape of the Internet in perpetuity? It’s clear that if you want to build a Web application business around a traditional product model then utility apps are the way to go, but are social networks too much an uphill battle to be worth the time? Hardly.

Looking for value

I have always admired the willingness of the folks at 37signals to call out the naked emperors of the Internet. Jason Fried in particular has been reminding us for years that real business is about creating value, not just taking a gamble on a buy-out. Their products are splendid examples. And I agree. So if we’re going to take creating a social network seriously, we must do it with a full awareness of all the dangers I’ve mentioned here. If it’s going to be hard to build a water-tight bucket, as it were, without constantly outlaying cash, spamming like crazy, or being absorbed into a larger company, we need to ask precisely what the value is we’re trying to create, and whether it’s worth surmounting the obstacles that lie in our path.

Value, of course, can be defined in many ways. (Merely planning to sell your company to a bigger sucker is not one one of these ways.) The most obvious perhaps is actually making money. Corkd is very interesting in this regard. They’ve figured out that a social network around wine will generate affiliate commissions on wine sales, with the added advantage that oenophiles have strong real-world social ties, which help to spread the word about the site organically.

An example of practical product-style value can be found Kevin Rose’s new social network Pownce. It layers useful collaborative software functionality on top of the social component in a way that de-emphasizes making new connections and puts the focus on the ways it empowers you to interact with your existing friends (see also Twitter.)

But there are other forms of value, too. Many social networks like Zaadz, MakeMeSustainable and my own were created to address what we saw as social problems. We wanted to give people more socially responsible and personally fulfilling alternatives. In some sense, our very existence is to act as a critique of our major competitors and to empower our users to demand more of the mainstream sites. Huge sites like Gay.com end up being forums for facilitating hook-ups, and at Lovetastic we wanted to offer something more holistic. I got to experience the value of that enterprise first-hand in a way I could never have imagined when I started the company: I met the man who would become my husband on Lovetastic, something that would never have happened on one of the mainstream sites. And I’ve heard from many other members who have made similar connections. Working to make people’s lives better carries its own sort of value.

But this sort of social critique is not entirely a non-business concern. Only recently, we’ve come around to the idea of potentially selling Lovetastic to another larger personals or media company. We set out to create something of an alternative site with an innovative, appealing interface. So we’ve realized that if our company goads our major competitors into doing things differently — including by buying and absorbing our site and philosophy into their organization — then we will have succeeded by our original criterion of rallying and serving an under-served niche market that we considered ourselves a part of. This kind of aspiration is different than having a single-minded devotion to getting big fast and selling hard. For companies that want to change the marketplace and create a different sort of value, I think this is as worthy a goal as any other.

My next project will be a utility app, partly for the reasons mentioned here. But I don’t regret for a second what we’re doing with Lovetastic or the time I will continue to spend on it. We’re changing the topography of our little world, and there is plenty of value in that. But, notwithstanding the multi-million dollar headlines we keep seeing, I would caution any entrepreneur who believes social networking is the path to quick riches. It can be a rewarding, and ultimately market-transforming undertaking, but one ought to go into it fully aware of its peculiarities and perils and a clear vision for the precise kind of value one hopes to create.

Original post by contact@thinkvitamin.com (Carson Systems Ltd)