Last Comment Bug 432669 - add slider for home page
: add slider for home page
Status: VERIFIED FIXED
:
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Public Pages (show other bugs)
: 3.2
: All All
: -- normal
: 3.4.5
Assigned To: Les Orchard [:lorchard]
:
Mentors:
Depends on: 432665
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-07 12:15 PDT by Michael Morgan [:morgamic]
Modified: 2016-02-04 14:51 PST (History)
7 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
slider mockup, rev 1 (104.71 KB, image/png)
2008-05-15 13:14 PDT, Madhava Enros [:madhava]
no flags Details
3 slider variants (324.28 KB, image/png)
2008-05-20 18:26 PDT, Madhava Enros [:madhava]
no flags Details
Initial stab at a slider on the home page (9.65 KB, patch)
2008-06-27 15:32 PDT, Les Orchard [:lorchard]
no flags Details | Diff | Review
Revised slider with variable height (11.41 KB, patch)
2008-07-02 11:12 PDT, Les Orchard [:lorchard]
no flags Details | Diff | Review
Button graphics: left, right, disabled left, disabled right (8.28 KB, application/zip)
2008-07-03 12:48 PDT, Jennifer Morrow [:Boriss] (UX)
no flags Details
Revised slider with conditionally disabled prev/next buttons (13.07 KB, patch)
2008-07-07 13:16 PDT, Les Orchard [:lorchard]
ryan.doherty: review-
Details | Diff | Review
OSX screenshot with overlap from Recommended column (210.02 KB, image/png)
2008-07-07 14:34 PDT, Jennifer Morrow [:Boriss] (UX)
no flags Details
Slider rewritten with resizability and jQuery plugin-ability (14.68 KB, patch)
2008-07-07 21:11 PDT, Les Orchard [:lorchard]
ryan.doherty: review+
Details | Diff | Review
Lots of empty space (63.10 KB, image/png)
2008-07-10 09:29 PDT, Ryan Doherty (:rdoherty)
no flags Details

Description Michael Morgan [:morgamic] 2008-05-07 12:15:15 PDT
Need to add a slider to rotate through recommended add-ons on home page.
Comment 1 Madhava Enros [:madhava] 2008-05-15 13:14:23 PDT
Created attachment 321136 [details]
slider mockup, rev 1

This is the kind of thing I was thinking.  Thoughts?
Comment 2 Basil Hashem [:baz] 2008-05-15 14:18:24 PDT
Yes, can we make it cleaner by removing the 1-5 buttons? This way you don't have to worry about which one you are on, having to mark the selection of the button, dealing with going left when you are on 1, etc...

See http://www.comcast.com/ for an example of < " > [left, pause, right]. This will allow us to auto-scroll and give users the ability to pause it. Do you like that?
Comment 3 Madhava Enros [:madhava] 2008-05-20 18:26:15 PDT
Created attachment 321869 [details]
3 slider variants

Basil - so you're thinking something more like (a) in the attached mockup?  Are you sure we want these to cycle automatically?
Comment 4 Basil Hashem [:baz] 2008-05-21 16:24:01 PDT
Even though I suggested it (auto-scrolling), I think we should start with Option C in the attachment for comment 3. If you feel strongly about auto-cycling thru the choices, then we go with option A.
Comment 5 Fred Wenzel [:wenzel] 2008-05-22 00:23:44 PDT
Apple uses dots (a filled dot being the current "page", all others being circles), if I remember correctly. Not sure if that would make it any better than option C, though.
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2008-06-24 09:43:06 PDT
Let's use C, since it allows us to grow arbitrarily from 5 over time.
Comment 7 Les Orchard [:lorchard] 2008-06-27 15:32:18 PDT
Created attachment 327191 [details] [diff] [review]
Initial stab at a slider on the home page

Okay, so here's an initial stab at implementing a slider with multiple recommended addons.  I'm thinking this patch from svn diff may not quite work directly, since there are images involved - not sure about that.

I've got this running here on khan internally:

http://amo.lorchard.khan.mozilla.org/en-US/firefox/

And viewing this may require the following /etc/hosts addition:

10.2.74.111 amo.lorchard.khan.mozilla.org

There's a bit of extra spacing in the slider rendering of addons, but that's mostly to try to account for various sizes of titles, author names, etc in one consistently-sized slider viewport.
Comment 8 Les Orchard [:lorchard] 2008-06-27 15:34:49 PDT
Adding stephend, since he'll probably want to see this
Comment 9 Basil Hashem [:baz] 2008-06-27 15:36:45 PDT
Les, this is looking really good. Is the rapid animation at wrap-around (From 5->1 or 1->5) optional? If so, I personally find it distracting. Can we do a smooth slide like the other transitions?
Comment 10 Stephen Donner [:stephend] - PTO; back on 5/28 2008-06-27 20:31:49 PDT
For longer text descriptions, I'm seeing vertical scrollbars; if we fixed our site-wide CSS model to use :float, would that no longer be a problem (the page's height would automatically adjust to fit all content)?
Comment 11 Les Orchard [:lorchard] 2008-06-27 20:35:59 PDT
Yeah, the scrollbar is a bit of a compromise that might need some playing around with.  The problem with allowing the height to adjust automatically is that all the different lengths of description text for that section causes the prev/next controls at the bottom to jump up and down with each click.
Comment 12 Les Orchard [:lorchard] 2008-07-02 11:12:38 PDT
Created attachment 327831 [details] [diff] [review]
Revised slider with variable height

Okay, I here's a reworked slider that should expand vertically to accomodate the longest addon item in the set.  Also, I've switched from "1 of 5" to "1 / 5" because I'm a bit unsure how "X of Y" would translate into various languages.

This update should be available on my khan domain now:

http://amo.lorchard.khan.mozilla.org/en-US/firefox/
Comment 13 Les Orchard [:lorchard] 2008-07-02 11:22:51 PDT
Just saw baz's comment about the start and end animations.  

That'll take some thinking:  For this slider, the addons are laid out on a wide horizontal strip side-by-side with a viewport revealing one addon width.  Seemed like the easiest way to do it.  There's not really a good way to continuously or smoothly go from one end of the strip to the other.

If it's too distracting, I could disable previous for 1/5 and next for 5/5.
Comment 14 Stephen Donner [:stephend] - PTO; back on 5/28 2008-07-02 17:39:53 PDT
As I told Les in IRC, this looks good to me, sans the slightly jarring "whirring" issue Basil noted in comment 9 -- are we ready for reviews yet, or do we want to implement Les's proposed mitigation in comment 13?
Comment 15 Justin Scott [:fligtar] 2008-07-02 17:47:57 PDT
fwiw, I like the fast motion going from one end to the other as a visual cue that I did something different than the previous 4 clicks.
Comment 16 Jennifer Morrow [:Boriss] (UX) 2008-07-03 10:38:30 PDT
My recommendation is for pressing the left arrow at 1 to create another small left-scroll to 5, and similarly for pressing the right arrow at 5 to create another right-scroll to 1.  In this way, pressing one arrow over and over makes the entire set cycle with no breaks at either end.

The reason I don't think maintaining a solid representation of the slides going from 1-5 is important is because the slides are completely unrelated to each other; there's no progression or reason to limit the user's actions by their order.

I agree that the fast scrolling is very distracting.  The user first pressing the left arrow would likely be expecting another add-on to appear: for it to do so without a transition would likely be expected, for it to do so with a transition would be a good surprise ("cool!" - person sitting next to me), and for it to quickly blow past three other options is a negative surprise ("what happened?  can I go back?").

I don't think disabling the buttons at either end is better either.  The affordance to begin viewing is clearly here with the arrows, and for one to not work would just seem broken.  Even to gray out the arrow would be an unnecessary restriction on the user, since there's no importance of viewing the slides 1-5 rather than 1, 5, 4, 3, 2.
Comment 17 Les Orchard [:lorchard] 2008-07-03 10:58:15 PDT
Basically, with this current implementation, the options are to disable the buttons at either edge or to leave the fast scrolling enabled.

Basically right now it's a wide strip of addons statically laid out with a moving viewport window sliding over it.  To have a continuous transition from 5 to 1 and vice versa, I'll need to go back to the drawing board and find another way to stitch the addon items together.

The conceptual alternative would be much more complex and dynamic: Attempting to actively position the next addon in the desired direction just before the transition fires.  Not entirely sure how I'd go about that, off the top of my head - thus, the drawing board and probably not ready by Monday. :)

Comment 18 Jennifer Morrow [:Boriss] (UX) 2008-07-03 11:39:01 PDT
Sure, makes sense.  Would it be possible to render a disabled version of the button at either end?
Comment 19 Fred Wenzel [:wenzel] 2008-07-03 11:44:41 PDT
I honestly don't mind the way it is right now.

On the other hand, clicking to the right, and achieving a "going left" is not good for stimulus-response compatibility. I do think we need a way to jump all the way back though, and arrows along with a "1/5" display may not be the best way to do it.

How about 

<- o o o O o ->

where the big O is a filled circle, and the lowercase 'o's are rings?

In fact, I just found this pattern on the Yahoo design pattern library as well: http://developer.yahoo.com/ypatterns/pattern.php?pattern=carousel
Comment 20 Les Orchard [:lorchard] 2008-07-03 12:10:06 PDT
boriss: I cut the arrows from the Madhava-supplied mockup.  I think I'd need either him or someone with the original photoshop doc to render them.  My graphic-design-fu is not strong.

wenzel:  Yup, I've seen that Carousel pattern.  I went with the 1/5 indicator per Beltzner in comment #6, because I think it makes it easier to go from 5 to whatever number we want.  Though, of course, the other pattern makes random access easier.

https://bugzilla.mozilla.org/show_bug.cgi?id=432669#c6

We could go with a different position indicator if need be, though.  Clock's a-tickin' though :)

(And hey, I got through this comment without once writing "basically"...  Oh.  Crud.  There it goes.)
Comment 21 Jennifer Morrow [:Boriss] (UX) 2008-07-03 12:16:49 PDT
l.m.orchard: I can make you some arrows, I mean would it be possible to have an active arrow that displays if the user can press it and switch it to a deactivated, faded-out version for the left arrow at 1 and right arrow at 5?  This might be a good way to go since it would never disappoint the user.
Comment 22 Les Orchard [:lorchard] 2008-07-03 12:21:42 PDT
boriss: Oh, sure - given the images, I can swap when one of the buttons needs to be disabled.
Comment 23 Jennifer Morrow [:Boriss] (UX) 2008-07-03 12:48:50 PDT
Created attachment 328031 [details]
Button graphics: left, right, disabled left, disabled right
Comment 24 Jennifer Morrow [:Boriss] (UX) 2008-07-03 13:01:52 PDT
Arrows with a deactivated state may be a good temporary fix since the clock's a-tickin (see attachement)

Wenzel - very cool link, perhaps we can do something along those lines when there's more time to devote to a solution
Comment 25 Les Orchard [:lorchard] 2008-07-07 13:16:12 PDT
Created attachment 328376 [details] [diff] [review]
Revised slider with conditionally disabled prev/next buttons

Okay, I've updated my staging host with the disabled buttons:

http://amo.lorchard.khan.mozilla.org/en-US/firefox/
Comment 26 Les Orchard [:lorchard] 2008-07-07 13:30:42 PDT
Comment on attachment 328376 [details] [diff] [review]
Revised slider with conditionally disabled prev/next buttons

r? :roherty
Comment 27 Jennifer Morrow [:Boriss] (UX) 2008-07-07 14:34:07 PDT
Created attachment 328395 [details]
OSX screenshot with overlap from Recommended column

l.m.orchard:  Looks great, although there's seems to be an overlap problem when the window's width is shortened on OSX (see screenshot).
Comment 28 Ryan Doherty (:rdoherty) 2008-07-07 17:33:49 PDT
Comment on attachment 328376 [details] [diff] [review]
Revised slider with conditionally disabled prev/next buttons

Works, but could use some improvement :)

-Doesn't handle browser window smaller than 1046px wide
-Each addon could be in a list instead of divs.
-Doesn't work without JS. Buttons could just be links to the homepage and have ?slider_index=2,3, etc.
-Can the JS slider code be a jQuery plugin? Then we can use it anywhere and just have 1 line of JS at the bottom of the page initializing it.
-The slider code should be moved to addons.js to gain caching, minification, etc.
-Instead of testing the target that is clicked, there could be id's added to the buttons and the id could be used to figure out if the next/prev button was clicked.
-Some sort of internal state could be used to track what addon is shown. Then it can know if there's a next or previous addon to display and I think some logic and css classnames could be removed. Less DOM manipulation to save state, the better.
-Some browser history management would be nice too (URL#slider-index=2). That way people who click the next arrow can send a link to a friend that would show the same addon.
Comment 29 Les Orchard [:lorchard] 2008-07-07 17:39:00 PDT
Okay... that list won't be done for code freeze tonight.
Comment 30 Les Orchard [:lorchard] 2008-07-07 21:11:21 PDT
Created attachment 328441 [details] [diff] [review]
Slider rewritten with resizability and jQuery plugin-ability

Okay, this patch doesn't address everything, but:

- Browser resizing should be handled now

- Switched to list items from divs

- Still doesn't work without JS

- It's now rewritten from scratch as a jQuery plugin, fired up with one line of code near the bottom of the page.

- The plugin is in addons.js

- The next / prev buttons are given event handlers directly now.  It was done using event delegation because a previous version gave each addon its own next / prev button, but the single control set obviates that.

- An internal index is used to select through a list of items fetched at startup.

- Browser history isn't useful for this bug, because the addons are selected at random for each page load.  Could be a future addition to the plugin though.

going to bed now.
Comment 31 Ryan Doherty (:rdoherty) 2008-07-08 09:29:38 PDT
Comment on attachment 328441 [details] [diff] [review]
Slider rewritten with resizability and jQuery plugin-ability

Looks really good. r+ it for code freeze, but would like to have the few small improvements done during the next release.
Comment 32 Les Orchard [:lorchard] 2008-07-08 10:08:44 PDT
Just checked this in as r16796
Comment 33 juan becerra [:juanb] 2008-07-09 21:52:17 PDT
On https://preview.addons.mozilla.org/en-US/firefox/

Verified Fixed -- Slider is there and resizing browser window is handled well.

Comment 34 Ryan Doherty (:rdoherty) 2008-07-10 09:29:02 PDT
Created attachment 328906 [details]
Lots of empty space

Just noticed a small issue where if 1 addon has a large description, it causes the slider height to be extremely tall. This causes other addons listed to have lots of empty space. Could we trim all descriptions to a max # of characters to prevent this?
Comment 35 Dave Garrett 2008-07-10 09:56:57 PDT
(In reply to comment #34)
> Could we trim all descriptions to a max # of characters to prevent this?

See bug 443977 for that.

We could also consider moving the button and "view more" link to the left side to give more room for the description on the right.

Note You need to log in before you can comment on or make changes to this bug.