193563 - [RFE] Prefetched links should be listed in a separate folder on Site Navigation Bar

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Sergey Sokoloff]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

Link prefetching, which was first introduced in Mozilla 1.2, actually provides
an alternate method of navigation. Instead of browsing the whole loaded document
and searching for hyperlinks, one may expect that those links more likely to be
followed are already in the prefetching list. That's why, for any user reading a
page which uses prefetching, it's worth looking through the pull-down menu of
prefetched content. (It really helps answering the most frequent question "So
where am I supposed to go next?")

Unfortunately, nowadays those link titles (I mean text inside <link title="">,
when rel="prefetch") are buried deep inside Mozilla Site Navigation Bar. For
example, <link rel="prefetch" href="url" title="Page Title"> needs three clicks
to be accessed: "More" on Site Navigation Bar, then "prefetch", and finally
"Page Title". That's too much. And someone (I mean someone who is really new to
prefetching) may not even expect finding prefetched content in "More" folder,
and the new navigation ability will be lost.

Let's make it usable, make it easy to be understood. What if Site Navigation Bar
had a separate folder for prefetched content, like already existent "Document"
and "More" folders? We could call it "Prefetched content", or even "Instant
access", that's really self-explanatory, anyone is able to understand it.

Having all prefetched links in a separate folder has some additional advantages,
not to mention the obvious effect on usability. There's a way ahead, previously
locked by grouping a bunch of mutually unrelated links together in "More". May I
suggest, for example, a prefetching progress indicator? At least, an icon in
that "Instant access" list may be altered slightly when the corresponding link
is finished (i.e. its content is prefetched entirely). I wish I could see the
progress even when the folder is not open. By means of a progress bar put on
Mozilla Site Navigation Bar, or numbers added next to the folder name, or anywhat.

There would be a real help to distinguish one link from another in that menu. Is
it already prefetched or not? What if I click on it, will it be a really instant
teleport or not? Right now there's now answer. It's like playing the notorious
Russian Roulette. And hell I'm Russian, and still I don't like it. Prefetching
must be improved... I mean its interface, the prefetching itself is quite fine.

And I insist on changing the term also. "Link prefetching" is about the process,
but the folder would be named after its advantages, to be much more obvious:
"Instant access", "Click-and-read", "Jump to...", "Immediate view", "Browse
now"... there are lots of suitable names. Follow the KISS principle.

Note: this RFE makes Bug 183703 obsolete, and that bug is now to be rather
considered a feature. I'll mark Bug 183703 INVALID.

Reproducible: Always

Steps to Reproduce:
1. Uncheck "View -> Show/Hide -> Site Navigation Bar -> Hide Always" item.
2. Load any webpage containing prefetched <link> tags.
3. Quick, where the titles of prefetched content are stored? What of them are
prefetched already (and it is possible to read the page instantly) and what are
being prefetched yet?
Actual Results:  
I expect it will be difficult for a newbie to find them under More -> prefetch.
It isn't really natural. And there's no way now to find what links are
prefetched, what are not, and what is the total progress percentage.

Expected Results:  
To help some people with telepathical disabilities, the new navigation method
must not be so hidden. And some progress bar must appear. May it be in status
line, as suggested in Bug 192304, or in the right side of Site Navigation Bar,
near the click-and-read folder.

Comment 1

[Sergey Sokoloff]

Hardware -> All

Comment 2

[Brant Gurganus]

In my opinion, the prefetch links should not appear in the Site Navigation Bar
at all.  Their purpose is to preload the page so that when the user decides to
go to that page, it loads more quickly.

CC'ing links toolbar and prefetch people

Comment 3

[Brant Gurganus]

Attachment: doesn't show prefetch in toolbar

If it is decided that the link toolbar should not show prefetch links, this
patch should take care of that.  I added prefetch in the same expression that
hides stylesheet, icon, and similar link types.

Comment 4

[Brant Gurganus]

Comment on attachment 116718 [details] [diff] [review]
doesn't show prefetch in toolbar

I don't know if the reviews are by the correct people, but Gerv seems to have
done a lot of the original Link Toolbar work and Boris seems to have reviewed
many of the original patches.

Comment 5

[Sergey Sokoloff]

If it is decided that the link toolbar should not show prefetch links, the new
ability of navigation via menu of prefetched content titles (as described
above), which was introduced first in Moz1.2, is going to be lost.

I've filed the bug to improve it - not to kill it.

Comment 6

[Gervase Markham [:gerv]]

I'd say that Brant is right. What we should do is hide prefetch links
completely, because they are a hidden internal mechanism, like stylesheets. If
you want the prefetched URL to appear somewhere on the bar, add a second <link>
element pointing to the same resource.

Often, the correct link to fetch is the one with "rel='next'" anyway. Hmm. How
would we handle 
<link rel="next prefetch" ...>
with Brant's patch? 

Gerv

Comment 7

[Sergey Sokoloff]

May you file another bug for that patch Brant Langer Gurganus offered? At least
it doesn't look like fixing my RFE.

And, you know, I also have an arguement against hiding "prefetch" the same way
"stylesheet" and "shortcut icon" are hidden. Note that stylesheets and icons are
something that user doesn't want to see anyway, they are system files affecting
current page. Prefetched pages are different, we have already Bug 192304 that
there's no visible sign of prefetching, and if we loose "prefetch" in More, then
there is nothing visible at all, there's no way to find out, if there is any
prefetching at all, how many pages are prefetched, what are they. Since
prefetched pages are different from normal (and one may follow the link
instantly), there should be an easy way to see the difference.

And, probably, there should be alternate navigation method also, which involves
prefetched links only. This is what we have already, via More -> prefetch. All
thar I requested was to enhance the already existing navigation, to make it more
visible, not so hidden.

Comment 8

[Gervase Markham [:gerv]]

I don't think it's necessarily true that we want to indicate to a user that a
link is rel=prefetch. For a start, marking it as such does not guarantee that
Mozilla will prefetch it. Even if Mozilla is going to, we do not know if it has
or not - and, if prefetching is not complete when the user navigates away from
the page, the partial prefetch is thrown away.

So, any indicator based on this which says "These links have been prefetched for
you" would be wrong. 

The way I see prefetch, is should be a mechanism that page authors use to
silently make the surfing experience more pleasant for their users. The users
should not be bothered at all by this. 

The question "So where am I supposed to go next?" is answered by the <link
rel="next">. So, I would say this RFE is WONTFIX, and Brant's patch is something
we want - although he needs to address the comments in my review about what
happens with <link rel="next prefetch">. 

Gerv

Comment 9

[Darin Fisher]

> or not - and, if prefetching is not complete when the user navigates away from
> the page, the partial prefetch is thrown away.

this is an incorrect statement.  provided the server supports byte range
requests, mozilla will store a partially prefetched document.  when the document
is requested "for real" mozilla will only request the range of bytes that were
not previously downloaded.

otherwise, i agree with what gerv said.  prefetching is not intended to be silent.

Comment 10

[Darin Fisher]

> otherwise, i agree with what gerv said.  prefetching is not intended to be 
> silent.

prefetching IS INTENDED to be silent :-/

Comment 11

[Gervase Markham [:gerv]]

Apologies for the misstatement about the way prefetching works; I must have
misremembered some comment somewhere, or failed to remember the
byte-range-request qualification.

Anyway, this should be WONTFIX, but Brant should open a new bug for his patch
(or the fixed version of it.)

Gerv

Comment 12

[Brant Gurganus]

I am resolving this as WONTFIX per comments.  I open bug 197623 for discussions
on not showing prefetch links in the toolbar.

In response to Gerv:
rel="next prefetch" is superfluous as rel="next" is prefetched according to the
FAQ.  I will take a closer look at the JavaScript file when I get CVS running again.

Comment 13

[Brant Gurganus]

I am resolving this as WONTFIX per comments.  I open bug 197623 for discussions
on not showing prefetch links in the toolbar.

In response to Gerv:
rel="next prefetch" is superfluous as rel="next" is prefetched according to the
FAQ.  I will take a closer look at the JavaScript file when I get CVS running again.