[thelist] survey says...

Keith cache at dowebscentral.com
Sun Dec 29 13:48:01 CST 2002


At 01:27 PM Sunday 12/29/2002, Peter-Paul Kock wrote:

>Well well, this is interesting. I'd have guessed that most people would opt
>for DHTML, too.

I do believe that the preference for the app design is that it does not
detract from the visitor's purpose - to get at the newspaper articles -
whereas the DHTML design is a distraction. This preference on that site may
not translate across to a site selling ladies shoes and bowling balls.

>Can you provide a URL? I'd like to take a look myself.

Wish I could. Schools subscribe to access to the interface which is behind
basic authentication. We had a demo account but took it down and give
schools 30 day free access instead - it's easier to expire that access than
to police the access to the demo account.

>Interesting question. It touches on "what you're used to is what you get"
>(WYUTIWYG?).

LOL! I like the term. But, at one point we were all used to things like
MSDOS, proprietary webs like Compuserv & Prodigy, etc. etc. and we got over
them.

>Generally I think the most succesful interface is the one that most closely
>resembles what users are used to (regardless of whether this interface is
>actually the best you can invent).

Depends on how intuitive the new interface is and how many "familiar"
elements it carries into it's design.

>>But what type interface is out there that doesn't require a user to >learn
>>how to navigate it?
>
>None.

Depends. If you use the page as a changeable workspace instead of a
destination among destinations, navigation on that page doesn't happen. The
question, within that workspace, becomes "learn to use" rather than "learn
to navigate".  The user's question "can I get back here if I chose A
instead of B and find out A didn't go where I thought it would" is
eliminated, if A doesn't do what you thought it would, option B is still
available because you haven't went anywhere. Likewise, from the same canvas
you can do both A and B without wondering if B will be an available option
when you've finished the A task.

>>Can a "Windows app" be bookmarked?  Or searched with a search engine?  >How
>>"easy" it is to navigate becomes worthless if people can't find >your site.
>
>Depends on the site. If I read Keith's concept correctly, the users would
>only need to find the actual application. Maybe they can store their
>preferences through cookies or something, which would help.

Using pages as workspaces would be irrelevant and counter-productive for a
catalog or brochure type site for the reasons sasha cited. But, on sites
that are built around "processes" a workspace design eliminates
navigational concerns. You might not want a search engine to find a page
that's half way through a process and totally out of context, or even let
someone bookmark it.

>Create a W3C-DOM interface that loads the correct XML files and displays
>them (or the portions you want to see) in the way you want to view them.

That's one approach. I'm releasing a site next week that uses a different
concept. This site doesn't look at all like an application, but in many
ways it works like one. For example: people create a Personal Fitness
Center, that gives them their own static html page. From that page, without
ever reloading the page, they can create, manage and use their own exercise
rotation calendar, manage their personal collection of videos to use in
their calendar, maintain an exercise web log, create generic rotation
calendars and publish them so others can see them and import them into
their personal calendars, change their preferences, and chat with other
visitors - all of that without ever leaving the page or even reloading it.
We simply query the server and reflow portions of the page with the
response data by changing the content of divs, or sometimes toggling
display of an iframe between none and inline.  The point is, once you look
at the page as a workspace, as a changeable canvas, opportunities to
eliminate "navigation", and the technologies to do it, abound.


Keith
================
Web: http://contentEditable.com
Email: cache at contentEditable.com




More information about the thelist mailing list