Saturday, October 23, 2010

[Gd] Research Project: AppScale at University of California, Santa Barbara

| More

Google App Engine Blog: Research Project: AppScale at University of California, Santa Barbara

The following post is a guest post by Chris Bunch, a Computer Science Ph.D. student at the University of California, Santa Barbara. He is one of the student leads on the AppScale project, an open source Google App Engine compatible hosting solution led by Professor Chandra Krintz. Chris has developed and maintained AppScale as a research project over the last two years with fellow student lead Navraj Chohan and others.



---------

Over here at the UCSB Racelab, we've complained endlessly about finding a web framework we actually could use. For a long time we thought we just wouldn't be able to find it - many were so-so or good but only after a substantial learning curve. So imagine our surprise back in April 2008 when we heard about what we thought would be just-another-web-framework provided by Google in the Python version of App Engine. But after giving it a try, we were smitten. We finally found a web framework that (1) we could actually use on non-trivial projects
and (2) we could teach in nine-week classes without having students lose half the time with the idiosyncrasies of the programming language involved or the web framework itself. Furthermore, the minimalistic APIs make it simple to get work done: it did for us exactly what we needed and nothing else.



Yet as researchers and hackers-at-heart there was one thing that we really wanted to do with App Engine that we couldn't do: run it on a whole bunch of our machines and tinker with it. A similarly-minded hacker named Chris Anderson had released AppDrop, which was a modified version of the App Engine SDK that hooked up to PostgresSQL and run in Amazon EC2, but only ran over a single machine. So after much discussion, we came up with the following short list of things we wanted to do with App Engine:






  • We wanted to run it on our own virtual machines or those running in Eucalyptus or Amazon EC2 in order to investigate how we can optimally harness cloud infrastructures in our cloud platform.


  • Tons of new datastores have emerged as part of the "NoSQL" movement, and we need a mechanism to evaluate their performance under controlled experiments as well as traditional databases such as MySQL. We also need a platform that supports the ability to add new data storage mechanisms so that when developers tout the features of their new datastore, we can download it and evaluate it under similar circumstances as other datastores.


  • One of the reasons we love Google App Engine is the simple set of APIs provided, but we also wanted to use that as a starting
    point where we could add new APIs and control the environment in which they run.

  • We love that Google App Engine "just works". You don't know where it's running and how it's running, but you can see that it is running, and we wanted to make sure that whatever we developed, that it did the same. We wanted to develop something that automatically deployed your App Engine app and configured everything for you. Expert users should be able to have more control over the system, but the system should be able to handle your app from the moment you deploy it to the moment you tear it down.


  • It had to be open-source - just like how we wanted something to tinker with and run experiments on, we wanted it to be something that you could tinker with too. We wanted you to be able to add in support for a database you're interested in and see how it performs, and we wanted you to be able to add in APIs that you think would be interesting to have an easy-to-use web framework interact with.




So with that in mind, we created AppScale, an open-source cloud platform
for Google App Engine applications. Here's how we did it:




We took the standard three-tier web deployment approach and clearly segmented each tier into a specific component in the system: an AppLoadBalancer routes users to their applications, an AppServer runs the user's App Engine app, and an AppDB handles database interactions. Each have clearly defined roles in the system and are controlled by an AppController, a daemon that runs on each machine, monitors each component, and controls the specific order in which services are started. It writes all the configuration files for each service and coordinates services between the other AppControllers in the deployment. For those interested, we detail the specifics on the original AppScale implementation in this paper.




We also wanted to embody the principle of "standing on the shoulders of giants", and as such, we employ open-source software as often as possible, where appropriate. Our AppLoadBalancer employs the nginx web server as well as the haproxy load balancer to ensure high performance. Our Memcache API implementation uses memcache under the hood, while our MapReduce API uses Apache Hadoop, which we added to give App Engine
users running over AppScale the ability to run Hadoop MapReduce jobs from within their web applications.



Because we were able to keep the database support abstracted away from the other components in the system, we were able to add support for nine different data storage solutions within AppScale: HBase, Hypertable,
MySQL, Cassandra, Voldemort, MongoDB, MemcacheDB, Scalaris, and SimpleDB. Many of these databases have seen interest in recent years but have been hard to measure under comparable conditions, and vary greatly. To give a few examples, they vary in the query languages they provide, their topologies (e.g., master / slave, peer-to-peer), data consistency policies, and end-user library interfaces. This has made it non-trivial for the community to objectively determine scenarios in which one database performs better or worse than another and investigate why, but under AppScale, deploying all these databases is done automatically with no interaction from the user. And because AppScale is open-source, if a developer doesn't like the particular interface we use for a database, they can improve on it and give back to the community. We've used
AppScale internally to evaluate the performance of Google App Engine applications on these datastores as well as developed an App Engine app, Active Cloud DB, that exposes a RESTful API that developers can use
to access these datastores from any programming language or web framework.



Finally, the most important lesson we learned was the value of incremental development. Our core development team fluctuates between two to three developers, so from the first meeting we had, we knew that
our very first release couldn't support every App Engine API nor could it run nine databases seamlessly. Therefore, we started off with support for the two BigTable clones, HBase and Hypertable, as well as support
for just the Datastore API, the URL Fetch API, and the Users API within App Engine. From there, we learned what datastores people actually wanted to see support for as well as what APIs people wanted to use. We
were also able to add APIs within App Engine apps deployed to AppScale to be able to run virtual machines under the EC2 API, while also running computation under the MapReduce API.



But developing AppScale was certainly not a cakewalk for us. Over the course of the last two years, five major issues (some technical and some not) have arisen within the project:





  1. Writing software that works without knowing ahead of time how many machines will be in the system proved initially to be difficult to grasp, but in many cases we were able to reduce the number of variations that could occur and use that to provide some predictability with respect to how we configure and deploy databases and applications.


  2. We couldn't assume that the AppScale administrator has access to DNS; without it, a number of APIs and features are extremely difficult to implement. Load balancing is much more difficult, and many APIs that are tied to host names must be tied to one machine in the system, else they don't work properly. VLAN tagging shows some promise to alleviate these problems, but right now is far from being deployed inexpensively and easily.


  3. The source code for the Java version of App Engine isn't publicly available, so we had to spend a lot of time decompiling the SDK, modifying it to use our database and our API implementations instead of the SDK implementations, and recompiling it. All of these were non-trivial and greatly added to the time it took for us to deploy a version of AppScale with Java App Engine support.


  4. Not all users want a pre-built virtual machine image, so ensuring that building the AppScale environment was done right every time was a top priority. We had to limit ourselves to Ubuntu Jaunty for many releases, and only recently were we able to expand to include Karmic and Lucid, which still make up a microcosm of the distributions available in the Linux world. Adding the ability to install AppScale via apt-get in these specific Linux distributions has also been a crucial step in making sure that users could easily and quickly install AppScale for use.


  5. Both undergraduates and graduate students here at UCSB have done projects involving AppScale, which means that the number and experience levels of developers working on AppScale is completely unpredictable at a given moment in time. Oftentimes the projects they work on are only tangentially related to features that users want, and the time scales that they are available to work for is vastly different than most software engineers are used to.



All of these problems are greatly exacerbated by only having a two-to-three person core developer team, but this also makes the AppScale project particularly interesting to work on. Despite having worked on AppScale for two years, there are still tons of interesting problems to work on and we still love the Python App Engine web framework as much as we did when we first picked it up. And of course, AppScale is open-source, under the New BSD License, so feel free to download it and tinker around like we have! Check out AppScale at:




http://appscale.cs.ucsb.edu




http://code.google.com/p/appscale



-- Chris
URL: http://googleappengine.blogspot.com/2010/10/research-project-appscale-at-university.html

Friday, October 22, 2010

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Chrome Dev channel has been updated to 8.0.552.11 for all platforms. It contains a number of stability and other improvements including:
  • about:labs moved to about:flags
  • New Tab Page cleanup
  • Various Chrome Frame fixes for non-en-US locales
Full details about the changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/10/dev-channel-update_21.html

[Gd] Discover v201008: Remarketing

| More

AdWords API Blog: Discover v201008: Remarketing

Version v201008 of the AdWords API introduces the UserListService and the CriterionUserList which give you API access to the features available in the ‘Audiences’ tab in the AdWords interface. To learn more about remarketing, visit the AdWords Help Center.

You can set up remarketing using the AdWords API in two steps:

  1. Create a remarketing list.
  2. Create a CriterionUserList to tie your list to an AdGroup.

We’ve also included short code snippets showing you how to manage LogicalUserLists, also known as custom combination lists, and how to monitor your user list size.

Create a remarketing list

Creating a remarketing list involves the creation of two separate entities: the RemarketingList itself and its associated UserListConversionTypes also known as remarketing tags. The following code shows how to create a remarketing list.

// Get the UserListService.
UserListServiceInterface userListService =
user.getService(AdWordsService.V201008.USER_LIST_SERVICE);

// Create conversion type (remarketing tag).
UserListConversionType conversionType = new UserListConversionType();
conversionType.setName("Mars cruise customers #" + System.currentTimeMillis());

// Create remarketing user list.
RemarketingUserList userList = new RemarketingUserList();
userList.setName("Mars cruise customers #" + System.currentTimeMillis());
userList.setDescription("A list of mars cruise customers in the last year");
userList.setMembershipLifeSpan(365L);
userList.setConversionTypes(new UserListConversionType[] {conversionType});

// Create operations.
UserListOperation operation = new UserListOperation();
operation.setOperand(userList);
operation.setOperator(Operator.ADD);

UserListOperation[] operations = new UserListOperation[] {operation};

// Add user list.
userList = userListService.mutate(operations).getValue()[0];

Tie a remarketing list to an AdGroup

A new type of criteria object called CriterionUserList is now part of v201008. Through this type of criteria you are able to tie a UserList to an AdGroup. As with other types of criteria, this type is also managed through the AdGroupCriterionService. The following code shows you how to create a CriterionUserList and tie it to an existing AdGroup.

// Create user list criteria.
CriterionUserList userListCriteria = new CriterionUserList();
userListCriteria.setUserListId(userList.getId());

// Create biddable ad group criterion.
BiddableAdGroupCriterion userListBiddableAdGroupCriterion = new BiddableAdGroupCriterion();
userListBiddableAdGroupCriterion.setAdGroupId(adGroupId);
userListBiddableAdGroupCriterion.setCriterion(userListCriteria);

// Create operation.
AdGroupCriterionOperation userListAdGroupCriterionOperation = new AdGroupCriterionOperation();
userListAdGroupCriterionOperation.setOperand(userListBiddableAdGroupCriterion);
userListAdGroupCriterionOperation.setOperator(Operator.ADD);

AdGroupCriterionOperation[] criteriaOperations =
new AdGroupCriterionOperation[] {userListAdGroupCriterionOperation};

// Add ad group criteria.
adGroupCriterionService.mutate(criteriaOperations);

Custom combination list

It’s also possible through the API to create LogicalUserLists, also known as custom combination lists in the AdWords interface. A LogicalUserList lets you group together other UserLists, which includes RemarketingUserLists and other LogicalUserLists, through a series of UserListLogicalRules. The following code shows you how to create a simple LogicalUserList that combines two other remarketing lists, but it’s possible to create more complex combinations using this type of list.

// Remarketing user lists to be referenced.
UserList list1 = new RemarketingUserList();
list1.setId(remarketingUserListId1);

UserList list2 = new RemarketingUserList();
list2.setId(remarketingUserListId2);

// Create logical user list.
LogicalUserList logicalList = new LogicalUserList();
logicalList.setName("Logical list #" + System.currentTimeMillis());
logicalList.setDescription("A list of two other lists");
logicalList.setMembershipLifeSpan(365L);
logicalList.setRules(new UserListLogicalRule[] {
new UserListLogicalRule(UserListLogicalRuleOperator.ALL,
new LogicalUserListOperand[] {
new LogicalUserListOperand(null, list1),
new LogicalUserListOperand(null, list2),
})
});

// Create operation.
UserListOperation operation = new UserListOperation();
operation.setOperand(logicalList);
operation.setOperator(Operator.ADD);

UserListOperation[] operations = new UserListOperation[] {operation};

// Add user list.
UserListReturnValue result = userListService.mutate(operations);

Monitor the size of your list

You also might be interested in monitoring the growth of your list. You can accomplish this by making a simple get() call to the UserListService to retrieve this kind of information. The following code shows you how to retrieve information about all of your user lists.

// Create selector.
UserListSelector selector = new UserListSelector();

// Get all user lists.
UserListPage page = userListService.get(selector);

// Display user lists information.
if (page.getEntries() != null) {
for (UserList userList : page.getEntries()) {
System.out.printf("User list with name '%s' has an estimate size of '%d' users.\n",
userList.getName(), userList.getSize());
}
}

All code snippets included in this post are based on the AdWords API Java Client Library, other client libraries also include code examples and support for remarketing.

As always, please post your questions about how to use this new service on the forum.

Posted by David Torres, AdWords API Team
URL: http://adwordsapi.blogspot.com/2010/10/discover-v201008-remarketing.html

[Gd] Manymoon sees 30% higher conversions on Google Apps Marketplace

| More

Google Apps Developer Blog: Manymoon sees 30% higher conversions on Google Apps Marketplace

Editor's Note: This post was written by Amit Kulkarni, CEO at Manymoon, a company that provides team and project management software. We invited Manymoon to share their experiences building an application on top of Google Apps utilizing some of our APIs.

An Idea

We started Manymoon with the idea of bringing social communications to the workplace. Not because it was cool, but because we think the best way to get work done is with the help of the people around you while still minimizing interruptions.

Like most start-ups, we wanted to build something we’d use ourselves. As heavy Google Apps users, we immediately saw the benefit of integrating Manymoon with Google Apps for tracking tasks or projects.

We also knew that professionals have unique requirements:
  • Utility - professionals are busy throughout the work day and get judged on productivity. Any app they use needs to provide tangible value with immediate gratification. And what’s more satisfying than completing a task or project?
  • Security - they need the ability to control what’s shared and with whom.

This led us to create Manymoon: a social productivity tool. It allows you to leverage your professional network to get work done. That means doing things like tracking conversations, managing projects, completing tasks and sharing documents. That was the easy part, now we just had to build it and find customers.




Finding Customers

The market opportunity speaks for itself: Google Apps has over 30 million users spanning over 3 million businesses. It’s also a growing business since they’re signing up over 3,000 new businesses per day. We would be in good shape if we got a small fraction of this flow.

Most importantly, the Google Apps Marketplace brings qualified customers who are comfortable using the cloud to run their business. Google Apps customers understand the value of:
  • Not having to install or maintain software
  • Software that requires minimal training
  • Self-service software (they don’t require significant amount of in-person sales or support).
These are critical traits since they allowed us to focus on building a great product instead of having to ramp up other parts of the organization (e.g., hiring sales people, support engineers, etc).

How We Did It

As a start-up, one of our advantages is time to market. There are numerous features that would have normally taken us months to develop but we accelerated the process by leveraging a variety of Google APIs and products.

Google Docs
Attach a Google Doc to a task or project and Manymoon will automatically handle the sharing permissions. This is the feature that consistently receives the most “wow” comments from customers.

Google Calendar
Keep your calendar automatically updated with relevant tasks and project information. We saved months that would have been required to build features such as reminders, views and meeting requests.

OpenID & Google Universal Navigation

Business customers already trust Google with their data, and this significantly reduces the friction in activating users. And with Google Universal Navigation, new users can experience Manymoon immediately without even having to register. Using Single Sign-On means users can move seamlessly from Google Apps to Manymoon without needing to re-enter their credentials.

Google Contacts

Contact integration via Google Contact API makes it incredibly easy to assign a task to someone or invite them to a project. Just enter their name! No more remembering email addresses or having to import contacts.

Gadgets!
Our customers are Google Apps customers first and foremost and this makes it simple to use Manymoon in the environment they’re already used to. We support a Gmail Contextual Gadget so users can create tasks and projects without ever leaving their inbox. And a Google Sites/iGoogle gadget allows project data to be part of more complex wiki and portal pages that customers build. Ultimately, Google Gadgets significantly reduce the friction for users to create and track projects.

The Results

The results have been fantastic. Since the launch of the Google Apps Marketplace in March, we’ve been signing up as many as 1,000 new businesses per week ... and that’s with no sales or marketing people in our company. These customers are finding us on their own in the Google Apps Marketplace, adding the app and getting engaged with it.

Google Apps Marketplace customers upgrade to a premium edition of Manymoon at a 30% higher rate than non-Google Apps Marketplace customers. The best part, however, is that our monthly registrations increased by 150% since the launch of Google Apps Marketplace. And that’s where the Marketplace really excels, it provides large enough volumes to make the Freemium business model work.

We also closely monitor business sign-ups since their users activate over a period of time. If a business with 1,000 employees signs up to Manymoon, some fraction of those users will use Manymoon in the 1st day. But a larger fraction will use it in the first week and and an even larger in the first month.

What We’ve Learned

We think there are three ingredients that are important to sustaining a large number of business sign-ups from the Google Apps Marketplace:

1) Appeal to a broad audience - Google Apps customers comprise all types of industries and job functions. Manymoon is broad enough to apply to most of them, so we cast the widest net and try to appeal to as many as possible.

2) Integrate deeply - of course most all Google Apps customers use Gmail. But each customer has its own mix of Google Apps they use (e.g., Google Docs + Gmail, Google Sites + Gmail, etc). We built Manymoon to be flexible enough to accommodate any of these mixes.

3) Demonstrate immediate value - logging in using a Google Apps account is the price of admission (literally). To really engage customers, you have to very quickly demonstrate additional ways your app works with Google Apps. We do this during the registration process.

How To Get Started

Google provides open APIs with very good documentation that can be accessed here. They also have a simple and transparent process for listing your app. We were able to find everything we needed to build and integrate Manymoon with Google Apps.

Posted by Don Dodge, Google Apps Team

Want to weigh in on this topic? Discuss on Buzz

URL: http://googleappsdeveloper.blogspot.com/2010/10/manymoon-sees-30-higher-conversions-on.html

[Gd] Get Involved! Two new OpenSocial workgroups!

| More

OpenSocial API Blog: Get Involved! Two new OpenSocial workgroups!

As President of the OpenSocial, I'm pleased to announce the formation of two new Foundation sponsored workgroups (officially called Board Advisory Committees), that will focus on two areas of great importance; alignment with key open source and standards efforts, and interoperability.

OpenSocial has grown organically over the last few years, expanding from traditional social networks like MySpace into community oriented sites such as the Nature Network (see the earlier blog post). OpenSocial has even moved into the enterprise with offerings from Cisco, Liferay, and others all supporting the standard. Now, we are seeing the formation of application market places, e.g. Jive Apps Market, based on OpenSocial Technology.

As our community grows into this diverse ecosystem of containers and application providers, it becomes essential that our you have multiple ways to get involved and be recognized for your hard work. To help foster this community interaction the Foundation's Board has established two new Advisory Committees, a.k.a, workgroups.


The Open Standards and Open Source Alignment Advisory Committee
The availability of a production quality reference framework and implementation is a fundamental enabler of open standards. As many of the open source projects continue to grow, and as OpenSocial continues to add new capability, it becomes important to ensure that we have the ability to quickly implement these innovative new features, without sacrificing the ability to incrementally build upon and maintain core capability. Here are some of the things this workgroup will tackle:
  • Keep the community, and the Board, abreast of key open source projects, notably, Apache Shindig
  • Work across open source projects to coordinate release cycles of the specification with implementations
  • Ensure an accurate, up-to-date set of examples and documentation that are consistent with the specification
  • Recommend alignment with key industry standards and specification efforts, e.g. Activity Streams, One Social Web, and others as appropriate
  • Participate in the definition of the OpenSocial vision
  • Recommend to Board on where resource investments should be made to the benefit of the entire community, so that Board members and Officers can work within their organizations and the community to secure the allocation of resources

The Interop & Enterprise Advisory Committee
One of the stated missions of OpenSocial is to provide a common programming model that allows a social application developer to write their application once, and have it run in a wide variety of containers. We've taken a very positive first step, but as a community, we've got to do better if we are to make this vision real. In addition, vendors have added their own capabilities that deviate from the specification. We will need to work with those vendors get them to invest their valuable resources into OpenSocial and bring their enhancements back to the community via the standard and open source. The purpose of this workgroup is to have a focused set of people responsible for spearheading this effort. Here's some of what will be on the plate of people who work on this important team:
  • Ensure updated and accurate compliance test suites
  • Plan, supervise, and manage interop events on a regular basis
  • Actively recruit key industry participants (containers and app vendors) to participate in the events
  • Recommend and propose changes to the specification to improve interoperability
  • Define interop scenarios based upon real world aggregation experience across multiple domains, e.g. enterprise, education, retail, games, etc...
  • Recommend and propose changes to the development process to ensure the ability to keep pace with innovation in the industry, early prototyping, transparent development, and, of course, interop
  • Establish strategy for alignment with key industry interoperability efforts, e.g. SWAT0

We've already gotten off to a good start! Paul Lindner has volunteered to lead the work group on Open Source and Open Standards alignment.With his leadership of Shindig, this is a great fit. But Paul can't do it alone. WE NEED YOU to be successful!

These are great opportunities to get involved and help advance the OpenSocial technology and grow our community! If you are interested, please contact me or one of the Foundation Officers or Board Members directly, or post to the OpenSocial community discussion group.

Thanks!

Posted by Mark Weitzel, President, OpenSocial Foundation



URL: http://blog.opensocial.org/2010/10/get-involved-two-new-opensocial.html

Thursday, October 21, 2010

[Gd] Improving App Quality

| More

Android Developers Blog: Improving App Quality

[This post is by Roman Nurik, who is passionate about icons. —Tim Bray]

With thousands of new apps being published in Android Market every week, it’s becoming more and more important to proactively work at breaking through the clutter (hooray for marketing jargon!). One way of improving your app’s visibility in the ecosystem is by deploying well-targeted mobile advertising campaigns and cross-app promotions. However, there’s another time-tested method of fueling the impression-install-ranking cycle: improve the product!

A better app can go a very long way: a higher quality app will translate to higher user ratings, generally better rankings, more downloads, and higher retention (longer install periods). High-quality apps also have a much higher likelihood of getting some unanticipated positive publicity such as being featured in Android Market or social media buzz.

The upside to having a higher-quality app is obvious. However, it’s not always clear how to write a so called ‘better app.’ The path to improving app quality isn’t always well-lit. The term ‘quality’, and its close cousins ‘polish’ and ‘fit and finish’ aren’t always well-defined. In this post, we’ll begin to light the path by looking at a couple of key factors in app quality, and furthermore, look at ways of improving your app along these dimensions.

Listen to your users

Given that pretty much any measure of the ‘success’ of an app involves user-related metrics such as number of downloads, daily actives, retention rates, etc., it’s a good idea to start thinking of your app’s quality as it relates back to your users.

The most obvious way to listen to users is by reading and addressing comments on your app in Android Market. Although the comments aren’t always productive or constructive, some will provide valuable insight on aspects of your app that you may not have consciously considered before. It’s important to remember that users have the opportunity to change their ratings and comments about an app as much as they’d like.

Now, since Android Market doesn’t currently provide a bidirectional communication medium for developers and their users, you should set up your own support and discussion destination(s). There are some great support tools out there that can put you in touch with your users directly such as Google Groups, Zoho Discussions, getsatisfaction.com and uservoice.com. Once you get set up with such a tool, make sure to fill in the support link in your Android Market listing -- users do click through to these.

Another way to better listen to your users is by having a public beta or trusted tester program. It’s crucial to have some amount of real user testing before releasing something in Android Market. Fortunately, you can distribute your apps to users outside of Market via a website; this website can require a login or be publicly accessible — it’s entirely up to you. Take advantage of this opportunity by offering your next planned update to some early adopters, before submitting to Market. You’ll be surprised by how many little, yet impactful, improvements can come out of crowd-sourced, real-user testing.

Improve stability and eliminate bugs

I won’t go into detail about why this is important, because hopefully it’s obvious. And hopefully you’ve been reading this blog and following the best practices outlined in previous posts, so you have a solid idea on how to improve in this arena.

One noteworthy and yet relatively underused tool for catching stability issues like crashes, is the UI/Application Exerciser Monkey (aka Monkey). Monkey will send random UI events to your app’s activitie, allowing you to trigger user flows that can uncover stability problems.

Also, with the new error reporting features in Android 2.2, users now have the ability to report application crashes to developers. These show up in aggregate in the Android Market developer console. Make sure to read these reports and act on them appropriately.

Lastly, keep an external bug and feature request tracker. This will enable your users to engage with the app at a closer level, by following features and bugs that affect them. User frustration with app problems can be effectively managed with diligent issue tracking and communication. Some of the community support tools listed above offer issue tracking features, and if your project is open source, most popular repository hosting sites such as Google Code and GitHub will offer this as well.

Improve UI Responsiveness

One sure-fire way to tick off your users is to have a slow UI. Research has shown that speed matters... for any interface, be it desktop, web, or mobile. In fact, the importance of speed is amplified on mobile devices since users often need their information on the go and in a hurry.

As Brad Fitzpatrick mentioned in his Google I/O 2010 talk, Writing Zippy Android Apps, you can improve your apps’s UI responsiveness by moving long-running operations off the application’s main thread. See the talk for detailed recommendations and debugging tips.

One way to improve UI performance is to minimize the complexity of your layouts. If you open up hierarchyviewer and see that your layouts are more than 5 levels deep, it may be time to simplify your layout. Consider refactoring those deeply nested LinearLayouts into RelativeLayout. As Romain Guy pointed out in his World of ListView talk at Google I/O, View objects cost around 1 to 2 KB of memory, so large view hierarchies can be a recipe for disaster, causing frequent VM garbage collection passes which block the main (UI) thread.

Lastly, as Tim pointed out in Traceview War Story, tools like traceview and ddms can be your best frends for improving performance by profiling method calls and monitoring VM memory allocations, respectively.

More resources:

Improve usability

I’ll say it again here, listen to your users! Ask a handful of real Android device users (friends, family, etc.) to try out your application and observe them as they interact with it. Look for cases where they get confused, are unsure how to proceed, or are surprised by certain behaviors. Minimize these cases by rethinking some of the interactions in your app, perhaps working in some of the user interface patterns the Android UI team discussed at Google I/O.

In the same vein, two problems that currently plague Android user interfaces are small tap targets and overly small font sizes. These are generally easy to fix and can make a big impact. As a general rule, optimize for ease of use and legibility, while minimizing, or at least carefully balancing, information density.

Another way to incrementally improve usability, based on real-world data, is to implement Analytics throughout your app to log usage of particular sections. Consider demoting infrequently used sections to the options menu, or removing them altogether. For oftenly-used sections and UI elements, make sure they’re immediately obvious and easily accessible in your app’s UI so that users can get to them quickly.

Lastly, usability is an extensive and well-documented subject, with close ties to interface design, cognitive science, and other disciplines. If you’re looking for a crash-course, start with Donald Norman’s The Design of Everyday Things.

Improve appearance and aesthetics

There’s no substitute for a real user interface designer — ideally one who’s well-versed in mobile and Android, and ideally handy with both interaction and visual design. One popular venue to post openings for designers is jobs.smashingmagazine.com, and leveraging social connections on Twitter and LinkedIn can surface great talent.

If you don’t have the luxury of working with a UI designer, there are some ways in which you can improve your app’s appearance yourself. First, get familiar with Adobe Photoshop, Adobe Fireworks, or some other raster image editing tool. Mastering the art of the pixel in these apps takes time, but honing this skill can help build polish across your interface designs. Also, master the resources framework by studying the framework UI assets and layouts and reading through the new resources documentation. Techniques such as 9-patches and resource directory qualifiers are somewhat unique to Android, and are crucial in building flexible yet aesthetic UIs.

The recently-published Android UI Design Tips slide deck contains a few more best practices for your consideration.

Deliver the right set of features

Having the right set of features in your app is important. It’s often easy to fall into the trap of feature-creep, building as much functionality into your app as possible. Providing instant gratification by immediately showing the most important or relevant information is crucial on mobile devices. Providing too much information can be as frustrating (or even more so) than not providing enough of it.

And again, listen to your users by collecting and responding to feature requests. Be careful, though, to take feature requests with grains of salt. Requests can be very useful in aggregate, to get a sense of what kinds of functionality you should be working on, but not every feature request needs to be implemented.

Integrate with the system and third-party apps

A great way to deliver a delight user experience is to integrate tightly with the operating system. Features like app widgets, live folders, global search integration, and Quick Contacts badges are fairly low-hanging fruit in this regard. For some app categories, basic features like app widgets are par for the course. Not including them is a sure-fire way to tarnish an otherwise positive user experience. Some apps can achieve even tighter OS integration with the new contacts, accounts and sync APIs available in Android 2.0 and later. A few sample apps that show how to use these APIs are SampleSyncAdapter (bundled with the SDK samples) and JumpNote.

Third-party integrations can provide even more user delight and give the user a feeling of device cohesiveness. It’s also a really nice way of adding functionality to your app without writing any extra code (by leveraging other apps’ functionalities). For example, if you’re creating a camera app, you can allow users to edit their photos in Photoshop Express before saving them to their collection, if they have that third-party application installed. More information on this subject is available in the Can I Use this Intent? article.

More resources:

Pay attention to details...

One particular detail I’ll call out is in icon quality and consistency. Make sure your app icons (especially your launcher icon) are crisp and pixel-perfect at all resolutions, and follow the icon guidelines, at least in spirit if not in letter. If you’re having trouble or don’t have the resources to design the icons yourself, consider using the new Android Asset Studio tool (a project I’ve recently open-sourced) to generate a set.

...and more...

Along with this blog, make sure to follow @AndroidDev on Twitter — we’re constantly collecting and sharing tips and tricks on Android application development that you won’t always find anywhere else. And of course, don’t be afraid to ask questions in our support forums on Stack Overflow and Google Groups.

Thanks for reading!

URL: http://android-developers.blogspot.com/2010/10/improving-app-quality.html

[Gd] Google Developer Day - After Japan, Ready for Brazil and Europe

| More

Google Code Blog: Google Developer Day - After Japan, Ready for Brazil and Europe

Google Developer Day Japan on September 28 welcomed 1700 attendees across Tokyo and a satellite location in Kyoto.



During our keynote presentation, we shared updates and demos for each of our global priority areas: Android, Chrome & HTML5 and Cloud Computing. To watch the keynote video, go to http://youtube.com/GoogleDevelopersJa (keynote starts 5 minutes in, some parts will be in Japanese). Thanks to our Japanese developer community, Japan is the 2nd largest global market for Android app uploads and App Engine usage. We were happy to share that worldwide, Android is now at 200,000 activations per day and App Engine is at 90,000 active developers per month. We announced an open source font for Mac OS and support for the Japanese Transliteration API.

We also welcomed over 30 Sandbox developers and hosted 22 technical sessions, with speakers from both Google Mountain View and Google Tokyo. Two additional highlights at GDD Japan were the Android-based Android robot, built by one of the Sandbox developers, and the Chrome bento lunch box.

Coming up very soon are the rest of our Developer Days, which will take place on:
Agenda details for all cities are now available on our website. Please feel free to read up and start planning your day with us!

Our GTUGs in Europe are planning hackathons the day before Developer Day, so be sure to find out more information on our country blogs and Twitter:
Overall, we saw enormous demand for invitations to Google Developer Day. We do wish we could invite more of you, and please stay in touch with us here on the Code blog and your local developer blogs.

Here again are our official hashtags: #gdd2010jp, #gddbr, #gddde, #gddru, #gddcz. We look forward to hearing your thoughts!

By Susan Taing, Product Marketing, Developer
URL: http://googlecode.blogspot.com/2010/10/google-developer-day-after-japan-ready.html

[Gd] Advancing cloud computing with integrated developer tools by Google and VMware

| More

Google Code Blog: Advancing cloud computing with integrated developer tools by Google and VMware

Cross-posted from the Google Web Toolkit Blog

Earlier this year at Google I/O, we announced a collaboration between Google and VMware focused on making it easy to build business-oriented, cloud portable web apps. We showed how businesses could use our integrated developer tools to build modern web apps that are “cloud ready” from the start, and can be deployed to any standard environment, including Google App Engine and on VMware vFabric on-premise solutions. Today we are happy to announce that these tools will be generally available within the next few weeks.

Of course, if you’re itching to get a head start, you can jump right in by downloading the release candidate version of SpringSource Tool Suite.

If you’d prefer to wait for the general release, you can sign up to be notified as soon as they are available.

The list of developer tools includes that are available as part of this collaboration include:

Spring Roo and Google Web Toolkit - Spring Roo, a next generation rapid application development tool, combined with the power of Google Web Toolkit (GWT) enables developers to build rich browser apps in enterprise production environments. These GWT-powered applications leverage modern browser technologies such as AJAX and HTML5 to create the most compelling end-user experience on both desktops and mobile browsers.

Spring Insight and Google Speed Tracer - Google’s Speed Tracer with VMware’s Spring Insight performance tracing technology enable end-to-end performance visibility into cloud applications. This integration provides a holistic view into the web application performance, improving the end-user experience by optimizing the client side as well as the server side.

SpringSource Tool Suite and Google Plugin for Eclipse - The integration of SpringSource Tool Suite and the Google Plugin for Eclipse makes it easy for developers to build and maintain large scale, web-based, enterprise applications, putting tools that were previously only available when building desktop and server solutions in the hands of those building cutting edge web apps.

For a complete “Getting Started” guide, be sure to checkout Getting Started with GWT, Spring Roo, and SpringSource Tool Suite.

Both teams are excited about the strides we can make in the mobile web app space. As it stands today, the current technology stack makes it possible to create optimized web apps targeted for the mobile browser. Longer term, we will be looking at incorporating mobile best practices, styled UIs, and HTML5 features such as app cache, local database storage, and geolocation to make the developer and end-user experience first class.

As always, we’d love to hear your feedback and thoughts on this release. Our GWT developer forum is the best place to post this information. Happy coding!

By Brad Abrams, Google Developer Team
URL: http://googlecode.blogspot.com/2010/10/advancing-cloud-computing-with.html

[Gd] Optimizing sites for TV

| More

Official Google Webmaster Central Blog: Optimizing sites for TV

Webmaster Level: All

Just as mobile phones make your site accessible to people on the go, Google TV makes your site easily viewable to people lounging on their couch. Google TV is a platform that combines your current TV programming with the web and, before long, more apps. It’s the web you love, with the TV you love, all available on the sofa made for you. Woohoo!

Because Google TV has a fully functioning web browser built in, users can easily visit your site from their TV. Current sites should already work, but you may want to provide your users with an enhanced TV experience -- what's called the “10-foot UI” (user interface). They'll be several feet away from the screen, not several inches away, and rather than a mouse on their desktop, they'll have a remote with a keyboard and a pointing device.

For example, here’s YouTube for desktop users versus what we’re calling “YouTube Leanback” -- our site optimized for large screens:


YouTube desktop version on the left, YouTube Leanback on the right

See our Spotlight Gallery for more examples of TV-optimized sites.

What does "optimized for TV" mean?

It means that, for the user sitting on their couch, your site on their TV is an even more enjoyable experience:
  • Text is large enough to be viewable from the sofa-to-TV distance.
  • Site navigation can be performed through button arrows on the remote (a D-pad), rather than mouse/touchpad usage
  • Selectable elements provide a visual queue when selected (when you’re 10 feet away, it needs to be really, really obvious what selections are highlighted)
  • and more...
How can webmasters gain a general idea of their site’s appearance on TV?

First, remember that appearance alone doesn't incorporate whether your site can be easily navigated by TV users (i.e. users with a remote rather than a mouse). With that said, here’s a quick workaround to give you a ballpark idea of how your site looks on TV. (For more in-depth info, please see the “Design considerations” in our optimization guide.)
  1. On a large monitor, make your window size 1920 x 1080.
  2. In a browser, visit your site at full screen.
  3. Zoom the browser to 1.5x the normal size. This is performed in different ways with different keyboards. For example, in Chrome if you press ctrl+ (press ctrl and + at the same time) twice, that’ll zoom the browser to nearly 1.5x the initial size.
  4. Move back 3 x (the distance between you and the monitor).
  5. Check out your site!
And don’t forget, if you want to see your site with the real thing, Google TV enabled devices are now available in stores.

How can you learn more?

Our team just published a developer site, with TV optimization techniques, at code.google.com/tv/web/.

Written by Maile Ohye, Developer Programs Tech Lead
URL: http://googlewebmastercentral.blogspot.com/2010/10/optimizing-sites-for-tv.html

Wednesday, October 20, 2010

[Gd] Advancing cloud computing with integrated developer tools by Google and VMware

| More

Google Web Toolkit Blog: Advancing cloud computing with integrated developer tools by Google and VMware


Earlier this year at Google I/O, we announced a collaboration between Google and VMware focused on making it easy to build business-oriented, cloud portable web apps. We showed how businesses could use our integrated developer tools to build modern web apps that are “cloud ready” from the start, and can be deployed to any standard environment, including Google App Engine and on VMware vFabric on-premise solutions. Today we are happy to announce that these tools will be generally available within the next few weeks.




Of course, if you’re itching to get a head start, you can jump right in by downloading the release candidate (RC1) versions of the tools. The easiest way to get the entire tool set is to by downloading SpringSource Tool Suite RC1.




If you’d prefer to wait for the general release, you can sign up here to be notified as soon as they are available.




Spring Roo and Google Web Toolkit - Spring Roo, a next generation rapid application development tool, combined with the power of Google Web Toolkit (GWT) enables developers to build rich browser apps in enterprise production environments. These GWT-powered applications leverage modern browser technologies such as AJAX and HTML5 to create the most compelling end-user experience on both desktops and mobile browsers.




Spring Insight and Google Speed Tracer - Google’s Speed Tracer with VMware’s Spring Insight performance tracing technology enable end-to-end performance visibility into cloud applications. This integration provides a holistic view into the web application performance, improving the end-user experience by optimizing the client side as well as the server side.




SpringSource Tool Suite and Google Plugin for Eclipse - The integration of SpringSource Tool Suite and the Google Plugin for Eclipse makes it easy for developers to build and maintain large scale, web-based, enterprise applications, putting tools that were previously only available when building desktop and server solutions in the hands of those building cutting edge web apps.




For a complete “Getting Started” guide, be sure to checkout Getting Started with GWT, Spring Roo, and SpringSource Tool Suite.




Moving forward, both teams are excited about the strides we can make in the mobile web app space. As it stands today, the current technology stack makes it possible to create optimized web apps targeted for the mobile browser. Longer term, we will be looking at incorporating mobile best practices, styled UIs, and HTML5 features such as app cache, local database storage, and geolocation to make the developer and end-user experience first class.




As always, we’d love to hear your feedback and thoughts on this release. Our GWT developer forum is the best place to post this information. Happy coding!




By Brad Abrams, Google Developer Team

URL: http://googlewebtoolkit.blogspot.com/2010/10/advancing-cloud-computing-with.html

[Gd] Enjoy more API units this holiday season

| More

AdWords API Blog: Enjoy more API units this holiday season

Last year, we provided you with a bonus of 20% more AdWords API units at no additional cost. We’re pleased to announce that we’re bringing back our holiday bonus this year. Starting now and extending through January 15, 2011, you’ll receive 20% more API units at no additional cost.

Here are the details:

  • Developers can purchase AdWords API units at the rate of 1250 for 0.25 USD, up from 1000 for 0.25 USD. Don’t forget that you can apply for preferred AdWords API pricing to receive free units.
  • Advertisers who are eligible for free units will receive credit at the rate of 300 units for every 1 USD of AdWords spend, up from 250 for every 1 USD of AdWords spend. They will be credited the holiday bonus based on their spend in previous months


You can view your AdWords API usage in your MCC account, by clicking the AdWords API Center link under the My Account tab.

You can use this as an opportunity to try out and take advantage of the many new features just released in version v201008. As always, we encourage you to use the AdWords API as efficiently as possible.

Happy Holidays,
Jason Shafton, Product Marketing Manager
on behalf of the entire AdWords API Team
URL: http://adwordsapi.blogspot.com/2010/10/enjoy-more-api-units-this-holiday.html

[Gd] First Enterprise OpenSocial “Interop-fest” November 4, 2010

| More

OpenSocial API Blog: First Enterprise OpenSocial “Interop-fest” November 4, 2010

The first Enterprise OpenSocial “interop-fest” will be held Novevmber 4, 2010, at SAP in Palo Alto, CA. This event will consist of enterprise vendors such as Atlassian, Cisco, IBM, Jive, Liferay, and others coming together to “get their hands dirty” proving interoperability of OpenSocial. This will include using the gadgets from different vendors deployed across a variety of containers, inter-gadget communication via the new pub-sub feature in the forthcoming OpenSocial 1.1 spec, and a first pass at leveraging the proposed Enterprise extensions.

The working page for the event is on the OpenSocial wiki and logistics are included in the eventbrite invitation. All are welcome to attend, but please keep in mind that this is a working session and you will be expected to contribute. Space is limited, so please RSVP so our hosts at SAP can get an accurate count. We are working on remote connectivity as well and will post those details on the wiki as they become available.

Thank you in advance to SAP for hosting the event.

Posted by Mark Weitzel, President, OpenSocial Foundation
URL: http://blog.opensocial.org/2010/10/first-enterprise-opensocial-interop.html

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update


Google Chrome 7.0.517.41 has been released to the stable and beta channels for Windows, Mac, and Linux.  Updates from the previous stable release include:

  • Hundreds of bug fixes
  • An updated HTML5 parser
  • File API
  • Directory upload via input tag
More information on these and other changes in Chrome 7 can be found on the Google Chrome blog. Download Chrome today!

Security fixes and rewards:
Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.

  • [48225] [51727] Medium Possible autofill / autocomplete profile spamming. Credit to Google Chrome Security Team (Inferno).
  • [48857] High Crash with forms. Credit to the Chromium development community.
  • [50428] Critical Browser crash with form autofill. Credit to the Chromium development community.
  • [$500] [51680] High Possible URL spoofing on page unload. Credit to kuzzcc; plus independent discovery by Jordi Chancel.
  • [53002] Low Pop-up block bypass. Credit to kuzzcc.
  • [53985] Medium Crash on shutdown with Web Sockets. Credit to the Chromium development community.
  • [Linux only] [54132] Low Bad construction of PATH variable. Credit to Dan Rosenberg, Virtual Security Research.
  • [$500] [54500] High Possible memory corruption with animated GIF. Credit to Simon Schaak.
  • [Linux only] [54794] High Failure to sandbox worker processes on Linux. Credit to Google Chrome Security Team (Chris Evans).
  • [56451] High Stale elements in an element map. Credit to Michal Zalewski of the Google Security Team.
In addition, we would like to credit Aki Helin of OUSPG and kuzzcc for finding bugs during the development cycle such that they never reached a stable build.
URL: http://googlechromereleases.blogspot.com/2010/10/stable-channel-update.html

Tuesday, October 19, 2010

[Gd] Introducing two new ValueTrack parameters

| More

AdWords API Blog: Introducing two new ValueTrack parameters

We just announced two new ValueTrack parameters on the Inside AdWords blog. ValueTrack is a feature that helps you pass dynamic AdWords ad click information in your Destination URL. The new {matchtype} parameter provides you with the matchtype of the keyword for search ads (“b” for broad, “p” for phrase, and “e” for exact). The new {network} parameter gives you information about where the ad appeared (“g” for Google search, “s” for search partners, and “d” for display partners).

To learn more about how to implement all 13 ValueTrack parameters, visit the AdWords Help Center.

-- Jason Shafton, Product Marketing Manager
URL: http://adwordsapi.blogspot.com/2010/10/introducing-two-new-valuetrack.html