“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.

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.

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.

All of our sites are hosted “in the cloud” on Amazon’s EC2 service. Because of that we’ve been able to grow our network organically as needed. Early in the year we decided a dedicated caching server (memcache) was needed, and within hours it was up and running. Coolspotters depends heavily on our search server running the Apache Solr search engine. Mid-year we found it needed a little more juice, so without much more than a reboot we more than doubled that server’s available resources. These flexibility and agile tools have allowed us to grow and improve the servers without needing to dedicate full-time resources to it. More time to develop cool new features!

We’re working on a number of new projects, some of which you may have heard about in earlier blog posts, others you really should check back to hear about soon. An interesting part of that has been the opportunity to explore technologies more deeply. Coolspotters has always used software libraries to resize photos our members post so they fit in all the different places photos are shown on the site. Up until the summer of 2009 that work was largely done with just a few configuration settings on some stock open source software (attachment_fu, rmagick). But more discrete requirements made it worthwhile for us to go deeper into the tools and make our use of them more flexible. We developed custom recipes for manipulating images to optimize them for the platforms they’ll be seen on, and to make beautiful composites for use in our publishing tools. It took a team effort to hunt down tricky little problems along the way and teamwork like that is what I love about our crew.

One other big push in 2009 was to start making the awesome spots by our community available on other social media sites. As they say, “Go big or go home”, so we started with publishing to Facebook and Twitter. We’ve added associations within our data to link profiles of celebrities and brands to their social media identities (Twitter accounts, Facebook pages, etc) and are able to intelligently mention who a post refers to in context, with a link back to the spot for more details. It was a trying process to learn the ins and outs of several very different publishing interfaces simultaneously, but the results are proving it worthwhile. Most of our posts to these social networking sites are part of our automated publishing tools, with editorial involvement to ensure we’re posting what many followers are interested in. Our work so far has only scratched the surface of what’s possible, so definitely become a fan of Coolspotters on Facebook and follow us on Twitter (@coolspotters) to see what comes next.

2009 brought new faces to the team, while some shook hands and bid farewell, and all the while Coolspotters grew and grew. Some of the days were very long, but the year flew by. It’s hard to believe 2010 is tomorrow, but I know the best is yet to come.

Who Am I?

My name is Jon Maddox, I live in Richmond, Va. I’m a software developer that loves building great products. You can find a little more about me here, you can Google me, or follow me at Twitter and GitHub. For now, lets talk about something that’s actually interesting….like why I’m at Fanzter and what I’ll be doing.

Why Am I Here?

I am currently the VP of Technology and Product Development for Fanzter. I joined Fanzter through the acquisition of my previous company, Mustache, Inc. So why am I here? Well, in all my years of using/playing with/developing technology, I’ve come to have pretty high standards and taste. I know what’s good and I know what’s not-so-good. In a nutshell, I know what sucks. And the inverse of that, I know what’s awesome — the work Fanzter is doing is AWESOME. So my role here is to help them finish their current product roadmaps and help invent future products. So while I’ll still be developing, I’ll also be making some pretty crucial decisions on our product roadmaps.

Coolspotters.com was already a really amazing product before I joined the team. I wouldn’t be here if it wasn’t. But, the beauty of Coolspotters is, that it’s a rooted product that has the ability to scale out in a million different directions. The hardest part is to control those directions. So one thing I’ll be doing is helping to determine which of those directions we actually act on, and in what order. All of those decisions will be based on 3 things:

• Time to Develop / Value – The old ‘low hanging fruit’ plan. Being a small team, we have to pick and choose our next gen features wisely. The last thing we want to do is spend months on a feature that lends nothing to the entire site. It’s important that we we balance how awesome a feature will be for users with the length of time it will take to develop.
• Does it make Coolspotters easier to use? – Coolspotters is a pretty massive site. If time isn’t taken to examine a feature closely, it’d be super easy to junk it up. It’s important to make sure each new feature fits into the flow of Coolspotters easily. Anyone can add feature after feature. But without a clear understanding and fit for that feature, you end up with super bloat. We want to make Coolspotters as user friendly to browse as we can.
• Does it make Coolspotters’ data more expressive? – Coolspotters hosts an enormous amount of data. Awesome data. This has the potential to get you lost pretty easily. It’s important for us that Coolspotters data is understandable and obvious. Any new feature has to improve this usability, not make it more hectic.

Etc.

During all of this, I’m also working on some pretty awesome internal tools, and a iPhone app here and there, that help the Fanzter family of products become even better. But more on that later…

Where We Are

Coolspotters, our flagship product, was built using Ruby on Rails and runs on Phusion Passenger application servers. Traffic is balanced using HAProxy. We use MySQL for storing all spot, profile, comment, and user data; everything except images. To increase performance and reduce load on our databases, we aggressively cache our data using Memcached. About 50% of Coolspotters activity hits cache. All searches, including site search and form auto-completes, are run against a Solr search server.

All Coolspotters servers are hosted on Amazon’s EC2 service. This allows us to scale quickly and perform reliably while keeping our costs down. All MySQL data is stored using Amazon’s EBS which provides snapshots several times a day. So should anything bad happen, we can restore our database quickly. I mentioned above that all data except images was stored in MySQL. For images, we use S3 for storage and Amazon’s CloudFront for delivery from several locations around the globe. All of our Amazon services are configured, deployed, and managed using RightScale.

Future Plans

We’re always trying to create a better experience for our users. This involves careful analysis of our infrastructure, identifying areas that need improvement, creating solutions, and then executing. One area we’ve identified as needing improvement is search. The indexing time of our current solution, Solr, isn’t optimal. Since search is tied into so many aspects of Coolspotters, we know we need to improve this to get the user experience we want. We’ve been experimenting with Sphinx as a replacement and have been pleased with the results so far.

Another area we are looking to optimize is image encoding, storage and delivery. Currently, most of the media uploaded to Coolspotters are images, so any improvement we make to speed up encoding and rendering time has a great impact on the entire site.

We’re looking forward to sharing more about the technical aspects of our products and what goes on behind the scenes here at Fanzter.

-Jon