Expo hall – Web 2.0 Expo Berlin

Of all the speakers (among them Tim O’Reilly and Martin Varsavsky) the only panel to note was the one by Leisa Reichelt, “Redesigning drupal.org”.

Drupal.org is the community site of the opensource CMS and social networking software Drupal. The site has 720.000 unique visitors, 300.000 users, 300 new users per day.

The discussion focused on how to redesign the home of such an active, engaged community and, in general, how do we design in an open source way.

Design by and with the community

  • recruiting participation with Google Apps forms
  • openly blogging the process and asking questions
  • engaging with existing community infrastructure
  • crowdsourcing design (wireframes) – eg a flickr group where to put wireframes
  • online card sorting (information architecture)
  • recruit more participation (search.twitter.com)
  • lightweight communication with community via twitter
  • knowledge sharing and empowering – wiki – crowdsourcing usability testing
  • rapid, iterative, rapid prototyiping

Living in the Compute Cloud – Web 2.0 Expo Berlin

Your site can have a lot of traffic, for many different reasons. Apart from that, your site can experience peaks of traffic.

To deal with this you can build your own infrastructures, but today there are other solutions available, such as the ones provided by Amazon and by Google.

Amazon web services

They are several platforms:

  • s3 is used for storage
  • ec2 is an on demand virtual server controlled with web service api (you can use your favourite linux distribution). It provides Acl for port control, you can choose datacenter (currently only in the US), and do a snapshot backup to s3
  • simpledb is a hash-like database that store items with attribute/value pairs. It is meant for small items, organized into domains, redundant and distributed, has no schema, in it everything is a strin, it allows to use list values, you use sql-like queries to retrieve data

Google apps engine

With this solutions you run your application directly on the Google infrastructure. There is no concept of hardware – you just deploy an application. For the moment it’s limited to python and for sure it has not the same flexibility of the Amazon Solutions. As a compensation for not having access to low level sockets you can use memcache, image, email, url fetch, google auth and users. The platform is limiting but takes care of scaling problems.

Bigtable is Google solution for database. It is very similar to simple db (no schema, list values) but also very different (data type support, references and multiple tables, blob files (1mb)). What is very limiting is that results can only last for a couple of second, after that they are killed by the system. On the other hand it is very easy to use. In few words, you have to accept the limitations.

With Google Apps Engine you have no background jobs, no possibility to backup/snapshot data, emails can only be sent from google accounts and it’s restricted to pure-python libraries and given apis

Considerations and usage suggestions

The impression taken from this session is that we need to use a lot of tricks to proficiently use these tools, even Amazon. The speaker illustrated some case such as uploading users data with authentication.

If the application I developed needs extra capacity for an unknown period of time with Amazon ec2 is quite easy to start additional instances. It’s a matter of using a time base systems, such as cron (amazon)

If the need is for something that is load balanced a possible solution is to itegrate ec2 usage with some monitoring tool, such as Monit. With these tools I can monitor if the load is too high and eventually add new instances. Monitoring for these solutions is the hard part to do because there is no ready solution for it

Even if the site has its own infrastructure that works it’s possible, if neededn, add extra capacity connecting to ec2, so to combine the best of both worlds. However ec2 is not available in Europe at the moment and so there could be latency problems.

Real life use cases of these platforms:

  • googbad.me
  • dawanda.com
  • g.ho.st

Final thoughts

  • get accustomed to eventual consistency (not sure that queries of few milliseonds are updated in all instances)
  • be prepared to leave relational database
  • many miss strong SLAs – most of the time u can live fine without
  • hardware is a commodity – only specialize in it if it really necessary
Jonathan Weiss
A Ruby consultant and partner at Peritor Wissensmanagement GmbH in Berlin, Germany. For the last years he has been developing and consulting large Ruby on Rails projects where he focused on Scalability and Security. He is an active member of the Ruby and Rails community and is the developer of the Open Source deployment tool Webistrano. In his spare time he maintains Rubygems and Rails in the FreeBSD Ports system.

Checking the “Feel” of Your UI with an Interaction Audit – Web 2.0 Expo Berlin

The author presented the process that in Ebay leads to interaction audit. But, first of all, what is “feel” and why should i matter?

It’s the feel in look and feel, while many times we just consider the look of the interface. The feel can be considered how you operate the user interface with your own hands.

Feel affects:

  • learning curve
  • mental bandwiith needed to operate the user interface
  • user success (or errors)
  • site personality
  • brand promise
  • adoption (or abandonment)

While developing the Ebay interaction audit the team created a flash demo of the different pages and sections of the Ebay sites. What is interesting to note is that by playing this series of screenshots a little fast it’s possible to highlight several inconsistencies, especially in the structure (eg. headers, logos of different size and in different positions). Creating this sort of animations is very valuable but it’s not expensible or complex to do. They use such animation as a sort of benchmark.

Developing an interaction audit was not like following a strict blueprint. It happened that, based on new findings, they noticed how to improve the process.

Project phases

  • strategy
  • data collection
  • analisisy
  • recommentdations

Strategy

Improvement of user experience on ebay: they made a compelling artifact. They wanted to collect data around the flows. So they imagined flows based on their user behaviour, such as “new users finds an item, bids for it, register as a member”, “new seller lists item for sale, create sellers account”.

They eventually put all on a spreadsheet to see with tasks were common to several flows

Data collection

They used a simple db (filemaker pro). They also captured graphical data.

Database fields used:

  • task and subtask
  • step description
  • page and url
  • action (syntacrtic)
  • screen shot close up
  • instructional text
  • click/keystroke record

Analysis

They printed each record (flows as storyboards) so they could made comparisons. It was like storyboarding in the comics industry.

Ideas for presenting the findings

  • Radial charts to track feel metrics
  • Emotional flow to track feel effects

Recommendations

Here is a list of some of the analysis results

Affordance: a visual cue that some interaction is offered
Affordance inconsistencies
: inconsistencies: hyperlink, tab

Task: a path to accomplish an immediate goal
Task Inconsistencies: a simple goal is accomplished via multiple path: filtering data, enable/disable section of a form

Data objects: a representation of a data record or other piece of data
Data objects inconsistencies
: a single data tye object representede multiple ways: ebay member

Interaction audit goals:

  • low learning curves
  • consistent clues for actions
  • predictable behavior of affordances
  • instant recognition of interface elements
  • allow ebay member content to shine

After being presented the results, the design team was divided in several group (clean-up teams) based on the inconsistencies found:

  • The clickers: links and buttons
  • The swappers : tabbs and toggles
  • the submitters: forms
  • shufflers: sorting
  • disclosers

They work of “cleaning-up” ended creating reusable components thanks to patterns

Clean-up process

  • find problem area
  • recommend simpler set of interactions
  • document design patterns

Feel metrics

objective: page dimension, number of elements, density….
semi-objective: number of syntactic actions, reloadiness, number of tools switches (keyboard, mouse), popup,
subjective: number of different interaction styles, simplicity, flatness, cognitive load

What we’ve learned:

  • it’s important to check feel
  • an interaction audit can be compelling, actionable and part of a real environment
  • audit should focus on flows and be representative of real experience
  • simple tools work
  • audit for inconsistencies in afforfance, task, and data object
  • clena up objects
  • harder problems require site specific values