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


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


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


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

RIA and Ajax Security Workshop – Web 2.0 Expo Berlin

A very interesting and informative talk dealing with the new types of attacks that affect web 2.0 applications and RIA in particular.

The session was divided in 2 parts, the first about AJAX and the last about Rich Internet Applications.

The slides of this talk are available on slideshare and are impressive for their completeness. Not only they provide detailed examples for every case illustrated, but they link to a series of articles and web resources.

The main problem of this talk is that it’s quite impossible to be able to be specific enough and, at the same time, don’t get too much into details. This resulted in some hard-to-understand parts.


In general attacking an AJAX application is more difficult compared to a web 1.0 site. But on the other hand is more difficult to protect an AJAX application because there are more ways to exploit it and new ways are discovered every day.

  • Not all “web 2.0” sites use new technologies (such as Youtube and MySpace)
  • A single page in Myspace has a lots of includes.
  • Also Google Maps has a lot of includes, but ofJavascript code. Google code can be potentially insecure

Why care about web 2.0 security

  • People changed how they interact with web sites (they erase privacy barriers and they don’t feel the distance. The are the new generations)
  • Technologies spread from innovators to traditionalists (today AJAX in financial institutions, health care, government) – mainstream
  • Bugs are affecting people now

Discovery and method manipulation

  • Playing with parameters is still an excellent web attack (asking application to do the work for you). As business logic gets more complex, so do parameters vulnerabilities
  • Figuring out web apps is tough part of pen-test

Two types of Ajax apps

  • client-server proxy (equivalent to SOAP, client hides javascript)
  • client-side rendering (we can see the javascript and know what it does)

Cross Site Scripting

  • Downstream communication methods are much more complicated
  • User controlled data might be contained in arguments in dynamically created javascript, contained in Javascript arrays, etc. As a result, attack and defence is more difficult

Four bugs

  • downstream JS Arrays. Dangerous characters
  • XSS payload can be tucked into many places
  • XSS might already be in the dom (document.url, document.location, document.referer).
  • AJAX uses “backend” requests never expected to be seen directly in browser


Is ill-defined. Many contain many terms, AJAX, Flash, offline mode, decoupling from the browser. There is a huge disparity in features and security design.

Why use RIA

  • to increase responsiveness
  • desktop integration
  • to write full desktop apps

RIA Frameworks

No one framework is without limits and security problems. The worst seems Adobe Air because it shows all the limits of the very old ActiveX model.

The frameworks:

  • Adobe AIR
  • Microsoft Silverlight
  • Google Gears
  • Mozilla Prism

Adobe Air

  • Full-featured
  • Cross-browser, cross-platform
  • Created with Flex, Flash
  • Can be invoked by browser with arguments, like ActiveX or Flash
  • Air is best thought as ActiveX than Flash ++ (code runs with full privileges and can install malware)
  • SWF files can import functionalities that allows them to interact with AIR applications
  • SWF files can check install status and version
  • By default, code included in AIR application has full rights
  • There is not a “code access security” model such as in Java or .Net
  • AIR has many ways of loading executable content to run, such as HTML/JS and SWF
  • AIR applications can be bundled as binaries
  • Problems: allowing users to install signed applets is dangerous. Allowing self-signed is terrifying
  • Some suggestions to adobe: change default action, disable unsigned install prompts


Lot of sensibility toward security

  • Is the Microsoft Flash equivalent
  • Cross browser and cross platform
  • Subnet of the .NET frameworks
  • The security model is based on .NET
  • Calling system primitives the system will fail. You need to isolate it
  • What could go wrong (threading, DoS attacks against local system)

Google Gears

  • Has SQLite embedded
  • Uses an homegrown API for synchronizing data
  • Has a LocalServer
  • Works offline via SQL database, local assets and a local app server
  • Uses some origin to restrict access to site databases and LocalServer resource capture
  • Provides for parametrized SQL
  • Unfortunately they allows personalization of opt-in screen

Yahoo! Browserplus

  • A very bad idea
  • Runs as a browser plugin, with a separate helper process
  • It’s very similar to ActiveX concepts
  • Use old version or Ruby. Perfectly safe as long as you don’t use strings and arrays

Mozilla Prism

  • Wraps webapps to appears as desktop apps
  • Standalone browser instance
  • Problem: the Javascript included with webapps has full XPCOM privileges (but no content scripting privileges)
  • Problem: the sandbox isn’t real


HTML introduces some new concepts related to storage of informations.

  • Introduces DOM storage (sessionStorage, localStorage, database storage)
  • The major goals are more storage space and real persistence, because cookies are considered too small and users delete cookies or won’t accept them
  • This method bypasses pesky users, that however can use a specific about:config directive

Browser based SQL Databases

  • Injection becomes far more damaging (because of lot of privileges)


  • prevent predictability named data stores
  • parametrize sql statements


  • RIA frameworks widely vary in their security models
  • It is highly likely that web developers will introduce interesting flaws into their desktop applications
Alex Stamos is a Founding Partner of iSEC Partners, Inc, a strategic digital security organization. Alex is an experienced security engineer and consultant specializing in application security and securing large infrastructures, and has taught multiple classes in network and application security. He is a leading researcher in the field of web application and web services security and has been a featured speaker at top industry conferences such as Black Hat, CanSecWest, DefCon, SyScan, Microsoft BlueHat and OWASP App Sec. He is a contributing author of “Hacking Exposed: Web 2.0” and holds a BSEE from the University of California, Berkeley.
RIA And AJAX Security Workshop, Part 1

View SlideShare presentation or Upload your own. (tags: 2.0 web)

Collaboration Techniques that Really Work – Web 2.0 Expo Berlin

Leisa Reichet in her workshop (of which i lost the first 30 minutes) talked about ways to improve productivity while planning a new web experience.

Nothing new, but it was a good idea splitting the attendands in several group and ask them to work together.

Even if the workshop lasted for 3 hours, however, many arguments where just drafted.

Some notes taken while not brainstorming with my group:

  • build collaboration into your project methodology – collaborate with your project team
  • collaborate with your peers (people who do the same thing as you) and invite other expert perspectives
  • consider wildcard collaborators (not necessarily part of ur team) that has other perspectives

When to collaborate

  • at the beginning
  • not just at the beginning
  • when you’re stuck (trouble shooting / problem solving) – narrow focus

Collaboration tools

  • people (the right ones)
  • sticky notes & market pens
  • whiteboards/flip charts
  • fun stuff (stimulus)
  • sugar (if it’s afternoon)
  • an objective
  • tecniques
Leisa ReicheltLeisa Reichelt
Freelance user experience consultant specialising in collaborative and guerilla user centred design and with a particular interest in designing for (and with!) communities.