voice of humanity: The Annotated Web

voice of humanity: The Annotated Web
Roger Eaton's notes towards a collective voice for humanity on the web

The Annotated Web

28 Nov 2003 @ 14:44, by Roger Eaton

The voice of humanity network will be implemented first as the "annotated web", that is, as a community created stigmergic overlay of the web. The AntWeb is entered through portal pages, one portal page for each participating web community. Having entered through the portal, every link traversed by the membership is logged as the members browse the web. Facilities will be available to rate web pages and to add notes and keywords as members browse along. The links followed and the ratings given will be used to mark links as popular or unpopular for the others who might visit the same site – provided they have entered through the same portal, of course. The notes will likewise be accessible to those who come by later, and the keywords can be used in a lookup facility on the portal page to jump straight to items that are "funny" or "curious" or "delightful" etc. It should be fun. (See the MetaWeb Article for a previous take on the Annotated Web concept.) For example, take the Blogger’s Parliament...

As an MBP (Member of Bloggers Parliament) myself, I will be very interested to try to persuade my fellow members to participate in the BP Annotated Web. Our portal will list all MBPs with links to their Solutions. Access to the portal will be open to the public, though there may be a sub-portal open to MBPs only. Public, or MBP, all will have to sign in, or use a common "anonymous" login, which will not have rating and annotating rights. Once signed in, a personal pre-logged-in portal address will be bookmarkable, so the login process will not have to be repeated on every visit.

From the portal, every link we take will be tracked and participants will be encouraged to rate each page visited and optionally to add notes and keywords. This tracking process will not cover only the links on the portal, but will continue no matter how deep into the web we get. When we visit pages, if we have "NOTES ON" then we will see the annotations as interpolated wiki-like links, or if "NOTES OFF", then the annotations will be available through tiny buttons. Either way, the annotations will be presented as separate web pages, available for sub-annotations and rating. Annotations, therefore are wiki like. However, it is not possible to actually edit the original page, only to add annotations.

The annotated web is fertile territory; the ideas just keep coming! For instance, though we cannot edit the original web pages, we could edit copies. Whoa! Is this asking to be sued? But it is just too attractive a possibility to be ignored, this idea of wiki-izing the entire web.

Back to our Bloggers Parliament example. Clearly we want our portal to show us the highly rated solutions we have found – the portal should be automated in this respect. And there should be some kind of zoom factor, so new solutions that rack up high ratings are given priority even though the total of ratings is much lower than that of older items. We also need to handle our categories, such as "Health and Environmental Problems" or "Poverty, Hunger and Illiteracy". Ideally each of these categories should have its own portal, and membership, and the ratings and annotations should feed up to the larger Bloggers Parliament AntWeb. This concept of feeding ratings up from sub-categories is an essential part of the voice of humanity networking concept. See the How to Build a Voice of Humanity on the Web article and the follow-on article, Handling Collective Messages, including the comments.

Curiously, checking out "antweb" via google, I found a paper out of the University of Brasilia that has a very similar approach to that detailed here as the "annotated web": AntWeb: The Adaptive Web Server Based on the Ants’ Behavior, by Teles, Weigang and Ralha. One good idea from this paper is that of "pheromone evaporation". I.e. old ratings count less! This paper also uses the time spent at a site as an automatic rating. Tricky, since any number of interruptions could skew the value, still the user is not burdened by having to give a deliberate rating.

In the previous article about Chandler, I suggested it would be a GOOD THING to adapt Chandler as a user interface for the InterMix voice of humanity middleware. That idea of using Chandler as an interface is still on. There is though a more radical possibility, which would be to build InterMix using Chandler as its platform. This would wed InterMix to Chandler irreversibly, and at this point is certainly not on, but only up for discussion. In this context a message on the Chandler Design List is relevant: Thoughts on a browser parcel? by Tom Mueller. To implement the AntWeb in Chandler would require a browser option within Chandler, which sounds difficult. So far no one has responded to Tom Mueller’s interesting suggestion. I have the feeling the Chandler team is pressed too hard just now trying to get something out the door by the end of 2004 to let any more blue sky in. I’ll see if I can connect with the Chandler team on this and get something more definite.

[< Back] [voice of humanity]

Category: Articles

29 comments

29 Nov 2003 @ 06:57 by Natalie @82.35.43.4 : your ANT
Roger, I love your ant, *and* the idea of the project. When it's set up, I'll join.
My only quibble concerns the 'popular/unpopular' rating system since I'm not in favor of that competitive/cliquey/snobbish tendency that can be found in the blogosphere. It has an unfortunate ressemblance to the same thing in the 'real world' outside cyberspace.

29 Nov 2003 @ 08:16 by ming : Browser Parcel
That sounds almost inevitable, and sounds like it could be done without the Chandler team. Of course I don't understand the whole thing yet, but if it is really as modular as it looks like, I can't see why not.

29 Nov 2003 @ 08:24 by ming : Mozilla
The Mozilla browser has a lot of hooks for creating customized interfaces, and connecting up with most of the inner operations of the browser. Like, see NewsMonster which is a fancy RSS aggregator within Mozilla. I don't know much about how that works, but it wouldn't be surprising if you could intercept links and provide panes for entering comments and ratings. Plus it has the Composer component which lets you edit webpages within the browser.

29 Nov 2003 @ 17:10 by Roger Eaton @209.55.71.129 : ratings / popularity
Tough quibble to answer, Natalie. I suppose we can call it "interest" instead of "popularity", but it amounts to the same thing and even our Bloggers Parliament vote for best solution has the same idea built in. I would only add an interest rating to the yes/no vote so we don't end up picking "alternate nostril breathing" as the Parliament's best solution because it gets the most ayes and the least nays!

29 Nov 2003 @ 21:59 by Natalie @82.35.43.4 : popularity
True, but in the case of Bloggers Parliament the term 'best solutions' means those most relevant to the problem, not those that are necessarily most popular. H'm. That leads to another question: who will decide what solutions are most relevant? Maybe there could be some fixed criteria - like "what works" and "what sounds good but hasn't a hope in hell of working". Etc. What do you think?

30 Nov 2003 @ 09:41 by Roger Eaton @209.55.71.129 : re: popularity
What might work is to give each voter one thousand credits to spread amongst the solutions. This keeps the parallel to Parliament, where there is no one winning policy, but rather a set of priorities are developed. I advise against equating "best" with "most relevant" -- doesn't meet the crossword puzzle criteria of meaning.

30 Nov 2003 @ 11:42 by Natalie @82.35.43.4 : popularity
Not sure I understand, Roger. How would this actually function? Sounds a bit complicated to implement technically.

As for relevance, surely that has to be the major criteria for any solution?

To give an exaggerated example, if somebody proposes that the best solution to terrorism is to nuke all countries on Dubya's "axis of evil", and if those who actually do think this would be the best solution vote for it in large numbers, are we really going to announce that this is the best of all possible solutions? I don't know about crossword puzzle criteria but no way could I defend such a result.

30 Nov 2003 @ 12:51 by Roger Eaton @209.55.71.129 : Voting on the Web
I think you have to allow that the vote will not go the way you want it to. Sure a gang of neo-nazis might decide to mess up the results, but more likely things will work out ok. If we wait until the AnnotatedWeb is working, we can require a login, which will help towards preventing multiple votes, and will discourage people who are not serious. The idea about distributing credits is perhaps too difficult to implement, you are right, though it is an option to keep in mind. Relevance is an important criterion,of course. It is just not the only criterion. "Best" is inevitably somewhat subjective.

30 Nov 2003 @ 13:11 by Roger Eaton @209.55.71.129 : re: ming's comments
Ming, I just sent the following to the Chandler design list. Let's see what they say.

No one has responded to Tom's query yet. Is his idea far-fetched,
or well within the realm of the possible? How would it work?
The entire browser would not be stuffed into a Chandler pane,
would it? Would a good implementation allow bookmarking?

So say embedding a browser in Chandler is not on for the core
team at this time. Would it be the kind of Chandler addition that
would make it into the standard distribution if done well? Or is it
off to the Wiki "jungle" for talk like this?

I hope someone will take the time to respond. I am very
interested in using Chandler for an ambitious peer to peer
project -- see [link] -- recent article
about Chandler there. Currently my thinking is to develop the
InterMix peer to peer product as middleware. In this scenario,
Chandler will function as one possible user interface, with at
least an email interface in addition. However, I am also
looking at the possibility of using Chandler as a platform for
the InterMix product. I would need to have a browser embedded
in Chandler for Chandler to work as a platform, tho.

> Has there been any talk about a browser parcel (capplet?)
> Might it be possible to "just" (easy enough for me to say, I
> realize) package Firebird as a parcel? The idea of having
> an embedded browser, with which I could save clippings or
> entire pages directly into the searchable, massagable,
> intertwinglable Chandler repository, fills me with great joy.
> This might also be a quick way to show many people the light
> about Chandler - lots of browsers out there, and scads of
> databases, but the world is crying out for a happy marriage of
> the two.

30 Nov 2003 @ 14:07 by ming : Chandler
Cool. I hope somebody answers.

1 Dec 2003 @ 05:45 by istvan : Not related?, but
maybe useful.
[link]

1 Dec 2003 @ 07:11 by ming : House of Eyes
Oh, my good friend Heiner Benking. I'd say that sort of relates.

1 Dec 2003 @ 19:46 by Roger Eaton @204.250.12.246 : House of Eyes
Thanks for the Benking link. I'll see what I can do with it in my next article. Did you mean to include the fragment at the end of the link pointing to footnote 28, which was referenced in the body for this quote: ".. we should never blur the insight that we need socially stabilized world models to live in, and that we can not do without moral orientation." from S.J.Schmidt? I have not heard of Schmidt before, but I do agree with the ideas of "socially stabilized" and "moral orientation" -- so long as we don't go overboard along those lines.

2 Dec 2003 @ 10:01 by Roger Eaton @209.55.71.129 : We have a reply from Mitch Kapor
Mitch Kapor has replied to Tom Mueller's question about embedding a browser.

Subject: [Design] Thoughts on a browser parcel
Date: Tue, 2 Dec 2003 07:19:51 -0800
From: Mitchell Kapor
To: design@osafoundation.org

To be able to save clippings or pages to the Chandler repository
wouldn't seem to require embedding a browser as much as creating a
conduit between the browser and Chandler. In fact, it's reasonable to
believe a Mozilla plug-in could be created which would do just this,
i.e., populate the repository with items generated by the browser.
Embedding a browser, per se, raises all sorts of complex user interface
issues which may be unnecessary and avoidable. That said, such a
project is something which would need to be undertaken by an external
developer, as it's not on spec for Canoga.

--------end of quote from Mitch Kapor----------------

So now we know. The answer did cover my questions as well. In particular it is clear that stuffing a whole browser into a Chandler pane is not on, though one could render html in a pane using the Mozilla renderer, called Gecko. The problem with that approach is that one would have to code for the standard Stop, Reload, Home, Bookmarks, History, Print and so forth features, plus the fetching code etc etc. It sounds like a big project and that the result would never be as good as a regular browser.

On the other hand, requiring the user to have Mozilla in order to have a connection between Chandler and the web is also something of a drawback. It certainly makes it harder for your gazillions of MSIE users to integrate the web with their email, calendar and contacts. They will have to download and install Mozilla or Firebird. Well it is not a show-stopper for Chandler to go that way, but it does hurt.

So where does that leave us? Mitch Kapor has given us a pointer here -- develop a plugin for Mozilla. I wonder -- would a plugin for Mozilla also work for Firebird and Camino? Not for Camino, anyway, I bet, and that is not good for the mac connection.

The alternative is to go with the InterMix as middleware concept, which allows any browser. This is simpler. We get something out the door in less time. We don't have to support browser code which might break or get complicated as new browser versions come out. We don't have the problem of supporting Camino, too.

It would be ideal though, to end up being THE web browser solution for Chandler as well. As middleware, InterMix should support multiple file systems, so we could begin by using the Chandler Repository. They still have issues, but have basically settled on their repository design, I believe.

I need help thinking this through to make sure I haven't made a dumb mistake in the overall structure. As I see it now, in order for InterMix to be middleware and to be THE Chandler web interface both, we will need to implement a new idea, the "personal portal". I have been thinking up to this point of community portals being the entrance to the AntWeb. InterMix would be running on a box that is also a web server, and the link to the portal page would invoke InterMix via cgi. This is how the current InterMix works -- see sharingLA for a working InterMix implementation.

But for a personal portal to work, InterMix will have to be its own cgi server, or the user will have to install a web server. We could go with the idea of installing a web server separately, I suppose, and plan to eventually bring the relevant cgi-server capability into InterMix. Requiring a separate web server install is ok for technical people, but not ok for the average Chandler user. Somehow I feel I may have missed something important in this analysis. Ming?

2 Dec 2003 @ 11:46 by Roger Eaton @209.55.71.129 : More on the Personal Portal idea
There is a python product called Twisted that might do for an embedded server. Might do. There are comments about cgi not working in Windows from 2003, and disparaging remarks about Win98, plus it is a very big package and we only need a little part of it.

Thinking on what I have missed -- even for the community based AntWeb that does not require a Personal Portal, InterMix needs to act as a browser. What I think is that InterMix as browser will be the simplest sort of animal.

The idea is for the original link to the community portal to go to InterMix as a cgi request. InterMix will serve the portal page. This much I know how to do. The portal page will have links to other web pages, but each such link will be wrapped as a cgi request back to InterMix. For instance a link to ming . tv would look like this - h t t p : / / intermix.tv/cgi-bin/imix.exe?"ming . tv" -- something like that. We pass the true link as a cgi parameter. Then InterMix will receive the request and it will in turn go out to ming . tv as if it were a browser.

The webserver for ming . tv will return just the main html page -- the same that you get when you "view source" on your browser. Please someone correct me if that is wrong. Normally the browser receives this page and then requests all the jpegs and scripts and so forth that are just references and not themselves part of the main html page. So now, InterMix has this main html page so it can redo all the links so they will come back through InterMix. There is a trick here about relative web addressing that we can handle easily and I am not quite sure how we will deal with frames, but it looks like for the most part, the code is simple. InterMix must act as a browser, but not a complicated one. Please correct me, anyone, cause this is a crucial assumption. I will take a look out there about browsers, too, and how they work.

2 Dec 2003 @ 11:56 by Roger Eaton @209.55.71.129 : Here's a reply to Mitch Kapor came in
Notice "relatively small amount of work". That is a good sign. We have no decision yet on direction here. Maybe Mitch's suggestion is a good one after all. Any thoughts? I think I am still inclined to go the middleware route, tho.

Subject: Re: [Design] Thoughts on a browser parcel
Date: Tue, 02 Dec 2003 10:16:18 -0800
From: Heikki Toivonen
To: design@osafoundation.org

If anyone is interested in creating such an extension for Mozilla, the
best place in my opinion would be the [link] website that
houses dozens of Mozilla extensions and add-ons. I also think this
extension would work better than embedding a browser in Chandler - you
would get best of both programs with relatively small amount of work.

Mitchell Kapor wrote:

| To be able to save clippings or pages to the Chandler repository
| wouldn't seem to require embedding a browser as much as creating a
| conduit between the browser and Chandler. In fact, it's reasonable to
| believe a Mozilla plug-in could be created which would do just this,
| i.e., populate the repository with items generated by the browser.
| Embedding a browser, per se, raises all sorts of complex user interface
| issues which may be unnecessary and avoidable. That said, such a
| project is something which would need to be undertaken by an external
| developer, as it's not on spec for Canoga.
|

2 Dec 2003 @ 12:51 by ming : Server technicalities
It is not terribly hard to make a basic webserver, which could be embedded in a program people download. Somebody wrote one in 50 lines or so of Rebol as an experiment. Anyway, increasingly it will be part of the operating system that it already has a basic webserver, like on OSX and, I believe XP. So one might actually start counting on that.

CGI as such is not much harder, as it basically is just to run some program and feed the output out to whoever's accessing the webserver. Which you in principle can do in one line of code.

I suppose the reason they're phasing out CGI is that it is more of a security risk, and it is resource intensive to have to load a whole Perl or Pyhon interpreter every time one runs a little CGI. The better alternative is that an interpreter is built into the webserver, like PHP, ASP or mod_python.

A webpage being served from a webserver is indeed the source of the page, but first there's a bunch of headers, giving an HTML response code (e.g. 200 for success), the referer of the page, a statement of what kind of server it comes from, and a few other details. It is in plain ascii and not hard to to duplicate.

2 Dec 2003 @ 13:17 by ming : Browser
So the thought of having to make a browser is to make a way of transparently tracking for the user what links he clicks on, right? I.e. somehow filtering all links through a program that tracks where one went. Indeed it is not hard to grab a page and transform all the links to links that pass through some cgi that will track things. But it somewhat hinders the user experience if one has to go to a particular site before one does one's browsing. It would be best if one just does the normal things one does, including being able to cut and paste a link into the browsers URL field. So we're trying to make a way of mostly keeping the user's normal experience, while still tracking links, right?

I'm sure in Mozilla one can write a plugin that intercepts all links. But that's just Mozilla. However, that's not any worse than expecting people to use a special browser. Actually it is much better, as a bunch of smart people work hard at making sure Mozilla is up on everything people want from a browser.

One thought is to implement the interception of links in a proxy server. A proxy server is a program that receives all the user's requests for webpages anywhere, and then goes and gets them on his behalf and passes them back to him. So, of course, the proxy server could do whatever it needed to do with the data in-between, including replacing URLs. The proxy server could AFAIK run on the user's own machine, or it could be a centralized server for many people. All that is needed for the user to do is to configure his browser to go through a proxy, and all common browsers allow that in their configuration.

2 Dec 2003 @ 21:07 by roger eaton @209.55.71.129 : more from the Chandler Design list
The message below from Heikki Toivonen seems right on, except I am not sure that the tradeoff of not being able to handle MSIE is OK. That I assume is what is meant below by "it might not be possible for some closed source browsers". As if MSIE was just another browser rather than the one that 80 or 90 percent of people actually use and are not about to stop using.

Ming, it *does* hinder the user experience to have to go to a site to begin browsing. But it also hinders the user experience to have to install Mozilla and give up MSIE. Maybe the answer is after all to grasp the nettle and implement wxMozilla embedded in Chandler. Then the user is not hindered except by the Chandler community not keeping up with Mozilla.

However what you (ming) suggest about a proxy server might be just the ticket. I had no idea it was possible to configure a server to go through a proxy. I don't see where to do the configuring in IE. I'll check it out more thoroughly tomorrow.

Here's the interesting new article from the Chandler list.

Subject: Re: [Design] Thoughts on a browser parcel
Date: Tue, 02 Dec 2003 13:13:07 -0800
From: Heikki Toivonen
To: design@osafoundation.org

kapil thangavelu wrote:
| An alternative (better, imo) starting pointing would be wxmozilla

I don't think so. wxMozilla is (mostly) about embedding the Mozilla
engine inside a control that can be used easily from wxWindows framework
and wxPython. Sure, you could easily embed that in Chandler, but there
would still be tons of UI work that would need to happen to drive the
browser (buttons, URL bar, bookmarks, history, preferences, ...) - in
addition to doing the integration piece that collects interesting
browsing information and stuffs it into Chandler (and vice versa).

What Mitch (and I and several others at OSAF) think is better is to have
the browser(s) evolve on their own, and write *just* the integration
part. The downside is that you need to write the integration part for
every browser that you care about, and it might not be possible for some
closed source browsers. (It should be enough to write just one browser
integration parcel on Chandler side.)

Of course nothing is stopping you from creating a Chandler parcel that
does integrate a browser, but that just seems unnecessary work to me,
and you would not benefit from the UI work that the browser developers
were doing.

3 Dec 2003 @ 11:40 by Roger Eaton @204.250.12.246 : proxy servers
Using a proxy server is also problematic: see [link]

and the solution offered often is to use Mozilla!

Here is another link, [link] that tells us "Please note that you may not be able to configure access the Library's proxy server if your computer is on a corporate network that uses its own proxy server to restrict Internet access. Check with your network's system administrator for more information."

So corporate users may be restricted with the proxy solution.

Also, the two articles about accessing University libraries through proxies from outside the University suggests that those who use proxies now will have to switch proxies back and forth if that is the solution we adopt. Another drawback, even though we might not be talking about a lot of people.

Safari for mac os X does not support proxy servers. Proxy server is not available through AOL I.E.

The proxy will need to support https -- this means coding the proxy will not be so simple after all.

3 Dec 2003 @ 18:06 by Roger Eaton @204.250.12.246 : Chandler/Browser Quandry
I think I see a way to implement the personal portal idea so it integrates any browser to Chandler.

First, though, here is a list of the possibilities:

1) The OSAF solution -- set up a pipe between Mozilla and Chandler.

An open question here is whether the pipe can work both ways. What we need
is for Mozilla to notify Chandler so the user can be tracked, but also we
want a way to add Chandler/InterMix options to the Mozilla browser
experience. For instance, the user will need to be able to save a reference
to a particular web page in a particular category. InterMix will need the
user to be able to rate the web page and to add notes and keywords. To
implement these needs, Mozilla will have to have a special Chandler tool
bar. I think we can assume this is doable.

The big drawback is that each browser will need its own code/toolbar. And,
it is not totally clear that MSIE can be handled at all, tho the fact that
Google has a toolbar on MSIE suggests that it can. (Google says, tho,
that the toolbar has conflicts with some other plugins -- check this article.
Would a Chandler toolbar conflict with the google toolbar on MSIE? You
have to wonder.

2) Install Mozilla via wxMozilla into Chandler. In a way, this is the cleanest
solution, but it will take a lot of work and the Chandler implementation
is likely to be playing catch up to the real thing indefinitely.

3) A proxy web-server embedded in Chandler could be specified in each browser.
But this also has problems -- some browsers do not have proxy settings;
some people are using the proxy for normal business; the proxy server will
have to handle https.

To capture ratings, keywords and notes, the embedded proxy server will have
to modify the web pages served to add a Chandler Header and Footer with
forms with text boxes and radio buttons that can accept ratings and so forth.

4) Implement a personal portal as a button on Chandler. This works something
like the proxy solution but requires no setting on the browser. Pressing
the browser button in Chandler brings up the default browser on the user's
portal page. There is an embedded web server in Chandler, same as for the
proxy solution, but the embedded web server is invoked by the browser
purely through the href links in the portal page, instead of via the proxy
setting in the browser. The href links go to the embedded server with the
true web destination as a cgi parameter, so the embedded server works just
like a proxy server, but only for the manipulated links. Https links can
be left alone -- so the user will not be tracked when using https, but that
is as much a feature as a fault. Also, the user will immediately leave the
Chandler purview if the browser address window is used. Still the benefits
are that all browsers work and the user does not need to do any set up work.

This solution gets around the problem that the Chandler user has to go to a
portal page, because the invocation of the browser will take the user to the
page as needed. (I am assuming it is possible to invoke any browser with
a parameter for the initial page to override the user's "home" page. I
wonder if that is a good assumption!)

Let's discuss and then I'll write it up as a new article if it still looks good. Ming, do you have internet telephone? I am sure you do. I don't care for chat much, but I'd like to talk without spending a transatlantic nickel. I will set myself up on whatever system you are using so we can talk.

4 Dec 2003 @ 09:14 by Roger Eaton @209.55.71.129 : Tom Mueller responds to Mitch Kapor
Subject: [Design] Thoughts on a browser parcel
Date: Thu, 4 Dec 2003 09:19:21 +0100
From: "Tom Mueller"
To:

Agreed that an embedded browser isn't (at least today) a crucial PIM
feature, that it would ideally be done by an external developer (I can see
OSAF staffers glancing nervously at their calendars and getting
Inspector-Dreyfus-style tics), and that an external browser plug-in could be
made to send clips to the Chandler repository (as notes, a new item type
"clips" to facilitate searching, whathaveyou). Just getting the data into
Chandler would make it accessible to searches, and allow a host of agents
set to work on it, hammer and tongs.

Having said this, the same advantages that accrue to having email internal,
as opposed to imported into Chandler from Eudora, would seem to exist here
as well. Imagine being able to highlight text in an on-board browser, Alt+N
to create a new note from it, assign that note on the fly to relevant
categories, projects, clusters; then hit Alt+Ctrl+E to clone that note and
send as an email to a colleague; then select a few key words of note text
and Alt+P to make a new project with those as title words; etc. ad nauseum.
All in real time. Hard to see how this would be possible if the browser
were external. Also, an internal browser would presumably bring Favorites
into the heart of a person's computer experience, instead of the paradoxical
periphery they currently inhabit. Favorites could be another item type, to
be annotated, assigned hither and yon, shared, etc.

The alternative, importing web clippings from an outside program, would risk
producing precisely the kinds of intimidating middens of undigested,
to-be-reviewed information that Chandler ought to be so good at avoiding.

An on-board browser would give Chandler a pretty comprehensive coverage of
the internet - web, email, RSS, instant messaging. For the higher education
crowd, with the web becoming an indispensable research tool, this would be a
compelling capability. All that's needed (from this user's point of view,
anyway) is an integrated news reader, and the picture is complete.

The UI questions would admittedly be thorny. Balancing the utility of
maintaining the identical look and functionality of the outside program
(thus facilitating software updates), with the undeniable appeal of giving
all Chandler parcels an homogeneous appearance. I'd vote for functionality
over homogeneity, whichpresumably would also make the programming
significantly easier (and please the folks who initially developed the
browser - maybe even getting them to lend a hand?). One of the great
beauties of parcel mix-and-matchability is that it allows a few deviations
from the Chandler "look."

> Message: 4
> Date: Tue, 2 Dec 2003 07:19:51 -0800
> From: Mitchell Kapor
> Subject: [Design] Thoughts on a browser parcel
> To: design@osafoundation.org
> Message-ID:

> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> To be able to save clippings or pages to the Chandler repository
> wouldn't seem to require embedding a browser as much as creating a
> conduit between the browser and Chandler. In fact, it's
> reasonable to
> believe a Mozilla plug-in could be created which would do just this,
> i.e., populate the repository with items generated by the browser.
> Embedding a browser, per se, raises all sorts of complex user
> interface
> issues which may be unnecessary and avoidable. That said, such a
> project is something which would need to be undertaken by an external
> developer, as it's not on spec for Canoga.
>

4 Dec 2003 @ 09:31 by Roger Eaton @209.55.71.129 : another post from [Design]
Subject: Re: [Design] Thoughts on a browser parcel
Date: Thu, 4 Dec 2003 14:11:00 +0200
From: Philip Trauring
To: design@osafoundation.org

Isn't an embedded browser of some kind required for reading HTML
e-mails? I don't think I need Chandler to be my web browser, although
if it was and was fully integrated that could be a good thing, but I do
need Chandler to be able to support HTML rendering - or am I off-base
here?

On OS X it would seem logical to use the KHTML-derived WebCore
rendering engine (the engine used by Safari, and now OmniWeb). Clearly
KHTML is supported on Linux - although I don't know about Windows. The
wxmozilla project mentioned in an earlier posting would also seem a
good cross-platform option - although might the mozilla code base be
too big?

I'm not suggesting that supporting HTML rendering is the same thing as
offering a full-blown browser with all the features we would expect
(bookmarks, history, auto-complete, blocking pop-ups, downloading
files, etc...) but it would seem we do need to integrate some browsing
functionality.

Philip Trauring

4 Dec 2003 @ 20:08 by Roger Eaton @209.55.71.129 : Three more posts from Chandler [Design]
The main point here, I think, is the insistence of Heikki Toivonen on sticking with Mitch Kapor's original message that the UI was a show-stopper for embedding a browser as far as he was concerned.

Post #1
Subject: Re: [Design] Thoughts on a browser parcel
Date: Thu, 4 Dec 2003 13:26:20 -0800 (PST)
From: David Neeley
To: Philip Trauring , design@osafoundation.org

Perhaps I'm off base here, but there should be no reason Chandler can't work with whatever
your default browser might be for rendering HTML mail.

However, the rendering component in Mozilla--the "Gecko" code--is actually quite small and
very fast, unless it's become much more bloated since the last I heard.

In my opinion, if we were to want an integrated browser parcel, the Mozilla code makes the
most sense of all since it is already cross-platform.

David
---------------------------------
Post #2
Subject: Re: [Design] Thoughts on a browser parcel
Date: Fri, 5 Dec 2003 00:41:32 +0200
From: Philip Trauring
To: design@osafoundation.org

I for one definitely do not want to have to load my e-mails in a
separate browser when they contain HTML. I'd like the option of not
rendering the HTML for security reasons, but if I trust the sender I
definitely want to be able to view the e-mail as intended without
opening another application. That is the approach of Mailsmith, which
of course makes sense considering it comes from the creators of BBedit,
but that's the exact reason I don't use Mailsmith...

Philip

On Dec 4, 2003, at 11:26 PM, David Neeley wrote:
> Perhaps I'm off base here, but there should be no reason Chandler
> can't work with whatever your default browser might be for rendering
> HTML mail.
>
> However, the rendering component in Mozilla--the "Gecko" code--is
> actually quite small and very fast, unless it's become much more
> bloated since the last I heard.
>
> In my opinion, if we were to want an integrated browser parcel, the
> Mozilla code makes the most sense of all since it is already
> cross-platform.
>
> David
---------------------
Post #3
Subject: Re: [Design] Thoughts on a browser parcel
Date: Thu, 04 Dec 2003 15:00:19 -0800
From: Heikki Toivonen
To: design@osafoundation.org

Of course. I don't think anyone wants this. However, embedding an HTML
viewer for email (Mozilla for examples) is a separate thing from having
a *web browser* in Chandler. An integrated HTML mail view uses a small
subset of full browser features and components, and the UI requirements
are minimal compared to full featured browser.

Philip Trauring wrote:

| I for one definitely do not want to have to load my e-mails in a
| separate browser when they contain HTML. I'd like the option of not
- --
~ Heikki Toivonen

5 Dec 2003 @ 13:09 by Roger Eaton @209.55.71.130 : resolution of Chandler/Browser issue
Best option is the Personal Portal idea.

If Mitch Kapor and the other heavyweights at OSAF have discussed and discarded the embedded browser option in favor of the Mozilla toolbar idea (which is not a good solution itself), then despite its appeal, we need to discard the embedded browser solution, too.

The Mozilla toolbar option seems very poor because it requires either the users to adopt Mozilla and install the toolbar, or for Chandler to support any number of browsers, including MS IE, and that seems very problematical considering MS anti open-source stance.

The Proxy solution shares the problems of the Personal Portal solution and then has some other problems in addition -- we would have to support https in our miminal embedded server, and users who need a proxy for other reasons would not be able to play.

So we are left with the Personal Portal idea. This solution requires Chandler to be able to invoke the user's browser of choice with the Personal Portal page as target. If Chandler cannot do this for some reason, then we will have to reconsider. I'll do some research on this issue and if it looks ok, will write up the resolution in an article.

5 Dec 2003 @ 16:42 by ming : Personal Portal
Ok, so with 'personal portal' you mean essentially a program running on the user's computer, which will be a URL that tracks everything that is passed through it, and somehow provides a way of rating and categorizing links. And the information would be passed on to Chandler. Right?

And there would be a specialized data type added to Chandler, which stores those links/categorizations/ratings. And when one clicks on a link, it goes to the normal browser, but passed through the personal portal page. I doubt that that should be a problem.

But, hm, one of the core things that Chandler is about is to have a lot of facilities for categorizing items in many different ways. And most of what you have in mind doing with links to webpages boils down to categorizing them in various ways. So, I'm suddenly worrying whether you'd use Chandler's inherent ability to do that, or you'll do it elsewhere (in the personal portal) and then import the data into Chandler. Where Chandler might be the better place to do it in the first place, as I'm sure that will be what it will be very ingenious at. This is all not quite clear to me.

And if Chandler turned out to be perfect for doing the kind of categorization and rating you're looking for, then the question would become how that gets coordinated with loads of other people. I mean, Chandler obviously intends to let people share their data, but doesn't seem to attempt at solving how categories are synchronized between many different members of a certain group, and therefore how the data could be aggregated in the kinds of ways you're looking for.

Seems it would important to study how Chandler plans on sharing categories, and whether there indeed might be a way to coordinate categories and rating schemes between many people. But, of course, then there's still the issue that there's no browser in Chandler. But I suppose that won't have to be a problem if a link opens up a page in a browser.

5 Dec 2003 @ 20:09 by Roger Eaton @209.55.71.129 : reply to ming re: Personal Portal
> Ok, so with 'personal portal' you mean essentially a program running
> on the user's computer, which will be a URL that tracks everything that
> is passed through it, and somehow provides a way of rating and
> categorizing links. And the information would be passed on to Chandler.
> Right?

That and eventually a lot more. Once the user passes through the portal, she is in the Annotated Web. Categorized and rated links can be shared via the peer to peer voice of humanity network.

> And there would be a specialized data type added to Chandler,
> which stores those links/categorizations/ratings. And when one
> clicks on a link, it goes to the normal browser, but passed
> through the personal portal page. I doubt that that should be a
> problem.

Yes, I think it will work.

> But, hm, one of the core things that Chandler is about is to
> have a lot of facilities for categorizing items in many different
> ways. And most of what you have in mind doing with links to webpages
> boils down to categorizing them in various ways. So, I'm suddenly
> worrying whether you'd use Chandler's inherent ability to do that, or
> you'll do it elsewhere (in the personal portal) and then import the
> data into Chandler. Where Chandler might be the better place to do it
> in the first place, as I'm sure that will be what it will be very
> ingenious at. This is all not quite clear to me.

We will definitely want to hook into the Chandler categories. Our portal page code will be inside Chandler, so we will have complete access to everything. I am not clear on exactly how the categories will work either, and I've poked around quite a bit. Still, maybe I have just missed the relevant pages. In any case, clearly Chandler will have categories and clearly we want to be in sync with them.

7 Dec 2003 @ 16:02 by Roger Eaton @209.55.71.129 : another [Design] post - has some ideas
Subject:
Re: [Design] Thoughts on a browser parcel
Date:
Sun, 7 Dec 2003 14:14:03 -0500
From:
Selva
To:
Mitchell Kapor ,

Hi Mitch,

Comments in line:

>
> From: Mitchell Kapor
> Date: Tue, 2 Dec 2003 07:19:51 -0800
> To: design@osafoundation.org
> Subject: [Design] Thoughts on a browser parcel
>
> To be able to save clippings or pages to the Chandler repository
> wouldn't seem to require embedding a browser as much as creating a
> conduit between the browser and Chandler.

There may be some powerful advantages in allowing the repository for saving web
clippings be a Chandler edition of OpenOffices Writer application. This of course would
mean that Writer would need to be embedded with a HTML viewing module itself. But doing
so may allow Chandler to become more useful to the end user as described below.

For example, Chandlers version of Mozilla browser could have a button on its toolbar that
allows for saving the HTML version of the displayed web page as a Writer document. Of
course Writer, at this time, does not have powerful HTML editing features so the web pages
saved in this manner would be read only files.

However, employment of a HTML viewing edition of Writer as Chandlers web clipping
repository allows us to add a second button to the Chandler embedded browsers toolbar that
allows for saving just the text of a displayed web page as a Writer document. This of course
allows the user be able to edit the text of the web page just as any other Writer document.

Due to the multi-frame nature of many web pages with embedded advertisements, it would
also be useful if the user could highlight just the portion of the text of a web page that he wants
to save and then select from the right click contextual menu, the option to save that segment of
text as a Writer document.

Furthermore, if the user decides to save a web page as HTML or as text into Writer, then as
soon as the first Save action occurs, Chandler could convert the standard browser interface
into one with two tabbed windows. The first tab would be for the embedded browser itself,
and the second tab would be for the Writer clipboard which displays either the HTML page
or the text of the last clipping. This way, the user could always shuttle between the browser
and the Writer web clipping repository easily and also access the last clipping for editing and
emailing.

Once text from a web page is saved in Writer, it might also be useful if an icon could be
placed in the left hand margin of the Writer document next to the pasted text. Clicking on the
icon could then launch the Chandler browser if its not open already and then take the user to
the URL from which that particular web text clipping was taken from.

Emailing the clippings either as Writer text document attachment or as a HTML attachment or
as PDF attachment might accessed by the user in two ways.

1) This could be done by going to the Writer menu bar and selecting File -> email document
in Writer format, or File-> email document as HTML attachment, or File-> email document as
PDF attachment. Selecting any of these options would of course launch Chandlers email
composition window with the selected Writer file already attached.

2) This could be also accessed from Chandlers email application window using usual
Attach File button in the email composition window.

Rgds,
Selva

11 Mar 2004 @ 20:00 by Casey @129.78.64.100 : web annotation
Roger,

Thanks for the link to your article, it's good to see that some of these issues are being discussed!

I've also been alerted to Gibeo, which has reinvented the web-annotation-wheel. Its implementation relies on proxying and in-page modification, which I feel is flawed. Proxying is flawed because it does not scale (in terms of bandwidth or computation) and in-page modification is less flawed than it is contentious.

I think that using a sidebar gives annotations the credibility and weight that they deserve. If they are highlights/breakouts, then they're just parasites upon the original text. A separate presentation encourages serious posts, and also gives more flexibility to the method of presentation.

Regarding "automated cross posting or simple aggregation", these are two options for showing annotations as part of a personal blog. The first, automated cross posting, would just produce a blog entry for each annotation entry. This duplicates content but allows it to be managed separately, if that's what you want. The second, aggregation, is what Alan expanded upon: Using the existing mechanisms for blog aggregation (XML/RDF), the annotation server can provide individual annotations to be redisplayed independently of their host page.

I'm going to crosspost this comment to your blog just to make my idea more concrete :-)

It definitely seems like web annotation is on the rise!

Other entries in Articles
24 Jun 2007 @ 23:17: Global Assembly now accepting sign ups
26 May 2007 @ 19:26: WiserEarth / Paul Hawken
18 Mar 2007 @ 23:19: Latest InterMix Design
30 Dec 2006 @ 17:53: A Nonviolent Service Arm for the Global Assembly
19 Nov 2006 @ 15:45: Global Assembly Dialog Progress Report
12 Oct 2006 @ 15:49: True Religion Creates Community
1 Oct 2006 @ 18:24: Voice of Humanity and the Information Commons?
24 Sep 2006 @ 22:12: The Outsider has a place in the Global Assembly Dialog
17 Sep 2006 @ 20:44: "Unity and Diversity" and "Unity in Diversity"
11 Aug 2006 @ 05:13: The Wedding of Humanity and Nonviolence

[< Back] [voice of humanity]

[PermaLink]?

Link to this article as: http://blog.voiceofhumanity.net/newslog2.php/_v252/__show_article/_a.htm

Main Page: blog.voiceofhumanity.net

Your Name:
Your URL:	(or email)
Subject:
Comment:
	For verification, please type the word you see on the left: