408640 - Use eTLD+2 for downloads

Status: VERIFIED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[Ed Lee :Mardak]

Well, what are we trying to show with the domain info to begin with? Help the user find a download that s/he previously downloaded?

Most sites use a single level of subdomain and they can mean very different things.

E.g., Gmail attachments show up as google.com as well as anything else saved from google searches like pdfs from scholar, etc. Knowing that something came from mail.google vs scholar.google would be pretty useful -- especially when searching.

But as dolske pointed out.. going from eTLD+1 to +2 doesn't really solve the whole problem... Do we really want eTLD+x?

Comment 1

[Ed Lee :Mardak]

Attachment: screenshot of v1

Comment 2

[Jesse Ruderman]

eTLD+2 sounds weird and confusing.  Why not just show the whole hostname?

Comment 3

[Ed Lee :Mardak]

How about eBD+1 instead of eTLD+2? ;) Base domain + 1 subdomain. (Well.. is it still 'effective' base domain? hrmm..)

* Reason for eBD+1 over eBD
- Many sites use subdomains for different services like mail, groups, scholar for google or ftp, build, archive, stage, bonsai, hg, bugzilla, people, addons for mozilla.
- Subdomains are usually very different from each other: see above and sites like *.livejournal or *.googlepages where each subdomain is a different user

* Reason for eBD+1 over hostname
- Keeps things short and precise if the site has many levels of subdomains.
- mconnor gave an interesting example of load balancing sub-subdomains like ca.f881.mail.yahoo.com

Comment 4

[Shawn Wilsher :sdwilsh]

I think we'd get to a point where too much information is a bad thing.  I think the case can be easily made for eTLD + 2, but anything more than that, and I'm fairly skeptical.

Comment 5

[Madhava Enros [:madhava]]

My preference here is to go with the eTLD+1 (i.e. mozilla.com).  More than that, even as in the screenshot in comment #1, and we start to complicate the interface and dilute the _really_ useful information.  The goal here is not to tell a user exactly where the download came from but rather is (a) to help him or her remember what the download is about and (b) to help the user search for downloads from a specific site.

Comment 6

[Shawn Wilsher :sdwilsh]

For a, seeing that I download something isn't useful at all, but mail.google.com implies that I got it from my e-mail.

Comment 7

[Justin Dolske [:Dolske]]

I think eTLD+1 is removing useful information, although I suppose I can see the design justification for that.

Often the stuff above eTLD+1 is the only useful info... foobar.livejournal.com / foobar.googlepages.com as in comment 3, foobar.sourceforge.net, foobar.garage.maemo.org, foobar.randomwebhosting.com. "Foobar" is the only relevant thing to jog my memory of what's being downloaded in these cases. Specific recent example: Downloading the latest Firebug beta from http://fireclipse.xucia.com/. The "xucia.com" bit is meaningless to me (and I had to search awesomebar for "fire" to even remember the URL :-).

I don't think eTLD+2 (or +3, etc) would be a proper fix here, though, should we decide eTLD+1 is removing too much info. +2 isn't really fixing that problem -- just show the full hostname, perhaps with eTLD+1 hilighting.

Another possibility would be to only remove "www." and "ftp." (and other variations?) from the hostname, which would help shorten the displayed string in most cases, while preserving useful info.

Comment 8

[Ed Lee :Mardak]

With bug 405893, we'll be able to search the text that we show, and like dolske's case of trying to find "fire", it wouldn't match the TLD info.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

My feeling is that the heart of the issue here is being able to see more information when needed. I agree with Madhava that adding more than eTLD + 1 ends up cluttering the interface; at a glance, I think that it's right to try and provide the identity of the site from whence the file came, which is most often eTLD +1.

We might wish to provide additional information in a tooltip, though. We removed the info box (for good reasons; it was a b*tch to display nicely) and replaced it with context menu actions which allow the user to do something, but not inspect that information. Perhaps tooltips are a path to success here?

Comment 10

[Madhava Enros [:madhava]]

It's true - we're not really doing anything with the tool tips here.  We could have the tooltip on the "n kb - eTLD+1" line show the full hostname.  In the same vein, we could have the tooltip on the "Today/Yesterday/etc." show the full date.  The information would be available to people who want the extra detail without having it get in the way for normal use.

(In reply to comment #9)
> My feeling is that the heart of the issue here is being able to see more
> information when needed. I agree with Madhava that adding more than eTLD + 1
> ends up cluttering the interface; at a glance, I think that it's right to try
> and provide the identity of the site from whence the file came, which is most
> often eTLD +1.
> 
> We might wish to provide additional information in a tooltip, though. We
> removed the info box (for good reasons; it was a b*tch to display nicely) and
> replaced it with context menu actions which allow the user to do something, but
> not inspect that information. Perhaps tooltips are a path to success here?
> 

Comment 11

[Ed Lee :Mardak]

Would the bottom line show the full hostname without the size? There's nothing to clarify with the size. Additionally, what should the status tooltip be for other texts? Like in progress, etc. We can definitely do something like showing the full date on the tooltip as well. (Just something to think about as I don't have IRC access right now.)

Comment 12

[Ed Lee :Mardak]

Bug 409326 landed which provides the full host tooltip when hovering the eTLD+1 domain, so there isn't as much use here. Per comments about eTLD+2 not being the appropriate fix.. WONTFIX

Comment 13

[Shawn Wilsher :sdwilsh]

/me puts on MO hat

yup, not gonna do this

Comment 15

[Matt Lee]

So, the following two files work as expected, IMO..

http://www.devon-cornwall.police.uk/v3/PDFStore/crime/YouMatterWeCare.pdf

http://www.st-andrews.beds.sch.uk/learning/memletics.pdf

But the following files do not:

http://www.connectingforhealth.nhs.uk/systemsandservices/nhsnumber/patients/patleaflet.pdf

http://matt.lee.name/gnu/gnuftp/gnu/gnu-keyring.gpg

In particular, the .nhs.uk file is shown only as nhs.uk -- the equiv of co.uk or org.uk for healthcare.