Closed Bug 103034 Opened 23 years ago Closed 16 years ago

Evangelism - Get more sites to support <link>

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: gerv, Unassigned)

References

Details

(Whiteboard: aok) 

We now have a links toolbar. Auto-show support is in now, and will be available
tomorrow. It works, and is extremely useful, in Bugzilla bug lists. It would be
really cool if more sites supported it - 
search engines (Google, Altavista, Netscape, Yahoo), 
news sites (Slashdot, Kuro5hin, BBC), 
online newspapers (Telegraph, Times, New York Times, Wall Street Journal)

etc.

The possibilities are endless. From a Mozilla point of view, the more sites
implement logical navigation, the better. (From a Netscape point of view, if we
can get a bunch of sites using this in time for MachV, it will be a far more
trumpetable feature.)

In most cases, it's merely a replication in <link> tags in the <head> of the
same info that's already in <a> tags in the body. So it's not a major code change.

This bug has been filed to get the advice and help of the evangelism team in
this effort.

Gerv
Since bug 103082 has removed the links toolbar, I think we can put this off for
a while.

While increasing support for the more general uses of LINK is a good idea, I
think there are many other areas where evangelism is needed in terms of
communicating with site owners, developing documentation, tools, etc.

We still have to contend with the immediate fact the market share of Gecko based
browsers is still very small and we are having difficulty getting site owners to
update their content to support Mozilla/Gecko.  Adding additional requests for
site maintenance tied to a feature that is only supported by very recent Mozilla
builds will be a hard sell.

Considering that www.mozilla.org is for and about Mozilla, I think we can use
this feature on our own documentation first.  We can then begin the process of
educating site developers on the usefulness of LINKs by demonstration. 

Finally, I don't understand how a general search engine could use LINK
effectively. The LINKs would have to be inserted into the pages returned by the
search engine wouldn't they?
> I think we can put this off for a while.

I disagree. Jag made the excellent point that we should have had sites
supporting <link> before we even launched the toolbar. Let's not make the same
mistake twice.

> that is only supported by very recent Mozilla builds

And iCab :-) It's been in the HTML spec since HTML 2.0.

> will be a hard sell.

If it involved any major changes to pages, it would. But, as I said, it's merely
a replication of information and therefore, in most cases, not hard to add.

> I don't understand how a general search engine could use LINK effectively.

Anything that has a sequence of numbered pages could use <link> effectively.
Google returns 20 pages of search results <link> them together. It would be a
trivial server-side change for them, as I outlined in the original comment.

Gerv


It is hard to sell any maintenance to sites where there is no immediate benefit
to them to perform the maintenance. We can promote the idea but I don't see that
it is a very high priority issue now. 

I think using the idea on www.mozilla.org will help demonstrate it's usefulness
and help fine tune the implementation since we will gain experience from it's use.

I can see this being useful for documents in general that have an ordered
sequence of pages, but I still don't see how a general search engine would use
this. Google may return a list of pages, but those pages are owned by other
sites and do not contain the sequence info from the Google search. For this to
work in a general search engine, the retrieved pages would have to be retrieved
by the search engine, then modified to insert the LINKs (which would point back
to the search engine themselves), and then return the result to the user.  I
don't consider that a minor issue for the search engine, for the site whose
content is being retrieved nor the person doing the search.
Bob: for search engines, I believe the idea was to put the <link> tags in the
search results pages (much like they have custom navigation controls in there
right now), instead of in the actual pages they've found.
Yes, exactly :-) Google are friendly towards Mozilla, and very popular. We could
start with them.

Gerv
Ok. I get it now. Do we have a contact for them?
I got email from googletech@google.com about their XUL toolbar - that was signed: 

Regards,
The Google Team
 
So that might be a good place to start. CCing a couple of people who might have
time to write a short explanation and fire it off to a few well-selected emails.

Gerv
I've emailed LWN but got no response - that was back way before the toolbar was
checked in, though. I'll follow it up after 0.9.5 gets released, especially if
it's defaulted to autoshow in the release.

To be honest, I don't think the outlook is as bad as it could be anyway -
already it's quite rare for me to find myself thinking "I wish this site had
links" on a site that doesn't. The places that could really stand to benefit -
mailing list archives, texi2html'd documents etc - already seem to have it.

The best bet for mainstream corporate-owned sites would be some kind of official
contact from The Behemoth That Is Netscape-AOL-TimeWarner. Are the appropriate
people for that kind of corporate evangelism on this bug yet?
Attaching to the tracker bug so we can keep an eye on this.  Wouldn't another 
angle of attack be web-design sites?  Once whatever products have been made 
from 0.9.5 appear, they might be interested in writing articles on how to take 
advantage of this new feature of $PRODUCT...
Blocks: 103053
Does anyone feel like drafting a form letter? Someone with previous evangelism
experience would probably be good.

Gerv
Summary: Get more sites to support <link> → Evangelism - Get more sites to support <link>
I think we should start by making a "how to use <link> elements effectively" 
document for www.mozilla.org rather than by contacting speicifc sites.

Other Mozilla features we should encourage web authors to take advantage of:
- the ability to have a different alt= and title= for images
- <abbr title=> and other elements that get dotted underlines
- accesskey (IE supports accesskeys better, but Nav4 didn't have them at all)
- alternate stylesheets
- any interesting CSS2 features that might be popular if authors had heard of 
them
- XUL: make your web page feel like part of the browser

These could be lumped with documents related to traditional tech evangelism, 
such as "how to convert old JS to cross-browser JS" and "what Nav4/IE quirks 
Mozilla doesn't support and why", or they could be separate.
Well, why not widen the scope of this bug a bit? :-)

Seriously, if the evangelism team want to do "cool stuff evangelism" as well as
"your site is broken" evangelism, that would be great. But I don't want the
grand plan to stop the small one, which is to mail the tech teams of a few
well-chosen sites asking them to implement <link> support.

Gerv
Considering that the evangelism team has more than enough "your site is broken"
issues, -> Future. If anyone would like to contact Google or anyone else about
adding support for links, please feel free to take this bug.
Target Milestone: --- → Future
I think sites will be quick to pick it up. Webmasters are very enthusiastic
about any possible way to influence the user's UI.

We just need some initial documentation, if possible on some large site (e.g.
WebMonkey).
Also note that some of the buttons we have in the Site Navigation Bar aren't
defined in the Link Types section of W3C's HTML 4.01. For example, the Up
button, the First button, the Last button. We need our own page outlining what
LINK types we support and how they correspond to the UI buttons.
I agree with the idea. Mozilla is also there to support standards. So why not
push them as well?

I would like to point out that there are many open source programs that generate
pages that could have use of Links. 

I am thinking of Open Source search engines: 
- mnoGoSearch (Debian) [http://search.mnogo.ru/]
- swish-e (Apache) [http://swish-e.org/]
- ht://Dig (KDE) [http://www.htdig.org/]
- ...

Another field would be sites programs that generates HTML. I am thinking of
programs like latex2html.

E.g. http://cbl.leeds.ac.uk/nikos/tex2html/examples/IRCprimer1.1/IRCprimer1.1.html

We are open source developers. We can improve these programs so that they
generate <link> tags. Before dealing with closed 'software', let's push adoption
by improving standards thanks to Open Source.
Jerome: thank you for volunteering to help! If you could draft a letter, that
would be great. You may want to link to choess' draft document on link types.

Gerv
Gerv, where *is* "choess' draft document"?  I just added LINK tags to <a
href="http://sincerity-forever.lcs.mit.edu/photo/pcd0262/">some of my
(mostly-automatically generated) photo pages</a>, and I looked all over for any
kind of documentation on just what LINK tags were supported.  The W3 has <a
href="http://www.w3.org/TR/html4/types.html#type-links">a short description</a>
on the basic next/prev/start/etc types, a <a
href="http://www.w3.org/TR/html4/present/styles.html#style-external">description
of using LINK to implement alternate style sheets</a>, and a short discussion of
<a href="http://www.w3.org/TR/html4/struct/links.html#linksandss">providing
indexing hints to search engines using LINK</a>, but it's hard to sort through
this information.  Basic usage examples are omitted, as well: nowhere is it
stated how to use the "Chapter" LINK (for example) to actually create chapters
in a document.  A central home for this information is badly needed.
choess should be able to point you at it himself :-) His document is exactly
what you are asking for.

Gerv
Whiteboard: aok
Mass reassign of all tech-evangelism us general bugs assigned to bc to 
doron except bc's P1 bugs. You may search for this mass reassign (it is 
305 bugs) by searching for the keyword 'greeneggsandham'
Assignee: bclary → doronr
Target Milestone: Future → ---
Depends on: 103469
tech evang june 2003 reorg
Assignee: doron → english-us
QA Contact: zach → english-us
This ship has sailed.

Gerv
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Says who?
Says me, and I filed the bug. Firefox has no UI for the <link>s in question, and won't have. There's not much point in evangelising it without that.

Gerv
Though the SeaMonkey suite does.

However, the lack of comments for about five years does seem to show lack of interest.  It's a shame.
(In reply to comment #24)
> Says me, and I filed the bug. Firefox has no UI for the <link>s in question, 
> and won't have. There's not much point in evangelising it without that.

Yes, Fireforx has no UI for the <link>s in question.  I don't primarily use Firefox (but SeaMonkey) but for tests I use the Link Widgets <https://addons.mozilla.org/firefox/addon/2933> extension which is really nice.  It would be great if it could be integrated into the standard code base.
Talk to the SeaMonkey devs.

The closure of this bug doesn't prevent anyone going out and doing some <link> evangelism if they feel it's a good use of their time. You don't need a bug for that. Enough, already.

Gerv
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.