Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[RFC] LiveURLs Firefox extension

3 views
Skip to first unread message

Natarajan K

unread,
Apr 20, 2006, 1:47:54 PM4/20/06
to dev-apps...@lists.mozilla.org, Toufeeq Hussain
Hi,

We at InfyLUG, the Infosys [1] Linux User Group have been working on a
Firefox extension called LiveURLs [2] which lets users create links to
user selected portions of web pages. This adds dynamism to plain URLs
and hence the name "LiveURLs". This extension uses the fragment
identifier of the URL to achieve this.

Though LiveURLs was started to scratch a personal itch, we realize
this concept can be leveraged by both HTTP clients and servers.
Currently, our work focusses only on browsers. The project
development page is here [3]. The concept/technology behind the
extension is briefly described here [4]. At this point, we request
help from the Firefox/Mozilla community on the following areas.

- Feedback about the concept and it's possible usage/applications in browsers
- Alternate and better implementations of the concept
- Usability suggestions
- Testing and Bug reports [5]

In addition to Firefox, we also feel that the following projects will
benefit from this or a similar implmentation of this concept.

- Annozilla [6], Annotea [7], diigo.com [8] (Web based annotation services)
- Search Engines which can provide content specific links
- Content specific bookmarking

Feel free to provide your valuable feedback on the LiveURL's mailing
list [9] or to this thread.

Links:
[1] http://www.infosys.com
[2] https://addons.mozilla.org/firefox/2400/
[3] http://liveurls.mozdev.org
[4] http://liveurls.mozdev.org/tech.html
[5] http://liveurls.mozdev.org/bugs.html
[6] http://annozilla.mozdev.org/
[7] http://www.w3.org/2001/Annotea/
[8] http://diigo.com
[9] http://liveurls.mozdev.org/list.html

More information/discussion here:
[1] http://knutties.livejournal.com/24270.html

Thanks,
Natarajan & Toufeeq
Infosys Technologies Limited
www.infosys.com

Mike Beltzner

unread,
Apr 20, 2006, 2:42:23 PM4/20/06
to Natarajan K, Toufeeq Hussain, dev-apps...@lists.mozilla.org
On 4/20/06, Natarajan K <nataraja...@infosys.com> wrote:
> Hi,
>
> We at InfyLUG, the Infosys [1] Linux User Group have been working on a
> Firefox extension called LiveURLs [2] which lets users create links to
> user selected portions of web pages. This adds dynamism to plain URLs
> and hence the name "LiveURLs". This extension uses the fragment
> identifier of the URL to achieve this.

I like the idea, since there are many cases where users want to point
to a specific section of text that isn't helpfully marked by an
internal anchor. I'm not sure why you'd call them "Live" URLs, though.
The word "live" indicates that the URL is changing, dynamic, updating
itself ... this is really more of a web pointer or a web highlight.
Not that naming is the biggest issue here, but something to consider
in terms of making it easier for users to understand what this
function will do.

> - Feedback about the concept and it's possible usage/applications in browsers

We might want to add this to the bookmarking service as well. So if
text on a page is highlighted, and then the user asks to create a
bookmark, the bookmark should point to that section of text.

> - Alternate and better implementations of the concept
> - Usability suggestions

I'll play more with the extension and expand on these a little later today.

cheers,
mike

--
/ mike beltzner / user experience lead / mozilla corporation /

Laurens Holst

unread,
Apr 20, 2006, 9:52:13 PM4/20/06
to
Hi,

Natarajan K schreef:


> We at InfyLUG, the Infosys [1] Linux User Group have been working on a
> Firefox extension called LiveURLs [2] which lets users create links to
> user selected portions of web pages. This adds dynamism to plain URLs
> and hence the name "LiveURLs". This extension uses the fragment
> identifier of the URL to achieve this.

Do you know about the W3C recommendation XPointer?

http://www.w3.org/TR/xptr-xpointer/
http://www.w3.org/TR/xptr-element/

There’s also a scheme for XPath (xpath1()).

Mozilla supposedly already has this implemented for XML/XHTML documents
(although I have never gotten it to work properly). See:

http://developer.mozilla.org/en/docs/XML_in_Mozilla#Other_Supported_XML_W3C_Recommendations

Now this only works in XML. I don’t know the syntax of the links that
‘LiveURLs’ creates, but I think it would be worthwhile to use the public
standard for such functionality instead of something custom-made, and
add apply XPointer to HTML documents.


~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.

lholst.vcf

Natarajan K

unread,
Apr 21, 2006, 12:33:38 AM4/21/06
to Mike Beltzner, Toufeeq Hussain, dev-apps...@lists.mozilla.org
On 4/21/06, Mike Beltzner <mbel...@gmail.com> wrote:

> I like the idea, since there are many cases where users want to point
> to a specific section of text that isn't helpfully marked by an
> internal anchor. I'm not sure why you'd call them "Live" URLs, though.

When we started on this project, in addition to locating content, we
had planned to put in processing semantics like highlighting/zoom etc.
Since an action portion was also involved, we felt "Live" URL was
more approriate .

> The word "live" indicates that the URL is changing, dynamic, updating
> itself ... this is really more of a web pointer or a web highlight.
> Not that naming is the biggest issue here, but something to consider
> in terms of making it easier for users to understand what this
> function will do.

Agree totally. We are realizing this from the reaction and comments at
https://addons.mozilla.org/firefox/2400/. The name "LiveURLs" by
itself does not convey that we are doing some sort of web-pointing.
We'll work on it.

> We might want to add this to the bookmarking service as well. So if
> text on a page is highlighted, and then the user asks to create a
> bookmark, the bookmark should point to that section of text.

The user could just bookmark the LiveURL. The LiveURL already is a
pointer to that section of the text :)

Thanks,
Natarajan
--
http://puggy.symonds.net/~natarajan

Toufeeq Hussain

unread,
Apr 21, 2006, 1:20:50 AM4/21/06
to Laurens Holst, dev-apps...@lists.mozilla.org
Hi Laurens,

On 4/21/06, Laurens Holst <lho...@students.cs.uu.nl> wrote:
> Do you know about the W3C recommendation XPointer?
>
> http://www.w3.org/TR/xptr-xpointer/
> http://www.w3.org/TR/xptr-element/
>
> There's also a scheme for XPath (xpath1()).
>
> Mozilla supposedly already has this implemented for XML/XHTML documents
> (although I have never gotten it to work properly). See:
>
> http://developer.mozilla.org/en/docs/XML_in_Mozilla#Other_Supported_XML_W3C_Recommendations

Yes. We were aware of Xpointer and it did figure in one of our (very
early)implementations.
We had used Xponiterlib to achieve this.We are trying to figure how
best to represent the Xpointer as the fragment id and represent it as
a LiveURL.

http://xpointerlib.mozdev.org/

Xpointer usage for LiveURL's was picked up from here.
http://xpointerlib.mozdev.org/examples.html

> Now this only works in XML. I don't know the syntax of the links that
> 'LiveURLs' creates, but I think it would be worthwhile to use the public
> standard for such functionality instead of something custom-made, and
> add apply XPointer to HTML documents.

The "position based LiveURL" is DOM based and actually replicates the
Xpointer capability.One of our goals was also to ensure that the
length of the fragment identifier remains constant irrespective of the
text selection. More information on the "position LiveURL" is
available on the tech page of liveurls.

http://liveurls.mozdev.org/tech.html#search+5%20%20Pos19+1e153cd3 (liveurl :)

Our goal also is to follow standards.If we are able to extend XPointer
to LiveURL's that would be good.But LiveURL's which depends on DOM
have a few limitations as they are very dependent on the DOM structure
and any modifications in the DOM structure might result in the failure
of the LiveURL.Some limitations are listed here.

http://liveurls.mozdev.org/tech.html#search+5Limit1a9+55af4ac3 (liveurl again :)

Thanks,
Toufeeq
--
blog @ http://toufeeq.blogspot.com

Toufeeq Hussain

unread,
Apr 21, 2006, 10:16:18 PM4/21/06
to Mike Beltzner, dev-apps...@lists.mozilla.org
Hi,

On 4/21/06, Mike Beltzner <mbel...@gmail.com> wrote:

> > - Feedback about the concept and it's possible usage/applications in browsers
>

> We might want to add this to the bookmarking service as well. So if
> text on a page is highlighted, and then the user asks to create a
> bookmark, the bookmark should point to that section of text.

This is an interesting idea and definite value-add to the Firefox
bookmarking system.I found one such use case on the 'Bookmarks Use
Cases' section of the Mozilla Wiki.

http://wiki.mozilla.org/Bookmarks_Use_Cases#search+5Visua80+7e0a86c3
(http://wiki.mozilla.org/Bookmarks_Use_Cases#Visual_Bookmarks)

Though it talks about using images for creating the "snapshot", with
LiveURL's, the position of the page or the content selected during
bookmark creation can be re-created when the bookmark is re-loaded.

-Toufeeq

Brian Rakowski

unread,
Apr 25, 2006, 1:20:53 PM4/25/06
to
You're probably already aware of this but since I didn't see it
mentioned here, there was a study published on something very similar
called Landmarks. The writeup is nice and short:
http://doi.acm.org/10.1145/1056808.1056978

ABSTRACT
Re-finding information on the Web is a common yet often
time consuming and challenging task. Even with the use of
traditional bookmarks, which allow users to return to a
previously visited page, it can be hard to re-find facts
within that page. Furthermore, it is not uncommon for users
to have long and unmanageable lists of bookmarks, making
it difficult to identify the purpose of individual bookmarks.
In this paper, we present an extension to traditional
bookmarks called landmarks, a user-directed technique that
aids users in returning to specific content within a
previously visited web page. We investigate the efficiency
of landmarks for re-finding information on web pages and
present the findings of a study in which participants were
first primed on two web pages and returned at a later date to
re-find the information using both traditional bookmarks
and landmarks.

Natarajan K

unread,
Apr 25, 2006, 2:28:17 PM4/25/06
to dev-apps...@lists.mozilla.org
On 25 Apr 2006 10:20:53 -0700, Brian Rakowski <brianr...@gmail.com> wrote:
> You're probably already aware of this but since I didn't see it
> mentioned here, there was a study published on something very similar
> called Landmarks. The writeup is nice and short:
> http://doi.acm.org/10.1145/1056808.1056978

Brian,

We had'nt seen that earlier. Thanks a lot for the link. The paper
does mention that a customized version of Internet Explorer was used
to record landmarks, but I could not find details how landmarks are
implemented. It would be great/enriching to know how landmarks are
implemented. Maybe I should get in touch with the authors.

Splibbilla

unread,
May 8, 2006, 3:03:23 AM5/8/06
to
upthread:
>>http://wiki.mozilla.org/Bookmarks_Use_Cases#Visual_Bookmarks

an amazing collection of ideas on that page. after absorbing the ideas, probably need visual layout to best merge the ideas.

common idea: when bookmarking, provide a "keywords, not folders" type of categorizing (as gmail uses) for some quick
categorizing mouseclicks.

this reminds me of a wishlist+brainstorm, regarding when user chooses folder in which to drop bkmk:
i'd prefer single-click to choose among the few recent bkmk folders, rather than choosing via pulldown as in ff1.5.
The minefield/ff3 add-bookmark dialog provides a short list (this list appears not yet "polished", but i assume future firefox
add-bkmk dialog will list recent folders).

in keyword system, user could add/alter default keywords of that list. and could mouseover +/or mousebutton, down or up
quickly choose keywords? (though this resembles gestures, which are tricky for people who don't like them.)

hover could select a keyword, but clicking one of these keywords (a "rootword"?) could open branch to more specific keying?


"Brian Rakowski" <brianr...@gmail.com> in news:1145985653....@i39g2000cwa.googlegroups.com:

> You're probably already aware of this but since I didn't see it
> mentioned here, there was a study published on something very similar
> called Landmarks. The writeup is nice and short:
> http://doi.acm.org/10.1145/1056808.1056978
>
> ABSTRACT
> Re-finding information on the Web is a common yet often
> time consuming and challenging task.

have you notice that cached and newsgroup urls on google include the webpage (or gg news archive) url, but also include the
searchphrase at tail of the url? ***

i'd expect other searchsites use similar system, and i assume there is no "standard", but it suggests a possible informal
standard...

And then teh bookmark manager (bkmn) could extract phrases (broken or exactphrase) from searchphrase part of URL. when
user saves marks, the bkmn offers keywords from url searchphrase as suggested mark keywords. searchphrases should be
good keywords because (i think) peoples' brains attempt to reuse search terms they've previously used (if previously used is
recent, not 32 years preceding :-) )

one (unavoidable?) drawback, is that the tail terms in the saved mark represents *successful* searchphrases, and the search
may have succeeded only after many unsatisfactory searchphrases. brains tend to reattempt the same initial searchphrases.
example:
i begin with searchphrase:
braindrain-at-midnight
and the search engine gives me nothing i like, so then based on the best excerpts of these unsatisfactory results, i edit my
searchphrases during the next 40 minutes (persistence!) until ... i find some webpages i want to mark. but my final *successful*
searchphrase might be:
noggin | grey-matter daily laundry-backup

complication: the url's of everyday webpages wouldn't contain the searchphrase tail. so, from where would bkmn extract its
suggested category-words? from in-browser data of tab-click paths? **

yeah, so where can bkmn find likely categorywords?
people usually visit webpages via:
1 link on another non-search/directory webpage - I wouldn't expect webpage's "meta" words to provide bookmark
categorywords that user likes.
2 search results page - could contain categorywords in url.
3 existing bookmark - bookmark already has its own category words. Also, as soon as it's visited in browser, this bookmark
becomes 1 or 2 in this list. (the user can decide whether its categorywords are good for the new mark, but also, recognizing the
offered categorywords' association to the existing bookmark, user might feel urge to change *its* category words.)
4 link on local page (such as a software helpfile?) - where can bkmn look to find likely categorywords?
5 url directly entered into addressbar - provides no new categorywords to bkmn
6 ??


>Even with the use of
> traditional bookmarks, which allow users to return to a
> previously visited page, it can be hard to re-find facts
> within that page. Furthermore, it is not uncommon for users
> to have long and unmanageable lists of bookmarks, making
> it difficult to identify the purpose of individual bookmarks.

... inciting that concept of database bookmark manager. (there is "aftermarket" bookmark software, though i have'nt tried any of
it much)

> In this paper, we present an extension to traditional
> bookmarks called landmarks, a user-directed technique that
> aids users in returning to specific content within a
> previously visited web page. We investigate the efficiency
> of landmarks for re-finding information on web pages and
> present the findings of a study in which participants were
> first primed on two web pages and returned at a later date to
> re-find the information using both traditional bookmarks
> and landmarks.
>

ran out of time to further clarify this post... sorry... (assuming anyone's reading this, anyway :-) )

--
**Bloat Happens; no need to request it in any wishlist. but tabmixplus, and maybe other extensions, *already* have session-
savers which include saving history for each tab.

*** which is a type of clicktracking, ugh.

0 new messages