On Oct 30, 2006, at 3:39 AM, Greg Elin wrote:
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.
You're welcome! :) Glad to see this thread generating interest. I was afraid it would go without comment. :)
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:
Definitely agree with your premise here -- I see stuff like this happening al lthe time.
- growing use of chat as a back-channel at live events
Agreed.
- growing behavior of cutting and pasting chat snippets
Hugely agree.
- lack of ability to search multiple chat logs online as conversations the way we can blogposts and even forum postings to some extent
Hmm, I'm not so sure. Adium's search works pretty well for me. Once 1.0 comes out we'll be integrating OS-wide with Spotlight. It would be nice if I could get Spotlight to search google as well, or work in a google like way, but that's a different problem. The alternative is, of course, to plug google into the chat logs, but I would rather not have all of my chat transcripts indexed by GOOG ;)
- continuing need for IRC-to-Web-based chat gateways
In the "view only" direction, yes, definitely (rw is basically a web IRC client, and isn't a very interesting problem). Especially with a way to signal certain events as should be pushed through the gateway and others not.
- ability to use chat-stream for tracking attention-oriented events (Attention Stream)
Could you expound a little more here, please?
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?)
There is in fact a second (actual) thread, oddly enough. I started one (or replied to one) a couple months earlier -- It's not in my personal archives, and I haven't gone through and searched the pipermail interface yet. It's somewhere back there, though. That's kind of what Chris is referring to. I don't think it's horribly interesting from what I remember.
To go back to your concept of threads of conversation (and not threads of mail messages): I think you *can* render any XML document as a uF, for several reasons, the most obvious being that it's already in XML (the X in XHTML). The question is really *do you want to*. Assuming you can only use SAX, it's more straightforward to parse an XML document than an XHTML one, but not that much harder. The real trouble is that uFs can exist in HTML as well, which SAX will throw up on. Then you need to invoke an HTML parser, and since you've gone that far, you'll probably just use JS. When you're indexing thousands of logs, some of which may be in the multi-megabyte, things like this become important to think about.
Display v. Storage is definitely something I think Chris and me differ on. Which makes sense -- Chris is very interested and passionate about uFs, so it makes sense that he will initially propose a uF to solve a problem. I wouldn't call myself "passionate" about XML, but it a) does the trick, b) there are loads of tools for parsing and working with it and c) is fairly easy to get others to adpot -- in fact the Gaim people were going to implement it already and heard about our effort and jumped on board. FWIW, they too are experimenting with an SQL- based log format.
Finally, the problem you're talking about in the end of the above paragraph is exactly what we were talking about with Adium. We ended up deciding to make an XML format and standardize it across as many projects as we could. :)
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).
That makes a *lot* of sense. *thinks about making a terminal service type for Adium*.
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.
Well, that makes sense -- the keyboard is our primary input mechanism for text.
Everywhere I turn I see a textbox with an long vertical tail of text trailing above it.
Almost sounds like one of those old arguments against GUIs ;)
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.
Tried Quicksilver[1] yet? Example run: ctrl-space 'killall Dock r <return>
That's equivalent to running the command like killall Dock (which is needed more often than you'd think...).
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.)
Yeah, you're basically describing QS. It's freaking fantastic. I highly, highly suggest you, and any other mac users, try it out.
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.
I kind of agree? This point is a bit nebulous.
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.)
http://www.apple.com/macosx/leopard/mail.htmlThe new notes feature there actually has a public API any app on the OS can access. We plan to use that in Adium in some way :)
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.
Definitely agree that a microformat would need more than just a message and a time stamp. Still, I'm not convince that an on-disk storage system for a chat application needs more than that. Address Book apps can be polled to get information to generate an hCard for a contact, for example. That would be really useful for Adium. Want to email someone you're chatting with? Click on a contact's name and an hCard pops up, then you click on the mailto: url and BAM you're in your mail client with the last three or so messages included in the mail in plain text (of course ;) as a reminder context.
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.
Very interesting stuff! Could you hook me up with URLs to those? It sound like you have a lot of interesting stuff to offer to the group in general.
-Colin [1] http://quicksilver.blacktree.com/
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 aserver connection) is suitable for long term storage and parsing. Thisis another reason against using a uF for long term storage -- you canhave 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 uFsmakes 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 logsare 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 thatit'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
_______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
