“We’re just people, running this company. We’re trying to make great products for people. And so, we have at least the courage of our convictions to say, ‘we don’t think this is part of what makes a great product, so we’re gonna leave it out.’ That’s what a lot of customers pay us to do, is to try to make the best products we can. And if we succeed, they’ll buy them. And if we don’t, they won’t.”

I can’t think of a better way to describe what we’re doing here at Fanzter. Our number one goal is to make awesome things around contexts that people love.

All of us here at Fanzter are huge fans of movies, music, TV series, sports, video games, technology, and other things in pop culture. We want to make products around things we love. I had an iPod when it was a huge brick. I’ve owned every video game console in history, sometimes more than once. I spent a fortune on the iTunes store the day it came out. I’ve used every media center platform that exists. I maintain an Xbox Live subscription, not for playing games online, but for access to the media and online content they provide. And I rarely actually use any of it day to day. But I’ve spent HOURS playing with them all.

For me, its about the experience. I like to just play with these things. I like to study them. To see what is great, and what sucks. More times than not, things suck.

Here at Fanzter we like to think we know what is great, but more importantly, what sucks. Only in knowing what sucks, can you make something great.

There are a lot of contexts out there that people are passionate about. This is where we will be. We know all too well that fans of movies, tv, sports, etc, are not being served, because we ARE these people! So we’re extra motivated to make kick ass things for these fans.

Stick with us, because we have a lot of awesome things planned. We’ve been dabbling in the iPhone world for the last couple of months but will be shifting to some much bigger things soon.

Coolspotters turnes 2 years old today. Head on over to the Coolspotters blog post and leave us a comment. Thanks

Digging, voting, buzzing, retweeting, liking, bumping, shouting. These ubiquitous social tools have become the de facto mechanism to determine collective popularity. There’s little variation in terms of visual feedback when you engage these tools to increase an item’s popularity by one unit. Most just update the value instantly while others (Digg) perform a little fade effect.

Years ago I had done some push effects with live scoring applications for ESPN. I like this form of feedback when a numeric value increments. More recently I had created a UI for the CoolPapers “like” tool that uses a similar push effect:

In this tutorial I’ll create a new social voting tool called Flippit to demonstrate this:

See a demo here.

Markup

Like anything, this can be done a number of ways. There’s not much semantic relevance here, so any sensible structure will do. The only real requirement is to have enough elements for styling and animation.

293Flips


Flippit

Background & CSS

I’ll just use one sprite for this tool. The top will serve as the background for the numeric value, the bottom area gives us backgrounds for the unclicked, hover and clicked states of the action button.

There’s nothing too tricky or innovative in the CSS below. However, the key technique here is the overflow:hidden rule on the “votecard” class’s child div (line 10). This will effectively serve as a mask which the animating objects will move across. More on that later.

.votecard {
	background: url(images/sprite.png) no-repeat 0 0;
	padding: 4px;
	width: 63px;
	height: 43px;
	text-align: center;
}
.votecard div {
	position: relative;
	overflow: hidden;
	width: 63px;
	height: 43px;
}
.votecard em {
	display: block;
	position: relative;
	width: 63px;
	height: 33px;
	padding: 6px 0 6px 0;
	font: normal 24px/24px "Helvetica Neue","Helvetica","Arial",Sans-serif;
	color: #45453f;
}
.votecard strong {
	font-weight: bold;
}
.votecard span {
	font-size: 10px;
	line-height: 10px;
	display: block;
	color: #9a9a94;
}
a.voteaction {
	margin: 0 0 0 3px;
	display: block;
	text-indent: -9999px;
	width: 71px;
	height: 21px;
	background: url(images/sprite.png) no-repeat -3px -75px;
}
a.voteaction:hover {
	outline: none;
	background-position: -3px -54px;
}
a.voted,
a.voted:hover {
	outline: none;
	background-position: -3px -96px;
	cursor: default;
}

jQuery

Now we’ll have some real fun and wire this up.

$(document).ready(function() {
	/* create a node for the flip-to number */
	$(".votecard em").clone().appendTo(".votecard div");
	/* increment that by 1 */
	var node = $(".votecard em:last strong")
	node.text(parseInt(node.text())+1);

	function flip(obj) {
		obj.prev().find("em").animate({
			top: '-=45'
		}, 200);
		obj.toggleClass("voted",true);
	}

	$('.voteaction').bind({
	  click: function(event) {
	    event.preventDefault()
	  },
	  mouseup: function() {
	    flip($(this));
		$(this).unbind('mouseup');
	  }
	});

});

Content duplication

You might have wondered why the next number (294) was not included in the original markup shown earlier. The answer is found in line 3 through 6. This code duplicates the <em> node containing the current vote value (293) then increments that value by one. This new <em> node is forced to flow beneath the original one, but is hidden from view as specified in the CSS above. Here’s what your browser sees after this code runs:

Button events

Two events will be bound to the “Flippit” button, and you’ll see why these events are kept separate shortly. The default browser response is disabled in the click event. The mouseup event handler will call the flip() function which will perform the animation. It is important to allow this function to be called once only. After the user has initiated a “flip”, this action should be immediately disabled.

Had we grouped the event.preventDefault() together with the flip() call in a single button event (on click for example), we’d reinstate the default browser response when we unbound that event from the button. This would likely result in a page refresh if the user clicked the button twice. Keeping these events separate lets us unbind just the flipping action while preserving event.preventDefault().

Flip tha script *

The flip() function’s task is to select both <em>s and then move them up a distance of 45 pixels. Note also that this function takes as an argument a jQuery object reference to the button which called it. From this, we can traverse to select the <em>s we want to animate. The top <em> will slide out of view, while the jQuery generated one slides into view. The process is completed by toggling the button’s class name to “voted”.

What’s this good for?

This adds a little tactility to these contraptions. It reinforces the notion that you just impacted a piece of content on the web, if only by one solitary unit. If it’s good enough for sports apps, it’s good enough for anything else.

This technique could be used for anything where a numeric value increases or decreases whether it results from user interaction or not (as in live scoreboards).

View the demo (Works in IE6, IE7, IE8, Safari 4, Chrome, Firefox 3.6)

Reposted from aaronweyenberg.com.

Today we announced the launch of CoolPapers, a wallpaper application for your iPhone or iPod touch.

CoolPapers allows you to personalize the home screen of your device by providing access to the most extensive collection of pop-culture related photos available on any mobile platform.

CoolPapers taps the vast library of photos on Coolspotters, and optimizes and enhances them, allowing you to choose from over fifty-thousand wallpapers featuring your favorite celebrities, movie posters, album art, cars, products, brands, and more. The app also takes advantage of Coolspotters’ association engine to recommend related wallpapers.

We’re really excited about this app and we hope you enjoy it.

The 17th Century English historian Thomas Fuller once said that “all things are difficult before they are easy.” Things like the reflecting telescope (Newton) the steam turbine (Branca), and the adding machine (Pascal) were all inventions to make life easier back in Fuller’s time. In this millennium, one device I use daily (generously gifted to me by a colleague here at Fanzter) is an amazing Krups egg cooker. Now I enjoy perfectly hard boiled eggs in 15 effortless minutes using only 3 ounces of water. I put the eggs and water in the device, turn it on and forget about it until the buzzer sounds. The traditional way of hard boiling eggs offers nothing but inconvenience to me now. The new way is expedient. It’s easy. I can’t imagine making a hard boiled egg the old way.

Such is the sentiment for version control among developers. Sure, a developer could sit down and write unversioned code day to day, but few developers worth their salt would ever recommend that approach. And multiple developers working collaboratively? Out of the question. Here at Fanzter, we have migrated from SVN to Git for all our products. While its learning curve is a little steeper than SVN, the benefits are worth the climb. But is versioning your work just for developers and engineers?

Designers as team members

My creative career has taken turns through tiny design agencies to art direction in creative groups designing for over 20 million unique users per month. One observation has remained relatively constant throughout these environments: Creatives tend to operate as individuals, developers usually operate in small squads. Of course there are some exceptions to this precept, but they’re sporadic in my view. This isn’t to say that creatives don’t often draw upon each other for inspiration, influence and feedback. I’m focusing on the actual modus operandi of how the work is generated, stored and revised.

Here’s a rough, unscientific representation of these dynamics at Fanzter:

Developers have unsurprisingly capitalized on their own strengths by creating robust version control systems for themselves. Designers are generally unreceptive to this way of storing and revising their work, even with a GUI to take the geekery out of using a command line. But how can they be more integrated?

Creative crossover

While many teams include those whose prime skill is to convert mockups into something a developer can wire together, many creative types can (and often prefer) to translate their own artistic efforts into well-formed, semantic XHTML architecture and CSS. Some go as far as to mock the intended UI behaviors using popular Javascript libraries like jQuery, or even write custom scripts themselves. All well and good. But even if these files are created and managed individually, they can and should be versioned.

The moment a designer starts working with plain-text files, they have become a development squad member.

This is the moment to embrace version control. It’s a transient state, but it’s reality.

At Fanzter, every static XHTML mock is stored in the dev repository. This includes those mocks that are just exploratory and never see real development time. They also reference the same versioned CSS and other dependencies as files in the main dev repo do. This ensures that styling revisions to a mock never veer out of sync. It’s clean, it’s decentralized, it’s protected, and developers aren’t thrown any surprises.

Binary art files

Version control products like Git can store these files. Fanzter maintains a repo for key art source (.psd, .ai, and other binary formats) for all our products. It’s a bit of a tough sell for creatives to use these source control repos for art files, so there are some promising VC products available that may work well for those primarily working with these kinds of files. Timeline offers version control specifically for Photoshop using SVN, and Gridiron Flow lets you visually see how your art files are related and how they’ve changed.

But the essential distinction remains: design work is generally not socially collaborative, so the appeal for designers to faithfully use VC products may still be some distance away.

How does your creative team handle their own group’s versioning? If there is critical source that is shared among other groups, how is it organized to maintain a sensible work flow? I look forward to the day when filenames like mockup05_revised_final_reallyfinal.psd are left in the dustbin of antiquity… but things are often hard before they are easy.