Showing posts with label ajax. Show all posts
Showing posts with label ajax. Show all posts
06 October 2006
"Visit forum for site-feature"
google groups
and gmail
have yet to match
the 20+ year old conventions
of usenet-era email
for interleaving comments
with the '>' quoted text
being commented upon
gmail uses ajax
to hide the quotes
evidently presuming
most quotes are included
only accidentally
and so punishing
sophisticated writers
with unsophisticated readers
but how tortuous it is
to try to send them feedback
so it would be
super-classy
in a web2.0 way
(or better: web n+1)
if a rightclick on gmail's
'show quoted text' link
offered a popup menu that included
'visit forum for site-feature'
where you could read
others' comments on (eg)
this gmail design-feature
and add critiques of your own
and gmail
have yet to match
the 20+ year old conventions
of usenet-era email
for interleaving comments
with the '>' quoted text
being commented upon
gmail uses ajax
to hide the quotes
evidently presuming
most quotes are included
only accidentally
and so punishing
sophisticated writers
with unsophisticated readers
but how tortuous it is
to try to send them feedback
so it would be
super-classy
in a web2.0 way
(or better: web n+1)
if a rightclick on gmail's
'show quoted text' link
offered a popup menu that included
'visit forum for site-feature'
where you could read
others' comments on (eg)
this gmail design-feature
and add critiques of your own
29 August 2006
No-Ajax is better than Ajax
rebooting my machine
to kill off some runaway
Firefox javascript
reminds me
that no-ajax is better than ajax
to kill off some runaway
Firefox javascript
reminds me
that no-ajax is better than ajax
16 November 2005
The Ajax factor
when digital computers were a novelty
way back in the Fifties and Sixties
nobody could guess
what they'd be best at
so every human task
that taxed our patience
was auditioned as a programming project
and many flunked that audition
often, with the words
"this is more work
than the old way"
while a favored few
were accepted
with greater or lesser enthusiasm
as simplifying that task
(those tasks)
and as the power of computers
metastasized
new toolkits were gradually innovated
some new tasks were mastered
and some old tasks were streamlined
but this process of streamlining
has always been
more about inspired design
than gigabytes or megapixels or gigahertz
and most of our current tasks
in most of our current apps
still badly need replacement, as
"the old way"
when microsoft debuted dhtml in 1997
it wafted the stench of
bain de billg
but mozilla felt compelled to support it
and when the inspired designers
of google maps
(just this year)
showed what it can do
there was a collective epiphany
and, rechristened "Ajax"
it entered the collective imagination
as a new toolkit
for simplification
alas
it's easier to program
than to discover inspired design
and most ajax demos
simplify nothing
so to remind us
what the goal is:
we have tasks
that computers can assist
but this assistance requires
user actions
and these actions require
user decisionmaking
so the goal is
to simplify the actions
and the decisionmaking
for example
i maintain a flash mp3 blog
that streams my playlist like a radio station
and just as i reread
several times a day
the latest posts to my linkblog
so i try to listen
once a day (or more)
to my latest mp3-links
and during this listeningtime
certain tasks predictably recur:
i might want song or artist info
i might want host-site info
i might want to edit the playlist
or annotate the accompanying webpage
etc etc etc
so the challenge to future
inspired designers
is simply to simplify
my path to each of these
way back in the Fifties and Sixties
nobody could guess
what they'd be best at
so every human task
that taxed our patience
was auditioned as a programming project
and many flunked that audition
often, with the words
"this is more work
than the old way"
while a favored few
were accepted
with greater or lesser enthusiasm
as simplifying that task
(those tasks)
and as the power of computers
metastasized
new toolkits were gradually innovated
some new tasks were mastered
and some old tasks were streamlined
but this process of streamlining
has always been
more about inspired design
than gigabytes or megapixels or gigahertz
and most of our current tasks
in most of our current apps
still badly need replacement, as
"the old way"
when microsoft debuted dhtml in 1997
it wafted the stench of
bain de billg
but mozilla felt compelled to support it
and when the inspired designers
of google maps
(just this year)
showed what it can do
there was a collective epiphany
and, rechristened "Ajax"
it entered the collective imagination
as a new toolkit
for simplification
alas
it's easier to program
than to discover inspired design
and most ajax demos
simplify nothing
so to remind us
what the goal is:
we have tasks
that computers can assist
but this assistance requires
user actions
and these actions require
user decisionmaking
so the goal is
to simplify the actions
and the decisionmaking
for example
i maintain a flash mp3 blog
that streams my playlist like a radio station
and just as i reread
several times a day
the latest posts to my linkblog
so i try to listen
once a day (or more)
to my latest mp3-links
and during this listeningtime
certain tasks predictably recur:
i might want song or artist info
i might want host-site info
i might want to edit the playlist
or annotate the accompanying webpage
etc etc etc
so the challenge to future
inspired designers
is simply to simplify
my path to each of these
21 October 2005
Cnet's ontology browser
A couple of weeks back Cnet debuted a Flash ontology-browser (called "The Big Picture") that occupies a big chunk of the righthand sidebar with some/most/all articles.
I've been meaning to look closer at it, and this random link about how the brain represents habits seemed like a convenient moment... because the ontology-connections are especially bizarre.
It's easier if you jump directly to the fullpane view of the browser (identical url with "?tag=st.bp" at the end, where bp = big picture).
The story-author (or an editor) is supposed to tag each story with topical keywords (green bubbles) and mentioned-companies (red bubbles), but this story doesn't actually have either of these-- the three green and one red bubble you see here are linked via other 'similar' stories (grey bubbles), though you have to look closely to figure this out.
The author/editor has directly specified three 'similar' stories, which can be traced on the browser by following the grey lines from the central story-bubble:
These three similar-story links are appropriate and useful, and as a basic rule of web-design all web-articles should probably offer such a short set at the end, because many readers will at that point be ready to explore. I think Cnet was already doing that in text form, maybe in a sidebar though (which is less effective).
Someone should have added "MIT" as a red-bubble link-- I expect this will become more routine. It needs at least one green bubble for "Neuroscience".
The supposed rationale for using graphics instead of just text is that similar items can be visually clustered, but this isn't what's happening here-- the most similar stories are getting buried in random linkage.
Whenever I see a floating-bubbles interface (and I'm ashamed to say I even programmed an early one, back in 1990), I think of a bad stage magician waving his hands to distract you while he picks your pocket.
Cnet's readers would be much better served if this info was offered in text-outline form, maybe with fast Ajax browsing.
I've been meaning to look closer at it, and this random link about how the brain represents habits seemed like a convenient moment... because the ontology-connections are especially bizarre.
It's easier if you jump directly to the fullpane view of the browser (identical url with "?tag=st.bp" at the end, where bp = big picture).
The story-author (or an editor) is supposed to tag each story with topical keywords (green bubbles) and mentioned-companies (red bubbles), but this story doesn't actually have either of these-- the three green and one red bubble you see here are linked via other 'similar' stories (grey bubbles), though you have to look closely to figure this out.
The author/editor has directly specified three 'similar' stories, which can be traced on the browser by following the grey lines from the central story-bubble:
- One goes NNW to "Are we getting smarter or dumber?" which has no secondary links, for no obvious reason. (If you click on it, you'll see it does have green bubbles for "Internet" and "Education".)
- One goes due south to "IBM sells Blue Gene for brain research" which has zillions of secondary links. (But if you click on it, you lose the backlink to the original article!? There's a 'Reset' button down there, for this emergency.)
- One goes SE to "Harvard brain images: Cat vs rat" which is linked only to the green R&D bubble (you may have to click on some whitespace to get this to scroll into view). If you click on this story you'll see it does have more hidden grey and green links, so apparently the due-south link has been arbitrarily favored for expansion (maybe because it has the most links?).
These three similar-story links are appropriate and useful, and as a basic rule of web-design all web-articles should probably offer such a short set at the end, because many readers will at that point be ready to explore. I think Cnet was already doing that in text form, maybe in a sidebar though (which is less effective).
Someone should have added "MIT" as a red-bubble link-- I expect this will become more routine. It needs at least one green bubble for "Neuroscience".
The supposed rationale for using graphics instead of just text is that similar items can be visually clustered, but this isn't what's happening here-- the most similar stories are getting buried in random linkage.
Whenever I see a floating-bubbles interface (and I'm ashamed to say I even programmed an early one, back in 1990), I think of a bad stage magician waving his hands to distract you while he picks your pocket.
Cnet's readers would be much better served if this info was offered in text-outline form, maybe with fast Ajax browsing.
04 September 2005
The crystal-tags manifesto 0.1
There's a small set of puzzles that are frustrating everyone's ingenuity lately: email spam, web spam, blog discovery, blog search, music discovery, and tagging generally. I propose that they share a common solution that will require a new Net application, which I'll call "crystal tags".
Surprisingly, the closest model for crystal tags is the antique NNTP network-news transfer protocol, substituting today's "tags" for yesterday's "newsgroups". With NNTP, local news servers cached all recent posts on every topic, and users subscribed to the topics that interested them, killfiling the authors they disliked. A session of newsreading in 'trn' was often as simple as pressing the spacebar repeatedly, which took you thru all new posts for all your topics, one by one.
But then the Web hit, and the content got buried in elaborate formatting. And with regard to efficient communication, our sights were lowered. (And whoever Google has assigned to replicating 'trn' via Ajax in Google Groups has so far blown the job entirely...)
RSS is a feeble step in the right direction, unhappily limiting its newsgroups to a single author.
The 'tags' part of "crystal tags" means that every user should be able to subscribe to any tags/newsgroups they like, and the application will help them find, track, and organise relevant content. If one user uses the tag 'mp3' and another uses 'mp3s' the application can handle this easily.
The 'crystal' part is harder to explain. It means that over time everyone's tags should crystallise into a dynamic unity, where everything that should be synched, is quickly synched.
Synching in NNTP required two news servers to connect and compare which articles each had, using unique article-numbers, and to fill each others' gaps.
With crystal tags, you'll get to choose who you synch with, and to what degree. Someone whose judgment you respect, in a given area, will get synched automatically, and someone unknown will get synched only tentatively.
The webpages you publish will be (as now) available to any random stranger, but once ip-number and/or passwords have established a known identity, personalised or private content can also be offered. Your public blog will (as now) display links to new content you recommend to everyone.
MP3 blogs will offer playlists that add new discoveries at the top, and can be linked and subscribed-to like other tagged content, but also played.
Email will follow the same patterns, except that strangers can make 'cold calls' that may or may not get read by the human being approached. If these are followups to public blog posts on a particular topic, it should be clearly stated under what terms they can be published.
Somehow given topic/tag/newsgroups will get associated with particular hosts, who will be responsible for filtering submissions for spam, vandalism, griefing, etc.
Some sort of ping-system should be built-in so that checking for new content is a minimal effort.
Surprisingly, the closest model for crystal tags is the antique NNTP network-news transfer protocol, substituting today's "tags" for yesterday's "newsgroups". With NNTP, local news servers cached all recent posts on every topic, and users subscribed to the topics that interested them, killfiling the authors they disliked. A session of newsreading in 'trn' was often as simple as pressing the spacebar repeatedly, which took you thru all new posts for all your topics, one by one.
But then the Web hit, and the content got buried in elaborate formatting. And with regard to efficient communication, our sights were lowered. (And whoever Google has assigned to replicating 'trn' via Ajax in Google Groups has so far blown the job entirely...)
RSS is a feeble step in the right direction, unhappily limiting its newsgroups to a single author.
The 'tags' part of "crystal tags" means that every user should be able to subscribe to any tags/newsgroups they like, and the application will help them find, track, and organise relevant content. If one user uses the tag 'mp3' and another uses 'mp3s' the application can handle this easily.
The 'crystal' part is harder to explain. It means that over time everyone's tags should crystallise into a dynamic unity, where everything that should be synched, is quickly synched.
Synching in NNTP required two news servers to connect and compare which articles each had, using unique article-numbers, and to fill each others' gaps.
With crystal tags, you'll get to choose who you synch with, and to what degree. Someone whose judgment you respect, in a given area, will get synched automatically, and someone unknown will get synched only tentatively.
The webpages you publish will be (as now) available to any random stranger, but once ip-number and/or passwords have established a known identity, personalised or private content can also be offered. Your public blog will (as now) display links to new content you recommend to everyone.
MP3 blogs will offer playlists that add new discoveries at the top, and can be linked and subscribed-to like other tagged content, but also played.
Email will follow the same patterns, except that strangers can make 'cold calls' that may or may not get read by the human being approached. If these are followups to public blog posts on a particular topic, it should be clearly stated under what terms they can be published.
Somehow given topic/tag/newsgroups will get associated with particular hosts, who will be responsible for filtering submissions for spam, vandalism, griefing, etc.
Some sort of ping-system should be built-in so that checking for new content is a minimal effort.
Subscribe to:
Comments (Atom)