-goals of the Chrome project: stability, performance, and easier web development

Stability
- goal was to build a stable/reliable browser for use with web apps
- browser crash with web apps is more catastrophic
- browser crash should become comparable to BSOD in rarity
- multiprocess: one browser process + rendering processes for each tab and plugin
- everything within a tab is contained to that tab
- plugins have their own processes & are isolated
- really takes advantage of multi-core machines
- chrome has its own task manager where you can kill the individual processes
- no direct JavaScript access to multi-process capabilities *(Bri’s opinion: thank God)
- the Browser Process: network requests, cookies, browser UI (tabs, address bar, etc.)
- basically no third-party code allowed here, for increased stability & security

Performance
- “browsers are holding back the performance of web applications”
- startup time improved
- memory usage: each process uses a minimum amount, but smartly allocated among processes
- does DNS pre-fetching

Page Rendering
- modified version of WebKit
- WebCore (HTML/CSS)
- JavaScriptCore was replaced by V8 engine written by GOOG from scratch
- engine partly written in JavaScript itself

Enabling Web Development
- didn’t want to introduce yet another rendering engine
- some differences from Safari:
- uses Windows-style text rendering and form controls
- no @font-face, no HTML5 storage
- bugs Please file them! “Want to fix bugs before you have to hack around them.”
- dev build at dev.chromium.org/getting-involved/dev-channel
- hacking around: navigator.userAgent.match(/WebKit | Chrome | Safari/);
- Developer tools:
- V8 debugger (currently text-based, GUI is coming)
- WebKit Web Inspector (check it out in the WebKit nightly builds)
- put in a thing to kill infinite alerts (”don’t generate additional alerts”) *(Bri says: yay!)

What’s Next
- Mac and Linux ports “pretty far along”
- raytracing, cryptography, etc. in the browser; web apps as first-class citizens
- more stability, better performance, more improvements to web development

Open source project home: http://code.google.com/chromium

(Note: This ended up being more of a “design basics for non-designers” type of talk, rather than a talk aimed toward designers.)

Opening Thoughts
“We learn to describe the things we see, but we also see the things we describe.” - David Womack
As developers, we can tell often good from bad design but have a hard time articulating why, especially in visual design. (Bri’s opinion: This is true.)

“Is design the new black?” (aka it’s everywhere, but often used in a really vague way)
Fields of design: visual, interaction, information, service

What a “good” design is depends on the perspective of the user. “Good for whom?”
Have to know who your users are, and design for all of them. Prioritize users.

He used that layer diagram from Jesse James Garrett that we’ve all seen a million times.

Strategy
- what the heck are we doing?
- find the overlap between user needs and company/developers’ goals.
- know your stakeholders & site objectives
- traditional demographic methods (demographic profiles) don’t really give too much help in designing web apps
- Have to talk to/observe users
- Write a mission for your site or app that is not too general and not too specific

Scope
- what features go in
- don’t try to be everything to everyone
- avoid an algorithmic or voting-based approach to feature selection; have to select initial features as a coherent set that makes sense together, in context
- old model: first the cake, then the filling, then the icing
- new model: start with a cupcake, grow into a birthday cake, evolve into a wedding cake
- providing an API allows you to draw upon the efforts of passionate users

Structure
- how the pieces fit together; interaction design and information architecture
- interaction model needs to be consistent throughout the site; think modular/reusable when thinking about interactions
- have navigation elements at a consistent level of granularity
- use the language of the customer, not internal language
- use labels consistently across the site

Skeleton
- discoverability: make finding things easy
- use non-intrusive invitations to access more information
- provide helpful, contextual information based on what the user does
- recoverability: make actions without cost
- don’t lose any information upon errors
- provide error notification as quickly as possible, and clearly associated with the site of the error
- provide ability go back or change options without having to redo things that remain the same (live filters, etc.)
- prevent errors when possible by helping the user with just-in-time, contextual information (autocompletes, live password checkers, etc.)
- context: use time, place, and actions to add meaning
- tell users where they are in a process
- help them see where they came from and where they can go next
- feedback: let users know you saw what they did
- don’t include extraneous information in feedback (internal error numbers, etc.)
- keep feedback minimal, “just enough”
- use added item indicators, progress indicators
- ajax allows action at a distance (parts of the page affecting each other), but be careful with it
- make sure that updated areas are going to be visible to the user (could they scroll down and not see it? etc.)
- “not-suck-ability”
- many little annoyances are worse than one big annoyance
- minor annoyances that the user interacts with a lot can kill the user experience

Surface
- design is not just cosmetic, but visual design is also important
- attractiveness bias exists, might as well take advantage of it for your web app
- first impressons are important! people make a judgment in 1/20th of a second
- What is the personality of your site? How can the design/content of the site reflect that?
- recommends on visual design: “The Non-Designer’s Design Book”
- CRAP: contrast, repetition, alignment, proximity

A note on documentation:
- wireframes used to work really well for conveying layout
- what about when a page can have 27 different states?
- dev/des have to work more closely together
- some options:
- storyboards
- frame-by-frames
- wireframes with key frames of the interaction
- D.V. recommends “something more like a prototype”
- lo-fi animations (basic Flash, etc.)
- working prototype on which designers and developers are acting closely together

Prototype flavors:
- HTML/CSS/JavaScript with no backend
- working frontend drawing on xml/json instead of a “real” backend
- functional backend with a non-production backend language/architecture (e.g. Rails)

Have to work with the team that you have - what works best to increase/enable communication?

(Note: I thought that this session was going to be about the technique of progressive enhancement, or designing ajax sites that will still work with a reduced feature set when the user has javascript disabled. Turns out, not so much, it was more of a general intro to jQuery from a designer’s perspective.)

Philosophy of jQuery:
- unobtrusive javascript
- write less, do more
- basic model: select elements, interact with them

Interjection — Bri’s opinion:
* YUI is weaker on the select elements part, as well as the “write less” idea
* YAHOO.util.Dom.getElementsByClassName(”blue”)
* or, $(’.blue’)
* 46 characters, vs. 10 characters
* one of jQuery’s biggest strengths is its selector model which is both intuitive and expressive
* other strength: plugins!

Syntax stuff
- CSS selectors: same as in CSS, just wrapped in a $('’) (such as, $(’div.blue’) or things like that)
- form selectors: $(’:input’), $(’:button’), etc.
- custom selectors: $(’:visible’), etc
- traversal methods to move up, sideways, down, filter in various ways
- implicit iteration when doing operations on selector results ($(’li’).something() does for all li elements)
- methods to find width, heght, scrollpos, offsets
- event handling: .bind(), .unbind(), .trigger()
- built-in effects like slideIn, slideOut, fade, animate
* see documentation for more on all of these things

Tipz
- tip: store selectors in variables when used more than once
- tip: use length of selector to check for existence when necessary
- naming convention: use $variable when assigning a jQuery object
- tip: have to use string concatenation to pass in values within the $('’)
- tip: clone() is better for performance than creating new nodes from scratch, when adding lots and lots of new elements

* opinion: jQuery is pretty okay

* Then I thought we were going to get to progressive enhancement. He started showing a code example of a To Do list that he built using jQuery, which sort of used progressive enhancement in some ways, but not really. The end.

- fastest growing and most popular framework according to Google trends
- by far the most popular (68%) among “designers who use a js library”(as opposed to developers) according to Ajaxian survey
- also the most popular among developers, but by a lesser margin
- 3 releases within the past year
- 1.2.2: new Event API for plugins, mouseenter, mouseleave, ready, and mousewheel events; $(DOMElement) 300% faster
- 1.2.3: new methods: .data(), removeData()
- 1.2.6: performance improvements (event handling, css selectors, offset(), css(), dimensions plugin made part of core
- jQuery 1.3: “all about performance” - new selector engine, 10x faster DOM manipulation, no more browser sniffing in jQuery core (out this fall)
- jQuery UI 1.5: improved code quality, faster, bug fixes
- Nokia integrating jQuery into WebKit phone browser on all new Nokia phones
- Microsoft making jQuery part of dev platform, integration with Visual Studio
- instead of browser sniffing based on user-agent string, using a features-testing model which does some DOM operations and tests the results to determine what browser quirks and bugs are present

I find myself in Boston this week, attending the Ajax Experience conference. I’m very excited about some of the sessions, and I plan on posting up my notes for each session as soon as it happens.

Tomorrow I’m probably going to be splitting my time between the tutorials track and the jQuery track — some of the tutorials track is too basic, and some of the jQuery track is not of interest (like code reviews), so I’m going to do my best to jump back and forth and catch some interesting bits of each. There’s a session on designing for/around ajax that I’ll be sure to catch, on behalf of my design coworkers.

Stay tuned for more.

Lately I’ve been doing a bit of hacking with Processing. Today I made this interesting image generator, which uses Perlin noise to generate random, symmetrical images. It’s a bit like Rorshach blots in motion, I think. And if you stare at it long enough (not that I’ve been doing that *cough*), you’re bound to see at least some nice patterns come up.

Check it out.

I’ve been increasingly interested in procedural art lately, and I hope to do more experiments along these lines.

---

I guess I haven’t been feeling too writative lately. I’m not sure when that’s going to change, to be honest, so this blog will continue to be updated very infrequently for the time being.

Go Cornell!

I guess some kids (ok, PhD students and CS profs) in Upson Hall are working on this distributed system for searching .torrents.

Cubit creates alongside BitTorrent a lightweight peer-to-peer network designed from the ground up to enable rapid and accurate approximate searches. It performs the searches without relying on any centralized components, and therefore is immune to legal and technical attacks targeting torrent aggregators.

Of course, as several Slashdot commentators mentioned, this doesn’t solve the problem of file spam, things with misleading labels, etc. For that, you require some measure of trust in the file source. But that’s a different, and rather more difficult, problem.

For my first Flash assignment at work, a designer asked me if I could work up a version of the OS X Dashboard Widget effect, where the widget rotates in 3D around the y-axis, to reveal a set of controls or additional information on the “back”. The project turned out to be more difficult than I originally thought, especially since I wanted to make it easily reusable and customizable. But hey, what better way to learn?

Since I haven’t figured out yet how to embed Flash objects in WordPress (any tips? Please?), you can go here to check out my example. Just click on the little “i” icon to see it rotate.

http://www.bri-lance.net/Flash/WidgetFlip.html

An extremely large portion of this code, probably about 80%, was taken from this tutorial by Barbara Kaskosz at the wonderful website FlashandMath.com. So lots of credit goes to them.

I basically adapted their code, which works with bitmaps, to handle any group of Flash objects. At “spin time”, it copies those objects into a Bitmap, slices up the bitmap into 1-px wide vertical slices, and distorts those slices according to some neat equations that I got from their site. (This is necessary because you can’t do a free distort on Flash objects with ActionScript alone.)

I’m throwing out the code in hopes that it might be useful, or at least interesting, to someone else.
The ActionScript file can be found at http://www.bri-lance.net/Flash/WidgetFlip.as,
and the .fla that I used can be found at http://www.bri-lance.net/Flash/WidgetFlip.fla. Every line in the ActionScript that you might need to change to customize the file for your own use is marked with a comment beginning with //CHANGE, that explains what the line does and how you can customize it.

Some ideas for usage:

1) Display data on the front, configuration or customization controls on the back (this is what my example shows)
2) Charts and graphical data on the front, tabular data on the back
3) Summary information on the front, more in-depth information on the back
4) Two disparate views of the same data

Enjoy! (I know I am.)

Long time no post. I’ll explain why, soon.

In the meantime, I’ve been occupying myself by, among other things, learning how to program ActionScript3. (I’ve been using this excellent book as a reference.)

I used to implement Checkers whenever I was trying to learn a new GUI language, but I got bored with it. The new Checkers? Conway’s Game of Life.

Check it out! Click the mouse and move it around to “draw” a starting pattern. Then release the mouse button and watch it mutate.

Go to the Flash page.

This is another “what-if” type of post.

Monitors, in general, are getting bigger, and screen resolution is getting higher. (For example, the monitor I’m writing this on right now is 1920×1200 pixels.) The 800×600 screen is largely a thing of the past, relegated to technophobes and poor school districts — the rest of us seem to have readily moved on.

If monitors keep getting bigger, what new design challenges might that bring? Instead of struggling to cram too much functionality into too little space, might interface designers start facing the opposite problem, of being able to expose all of the functionality when maybe they shouldn’t? I could imagine it becoming a larger effort to direct and manage the user’s attention appropriately.

Let’s take an extreme example. What if monitors that were 3 feet diagonal became commonplace?

I’m willing to bet that full screen mode would become something very different. Even on my 24-inch monitor, I almost never use an application full-screen; it becomes too big of an area to look at. If I expand a website, it becomes hard to read. Instead, I use the extra space to layer auxiliary programs and windows (iTunes, AIM, the Dock, tool palettes, etc.) so that they are available without any extra effort.

I could imagine a program that really needs your focus having to dim or blank out other parts of the screen. Would full screen mode then mean that only part of the monitor gets used, only as much as we can take in at one glance?

Or maybe single screens start taking on some of the capabilities that multiple monitors have now. Maybe you get the ability to define different areas of the screen and assign different programs to them, the way people have email on one screen and do work in the other. So the monitor stops being a unified space and starts to become a segmented group of areas - like multiple desktops on Linux, but simultaneously present.

Of course, that gets into a whole different windowing system. Could you expand and collapse different spaces? How would you arrange them?

Alright, my brain’s starting to hurt. And even with all that, I still wonder about the effect on people’s attention. In order to combat information overload, I’ll bet programs will have to find a way to say, “Pay attention to me, and not anything else,” when the users need them to. In fact, that could become the biggest challenge of all.