A few ideas

[addyosmani]

A few ideas, but feel free to shoot down :)

• I imagine a few developers will be wondering if you can use the left/right keys to navigate the coverflow. Is it worth us including a separate demos page which showcases this? In the future it might also give us a place to show things like the horizontal scrollbar navigation of the coverflow which we had in an earlier version (though that was super-coupled!).
• Pretty much all versions of the coverflow have relied on UA testing to detect IE. Is there a better way of us doing this where we can rely on feature detection instead?
• Would you mind if we used album artwork for the demo imagery? (e.g like this) to showcase? These images tend to really 'pop' and might look good.

I'm happy to help with some of these but just checking what your thoughts might be.

[basti1253]

The demo page included in master branch is pretty much the same as the old one including a vertical slider ;) Wouldn't be a big deal to bind the 2 arrow keys towards coverflow next/prev after an item got focussed.
How about polishing the documentation example and dropping the included example in master branch?

Would you mind if we used album artwork for the demo imagery? (e.g like this) to showcase?

The only reason I used that flickr images is I didn't want to get into trouble with the harsh German copyright laws. If we are allowed to use that images let's go for it.

Pretty much all versions of the coverflow have relied on UA testing to detect IE. Is there a better way of us doing this where we can rely on feature detection instead?

Thought of this, too. We'd have to detect dx filter support. How about releasing a new major version now (doing some docs polishing before) and include feature detection for old IEs in the next minor version?

Another "nice to have" feature would be including append()/prepend()/remove() methods (see #9 ) - allowing users to manipulate coverflow items on the fly without destroying the widget instance.

[addyosmani]

The demo page included in master branch is pretty much the same as the old one including a vertical slider ;) Wouldn't be a big deal to bind the 2 arrow keys towards coverflow next/prev after an item got focussed.
How about polishing the documentation example and dropping the included example in master branch?

SGTM!

The only reason I used that flickr images is I didn't want to get into trouble with the harsh German copyright laws. If we are allowed to use that images let's go for it.

Ah! I completely forgot about the German copyright laws when it comes to image selection. I'll do a little research here and if it turns out we can't use them, perhaps we can look for some creative commons album artwork instead.

Thought of this, too. We'd have to detect dx filter support. How about releasing a new major version now (doing some docs polishing before) and include feature detection for old IEs in the next minor version?

This sounds good to me. We could also add a note to the source for anyone wondering to state that we'll be moving away from UA detection in the future just to cover the question.

Another "nice to have" feature would be including append()/prepend()/remove() methods (see #9 ) - allowing users to manipulate coverflow items on the fly without destroying the widget instance.

Yess. That would be fantastic. Next version perhaps! :)

[addyosmani]

Another idea:

I think it would be interesting to explore implementing coverflowjs without jQueryUI as a dependency. This would involve dropping the widget factory but could mean that developers could use this without having to buy into jQueryUI as a dependency.

Thoughts?

PS: We should do an official release sometime for sure :)

[PizzaBrandon]

I've been thinking about the same and I think it could (potentially should) be done. jQuery UI can be somewhat of a heavy dependency, especially if the developer doesn't want the other UI components.

I also was considering whether to work toward removing the jQuery Mobile dependency for swipe, but for right now I'm leaning away from that until we know how many people want or use it (if we ever do).

[basti1253]

Hi,

I don't really like the idea of dropping jqueryUI as the widget factory makes so many things so easy. As a bonus our plugin is easily inheritable, our plugin scope is our widget (not our dom node), we don't have to take care about namespaced event binding, etc. On the other hand I know the code base is heavy. What about a parallel, reduced js only version (using document.querySelectorAll as $ fn instead of jQuery) targeting mobiles with our after next release?

best regards

[PizzaBrandon]

Dropping all dependency on jQuery? That would be far more difficult with less payoff... I would figure jQuery would have a larger adoption base in our target developer market than jQuery UI. How much extra weight would we have to add to the plugin to remove jQuery dependency (that may be duplicated if the developer also uses jQuery)?

[addyosmani]

btw, just saw this today http://darsa.in/sly/

[PizzaBrandon]

Wow. All that without jQuery UI for only 15kb (versus 8kb for our current - not sure of what our size will be after adding my code). I'm sure there's plenty we could each learn from the other's code here. (I really want to look through their touted rendering code!)

Theirs close to what I've done, but has a few issues that I'm planning to upgrade for in the near future. One big thing is transitional selections on scroll. If you click and drag theirs, the 3D effect goes weird as you move the perspective and then finally shifts the perspective and flips the one tile it's targeted for. I want to make ours more fluid to flip through all the tiles until the target is reached, following the momentum of the swipe. I'm part-way there already, at least with the momentum.

[basti1253]

Aftter merging Brandons 3D-Renderer the coverflow.js file now includes it's jQueryUI dependencies by default (only ui.core, ui.widget and ui.effect). Hence I added an extra standalone file without the UI dependencies. The look of the old "classic renderer" is a little bit adjusted so both are looking very similar. => 3D is default if it's available.

Regarding the demo: I didn't include any slider yet ;) Besides that it's really responsive and the widget's reacts fine to resolution changes

I included Hammer.js support based on Brandons swipe handling as both jQm and hammer are really popular. The momentum swipe with Hammer is not as smooth as it is with jQm. Will open another issue to protocol mobile device testing.

best regards.

[saravanaselvan]

Hi,

Any plans to add mouseover interaction to the widget?

Thanks,
Saravanaselvan

[basti1253]

Hi,

Details please ;) Don't know what you expect the widget to do on mouseover.

best regards

[saravanaselvan]

Yes. Now there are 4 triggers supported - itemclick, itemfocus, swipe and mousewheel. For one of my projects I wanted to transition the images on mouse over instead of click. So is there a plan to implement the mouse over trigger?

Note: I have implemented by extending the widget and adding the trigger.

Thanks,
Saravanaselvan

[basti1253]

Mhm. Probably not. Sounds like an edge use case for me.