131160 - Standard way to publish a sitemap

Status: NEW

(SeaMonkey :: Sidebar, enhancement)

Description

[uamjet602]

The article in the URL talks about creating a standard way for sites to publish
their site map, so the browser could present it in a way that would be the same
for all sites.

IMHO a standard for describing a sites structure, and a sidebar displaying that
information would be great. I imagine something like the bookmarks pane, but
with content obtained from the site.

Possible features:
- Describe where you are on the site
- Show what areas you have visited already
  For this it would have to distinguish between pages and areas (groups of pages)
- Show the links and information thats in the link toolbar now.
- Simple, clear, uncluttered. Not stylable by the site to keep it consistent. 
  Not distracting, e.g. no animations.
- No opening/closing folders. Should require as little interaction as possible.

The article also states that we have to wait for IE 8 to get this. Do we?

Comment 1

[Doron Rosenberg (IBM)]

sounds like the linktoolbar. however, this is not a w3c standard. Most likely
invalid (yes, we could future/helpwant this, but no body will actually implement it)

Comment 2

[uamjet602]

Well, favicon.ico is not a standard by any means either, and it was implemented.
The only difference is that IE did already support it.

I'll try to think about a format. If XUL is really as powerful and easy to use
as mozilla.org tries to make me believe, perhaps I can even implement it :)

Comment 3

[Ben Bucksch (:BenB)]

I think this is a great idea. I think, we discussed this before on bugzilla, but
I cannot find it (maybe I just thought about it myself).

As for the standard, we need 2 things:
- A data format for the sitemap. Most likely XML, but which schema? How
expressive may it be?
- A way for the UA to discover the sitemap (url).


doron, this is nothing like the Link Toolbar, just as directional street signs
are not the same as street maps.
And it's certainly not an "invalid" suggestion. The useit alertbox suggests it,
and they are usually very clued.

> - No opening/closing folders. Should require as little interaction as
> possible.

Are you saying that the sitemap (display) should not be hierarchical? If so, I'd
strongly disagree.

Comment 4

[Ben Bucksch (:BenB)]

http://www.mozilla.org/rdf/doc/vocabs.html

Comment 5

[uamjet602]

>> - No opening/closing folders. Should require as little interaction as
>> possible.

> Are you saying that the sitemap (display) should not be hierarchical? If so, I'd
> strongly disagree.

From the article:
The greatest failures in our study came from site maps that attempted to lure
the user into a dynamically twisting and expanding view, rather than presenting
a simple, static representation of the information architecture. The site map's
goal is to give users a single overview of the information space. If users have
to work to reveal different parts of the map, that benefit is lost. 

There is a point in that.

Comment 6

[Ben Bucksch (:BenB)]

Before discussing about the graphical representation (which should IMO be open,
if that wants to be a standard), we should find a way to describe sites in
general, i.e. define the data format.

Is there any preceding discussion (by IETF, W3C, on Usenet or wherever) about
this topic?

The requirements I would set are:
- It must be able to sufficiently describe any significant organisation of
sites, existing and coming, i.e. any percievable, sensible structure of sites,
for whatever purpose, should be representable in the sitemap file.
- Any given file sitemap file should be easy to understand. There is IMO no
point in adding each internal link the site has to the sitemap file, because I
don't think that UAs could make something comprehensible out of it.
- The file format should be relatively simple.
Together, this means that the file format should be very flexible.

Note that not everything in the sitemap file necessarily has to be displayed by
the browser at the same time or at all.

Comment 7

[Minh Nguyễn]

This sounds like Aurora: http://wp.netscape.com/browsers/future/aurora.html .
According to http://www.mozillazine.org/screenshots/alookback.html , sitemaps
were once in Mozilla, but disappeared by August 1998. I remember reading an
earlier, unabridged version of
http://wp.netscape.com/browsers/future/aurora.html that said the sitemaps were
powered by RDF. I haven't been around Mozilla long enough to know much about
this, however.

Comment 8

[Ben Bucksch (:BenB)]

<http://www.mozilla.org/xpapps/aurora/>

Comment 9

[Christopher Hoess (gone)]

I'll have to look into this, but I think there's a link type designated in one 
of the early standards or internet-drafts to point to a navigational aid. That 
would be one piece of the puzzle, at least.

Comment 10

[Ben Bucksch (:BenB)]

Right, there was, it was link-type "sitemap", IIRC. It might be good to use. It
didn't specify a file format, though. We'd have to specify that.

Comment 11

[Asa Dotzler [:asa]]

->default contacts

Comment 12

[Thomas K. (:tom)]

It would need to be able to read the google standard:
https://www.google.com/webmasters/sitemaps/docs/en/protocol.html

Comment 13

[Thomas K. (:tom)]

Since no one objects, changing summary.

Comment 14

[Ben Bucksch (:BenB)]

No, changing "Standard way to publish a sitemap" to "Ability to display Google Sitemaps as navigational tool" is changing the meaning of this bug entirely, because Google sitemaps do not express hierarchy (logically). They are not a proper sitemap for humans, but just a list of pages that the Google spider should update regularly. Changing back to original topic.

FWIW, if done right, I still think that this would be one of the best possible usability improvements for Firefox and the web as a whole. In-page structure can how be expressed properly in HTML via <section>, but we're lacking a way to express the structure above the page level, and thus can't present it in a consistent way either.

Comment 15

[Ben Bucksch (:BenB)]

In-page structure: I was referring to http://www.w3.org/html/wg/html5/#the-section
(This also shows that the map standard needs to be done right to be used, because <h1> was silly and thus not used.)