Presenters

Christopher Schmitt – Heat Vision

Eric Ellis – Bank of America

Kimberly Blessing – Comcast Interactive Media

Date

Sunday, March 15

Sites

web form elements research

jquery validation

moz monkey

Conversations

Conversations are rooted in trust. Good forms should be structured on trust. Think about people/relationships, and context. The way you speak to your users impacts their excitement/enjoyment. The way you label your forms focused on a label that makes sense to the user not just to you.

Expectation

Apparently expectation is obvious.

Flow

Can a user look at a page in a matter of seconds and understand the pattern of interaction.

[Managed] Noise

Forms that are not initiated or expected; noise is anything that inhibits the user’s ability to complete the task. Marginilization over removal.

Order

Important things (the task) first, then the rest should be add-on. But make sure I have completed something soon.

Progressive Engagement

Lead a user down a path and show them questions only if they are necessary to the context and the type of user you are (if I already know about you, don’t ask me to fill it in again).

HTML5 Form Elements

• Slider
• Input date (calendar) drop-down
• Input time
• Placeholder

Web Form Management

Forms get re-purposed most often. How can you manage all the different form purposes simplistically in a common application pattern library? An editorial style guide for web forms: how do we speak to our customer or about our services?

Pull together the people who care about standards and build a style guide from the ground up.

Validation

Client-side validation doesn’t get it all, and can expose your validation methods to DoS. Split validation between client/server: format v. required. Server-side response for validation errors at top so screen readers see it force.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

Presenters

Molly Holzschlag – Opera Software

David Baron – Mozilla

Hakon Wium Lie – Opera Software

Sylvain Galineau – Microsoft

Date

Sunday, March 15

Sites

david baron

molly holzschalg

Jonathan Snook

Modules: Now

selectors

:nth-child(odd), :nth-child(even)

color

opacity vs. rgba()

borders

border-image, -moz-border-image

rendering properties

-moz-column-count, -moz-column-rule

text-shadow

-moz-box-shadow

-moz-border-radius

word-wrap: break-word

font-size-adjust (specify the font size by the x-height of the characters. e.g., 20px * 0.45)

@font-face (downloadable font specification where you define rules for each font and style): src: url(“font.ttf”)

media queries

@media screen, projection {}

@media print {}

@media (min-width: 22em) { }

@media all and (property) { }

Transformation/Paths

-moz-transform, -webkit-transform

svg clip-path, svg mask, svg filter

Modules: Future

• width: calc(50% – 8px)
• h1 { content: url(decorative.png); }
• new layout systems for user interface?

Internet Explorer + CSS

IE must implement 2.1 completely, correctly, and optimally. IE8/02.27 does.

CSS3 in IE8

The future includes opacity of color, backgrounds, borders, selectors, web fonts, media queries, and multi-column.

Communicate: www-style (at) w3.org

Opera + CSS

CSS3 is ready for demo with backgrounds, borders, fonts, transitions, selectors, media queries, and generated content for paged media. Microsoft needs to adopt TrueType and OpenType.

Printing (Paged Media)

Use HTML and CSS to build PDF documents for printing. Some features: Leaders and auto page-number based on pagination, footnotes, page headers, and page numbers. Yes Software.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

Feedback

When you deal with open standards, you want a single standard to be implemented correctly in a number of different engines/ways because each implementation is taking a different perspective (mobile devices vs. rich devices). Otherwise you have stagnation. Competition on a standards level is a core problem.

Using floats for layouts doesn’t hit the mark. A true layout module is needed. Jonathan Snook. We need layout modules based on other system user interface design history. HTML5 separation of elements may clash with semantic coding.

Accessibility in a portal has always been a challenge. It has to do (initially) with boxes.

Many early portals used quite hideous tables to layout the screen. Hey, a portal is a set of boxes, right? Oracle Portal still enforces a level of table-as-layout. Tables aren’t evil, but as layout devices they make it difficult to control keyboard interaction on a screen. You have to really implement them right to keep them accessible.

But my main problem with tables as a way to arrange a set of boxes is that the boxes (portlets) on a page are not always neat, tabular data in common rows and columns. Tables are for arranging tabular data. That means there are common relationships among the data sets.

A portlet is too complex an interaction to always fit as “tabular data”. The ways I want to navigate a table of numeric data is usually different from the way I want to interact with a portlet or group of portlets. For example, do I have to tab through every portlet (and inside through the inner elements) on the screen in order to get to the one I want (with the keyboard)? Or can I jump through HTML headers like every other well-formed webpage I encounter?

The other problem with tables is styling. Think about how difficult it is to style your own profile at MySpace. Nested tables to the nth degree. Portals are susceptible to this trap as well. Taking a beautiful Photoshop design of a portal interface and then attempting to style unclassed table cells (when tables themselves tend to break certain CSS layout rules–or better yet, when there is inline CSS inside a table definition that you cannot override!) is an exercise in insanity. I mention this because the level of design control I have over my content is usually closely related to the level of accessibility I can ensure in a page.

So the first accessibility challenge for portals is having enough control over the page layout interface to display portlets on a page in a way that is semantic and easy to interact with via a keyboard. The second is having enough freedom to make it look great.