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

The semantic web connects literal semantics with intent/knowledge. The idea is to build systems that can understand user requests with natural language and connect people to the “rest of the stuff”.

“For the first time, computers are starting to ‘understand’ what people are asking them to do… and the context surrounding the information” … in a super-literal / abstracted way. How do you use the entire breadth of knowledge, data, and facts to solve people’s problems?

What’s next

Presentation Engine – Google does a great job of understanding what I’m asking, but the presentation of the answers (long list) is not optimal. Aggregation and post-processing search results to make the results more useful to humans. Exact/pure answers with option to dig deeper. The result presentation should match the question/circumstance/context.

Command Engine – It’s no longer about information retrieval with a universal search box. The computer should understand what you are trying to do. Search is one type of command, what are other kinds of commands you can ask “the web” to do? Fully complete the task. Guide me through the contextual tasks. Relative task completion/guidance and get to know me (social networks the key to getting to know me?). Databases with APIs are starting to work together to let this happen.

Discovery Engine – Less searching and more proactive push of relevant information. This requires the ability to extract entities from data.

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.

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.