Google I/O – Design Sessions

Posted by Martin

I had the chance to attend two interesting and complementary sessions on design during the Google I/O 13 conference. During the Get Unstuck: Gamestorming Not Brainstormingsession the audience had a chance to play two brainstorming game. I will not go into detailed descroption of those games, for those curious or interested I recommend the session cheat sheet and gogamestorm.com.

However one interesting statement has been made at the beginning of the session:

Design is following the same path as quality within IT product development team.

It is now part of everyone job, and not only the responsibility of a group of specialist,

and should be in taken into account in every stage of the product development. 

The Cognitive Science and Design session has been very intense in terms of information delivery. Tons of excellent advice  No break through tricks or process have been presented during this session, only a solid list of things to keep in mind while designing your next screen.

Alex Faaborg and reminds the audience about the risk of design blindness, as

  • you are not right person or team to judge your design, and
  • once you launched something it is really hard to go back or do radical changes on it, since
  • a user make up his first opinion (trust, reliability, purchase) on a product based on its design, and it take times to change his mind for an other product / solution – first appearance / interaction has to be solid.
Then the session break down under four mains topics:

1. Gestalt laws of grouping:

  • to get a cleaner interface use white space to group your element instead of hard bar or delimiters
  • if you cannot use white space, vary shapes to group items (using icones or colors background)
  • user will complete half drown boxes and shape (law of closure), no need to over charge your design with closed box, you can just suggest them

2. User’s vision:

  • easier to catch the user attention with things happening in the periphery of the screen than in the center of it.
  • we recognize silhouette faster than the real object (good to keep in mind for icon design) as user don’t have to break down the structure and recognize.
  • among a large number of information, we recognized known faces quickly (use avatar in interface) – on your Facebook timeline your recognizable your friend face and you don’t read their name.

3. Color usage:

  • pay attention to color meaning in different culturs
  • user filter color based information faster than text based.
4. User memory and attention span
  • be careful when you interrupt users in their tasks as it trash their working memory and you will get them out of the flow (and drop a registration or check out process for example)
  • split your task in small chuck to limit the usage of memory and increase the process speed (for example split credit card information in 4 digits group)
  • don’t hesitate to innovate new interface and teach your user how to use it instead or repeating the same interface or process over and over.

Google I/O – Responsive Design

Posted by Martin

This post will cover the two sessions I attended on responsive design and HTML5 / CSS3 features for cross platform development.

The Point, Click, Tap, Touch session presented touchevent events (touchstart, touchmove, touchend, touchcancel) for tactile devices and how they differ with mouse events when selecting or dragging an element. The touchevent API is supported by all major browsers. Google released a mobile emulation tools for developers to emulate touchevent, viewport and other mobile device specific functionality.

For cross device development the main recommendations was to

  1. Design bigger targets and button to take into account touch screen device (phone, tablet and now touch screen laptop)  or to enlarge your button when you detect a touch event on the page.
  2. Stop using hover events as on a touch screen device a single tap both activate the hover event and the link event in the same time, the link event “over riding” the hover one.

Coming back from the conference and testing the pixel chromebook (a touch screen laptop) on Netflix has been a great experience on what NOT to do. On Netflix when you hover over the cover of a movie a short synopsis and link to related items are displayed, while a click will start the movie. Not being able to see description of the item totally killed my user experience and forced me to get back to my mouse.

An other consideration to keep in mind with the new touch screen laptop is to not disable the mouse if a touch is detected (I’m glad Netflix haven’t done that!) and have your page to listen to both mouse and touch event. You can use event.preventdefault() to manage exceptions.

The second the session, a more awsome web, introduced more experimental features currently supported by a limited amount of browser. Nevertheless, some of them are promising when widely supported and I noticed the following interesting features:

  • Using the css @-viewport feature you can define size of your page elements, image and font based on the screen resolution of the device, which is perfect for a responsive design page.
  • The introduction of CSS variables using -var- (only in beta in chrome for now) will help for sure front end developers.
  • The position sticky to manage sticky element that roll or disappear based on certain conditions (for example keep an header at the top of the screen or replacing H2 elements when scrolling down) and css clip-path let you crop and clip any image based on certain conditions looks promising to develop nice and fun web application.
  • The clip-path option will also help for responsive design when combine with the viewport feature.
  • The web audio and speech api (only in chrome) let you to records and transform sounds directly in the user browser, so you can offer google voice / siri like features to control your application.

Watch the presentation for the full list of feature introduced (or check the presentation)

In the meanwhile you can go on chromestatus.com to see which browser support which features and use the CSS supports to test if the browser support a specific feature and return true and false statement so you can defined fall back event accordingly.