As the Quipol team continues to push furiously toward launch, we thought we’d share some of the design decisions and processes we’ve gone through so far. Of course, it wouldn’t be much fun to just read about design, so this will also be the public’s first opportunity to see what a Quipol looks like and how it works. I hope you enjoy this peek into our world.

The Limits

We knew from the beginning that a Quipol had to be engaging and simple. It should be clear at a glance what it means and what it’s asking you to do. To that end, the first design problem we wrestled with was the creation of limitations.

We referenced Twitter’s character-count limitation here. While it may have initially been driven by the technological constraints of SMS, it turned out to be an important strategic move. It forced users to be concise and consider each additional character. It removed flexibility and control from the user, but guided behavior in a positive way.

With Quipol, our goal is to drive a very specific and simple behavior. We want you to look and vote (comment, too, but let’s take it one step at a time). We encourage this behavior by introducing both character counts and dimensional limitations.

Dimensional Limits

After lots of wrestling matches, yelling, tears, and hugs, 400 x 600 pixels was settled on as the standard, fixed Quipol size.

The dimensional limitations accomplish two things. First, they help Quipol users create the best-looking, most attractive content. Secondly, they ensure that a Quipol will fit comfortably on just about any blog or website.

Character Limits

Functionally, character limits help us control the way content flows into and fills a Quipol. More importantly, the character limit gives our users the freedom to stop writing. It forces them to make critical decisions about what’s important and how to best communicate that importance.

Questions are limited to 75 characters, while contexts are limited to 350. More on these elements later. (For a really cool example of how content limits can shape information and how it’s presented, check out Pecha Kucha.)

The Vibe

Quipols were born to be interacted with: skimmed, scrutinized, analyzed, interpreted, and, of course, voted on. We want people to pick a Quipol up and examine it more closely—or at least feel like they could. So, Quipols are designed to look like a thing, a card that can be picked up, flipped over, and explored.

The self-contained, dimensional appearance does a couple other things for us. First, it’s easy for users to place a Quipol onto any website or blog without interfering with other site content. Secondly, the Quipol experience is available in one place, from voting, to results, to commenting. The user never has to scroll or leave the page.

Tangent

The self-contained-ness of a Quipol raises an interesting, tangential issue that we’ve wrestled with: whether or not to provide access to an expanded, single page view of a Quipol on a user’s Quipol page. We haven’t landed anywhere with this yet, but are actively exploring the possibility of blog-style user pages. We’ll keep you posted.

Quipol Elements

A Quipol breaks down into three primary pieces of user-created content: media, question, and context.

Media

Visuals will play a huge part in driving an audience to engage with a Quipol. To that end, we’ve spent a bunch of time obsessing over how to help Quipol builders turn out an optimal result, regardless of their ability to edit images or locate a perfectly sized image.

The first fail-safe(ish) measure we put in place was to set the maximum/full-size image dimensions to a proportion as close as possible to an image taken with a digital camera or mobile phone. I say “as close as possible” because working within our 400px maximum width prevents us from being exact while still maintaining even margins.

Next, we implemented a fixed-size media area. When added, media is centered both horizontally and vertically in the space. The results look intentional and clean, regardless of the given media’s dimensions. Of course, it’s possible to create better or worse looking Quipols regardless of the framework we put in place, but we hope to prevent as many ugly Quipols as possible—it’s a battle worth fighting.

Question

This is the only required element of a Quipol, which was a tough decision. We considered that some users might want to build Quipols with just images, and that kind of makes sense. Eventually, though, we decided that there has to be a question. It’s foundational to the Quipol application: every Quipol must be explicit about what it is asking a user to vote up or down, yay or nay on.

The way we decided to implement the question is interesting. We wanted to make sure that if a user’s Quipol only includes a question, it still looks good. If we did nothing, the question would be floating in our fixed-size Quipol with a bunch of empty space above and below it. So, we introduced a responsive rule that allows the question text to fill the upper space when no media is present, and the lower space when no context (i.e., body copy) is present. It doesn’t just move into the empty space, though, it grows in size to fill the space. We think it’s pretty awesome.

On a more functional note, requiring the question also gives us a standard way to reference the Quipol in the application’s back-end.

Context

Context lets users add supporting text in case their Quipol needs a bit more explanation. It’s perfect for people who want to use Quipols as stand-alone blog posts.

Vote!

We knew right away that we wanted our vote buttons to feel “clickable,” so we used a straightforward button-style aesthetic. We made the buttons circular because, as the only circles in the Quipol, they command a certain degree of attention.

Color was a bit more of a challenge. Initially we had a green thumbs-up button and a red thumbs-down button. That was problematic (not to mention downright ugly) because of the meaning that those colors often carry with them; stop, go, alarm, environment, slap on the wrist, etc. We didn’t want those implied meanings to influence a voter’s decision, so we explored other options.

We thought maybe we could use gray and make both buttons the same color. While this approach eliminated the problem of color bias and preference, it wasn’t clear enough that we were expecting the voter to choose between two distinct (opposed, actually) options.

So, we kept looking. Blue and red? Too right versus left. Orange and green? Pretty ugly. Blue and orange? Too warm versus cold.

We finally settled on blue and green, two colors which aren’t diametrically opposed, don’t imply value, and can still be distinguished by colorblind users.

Quipol beta will be available on November 8. You can sign up for early access here.