Closed (works as designed)
Project:
Conference Organizing Distribution
Version:
7.x-1.x-dev
Component:
installation profile
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Aug 2012 at 19:02 UTC
Updated:
1 Jun 2014 at 21:55 UTC
Jump to comment: Most recent
Comments
Comment #1
pameeela commentedOur Sydney DrupalCon site has a slider too, so we'd also like to see this included, FWIW.
Comment #2
greggles@pameela - is views_slideshow also your choice as the best module for this purpose? I think one tricky thing is that everyone wants a slider, but people prefer different methods to get it done.
Comment #3
pameeela commented@greggles, sorry I missed your reply until now.
I don't really have an opinion on the best module for the job, it just happened to be the one we (and I guess Sao Paulo) chose. FWIW this issue isn't relevant to us anymore as we've had to create the slider functionality another way in the meantime. So if you'd like to close it that's fine with me.
Comment #4
mrconnerton commentedI like the motivation behind this issue. I can agree that for every COD6 or COD7 site I have created, I've slapped a views_slideshow on the homepage of flagged sessions, news, etc
As for choice of module I think views_slideshow is a great choice and has been the only slideshow module I have liked.
For the concept I think this comes down to adding the dependency in the make file per this issue and then a new issues in cod_support to:
If advanced COD/Views users prefer a different slideshow module then all they have to is clone the view or display, change the style and go. Slap the overrides in feature overrides and the are rocking the distro like a boss.
Comment #5
rootworkI agree -- while there are other options for slideshows (some of them great), this is by far the most popular and most supported. If there's going to be a slideshow module in the distro, this one makes the most sense by far.
The trickier question, I think, is whether we configure some kind of default slideshow. In other words, do we just add views_slideshow in the bundle of modules, or do we include a default view to demonstrate what it does? I think if we don't do the latter, casual users will never find it. (And power users know how to download and install slideshow modules anyway.)
Comment #6
mrconnerton commentedWe would definitely want to create the default view for them and slap it in the front page feature / context. There is already a front page view, we would either be extending that or doing the same thing in a new view.
Eventually if/when features comes with an "Example COD Content" module then after install the user would have a pretty slideshow out of the box already versus seeing it the first time they add a news/session node.
Comment #7
jackbravo commentedAnother option would be using http://drupal.org/project/field_slideshow. I haven't used this yet, but sounds like easier for the user to just edit a node and sort its images to set the slideshow, than creating several nodes maybe with a weight field.
Comment #8
gregglesIf we're going to discuss options, I like http://drupal.org/project/rotating_banner
Comment #9
mrconnerton commentedI prefer the views_slideshow approach since the slideshow on the homepage of my site is going to be a featured session, news article, user/speaker, etc.
I don't think field_slideshow would apply to this use case since our end result is going to be a "block" of some sorts. Wither its a view or rotating_banner, its something we will place on the homepage with context or panels. field_slideshow just formats images on a single node.
I do like rotating_banner, especially the UX makes it simple for new people, but again if was me, I would have to do extra work creating the featured session, then copying and pasting the content to the rotating_banner slides.
For weighting/order I create a sister views display with draggable views on my slideshow view. Obviously this would be another dependency but in D7 I'm using flag/draggable views for all my arbitrary content lists.
I am +1 for views_slideshow. I think with some nice defaults and an hours worth of time from a themer for text overlay it can be a great easy solution for people.
With that being said, I do like the idea of rotating_banner because of it's ease of use and while I wouldn't use it I know plenty of other people would.
One more thought to point out is this doesn't necessarily HAVE to go into cod_support core. It could very well be created as cod_views_slideshow or cod_rotating_banner module like commerce has companion modules. I think whatever is decided to go into core (YAY views_slideshow ;-) ), the other could always be made into a simple solution as a companion module. Especially once COD jumps on the Apps bandwagon, it will make this kinda thing even better.
Comment #10
rootworkJust to underscore mrconnerton, I think views_slideshow is the best choice. Principally because it's so widely used (orders of magnitude greater than either of the others) and has lots of support available. Experienced site builders or web developers can always forgo the built-in slideshow and create their own using other modules (we could even provide a list, I suppose). But I think it makes sense to include the module with the widest use cases as the default.
Comment #11
jackbravo commentedOk, I agree with the reasons outlined above. I too use views_slideshow most of the time. Sorry for the noise ;-).
Comment #12
gregglesI could be devil's advocate here and argue that we go with the one that has the best UX, but I realize that especially for some folks in the community they have to live with just the stuff that's in the box.
So! it is important for COD to make at least a default choice that is reasonably sane to let people do what they need without installing additional modules. People who have a particular need can disable the default and extend it.
I've updated the summary to provide a reasonable battle plan to get this done. We may not get Rupl/Ezra's approval to this idea, but I think it's reasoanble for someone who is interested in this to go ahead and create a patch to add views_slideshow to the make as the first step - then there can be more work on something in cod_support (not sure if it would be an existing module or a new one) that would add the things mrconnerton suggested.
Comment #13
ruplAnother counterpoint: in our client work we have found views_slideshow to lack all the necessary goodness to properly build a responsive site: fluidity, touch events, etc. I would not block the inclusion of views_slideshow if that's what people are converging on, but a solid, mobile-friendly solution is something worth considering in terms of future use-cases. Especially if there's COD-out-of-the-box requirements for people.
Here are ones we've implemented pretty easily within Views:
Comment #14
japerryFloating up to the top. Its been a year since we looked at this issue, and its quite possible the correct modules for showing a slideshow could have changed.
Comment #15
rootworkA lot of the mobile-friendly slideshow modules have matured and stabilized. I think it probably does make sense to pick one that's stable and mobile-friendly, even if it has less widespread use than views. All of COD's features should be responsive out of the box.
I'm not an expert enough on these to know which one to recommend, I just wanted to affirm that I've changed my mind from a year ago in light of their continued development. Thanks for bringing this up again @japerry.
Comment #15.0
rootworklet's do this
Comment #16
jackbravo commentedMy vote goes with flex_slider.
Comment #17
jyee commentedSlideshows and sliders fall outside of the core functionality of COD. While many events use them, they're certainly not universally required... and since everyone has their own preferred solutions, it's likely that choosing a solution could be an encumbrance for many people. I'd love to see someone create an extra module/feature for this... content types and fields are really stable at this point, so an extra module shouldn't encounter any major issues between now, when COD goes into beta and full release.