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 $&[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >> [email protected] >> 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 > [email protected] > http://microformats.org/mailman/listinfo/microformats-discuss _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
-- Greg Elin http://fotonotes.net - Because photos have stories (TM) http://duhblog.com _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
