393681 - New file listing makes very poor use of space, truncates filenames all over

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Spun off of bug 392718:

The new listing UI setup is making very poor use of screen real estate. Even given the smallish size of my windows (about 1000px wide), and the huge amounts of horizontal whitespace the current design puts in on the sides (easily a third of the window width), only about half of the space for the filename is being used before we start truncating.  It looks pretty silly to have those truncated filenames while there's a bunch of space available.

Can we either significantly increase the truncation length, or at least make it
resolution-dependent (maybe by moving the truncation into the script, though
that may have performance issues) or something?  

Ideally we would also trim off some of that whitespace on the sides, of course.  In my opinion any time we're truncating a filename the user loses.

Comment 1

[Boris Zbarsky [:bzbarsky]]

In particular, this bug is interfering with day-to-day work because it's making it very difficult to work with directories that contain a lot of similarly-named files (like build archives, in my case).

Comment 2

[[:Aleksej]]

Also on Debian → Platform=All.

Comment 3

[Dão Gottwald [:dao]]

(In reply to comment #0)
> Can we either significantly increase the truncation length, or at least make it
> resolution-dependent (maybe by moving the truncation into the script, though
> that may have performance issues) or something?  
> 
> Ideally we would also trim off some of that whitespace on the sides, of course.

With the patch in bug 392718, file names can be long enough to stretch the table, which will then eat itself into the available space. The problem is, if we allow even more characters, the table will overflow the body, which has an 'em' max-width.

Comment 4

[Benjamin Smedberg]

In the triage meeting, we discussed this as a functional regression, and that the filename information should be more important than the size/lastmodified time, and that the table should expand to larger than the body if necessary.

Beltnzer, do you disagree?

Comment 5

[Dão Gottwald [:dao]]

I disagree. A vertical listing with horizontal scrolling looks too broken to me.

What would help to convince me (not that you have to) is if someone could link to a listing where the current behaviour really makes it less useful. The simple fact that truncating happens is hardly a regression -- it happens all over the place in user interfaces, for instance in tab titles and menu entries. In those cases, the containers don't simply expand horizontally, and that's for good reasons.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Here's what a listing over here looks like:

File:2001-10-12-08-gtk1-trunk-mozil…inux-gnu.tar.gz  	10240 KB  	08/08/2002  	11:43:18 AM
File:2001-10-15-08-gtk1-trunk-mozil…inux-gnu.tar.gz 	10240 KB 	08/08/2002 	11:43:22 AM
File:2001-10-18-08-gtk1-trunk-mozil…inux-gnu.tar.gz 	10240 KB 	08/08/2002 	11:43:22 AM

Which of those files is pc-linux and which is ppc-linux?

At this point, with bug 392718 fixed, we're more or less using the space we allocate to the filename (at my default window size as above, still), but we only allocate about 30% of the available horizontal space to it (with another 30% going to size/date and the last 30% whitespace).

One thing file listings often do to avoid having the date take up all the space is to show either a time (for recent dates) or a date (for older ones) but not both.  Perhaps we should do that.

Comment 7

[Dão Gottwald [:dao]]

It seems that we could use a max-width of 65 em instead of 52 and then display up to 30 more characters while staying within the limits of 1024x768. Of course, that styling will fail early with bigger font sizes, or file names that consist of many wide characters, or windows that are not maximized.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Right.  Ideally we'd have something that dynamically truncates only if really needed and expand the space available to filenames.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

Er, how can you know whether 65 em fit into 1024x768? Surely that depends on the font size...

Comment 10

[Dão Gottwald [:dao]]

Attachment: attempt

I've been playing with DOM Inspector, modifying real listings, and I think this could work. This particular patch is untested, though. It needs Toolkit and maybe UI review, but I'd like to check with Boris first.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So what does this actually change?

Comment 12

[Dão Gottwald [:dao]]

It increases the available space, allows file names to display up to 96 characters and to allocate two or more lines while ensuring that the first line won't be longer than 71 characters.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 279171 [details] [diff] [review]
attempt

> and to allocate two or more lines while ensuring that the
> first line won't be longer than 71 characters.

This is done by making sure that there are at most 71 characters before the ellipsis?  Or something else?

>Index: netwerk/streamconv/converters/nsIndexedToHTML.cpp
>Index: toolkit/themes/pinstripe/global/dirListing/dirListing.css
> body {
>+  min-width: 30em;
>+  max-width: 65em;
>   margin: 4em auto;

So with this change, the <body> ends up at the window width here.  Which means there is no gray around the body, but 3em of white padding inside the body.  It would really look better to have at least 1em of the gray stuff in this case.  That is, insert a div between the body and the table, apply the current body styles to the div, decrease its padding to 2em, and give the body a padding of 1em.  Or something along those lines.

Run this by beltzner first, though?  He may have better ideas.

>+td > a {
>+  display: block;
>+}

This rule needs to go into the in-page stylesheet, since it's dealing with the fact that we're now allowing the filenames to wrap, which was a change in that stylesheet.

Same for the other theme.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #13)
> (From update of attachment 279171 [details] [diff] [review])
> > and to allocate two or more lines while ensuring that the
> > first line won't be longer than 71 characters.
> 
> This is done by making sure that there are at most 71 characters before the
> ellipsis?

Exactly.

> >Index: netwerk/streamconv/converters/nsIndexedToHTML.cpp
> >Index: toolkit/themes/pinstripe/global/dirListing/dirListing.css
> > body {
> >+  min-width: 30em;
> >+  max-width: 65em;
> >   margin: 4em auto;
> 
> So with this change, the <body> ends up at the window width here.  Which means
> there is no gray around the body, but 3em of white padding inside the body.  It
> would really look better to have at least 1em of the gray stuff in this case. 
> That is, insert a div between the body and the table, apply the current body
> styles to the div, decrease its padding to 2em, and give the body a padding of
> 1em.  Or something along those lines.

Makes sense, although padding for :root should work too.

> >+td > a {
> >+  display: block;
> >+}
> 
> This rule needs to go into the in-page stylesheet, since it's dealing with the
> fact that we're now allowing the filenames to wrap, which was a change in that
> stylesheet.

It could go into the base stylesheet, but doesn't necessarily have to. Wrapping works without it. I couldn't figure out if it would look and feel better or worse.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Makes sense, although padding for :root should work too.

If we can avoid adding elements, great.  ;)

> I couldn't figure out if it would look and feel better or worse.

It works better with, because then the filename doesn't end up under the icon.

Comment 16

[Dão Gottwald [:dao]]

Attachment: 1.1

Comment 17

[Dão Gottwald [:dao]]

Attachment: 1.1

err, that was a typo. 2em is enough.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 279660 [details] [diff] [review]
1.1

Looks good.  r=bzbarsky

Comment 19

[Dão Gottwald [:dao]]

I don't know about ui-review ... if it's needed, it would have to be informal or I'd have to change the Product.

Comment 20

[Boris Zbarsky [:bzbarsky]]

mano's review should be fine.

Comment 21

[Asaf Romano (gone)]

Comment on attachment 279660 [details] [diff] [review]
1.1

r=mano.

Comment 22

[Dão Gottwald [:dao]]

Comment on attachment 279660 [details] [diff] [review]
1.1

err, already blocking.

Comment 23

[Reed Loden [:reed]]

Checking in netwerk/streamconv/converters/nsIndexedToHTML.cpp;
/cvsroot/mozilla/netwerk/streamconv/converters/nsIndexedToHTML.cpp,v  <--  nsIndexedToHTML.cpp
new revision: 1.85; previous revision: 1.84
done
Checking in toolkit/themes/pinstripe/global/dirListing/dirListing.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/dirListing/dirListing.css,v  <--  dirListing.css
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/winstripe/global/dirListing/dirListing.css;
/cvsroot/mozilla/toolkit/themes/winstripe/global/dirListing/dirListing.css,v  <--  dirListing.css
new revision: 1.3; previous revision: 1.2
done