Amour GUO's Blog

得之我幸, 失之我命.

Monthly Archives: 4月 2010



Top 5 Ways to Make Your Site More Fun |

原作:Gabe Zichermann是《游戏式营销》(Wiley出版社,已出版)和《趣味件(Funware)实战》(Manning出版社,预计2010年第三季度出版)的作者。同时他也是新兴的专业移动社区网络公司beamME的CEO,我们可以在http://funwareblog.com上看到很多他关于游戏和世界的想法的文章。
译者:阿木( , amourguo(at)

    Just like sex, fun sells. The early proof of that can be seen in the amazing success of location-based networks such as Gowalla(), MyTown and Foursquare(), and in the breakthrough marketing efforts of major brands like Nike, Coke and Chase. Even finance made fun can be a winner —’s meteoric rise was in no small part due to the fun, social engagement of its approach. Ever feel elated while using Quicken? I didn’t think so.
    有趣的东西总是很受欢迎。在这一点上,已经有很多令人兴奋的成功案例,比如基于地理定位的社区网络:Gowalla, MyTownFoursquare;再比如在营销上取得巨大突破的公司如Nike, 可口可乐, 和Chase等;甚至是原本枯燥的财经类应用如果设计得富有趣味性的话,也能成为赢家——译者注:知名个人金融网站)的快速成长在很大程度上也归功于他的趣味性和社会融入度,而你在使用Quicken(译者注:一款专统的家庭及个人财务管理软)时会觉得有趣吗?呵呵,反正我不这么认为。

    The trend continues, with an ever-increasing number of startups looking to get an edge with consumers through fun. Their weapons of choice: Game Mechanics.

    When taken together, game mechanics such as points, leaderboards, badges, challenges and levels form part of what we call a Funware Loop. In my latest book I argue that the best and most compelling loyalty programs are built extensively around Funware and when applied creatively, can make any consumer web or mobile app experience more engaging.
    归纳来讲,这些游戏机制诸如积分、排行榜、徽章、挑战和等级,共同形成了一个环,我们称之为趣味件环(译者注:Funware Loop,好像没有什么中文短语可以把这个翻译得恰到好处)。在我的新书中我也谈到了,最好的、最有说服力的用户忠诚度计划(loyalty programs)必定要围绕着趣味件这个核心进行并且要有创造性的去运用它,这能使无论Web应用或是移动应用都获得更加精彩的用户体验。

    Whether you sell organic foods online, develop mobile application or run the world’s largest social network, you can benefit from applying the 5 simple strategies listed below to increase engagement.

    After all, who doesn’t like a little fun every once in a while?

1. Points | 积分

    Points are an essential part of any Funware Loop, and a great starting point for “gameifying” your site or app. Points allow you to keep track of user activities and make it easy to shape user behavior. Start by listing all the actions that you’d want users to perform and assign relative values to each, taking care to get the balance right.

    In most cases, you’ll want to emphasize user growth and engagement, so be sure to offer healthy point slugs for referrals and activities that generate user interaction (adding friends/followers, for example). Keep your point denominations reasonable: if you begin by giving away millions of points for every activity, you’ll reduce your future room to grow. Also don’t over design to deal with cheaters on day one; you’ll have plenty of time to work on that later.

    Once you’ve begun to assign points for various activities, you’ll need to ensure that you’re giving users an easy way to see their score and how they compare against others. The easiest way to accomplish both is with a leaderboard.

    Points help your users keep track of how they are doing in your app. Here, popular mobile social network MyTown uses dollars in lieu of points (something you should generally avoid unless it’s thematically relevant to your site/app).

2. Leaderboards | 排行榜

    Like the scoreboard at a sporting event, leaderboards are a universal way to convey to your fans and customers that a “game” is being played. The key to being successful with a leaderboard mechanic is to ensure that users are motivated by friendly competition while simultaneously not de-motivated by users who are better, faster and have been playing longer than them. There is no better solution to this problem than Facebook Connect.
    就如同一些赛事上的计分榜,排行榜可以让你的用户能够意识到他是正在“玩游戏”。通过排行榜的机制获得成功的关键就在于,要通过友好的竞争让用户得到激励,同时又不能因为其他用户更好、更快或是加入的时间比他更早而让该用户失去希望和动力。对于这个问题,似乎没有比Facebook Connect(译者注:允许用户从外部网站访问 Facebook 数据,这使得普通网站也可以具有社交功能。详见更好的方案了。

    The easiest option: show the points accumulated by your customers relative to their social graph, giving them a contextual ranking. Through callouts, illustrate how easily they can rise to the level of their next-highest performing friend (e.g. “invite two more people to beat Debbie’s score”). Of course, you should also show a global Top 10 and geo-located leaderboards if you can, but these should actually be somewhat buried in your design.

    Though points and leaderboards are quite powerful (and sufficient for most game-like experiences that target the achiever in us), they lack the ability to create social rewards for parallel or tangential activities. For that, there are badges.

    Social leaderboards, like this one from the wildly successful Facebook game Who Has the Biggest Brain (Playfish/EA), show your score relative to your friends on Facebook, making it easy to both feel successful and competitive at the same time.
    上图中的排行榜,来自最成功的Facebook游戏——Who Has the Biggest Brain(Playfish/EA),它显示了用户相对于其他Facebook好友的积分,这让人既有成就感又有竞争的压力。

3. Badges | 徽章

    The best way to think about badges is as a demonstrable, fun reward for a specific activity that is easily socialized with others. Much as Boy and Girl Scouts receive merit badges for particular activities, you too can create an almost limitless set of attractive, visual objects that can be “sewn” onto a users’ social graph – typically their Facebook wall or Twitter stream. By giving your customers an easy thing to crow about, you maximize the likelihood that they will evangelize your site/product to others while also creating a positive association for them.
    最好的理解徽章机制的方式就是:他是一种针对特定的社会化行为的可供展示的趣味性的奖励形式。就像美国童子军的奖章一样,你也可以无限量地设定各种诱人的、形象的徽章并把它们“缝合”到用户的社交体系上,比如说用户的Facebook wall或是Titter stream。当你的用户有了这些吹嘘的资本之后,他们在向身边的人炫耀并建立他在他圈子里的地位的过程中,你的网站和产品也就同时得到了宣传。

    Think of badges as rewards for ongoing contests that users are constantly engaged in – whether or not they are directly connected to point balances. In many applications, badges are issued without warning (see Foursquare), leveraging the power of operant conditioning – like slot machines – to keep users playing. Where possible, offer an auto-tweet/post option for your badges – braggarts are a great way to get the word out about your app.

    Where badges are frequently (though not always) given as a reward for a set of non-obvious activities, challenges are a direct way to engage users around a specific task – and are an essential part of the Funware Loop.
    当徽章频繁地(虽然不总是)为一些并非显而易见的活动颁发给用户作为奖赏的时候,挑战机制则是吸引用户来参加某项任务的一条直接的办法,它也是趣味件环(Funware Loop)中的一个基本部分。

    A badge by any other name is… a ribbon? Farmville, the uber-popular Facebook game uses ribbons to offer periodic rewards to users. Where possible, make your badges attractive and relevant to your users.

4. Challenges | 挑战

    Most walkathons and sales campaigns start with a challenge: “sign up ten walkers/new customers/friends and receive a reward.” Everyone has, at one time or another, taken up a challenge like this, and they are an essential part of an end-to-end system for customer loyalty. Once you have a sufficient group of users collecting and comparing their points, you can start offering them the option to compete for more points and virtual rewards.

    For example, you could offer users 10,000 bonus points for signing up 4 friends for your service. Automate the notifications, issue a congratulatory message, and immediately offer another pre-built challenge (e.g., 100,000 points for 20 signups). Consider offering a wide range of challenges tied to your evergreen and time-sensitive business objectives and allow users to access a list so that they can pick their own.

    With all the activity around points, badges and challenges, it seems obvious that users might need some easy way to track and reflect on their achievements within your app/site. Levels, a game mechanic from the earliest of video games, are the perfect solution for creating a constant sense of forward motion and the opportunity for reflection.

    Gowalla, a mobile social network, has a sophisticated and well-conceived challenge mode, known as trips. Like many winning Funware designs, Gowalla allows users to also see the complete list of challenges to choose the ones they like best.

5. Levels | 等级

    If there is a single mantra we could extract from the multi-billion-dollar casual games industry that has spawned Bejeweled, Diner Dash and Farmville, it’s “Reward Early, Reward Often (and don’t go negative).” While this is relatively easy to do, users in a more complex loyalty program or on Funware-based sites, frequently need levels to create a discrete sense of achievement. Levels allow users to feel like they’ve accomplished something by showing structured progression through the overall experience.
    如果要从催生了诸如Bejeweled, Diner Dash 和 Farmville等几个成功游戏的价值数十亿美元的休闲游戏产业总结出一句话来概括他们的成功的话,那将会是:“即时且时常的对用户进行奖励”。这些是相对容易做到的,用户在一个更加复杂的忠诚度计划或基于趣味件的网站中,经常需要等级来满足他们的成就感。等级让用户觉得如同他们经过一系列的努力而终于取得了一项进展。

    Levels can be complex to design properly, so start with simple breakpoints and leave yourself room to expand. Use numbers or letters to denote your levels and set their breakpoints with increasing degrees of difficulty. A good rule of thumb is that it should be at least twice as hard to complete the fourth level as it is the first, and so on.

    Diner Dash uses a clearly defined level system. Every time you clear the restaurant of patrons, you clear a board; multiple cleared boards gives you a finished level. Imagine doing the same thing with a fitness app: as users perform tasks and improve their health, they ascend the ranks.
    Diner Dash使用了一个定义清晰的等级体系。每个经营档期清场之后,都会清一次盘,几次清盘之后会根据你的分数(所服务的台数)给你一个等级;你也可以试想一下在一个模拟健身的应用程序上使用同样的等级策略:当用户完成任务并改善健康状况之后,他们也提升了在应用程序中的等级。

Conclusion | 结论

    With the breathtaking growth of game mechanics and Funware in the current crop of popular apps and sites, it’s easy to see why so many startups are interested in incorporating points, leaderboards, badges, challenges and levels in their designs.

    Whether you are building a healthcare app, forum discussion site or the next, these simple game mechanics can make your consumer-facing mobile or web experience substantially more fun and engaging — all for far less than the cost of a traditional loyalty program, and with far greater satisfaction.




Saying Yes to NoSQL

原作者:John Quinn(Digg:, Twitter:

    The last six months have been exciting for Digg’s engineering team. We’re working on a soup-to-nuts rewrite. Not only are we rewriting all our application code, but we’re also rolling out a new client and server architecture. And if that doesn’t sound like a big enough challenge, we’re replacing most of our infrastructure components and moving away from LAMP.

    Perhaps our most significant infrastructure change is abandoning MySQL in favor of a NoSQL alternative. To someone like me who’s been building systems almost exclusively on relational databases for almost 20 years, this feels like a bold move.

What’s Wrong with MySQL?

    Our primary motivation for moving away from MySQL is the increasing difficulty of building a high performance, write intensive, application on a data set that is growing quickly, with no end in sight. This growth has forced us into horizontal and vertical partitioning strategies that have eliminated most of the value of a relational database, while still incurring all the overhead.

    Relational database technology can be a blunt instrument and we’re motivated to find a tool that matches our specific needs closely. Our domain area, news, doesn’t exact strict consistency requirements, so (according to Brewer’s theorem) relaxing this allows gains in availability and partition tolerance (i.e. operations completing, even in degraded system states). We’re confident that our engineers can implement application level consistency controls much more efficiently than MySQL does generically.

    As our system grows, it’s important for us to span multiple data centers for redundancy and network performance and to add capacity or replace failed nodes with no downtime. We plan to continue using commodity hardware, and to continue assuming that it will fail regularly. All of this is increasingly difficult with MySQL.

Choosing an Alternative

    Digg is committed to the use and development of open source software and we’re keen to avoid the cost of proprietary large-scale storage solutions. We were inspired by Google and Amazon’s broad use of their non-relational BigTable and Dynamo systems. We evaluated all the usual open source NoSQL suspects. After considerable debate, we decided to go with Cassandra.

    Simplistically, Cassandra is a distributed database with a BigTable data model running on a Dynamo like infrastructure. It is column-oriented and allows for the storage of relatively structured data. It has a fully decentralized model; every node is identical and there is no single point of failure. It’s also extremely fault tolerant; data is replicated to multiple nodes and across data centers. Cassandra is also very elastic; read and write throughput increase linearly as new machines are added.

    We experimented on our live site, replacing a relatively high scale MySQL component with a Cassandra alernative. These tests went well. You can read more about these experiments here.

Where We Are

    At the time of writing, we’ve reimplemented most of Digg’s functionality using Cassandra as our primary datastore. We’ve supplemented Cassandra-based indexing using full text, relational and graph indexing systems. We’re getting used to dealing with eventual consistency.

    We’ve been working on Cassandra itself too. We’ve made massive performance improvements: increased comparator speed, added better compaction threading, reduced logging overhead, added row-level caching and implemented multi-get capability. We’ve also implemented native atomic counters using Zookeeper (you can probably guess why were motivated to add that feature 🙂

    We’ve tested and improved the operational capabilities of Cassandra, upgrading its Rackaware capability, added slow query logging, improved the bulk import functionality and implemented Scribe support for improved logging. We’ve also done a ton of operational testing.
    我们测试并改进了Cassandra的运转能力,升级了他的机架感知能力,加入了slow query logging,改进了批量倒入功能并为了改进日志功能而实现了Scribe支持。我们还做了大量的运行测试。

    We’re open sourcing all our work on Cassandra.

What’s Next?

    Currently our main focus is getting Digg’s latest release into general availability, but we’ll continue to lead the way in championing Cassandra’s development and adoption.

    If you’re interested in joining a world-class team using cutting edge, NoSQL technology at scale, check out
    Take it easy,



About User eXperience(aka UX/UE)

What UX stands for?
    In most domestic companies, we commonly call User Experience as "UE" for short, but for the worldwide scope, its well-accepted abbreviation is "UX";
    So what’s UX Stand for?
    Focus on the target users of the products/services, including who they are, how they behave, what makes them use our products, even their work, life, habits, and all other factors relevant to how will they response to the products or services;
    Focus on our Clients, we learn their business, process, also personas and roles in their products/services/processes;
    Respect users’ habits and guide users to cultivate a good habit of using the products/services;
    It’s not a single functional specification or a single research study, it’s not a fixed process, it’s a process of continually learning about users, responding to thier behaviors, and evolving the product or service.
    UX is everywhere in the processes, including end-user interview, product anlysis, interaction design, UI design and UI implementation;
    Simplicity is the best, make rich featured but simple user interface without distracting user’s mind, we love both efficiency and effectiveness;
    UX engineers are both liaisons and implementer, we know when to litsen, we know how to act, we balance the client bussiness goals and end-user requirements for the client organization;
    Finally, we help our clients to build highly usable and accessible, effecient, consistent, low dev/maintenance cost products, services or processes;
    UX is not only about technology, but good technologies DO help us to fulfill our goals better.

What we do in a project.
    First, we keep listening, asking, analyzing and iterating, to well learn the requirements from our clients and end-users;
    We help clients to get all the functionalities and workflows into shape;
    We help clients to idetify the roles from their workflow and create personas;
    We provide wireframes with Interaction Diagrams& Specifications;
     – We try to use GUI framework and proper functional block design to keep consistency of visual style and user experience on this product,
     – We use Axure/Visio/Photoshop/Illustrator to compose the prototypes, wireframes, and final visual design screens to show to all the related people and get feedbacks from them,
    Clients know their business/process well, what we need to do is helping them to achieve more goals through proper interaction design and implementation solution;
    We just don’t need always to do what is best for the end users, as UX engineers we have to find the sweet spot between the user’s needs and the business goals, while balance business and end users;
    Other than dealing with clients and end-users, UX engineers are also caught in the middle trying to speak the business language, the developer language and the UI designer language to justify why we need to do our job, how to do it, and why it’s important to success.
    So someone also says that UX is kind of an art of leverage and compromise:-)

UX Definition Process.


试用Google App Engine

    最近刚好聊起一个有关Google的话题,突然想起Google App Engine的帐号申请下来之后除了一个Hello World就没再用过了,就决定试用一下,也不枉申请一回;
    做试用的这个App没什么难度,只是通过用Cron Job定时每天在新闻网站上抓取数据,用SAX过滤出想要的内容,再提交到一个BBS上,所以主要还是共享一下在做App时遇到的一些问题,希望能给也遇到相同问题的朋友做个参考:
    1) App Engine上的应用有一个限制:应用程序代码仅在响应网络请求或 cron job 时运行,且任何情况下必须在 30 秒钟内返回响应数据。刚开始没看到这个,把所有的逻辑都写到一个servlet里了,在本地环境测试OK,一deploy到Engine上,就不行了,最后只能重写,尽量保证应用的响应时间在10秒以内;
    2) 同样一个本地环境测试通过,一但Deploy就不行的问题:在对一个URL进行Fetch的进候,老是会报IOException,追进去之后是在url.openConnection()老是“Can not fetch this URL”,最终查出来是在目标URL的php中的ob_start(‘ob_gzhandler’)所导致,不知道为什么AppEgine的URL Fetch跟PHP的gzip压缩会有冲突,没时间去研究,先把该PHP页的gzip关掉,OK,通过;(如果有对这方面原因了解的朋友希望能指点一下: amourguo[at]gmail[dot]com)
    3) 还是一个Deploy之后才出现的问题,看来Google应该解决一下保持本地测试环境和AppEngine的一致性问题,呵呵。在我的一个DB Entry里有一个字段叫作“newsLink”,用JDOQL做Query的时候("select from Xxxx where newsLink == linkParam parameters linkParam")就会老是报错说找不到一个叫做"sLink"的class,显然它是把newsLink中的new当做关键字了,不知为何,即便是中间没有空格,它也会把newsLink当做new sLink(),而且在SQL中应该是可以用[newsLink]来解决的,但在JDOQL试了证明行不通,最后不得不把这个字段改名了,所以,在JDOQL中,不但不能使用关键字作字段名,最好也不要包含关键字,以减少不必要的麻烦;
    Google App Engine还是不错的,使用多少资源就付多少费用,很合理,只是开发的时候会有诸多的限制,让人略有不爽,不过还好也不影整体的良好感觉,而且根据需要增加或减少对资源的消费这一点上,也符合节能减排的大潮流(-_-|||);GAE算是最早的PaaS(Platform as a Service)的大规模实现之一了,后来Sina也搞了一个SAE,不过帐户是邀请制的,我没有搞到邀请,所以没试过:-p