beyond algorithms: search and the semantic web

Future of search from the perspective of semantics. Using the data on the web began with search (literal match), evolved to specific/contextual answers to specific questions, and could move on to asking the web to do something for you more than just answer questions.

Should we drop the term “Semantic Web” and replace it with “Computable Web”?

[ session description ]

Presenter(s)
(lots)
Date
14 March 2010
Tag(s)
#beyondalgorithms

Continue Reading »

designing our way through web forms

Forms suck. Creating a style guide for form design is difficult.

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

Continue Reading »

tables don’t kill people, they just kill accessibility.

At least, tables (can) kill accessibility in web portals.

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.