[uf-discuss] [chat] Microformats are not for data storage

[Greg Elin]

Woohoo! I'm excited by this thread as well and have had a more than a
couple conversations with Kevin regarding the need for a chat
microformat. I'm jumping in with 3 points and a disclosure of my own.
Thanks for piping up Colin - I love Adium.

Point 1: Chat is not just for chat anymore.
-------------------------------------------------------------
Continuous pressure to multi-tasks, work with people geographically
dispersed (or silently with others in the same room), innovate
quickly, and the very human need for back-channel signaling and
communication is making chat one of dominant channel of
communications. The need for a better abstract chat
storage/exchange/display format is being driven by more than instant
messaging:

  - growing use of chat as a back-channel at live events
  - growing behavior of cutting and pasting chat snippets
  - lack of ability to search multiple chat logs online as
conversations the way we can
    blogposts and even forum postings to some extent
  - continuing need for IRC-to-Web-based chat gateways
  - ability to use chat-stream for tracking attention-oriented events
(Attention Stream)


Point 2 - XML vs. XHMTL vs. Microformats
---------------------------------------------------------------
It strikes me there are two major threads Colin and Chris are
discussing and it might be helpful to separate them a bit, at least
for me.

One theme is a microformat for chat. The other is a larger debate as
to whether or not XML eventually collapses into something microformats
or microformats-like. That is, can I express any given sequence of XML
elements

 <item><subitem> data </subitem> </item>

as a sequence of properly classed divs (e.g) XHMTL)

  <div class='item'><div class='subitem'> data </div> </div> ?

Am I right these are two threads here? If so, can someone catch me up
on the state of discussion of the second thread? (There are also seems
a related thread of display v. storage formats.) Pulling a part the
discussion -- if it can be -- would be helpful in catching me up. (For
me, this has hit home with Fotonotes since it is necessary to
translate any storage/exchange format (either database or XML) into
classed XHMTL in order for the increasingly universal render engine of
the Browser+Javascript to manipulate it.  Should I define my own XML
and respective elements, shoe-horn functionality into an existing
format like Atom, or just $&%@-it and store it as XHMTL with classes?)


Point 3 - Chat as Command Line Prompt for People
----------------------------------------------------------------------------
The more I use both chat and the command line, the more I experience
the command line as a means of IM'ing my computer and chat as a way of
responding to the people who have 'accounts' with me and need my
functionality and processing power (and a way of getting status and
queuing tasks for people to whom I am logged in).

You can only type in one text box at a time.  And I've begun to see
more and more interface usage -- what I actually do at the computer --
as typing one line at a time and more interfaces collapsing into the
chat window. Email on my Blackberry, SMS messages, IRC, Chat, editing
subetheredit or writely document, responding to gmail, adding an
annotation to a photo, blog comments, AJAX-enabled in-line editing,
forums, etc.

Everywhere I turn I see a textbox with an long vertical tail of text
trailing above it.

Every application I look at increasingly see user friendlier "command
lines". AJAX is a BIG DEAL b/c it makes web pages truly interactive in
a way Web 1.0 pages never were. Web 1.0 pages are like computer punch
cards with prettier interfaces: submit a batch of instructions at one
time and wait for the computer to print you back a page of fixed
output. Repeat.)

Instead of dashboard at the bottom of my Apple desktop I want
"textbox" -- a simple area I could always type and with a few controls
(or ultra simple /commands) do my work. Like Adium's wonderfully
tabbed chat interface, or Flock's context aware reader/posting
functionality...my 'textbox' would enable me to type in my box and
direct my output to the context I wanted -- or several simultaneously:
a chat to my colleague, a tagged note or todo to myself, a post to my
blog, save a tagged url to delicious, an SMS to twitter, a google
search, or a command line for the Internet. (The location bar is kind
of nascent command line for the Internet if you think about, accepting
an increasingly broad range of input. Non-linear visual applications
like Photoshop and Final Cut are obviously not command-line
oriented...but look again at Photoshop's non-desctructive action
tracker or Apple's use of core graphics and video and you will see a
tracked sequence of commands.)

Chat, in the sense of IRC and IM, is a special case of a "live
interactions + log" where most of the messages are status queries and
responses between people. It is going to be hugely beneficial to keep
in mind the more abstract representation of this type interaction when
thinking about formats for representing Chat. Even at the level of IRC
and IM, we need a microformats structure for chat that recognizes chat
as something larger than chat...as a sequence of discrete messages, or
as "packets of conversation". And each packet can have value in
contexts *outside* of the specific conversation of which it is a part.

For example, why the do I need to leave my chat window to open my
calendar to note an appointment? Or, why does not appropriate
modification to a document my colleague IM's me show up as a note I
can accept inside my Word document?  I would love -- just love -- if
my chat tools, like Adium, allowed me to chat with myself ...
including my future and past selves ... as easily it does other
people. Give me the chat interface where I can type to myself and tag
it to find it later. (Yes, I know a few apps of the endless journal
variety are exploring this. That is precisely my point.)

Each snippet has an originating source and context...and a target
source and context. A message *is* as well as *is about*. Right now,
our Chat applications are very stupid and just pass messages depending
upon the humans at either end (or the bots) to recognize the context.
That is a very good thing. Yet, a few more hooks -- like tagging a
message or recognizing the creator and recipient(s) operate in
different yet overlapping contexts -- would enable the computer to
handle certain functionality more easily and enable new functionality.
The microformats for a chat needs to represent more than a message
with a time stamp.


Disclosures
------------------
I got sucked into chat when David Isenberg asked me to help create an
"in-room chat" system in 2001 that included making the chat readable
on a large screen. That experience enlarged my thinking about the
nature of chat and how small changes in the UI had large social
effects. I've gotten to work with Manuel Kiessling creator of A Really
Simple Chat one of the first smooth web-based chat before Ajax took
hold and together we experimented with using the chat engine/metaphor
for an "Attention Stream" at Etech. I've done a bit of other hacking
to see if I could extend the Chat-metaphor to a kind of generic UI
described.  Jerry Michalski has tried to promulgate for a
more-context-flexible interface called "linkido" where a simple data
entry is provided the output of which can be targeted (and adjusted)
for different messaging contexts: IM, word document, blog post, email,
or simultaneous combinations context.


Greg Elin


On 10/30/06, Colin Barrett <timber at lava.net> wrote:
> On Oct 29, 2006, at 8:39 PM, Chris Messina wrote:
>
> > Whohoo! A point of real debate!
>
> :)
>
> > Well, as I did when we first spoke months ago, I firmly disagree, and
> > over time, I think you will be proven wrong. There's simply no point
> > in having multiple instantiations of the same data in a text-based
> > format (I'm exempting relational databases).
>
> Mmm, I think you're confusing the issues of immediate presentation to
> the user and long term storage (one of which is a *human* problem and
> the other is a *machine* problem). In many cases -- specifically
> Adium's case -- the on-disk logs are going to be read by things that
> aren't even *close* to a web browser -- Spotlight, for instance.
> Gaim's log viewer is another example.
>
> Also, think about an AJAXy web app (like Meebo) that constantly is
> modifying its DOM tree. I don't think that that markup and all of its
> included JS (and also the fact that it might be necessary to have a
> server connection) is suitable for long term storage and parsing. This
> is another reason against using a uF for long term storage -- you can
> have uFs in web pages with all sorts of extraneous information on them.
>
> I think it's very telling that you exempt relational databases. I
> could imagine a uF for specifying a table (<table> anyone?) and the
> relations therein -- this could of course be easily parsed and
> modified by JS. The way I see it, you've already acknowledging the
> need for machine-friendly data that is separate from human-friendly
> data (uFs).
>
> > In any case -- I know where you're coming from and I appreciate you
> > making a public statement about your position. This will allow us to
> > finally have this conversation out in daylight.
>
> Thanks! I agree, it's important to have this out in the open. On that
> note, I'm curious if anything you've worked on might provide
> additional examples for discussion?
>
> > Your point has been that straight XML is easier to parse than XHTML --
> > which could include linked CSS for use in presentation, or JS to
> > add/modify behavior.
>
> A nitpicky, off-topic point: XML can include CSS and JS and can be
> styled.
>
> In any case, my real point is that it's not the XHTML-nature of uFs
> makes them harder to parse. Rather, it's something about microformats.
> Microformats have to be much more flexible to interact with the other
> kinds of markup and presentation issues that exist on the web. A good
> example that popped up on the list recently was hCard's powerful (but
> tricky to parse) value class. A log that exists for machines to parse
> definitely doesn't need something like that.
>
>
> > Furthermore, as new chat programs emerge, the ability to move data
> > between them in a format that works in *any browser* seems like an
> > investment in the future, as opposed to the present and recent past.
>
> My main problem with this is the word "browser". Adium is not a web
> browser. It is a user agent, in that it displays (X)HTML, but it does
> no browsing of the web. As mentioned above, this is another instance
> of a non-browser working with HTML. See above for another example of
> the need for something that is easily read by a non-browser.
>
> As far as in-browser elements like Google's Gtalk web chat, those logs
> are stored on-disk by the server and then displayed to the user.
> Storing the entire web page (or a section thereof) for the log file
> that will be shown to the user is impossible -- Gmail is a highly
> dynamic web page. Thus, there's a uF offers no real advantage in this
> case: the file is going to have to be read in and parsed anyway, so
> why not use something easier for machines (like XML).
>
> > Lastly, the unknown uses and mashability of XHTML is one of the most
> > important elements of using XHTML as opposed to custom XML.
>
> Another nitpicky, offtopic issue: ULF isn't exactly custom, being that
> it's a published standard and has multiple implementations.
>
> Otherwise, this is a good point, and one of the reasons why I'm not
> discounting a uF for chat all together -- I'm just arguing about the
> specific *focus* the format will take.
>
> > These are a few of the basic assumptions that I work under. I would be
> > very happy if you would discount them, one at a time. ;)
>
> Hopefully I've done a satisfactory job. Anyone else can feel free to
> jump in, btw.
>
> -Colin
>
> > On 10/29/06, Colin Barrett <timber at lava.net> wrote:
> >> Particularly, I'm going to be talking about "hChat".
> >>
> >> Personally, I see the primary use case of a chat microformat to be
> >> for
> >> displaying of chat contents in a live (or semi-live) way. There are
> >> quite a few examples of this in the wild -- web-based IM clients like
> >> Meebo, and Adium and Kopete's message view, both of which are HTML
> >> based.
> >>
> >> Contrarily, most data formats are not HTML based (XML based,
> >> usually),
> >> or if they are, do not use modern HTML (i.e. AOL's HTML log format).
> >>
> >> I think the chat group should alter its focus to providing ways to
> >> semantically talk about the structure of a chat and a particular
> >> message entry. One of the most obvious benefits in this area is much
> >> better clipboard support -- copying things out of Meebo and Adium/
> >> Kopete's HTML view usually results in an un-useful mess.
> >>
> >> Another important use case, that I think there has been some research
> >> towards already, is "snippets". That is, small snippets of an IM
> >> conversation in a blog post. This, conveniently, goes along with my
> >> earlier point about copy-paste.
> >>
> >> Just a couple of other points that have been percolating:
> >>   - the use of hCard to mark up people's names
> >>   - Time zone information is important -- particularly wrt. time time
> >> zone of the sender and the time zone of the receiver.
> >>
> >> This email has been a long time coming -- I've waited for a couple of
> >> months, just lurking and trying to understand the process. Should
> >> people agree that this is the direction research should go, I'll
> >> start
> >> working on getting links on the wiki to examples of documentations of
> >> chat representations. I think that the idea of chat *logging* is a
> >> well-solved problem by XML and microformats shouldn't be butting
> >> their
> >> heads in -- especially since most of the time full logs aren't
> >> available on the web (the uF log bot being a notable, and
> >> interesting,
> >> exception).
> >>
> >> In the interest of full disclosure: I'm one of the developers of
> >> Adium
> >> -- we're looking into improving our message view, and copy/paste has
> >> been something that's plagued us for a while. I'm also one of the
> >> primary authors of an XML based log format that's been adopted by
> >> Adium, Gaim and Kopete.
> >>
> >> --
> >> Colin Barrett
> >> Developer, Adium
> >> http://adiumx.com
> >> _______________________________________________
> >> microformats-discuss mailing list
> >> microformats-discuss at microformats.org
> >> http://microformats.org/mailman/listinfo/microformats-discuss
> >>
> >
> >
> > --
> > Chris Messina
> > Citizen Provocateur &
> >  Open Source Ambassador-at-Large
> > Work: http://citizenagency.com
> > Blog: http://factoryjoe.com/blog
> > Cell: 412 225-1051
> > Skype: factoryjoe
> > This email is:   [ ] bloggable    [X] ask first   [ ] private
> > _______________________________________________
> > microformats-discuss mailing list
> > microformats-discuss at microformats.org
> > http://microformats.org/mailman/listinfo/microformats-discuss
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


-- 
Greg Elin
http://fotonotes.net - Because photos have stories (TM)
http://duhblog.com