The BigDoor Blog | API

Software usability evaluation isn’t at all a new concept, nor is it exclusively the realm of bespectacled folks in lab coats, deftly avoiding eye contact behind one-way mirrors. Far from it – “discount” usability testing methods and tools have democratized the process nearly as much as cloud computing has done the same thing to scaling a business’s online infrastructure. (User interface evaluation is even being crowdsourced by companies like UTest.). But your fast-paced market probably demands that you be incredibly nimble and “launch first, ask questions later” – and hope your analytics, some A/B variant testing framework, and direct feedback optimize an initial design. But if you don’t take time to show really early, rough sketch stuff to potential users, “head slappers” – painfully obvious mistakes visible only once you stop protecting your early design from exposure to its intended audience – will lie in wait.

We recently tested portions of a major design update to our tools for publishers who design and deploy BigDoor’s gamification solutions to their sites. The goal? We wanted to learn if our introductory “onboarding” process demonstrated this new experience effectively enough to potential publishers to persuade them to sign up.

Findings? Nope. It did not.

But that’s really good news. Because we had several potential publishers attempt to complete this sign up process and share their frustrations/confusion, we were able to:

• Remove jargon and update terminology that explained little
• Identify a point where adding a couple of previews and simple callouts to explain “this does that,” and “this works like that,” makes all the difference
• Learn that once publishers did find their way through it was fairly easy to understand how to set up the site features they wanted to use

This post should also serve as a shameless plug for Silverback, a stylish, clever tool for video recording a participant’s face and the screen they’re working on, picture-in-picture style, using a Mac laptop’s standard video camera. The impact of the results above was much easier to demonstrate to the entire company with some key video highlights, and all the raw footage was right there on my laptop to work with the moment we wrapped up testing. Hugely useful.

Some imposter dramatizes a dialog box

The barriers to quick, in-house (and crowdsourced) methods for finding out how many head-slappers your early UI designs are lower than ever before. Huge ROI for a relatively tiny investment of time and effort awaits teams of any size.

- Matt Shobe, BigDoor Chief Design Officer & early stage mistake-maker

Most studies have consistently shown that the optimal size of a work team is around 5-7 people. Many of us Amazon.com alumni used to call this concept the “two-pizza teams“–if it takes more than two pizzas to feed your team, then the team is too large. “Two pizza teams” have been around for a while now, well before “Agile” and “Scrum” entered the Product Development vernacular.

At BigDoor, we’ve been growing so fast that it was taking about 5 pizzas to feed our growing dev team. Plans to split into smaller teams began to get more serious. Finally last week, with the addition of our new awesome Product Managers Fayez and Scott, we re-organized into three scrum teams. Each team now has 6-7 members and the results have been immediate.

Here are some things we saw in the new teams’ first week:
• Planning meetings took less than an hour
• Team members have been more vocal and participating more in meetings
• Team members are much more aware of the status of the sprint and if co-workers need help
• New teams had successful sprints
• Sprint stories fall much more within a theme and are less randomized, resulting in a more focused team

As we continue to grow our organization it’s really exciting to take knowledge that worked very well in the past and apply it to our team.  Now, what’s for lunch!?

Today our friends at AppStoreHQ launched a new product that aims to help people find apps they love with the promise to “Never Install a sh*tty app again!” The 100% rearchitected version of AppESP is now available.

The guys at AppStoreHQ are using BigDoor behind the scenes to connect with Facebook, invite friends to use AppESP as well as provide feedback on user actions, including rating and sharing apps with friends. Additionally they designed a custom set of badges and a virtual economy, “AppBucks” that users can accumulate as they interact with the app. Cheers to Scott and team!

We’re pleased to announce that BigDoor is hiring! Are you an unconventional Black Box Tester? Can you use your reporting and analytic skills as a rockstar Business Intelligence Analyst? Are you a creative and strong Web Designer with web UI skills? A killer Content Manager? BigDoor is looking for YOU!

We’re a Seattle-based startup looking for individuals to help us create the next big killer company. Our platform helps digital publishers create loyalty programs and game mechanics into their site or application through points, badges, levels, virtual currency and virtual goods as well as building economies for our partners. We’re developing a game mechanics and virtual economy ecosystem based around our RESTful API to interact with our MySQL database for clients and we perform high transaction volumes. Our customers include digital publishers, content providers, app developers, goods vendors, and advertisers. Our platform is extensible in order to allow a wide variety of apps to be built on top of it. Sound interesting? Send your details to HR@bigdoor.com.

Today we are very proud to announce a partnership with MLB Advanced Media (MLBAM), the interactive media and Internet company of Major League Baseball. Major League Baseball! Fans visiting MLB.com’s Gameday section can earn and collect unique player badges that provide prestige, personalization and recognition.

Our CEO Keith Smith put it best, “It’s incredible validation for us that MLBAM chose BigDoor as its gamification partner. This is another critical milestone for us as we endeavor to build a loyalty and rewards program that will increase engagement and revenue for our partners.” MLB.com’s CTO, Joe Choti said,“Integrating a badging rewards program for fans as they consume content on MLB.com was a priority for the 2011 season. We’re pleased to deliver this enhanced level of fan engagement through our partnership with BigDoor and its powerful and flexible gamification solution.”

What’s even more exciting is we’ll be working with MLBAM in the future and will continue implementing additional opportunities for fans to earn badges and engage on their site. “Play Ball!”

Hello World!

My name is Collin. I’ve been at BigDoor from the beginning and have developed many iterations of our Front-End library. I have failed and have been successful. In all cases, the goal is to make something easy, fun and awesome to use. In dev-land this translates to quick iterations, learn from the issues and make it better. That being said, I’m very happy with our recent release of our JavaScript library. There are definitely warts and improvements to be made but I firmly believe we finally have a library to build from.

Engineering Goals
Our Front-End libraries have both short and long term goals. Usually our short term goals are feature driven while our long term goals are for long term adoption. The following long term goals have been driving our development from the beginning.

1. Must be generic so that a developer can come in and start extending or adding features as they see fit
2. Support the non-developer community by designing a clean API to support programmatic configuration

In our previous libraries we were more concerned with our short term goals by adding features and iterating over those features to get them right. Those goals still exist from a design perspective but from the engineering perspective we needed to shift how we were developing in order to support these two long term goals.

Past Design
Previously we developed ‘modules’ which provided an interface for a given feature. These modules would provide an API for the feature and handle remote and local communication. We also incorporated jQuery plugins. We used 3rd party plugins and wrote our own to define what feature a node would provide.

If we continued this way, we could never meet our goals. We were only developing the Logic and UI layers. We needed to shift from a scripted feature set to a full feature application with a clear separation of concerns.

Current Design
Before we started a recent custom implementation, we knew we had to provide better separation if we were going to be successful. We spent a few days drawing diagrams, researching best practices, deciding on how to leverage existing libraries and coming up with names for what we were trying to define.

Once we had flushed out our ideas we had to go back and provide some structure for how we could think and talk about it more publicly. We took the multitier architecture model and identified our layers as the following:

• Communication
• Data
• Logic
• Presentation
• Configuration

When these were identified we only had a rough sketch of which classes belonged where but we had to start developing due to our impending deadline. However, this was the first time we had a clear separation of concerns and a shared language to work from and couldn’t wait to get started!

We now have the following architecture to work from in order to meet our short term goals as well as quickly and accurately iterate over our feature development:

• Communication
  • Transport
  • API
  • BigDoor (inherits from API)
• Data
  • Model
• Logic
  • Authentication
  • Controller
  • Provider
• Presentation
  • Widget
  • jQuery templates
  • KnockoutJS
• Configuration
  • Application

Future Design
It would be nice if I could predict the future and tell you what features and functionality we are working towards but I can’t. What I can say is that we are working hard to make this publicly available as soon as possible by reintegrating Facebook Like, Badges, etc., as well as prototyping new applications.

I’m super excited with this release and couldn’t be happier to be a part of this team. I can’t wait to see what we can come up with next!

Goodbye World!

–Collin Watson

Today our Co-Founder and CEO Keith Smith and our Director of Monetization and Implementation Tommy Lee are attending Ad:Tech San Francisco. We’re really excited to announce the launch of the BigDoor Engagement Economy with Cost Per Quest! The BigDoor Engagement Economy is a new way for sites to engage their users while monetizing their content. One of the initial pieces is Cost Per Quest, an entirely new, performance based, ad format meant to reward end users for their time and attention while engaging deeply with online brands. Quests are a critical component of BigDoor’s Engagement Economy and are sold to advertisers on a Cost Per Quest (CPQ) basis.

The BigDoor Engagement Economy is currently in private beta mode. Last week, in partnership with SpectrumDNA Quests launched with UGO Entertainment. The incredible team at SpectrumDNA worked their magic and has truly created a gamified experience that’s intrinsically a social loyalty program incorporating interaction with news and information, as well as a rewards system that is original, native and meaningful.

We talk to websites all the time and get the question about our rumored “hidden fees.” We truly believe gamification should be a profit-center for web publishers and app developers, not a cost-center so we offer our technology for free. However, in order to provide publishers a free platform as well as enable them to make money by using gamification, we realize we need a solution that works not only for publishers and end-users, but also for advertisers as well. We think that any solution that gives advertisers traffic, can make publishers money, and reward users can be an Epic Win! The BigDoor Engagement Economy will roll out to a broader network of publishers by Summer 2011.

Online website owners interested in learning more about our Engagement Economy and Cost Per Quest advertising pilot program can contact us. Additionally, those attending San Francisco’s ad:tech 2011 are encouraged to meet with Keith Smith (keith@bigdoor.com; @ChiefDoorman) and Tommy Lee (tommy@bigdoor.com; @pikopoki) during the event, April 11-13, 2011.

Recently we were happy to post some shout outs for our dev team, who executed a significant upgrade to our systems with minimal disruption. A flawless transition to keep things performing at the levels we expect. But how does the API usually perform? We wanted to share some stats regarding how quickly our API typically responds. Below are some external, minute-by-minute checks of our API from a diverse set of US locations. The following was taken over the course of a 24-hour period:

Average GET requests: Under 175 milliseconds
Average Leaderboard requests: Under 250 milliseconds
Average transaction POST: Under 400 milliseconds

By way of comparison, Facebook’s average API response time for us over the course of the last month has been 14,249 milliseconds.

The key takeaway here is: “Our tech boys rock” but in more technical terms: “We slayed the evil database monster with some crazy ass ops wizardry.”

We wanted to let everyone know about this amazingly cool experiment Brad Feld is currently testing on his site. For those of you who don’t already know Brad, he’s the managing director at Foundry Group who invests in software and Internet companies (including Zynga). He was recently named the
“Most Respected Venture Capitalist”and he’s also one of our investors. For the next 30 days Brad will use the BigDoor MiniBar on his site to offer 30 minutes of his time as a reward for anyone who wants to exchange 10,000 Feld Gelt for the opportunity to speak with him. With the help of BigDoor’s MiniBar (white-labeled on Brad’s site), users have five easy options to earn Feld Gelt, including Check-in when visiting Brad’s site; Adding a comment to any blog post on the site; Sharing or Tweeting posts; ‘Like’ any post from the MiniBar and most importantly, the best way to earn Feld Gelt is when users click on links you have shared or Like links in your Facebook feed. Users can get started working their way up the Leaderboard for a chance at 30 minutes with Brad!

Update: Brad’s deal was so popular that it took about eight minutes to sell out! Brad mentioned there might be a new deal and we’ll update with any new details!

Today we all got a good chuckle over our good friends at Badgeville claiming in a bold headline that they are now “Delivering Real-Time Social Rewards Across One Billion Monthly Page Views.” That’s super impressive…until you read the details. Turns out that in reality they have “one billion page views of traffic under contract,” meaning that they have agreements with companies that have over 1 billion page views. This deflated our excitement for them considerably, but as a friend of mine is known to say, “Don’t let the facts get in the way of a good story.”

This got us thinking. Why constrain our headlines and announcements to reality? One can tell a much better story when you are no longer shackled by inconvenient nuisances like truth and accuracy. All of our competitors charge for their services, and we give ours away for free, so we figured that our meaningless facts must be considerably better than theirs. Little did we know how much better.

So we channeled our inner Badgeville, saddled up our magic unicorn and took our turn on the “look how awesome we are” train. Turns out, we have over 21 billion monthly page views “under contract” (I’m no math whiz, but that’s something like 21x bigger). What’s even more impressive is that we calculated that at last week’s Gamification Summit we shook hands with people who represent nearly 1 trillion monthly pageviews. Now there’s a stat that is finally worth crowing about.

Please join us in congratulating ourselves on this very true, but completely meaningless milestone.

(Sorry for the comedic intermission, we just couldn’t help ourselves. Now back to tonight’s roll-out, we’ve got some cool stuff to release this evening.)