427179 - Set second line in download manager results to GrayText

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: File system tile view in XP and Vista

To help achieve visual grouping with the alternating row colors removed (bug 426007), I think we should set the second line in download manager results to GreyText (size -- site).  Potentially also the date.  This is visually consistent with the file system UI in Vista and XP.

Comment 1

[(no longer active)]

Attachment: Patch (v1)

Make the dateTime and status gray.  I'll post a screenshot soon.  This is only done for non-selected items, because GrayText on blue is hard to read on most themes.

Comment 2

[(no longer active)]

Attachment: Screenshot

Screenshot useful for ui-review.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 313769 [details] [diff] [review]
Patch (v1)

Switching ui-r to beltzner since we haven't had a chance to discuss the idea yet.

Comment 4

[Dão Gottwald [:dao]]

gnomestripe is missing from the patch.

Comment 5

[(no longer active)]

Attachment: Patch (v1.1)

(In reply to comment #4)
> gnomestripe is missing from the patch.

Fixed.

Comment 6

[Shawn Wilsher :sdwilsh]

Comment on attachment 313918 [details] [diff] [review]
Patch (v1.1)

Note:  I tend to be slow to reviews on bugs that I'm not cc'd on.

r=sdwilsh, pending ui-r.

Comment 7

[Ed Lee :Mardak]

Do we want graytext on all platforms? FYI, bug 427979 got fixed, so linux has banding again. Windows is just the odd one out.

Comment 8

[Ed Lee :Mardak]

Oh. Interesting. Proto changes already makes the dateTime and status

 font-size:smaller; color: #555;

Comment 9

[Ed Lee :Mardak]

Attachment: mac screenshot

Comment 10

[(no longer active)]

So I guess the gnomestripe part of the patch can be ignored now...  Waiting for Beltzner's take on this.

Comment 11

[Ed Lee :Mardak]

Why would it be ignored now? OS X has striped rows and has graytext PLUS smaller font size. Couldn't we do that across all platforms -- GrayText and smaller?

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

The bug was originally intended to be windows only, cc'ing some linux folks to get their feedback.  We should do what is the most platform native on gnome.

Comment 13

[Michael Ventnor]

The problem here is there's no answer to this on Gnome, I've never seen any kind of UI like this in Gnome, or so I'm aware.

Comment 14

[Jakub Steiner]

The main-menu (SLAB) does use this sort of markup for the second line of the launcher tile.

random google image search result -- https://wiki.ubuntu.com/Slab?action=AttachFile&do=get&target=mainmenu.png

Comment 15

[Andreas Nilsson (:andreasn)]

Attachment: banshee music player screenshot

And so does banshee music player on Linux.

Comment 16

[u294409]

Jakub, that's the good, ol' SLAB :) .

And I of course agree with this bug.

Comment 17

[Ed Lee :Mardak]

Attachment: screenshot of selected but not focused

I'm not sure if this is remote desktop acting up, but if you select items and move focus to the search box, things are hard to read. I suppose the items are still considered "selected", but focus isn't actually in the list?

Comment 18

[Ed Lee :Mardak]

Comment on attachment 313918 [details] [diff] [review]
Patch (v1.1)

Oh er. hold on. Do you need the selected -> HighlightText?

Comment 19

[Ed Lee :Mardak]

E.g., see this attachment.. without moving smaller for statusText

https://bugzilla.mozilla.org/attachment.cgi?id=316841&action=edit

Comment 20

[Ed Lee :Mardak]

Comment on attachment 316863 [details]
screenshot of selected but not focused

There's something in pinstripe that looks for focus..

+richlistbox:focus > richlistitem[type="download"][selected="true"] label {

Comment 21

[(no longer active)]

Attachment: Everything seems fine...

Are you sure this is not the Remote Desktop messing up?  Here's the screenshot of the behavior that I get with patch 1.1 applied, without using RD.  I selected a couple of items and then focused the search box.

And reading the code, I don't see why having or not having the focus should affect the color...

Comment 22

[Ed Lee :Mardak]

What color is it when you do select it *and* keep focus on the list? Does the text remain gray instead of switching to white?

Comment 23

[Damian Shaw [Quan]]

Just a note, I was trying out this build because of another bug:

https://build.mozilla.org/tryserver-builds/2008-04-21_10:[e-mail]/

Which includes they grayed out text. On Windows it was a real strain read for more than a few seconds and my eyesight is very good compared to a lot of users I know.

I hope accessibility is being well taken in to if/before this patch lands.

Comment 24

[Ed Lee :Mardak]

Attachment: -moz-nativelinktext

Just to note.. OS X uses #555 which is darker than GrayText. But I couldn't find an OS color darker than GrayText but not black. Perhaps 3dShadow but that's not made for text..

Maybe we we can steal -moz-nativelinktext.. but it's not really a link... but it does have a TLD+1.... ;)

On Windows, it's bluer and darker.. see attachment 315778 [details] of bug 423718.

Comment 25

[(no longer active)]

(In reply to comment #22)
> What color is it when you do select it *and* keep focus on the list? Does the
> text remain gray instead of switching to white?

No, it switches to white.  Isn't that the desired behavior?

Comment 26

[(no longer active)]

(In reply to comment #23)
> Just a note, I was trying out this build because of another bug:
> 
> https://build.mozilla.org/tryserver-builds/2008-04-21_10:[e-mail]/
> 
> Which includes they grayed out text. On Windows it was a real strain read for
> more than a few seconds and my eyesight is very good compared to a lot of users
> I know.
> 
> I hope accessibility is being well taken in to if/before this patch lands.

Do you have the same issue in other apps which use GrayText, such as Windows Explorer?

Comment 27

[Damian Shaw [Quan]]

(In reply to comment #26)
> (In reply to comment #23)
> > Just a note, I was trying out this build because of another bug:
> > 
> > https://build.mozilla.org/tryserver-builds/2008-04-21_10:[e-mail]/
> > 
> > Which includes they grayed out text. On Windows it was a real strain read for
> > more than a few seconds and my eyesight is very good compared to a lot of users
> > I know.
> > 
> > I hope accessibility is being well taken in to if/before this patch lands.
> 
> Do you have the same issue in other apps which use GrayText, such as Windows
> Explorer?
> 

Well, I extensively use Windows Explorer and I've never had such a problem. But I can't think of a good example where it uses GrayText like this.

Also I'd like to point out, using that build, the first search result has white text with a light gray/brown background depending on which version and theme of windows your using. It's so hard to read the text under that circumstance that a friend thought that there was no dialogue at all and didn't spot it till I pointed out and he had to change his monitor settings to read it.

Comment 28

[(no longer active)]

(In reply to comment #27)
> Well, I extensively use Windows Explorer and I've never had such a problem. But
> I can't think of a good example where it uses GrayText like this.

Please set the explorer to show the icons in the Tile mode.  It uses GrayText for non-selected items in that mode, and HighlightText for selected items (like we're doing).  Please let us know if you observe the same problems in Explorer as well, so that I get a feeling of whether we're doing something unusual or not.

Thanks!

Comment 29

[Damian Shaw [Quan]]

Attachment: GrayText Screenshot

The above comes from a standard XP file like you said.

The below comes from the build of Firefox you referenced. I can very clearly see the XP GrayText when I sit properly in my chair, to clearly read the Text in Firefox I have to sit very closely up to my screen.

The first search result is hard to read, even if I put my face up to my monitor, and my monitor's colour gamut is quite high and I have excellent eyes for reading up close. My friend didn't think there was any dialogue at all on his screen (though slightly different system colours for him as he is on Vista).

Comment 30

[Ed Lee :Mardak]

If we don't use HighlightText, you can ignore attachment 316995 [details]. The patch from v1.1 only changes the status text to GrayText not also the file name. But the XP subtext is darker than GrayText.

Comment 31

[Damian Shaw [Quan]]

(In reply to comment #30)
> If we don't use HighlightText, you can ignore attachment 316995 [details]. The patch from
> v1.1 only changes the status text to GrayText not also the file name. But the
> XP subtext is darker than GrayText.
> 

I've been looking around for examples of GrayText in XP. The only examples that I think I can find is when options are unselectable and it's supposed to be hard to read. Surely this isn't the desired effect?

The file name became GreyText when I searched through the History. It wasn't default for found downloads.

Comment 32

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

Comment on attachment 313918 [details] [diff] [review]
Patch (v1.1)

Yeah, this is OK with me.

Comment 33

[(no longer active)]

Comment on attachment 313918 [details] [diff] [review]
Patch (v1.1)

Requesting approval to land this.  This patch helps in visual separation of the download entries in the Download Manager now that the alternating row colors have been removed.

Comment 34

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

Comment on attachment 313918 [details] [diff] [review]
Patch (v1.1)

a1.9=beltzner

Comment 35

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/themes/winstripe/mozapps/downloads/downloads.css 	1.32
mozilla/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css 	1.11 

Comment 36

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

Note that this caused bug 430685, and a portion of it was backed out.