462231 - [IE 6/IE 7] Display issues with Internet Explorer

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Collections, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: IE 6

Both IE 6 and IE 7 have pretty major rendering issues with our Fashion your Firefox interactive collections page:

https://preview.addons.mozilla.org/en-US/firefox/collections/interactive

I'll attach screenshots for each.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: IE 7

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

(FWIW, Opera and Safari--latest versions--are fine.)

Comment 3

[David Rolnitzky]

Stephen brought up a good point (in hallway) that when a user is using Firefox less than version 3 (or any non firefox browser), that the add message is currently:

"Upgrade Firefox to use this add-on.
An older version may work."

That's sort of a bad mixed message to send to users -- we say they need to upgrade to Firefox 3 at the top of the page, and then we say older versions may work.

Is there a way to disable this message from showing up in the collections web view?

This should probably be in another bug.

Comment 4

[Fred Wenzel [:wenzel]]

Note that the rendering problems just occur in IE: Safari looks peachy.

Comment 5

[Fred Wenzel [:wenzel]]

(In reply to comment #3)
> Is there a way to disable this message from showing up in the collections web
> view?

Indeed, different bug. I'll remove the "... may work" message, though.

Comment 6

[David Rolnitzky]

Created new bug 462396 to address comment #3:

https://bugzilla.mozilla.org/show_bug.cgi?id=462396

Comment 7

[David Rolnitzky]

This is a show-stopper IMO.  We can't run the risk (pretty great) of having a user with IE6 or IE7 have a completely broken experience.

Comment 8

[Fred Wenzel [:wenzel]]

Should be fixed on IE7, r19426.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot of IE 6, post-fix

David, are we happy with the above?  IE 7 looks just fine.

Comment 10

[David Rolnitzky]

I think this looks ok -- is this the same as IE7?  However, I believe foxmarks is compatible with Firefox 2, so it's weird that this message is appearing there.

Comment 11

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #10)
> I think this looks ok -- is this the same as IE7?  However, I believe foxmarks
> is compatible with Firefox 2, so it's weird that this message is appearing
> there.

I don't think we qualified that "upgrade" message to do anything but tell a non-Firefox 3 user to use Firefox 3; Fred can happily correct me if I'm wrong.  (I don't remember that being a requirement, if so, either.)

I think we're done here for IE support, since you're fine with the IE 6 appearance.

There's IE 7: http://img516.imageshack.us/my.php?image=picture5qo2.png

Verified FIXED.

Comment 12

[David Rolnitzky]

Oh, I misunderstood the functionality here.

Can't we tell whether or not the user actually needs to upgrade to Firefox 3 based on the add-on?  Seems like we already do this on the AMO site -- if the user has Firefox 2, but the add-on is compatible, they simply get the download button.

There are about a half dozen extensions and about a half dozen themes that are not compatible with Firefox 2.  But for all others, we should let them download the compatible Firefox 2 version.

I updated the grouphub with a listing of which ones were compatible only with Firefox 3.

Comment 13

[Fred Wenzel [:wenzel]]

(In reply to comment #11)
> I don't think we qualified that "upgrade" message to do anything but tell a
> non-Firefox 3 user to use Firefox 3; Fred can happily correct me if I'm wrong. 
> (I don't remember that being a requirement, if so, either.)

Stephen is right: We said this page is Firefox 3-only (for now, anyway) and should nicely encourage all others to upgrade. Doing further browser sniffing for Fx2 would be a new feature that I suggest we delay for now. If an Fx2-user wants the add-on they have, at the very least, the possibility to click on the add-on name in the list, which will take them to the add-on's details page with all regular AMO capabilities.

Also note that the green check boxes on the collections pages are not the same (code- and thus functionality-wise) as the install buttons on regular AMO.

Comment 14

[David Rolnitzky]

Not to keep circling back to this, but I feel like there has to be a simpler, nicer way to present this to the user.  In the minority of cases here, an add-on will only work with Firefox 3.  Otherwise, the add-on is compatible with Firefox 2 in most cases.

Is there a way to manually synch up the appropriate button if we can't incorporate it dynamically some how (like Boriss suggests in this attachment: https://bugzilla.mozilla.org/attachment.cgi?id=333067) in Bug 461038?  

We're really targeting the less technical user, so the easier we can make this, the better.

Comment 15

[Michael Morgan [:morgamic]]

Stick to the plan.

Comment 16

[David Rolnitzky]

Attachment: IE6 Windows XP missing expander arrows next to categories

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #16)
> Created an attachment (id=346072) [details]
> IE6 Windows XP missing expander arrows next to categories

You said in comment 10 that this looks OK, after I posted a similar screenshot of IE 6 in comment 9; do you now want a separate bug filed?

Comment 18

[Fred Wenzel [:wenzel]]

(In reply to comment #16)
> Created an attachment (id=346072) [details]
> IE6 Windows XP missing expander arrows next to categories

It's implemented with CSS2's :before "pseudo-class", a standard unimplemented in IE6 and 7. There's not much we can do about it, except cheesy JavaScript hacks. Considering the whole page's purpose is based on people using Firefox, I suggest we keep it that way and hope IE8 bothers implementing standards completely (for extra credit: even correctly).

Comment 19

[David Rolnitzky]

@ Stephen -- sorry, missed that small formatting error on the fix in comment #9.

@ Frederic -- that makes sense.  However, from a user's perspective, how would someone know to click on a category to expand it? There's really nothing to indicate that it's clickable.  Boriss, any comment?

Comment 20

[Fred Wenzel [:wenzel]]

Yeah, without moving the mouse you won't know. On hover, we do have the color and pointer change, but on the surface, there is no other indication.

Comment 21

[Ryan Doherty (:rdoherty)]

Couldn't we just add a bg image to the <h3> and use javascript to change it when it's parent (<div class="cat-header ui-accordion-header selected") has the 'selected' class?

Comment 22

[Ryan Doherty (:rdoherty)]

(In reply to comment #21)
> Couldn't we just add a bg image to the <h3> and use javascript to change it
> when it's parent (<div class="cat-header ui-accordion-header selected") has the
> 'selected' class?

Actually, no JavaScript needed.

.ui-accordion-container .ui-accordion-header h3 {
background: url(image here);
}


.ui-accordion-container .selected h3 {
background: url(different image here or same image with different background positioning);
}

Comment 23

[Fred Wenzel [:wenzel]]

I replaced the CSS with images in r19465. For the record, the triangles come from http://commons.wikimedia.org/wiki/Arrow_symbols -- I downloaded the SVG files, colored and exported them to transparent PNG.

Note that this means when the text color changes for the heading, the arrows need to be fixed manually.

Comment 24

[Jennifer Morrow [:Boriss] (UX)]

I think having a very visible right-pointing area, along with shading the category box to look like a button (perhaps slightly raised, slight shadow) will all aid the user in determining they need to click it.  The former hints that it will drop down, the latter hints that it is a button.  The latter I feel is even more important, because if anything it's a good surprise to see that the page is more interactive than the user expected.

Comment 25

[Fred Wenzel [:wenzel]]

So, Boriss, do you suggest I revert to the original (image-less) behavior? I'd personally prefer that, as it's less overhead, cleaner, etc.

Comment 26

[Jennifer Morrow [:Boriss] (UX)]

Re Frederic @ Comment 25: are you referring to https://bugzilla.mozilla.org/attachment.cgi?id=346072 ?  Can we not add any images/color here?

Comment 27

[Fred Wenzel [:wenzel]]

(In reply to comment #26)
> Re Frederic @ Comment 25: are you referring to
> https://bugzilla.mozilla.org/attachment.cgi?id=346072 ?  Can we not add any
> images/color here?

Ah, I think I misinterpreted your comment. You *do* want the arrows, and I did implement them in a way that IE can handle now (see comment 23). We should be fine, then.