I know ... I saw in another post on here where that widget didn't work well (Has anyone tried Qooqee's "Responsive Composition Widget"? ) I was wondering if anyone has been doing anything else as a work-around.
I was thinking of just hiding the composition widget at a breakpoint and inserting another one, then hiding it for the next breakpoint, etc. for all common browser sizes. Has anyone tried this or any other method?
Or is everyone simply not using the composition widget and building individual pages "long - ways"?
Responsive is a must with clients now-a-days... and widgets are a quick-fix for work flow... so if one has to go....
Or is everyone simply not doing compositions at all and building out each page??
1 person found this helpful
Take the time and think about the implications and consequences o responsive compositions/slideshows.
I think, it’s better to wait for a thoroughly developed responsive composition/slideshow feature. There are tons of things to have an eye on, so I wouldn’t be astonished, if we’ll won’t get completely(!) responsive versions of these at all:
• Responsive scaling thumbnails/triggers; if yes: scaling down to which size? And what about text size within these triggers? Minimize it? Expand the trigger to keep the complete text displayed? If expanding: Horizontally or vertically? What happens in this case to "neighbor" triggers?
• Thumbnail/trigger rows: minimize them, when the window is minimized, or generating new rows of thumbnails/triggers? If generating new rows: What happens, if an even or odd number of thumbs/triggers causes ugly (inconsistent) layouts?
• If thumbnails/triggers aren’t placed top or bottom of the target/hero image, but to the left or right: Should they respect the vertical size of the thumbnail container, which is perhaps exactly aligned to the target’s/hero’s height? And then? Generating a new column of thumbs/triggers? Minimize them? And: If more columns of thumbnails/triggers are needed: What happens to the trigger area/hero image? Should it be pushed out of the way – in which direction and if necessary should it even leave the horizontal page boundaries?
• Text and buttons: Should text within minimize according to window size or produce line breaks? If line breaks: Should content below the caption be pushed down?
• What happens, if the first composition target contains text, which needs to expand vertically to be displayed, and the second target of the same composition contains an image, which has to shrink proportionally, when the browser window is minimized? What, if text and images live together in the third "sheet" of this composition?
These are only a few questions of hundred and hundred others. Therefore: I prefer to wait, until this is engineered in a viable way and – not to forget – equipped with a streamlined user interface.
It is that simple to claim the necessity of responsive slideshows and/or compositions – especially if one doesn’t think about the consequences and looks at it from a coder’s and not a designer’s point of view …
So what have you been doing to get around compositions in responsive design with Muse?
- use a different composition for each breakpoint
- not use compositions at all and program everything out in separate pages
- something else
1 person found this helpful
I don’t use compositions for the time being. and when necessary, I use hide/show in other breakpoints. This works very well, if you take care of the width, you assign to the composition (not too wide), so that you don’t run into the danger, to have tons of breakpoints.