Underlying Logic in Muse Responsive

[Skyler Kline]

I see that part of the problem—at the moment—is that this current release is partly broken, but before that, and I'm sure after, understanding how to control responsive behavior has been an issue.

When Adobe was testing Edge Reflow, the logic was simple, you set a parameter to either work in pixels or percentages, and you could nest elements within each other, resulting in the percentages or pixels respecting their parent element.

While there are certainly enough complicated combinations possible with this system, at the end of the day you could easily track down your problem.

In Muse, I can see that using groups has a meaningful impact on how responsive behaves, but I've yet to find a rule set that I can use to solve problems.

Additionally, the resize parameters become greyed out when you add an element to a group. I can't understand why this would happen—though I'm sure there's an explanation...

I've experimented with pulling elements out of groups and changing the one of these parameters, then putting it back, and it seems to change the behavior. Assuming it wasn't just bad testing methods on my part (i.e. I'm imagining things), then this seems to be an inefficient workflow.

I still haven't figured out if elements respect groups as if they are a parent object, or are they simply there to help us organize our thoughts?

I know that posters on the forum have mentioned that they help Muse to know how to relate responsive objects to each other, but what are the exact rules they follow?

I've also seen posts that recommend using blank rectangles to encourage Muse to move responsive elements correctly. I've had luck with this, but it hasn't been consistent enough that I can derive a usable logic from it.

I also think it feels like a bit of a hack, and is a messy way to design—if that type of direction is needed from the designer, we should have a dedicated UI element for it.... either a tool, or an additional handle on each element that could draw a bar to the element that is supposed to be influencing it.

Once the team has tackled the current bugginess, I would love if someone close to development would make a comprehensive video describing the entire underlying rule set, so we have the tools to solve any unpredicted responsive behavior, and to design the behavior that we are desiring.

I think we all respect the attempts to make Muse responsive seem like magic, but as in the real world, when magic fails, you need to fall back on logic to accomplish things.

Thanks.

[Preran · Accepted solution]

Hi Skyler Kline,

I will share this post with the product team for their observations. The better way to provide feedback and interact with the team would be to join the Muse Prerelease program using this link Adobe Prerelease

Thanks,

Preran

[Skyler Kline]

Thanks

[amitcs06]

Thanks for your post and we respect your valuable feedback.

Edge Reflow was a design application enabling static designs not intended for production. Adobe Muse targets production websites with complete interactivity powered by its widgets. With multitude of options like pinning, nested widgets, fluid and fixed content in widgets etc., with everything responsive now, the problem is immensely more complicated. The idea of creating a video to explain, how users can take fine control over Muse by logic is taken. We will try to do one where we explain the relationship between responsive elements in Muse. I’m sure that will help enable users to solve certain issues with logic as you mentioned.

Coming back to the issue at hand.

Group is an entity which we can use to pass parameter onto its grouped element if applicable.  Group shouldn’t be looked as container and its doesn’t hold any property. It always derives property based on the grouped elements. Here is the group usage w.r.t to size policy:

1) Consider you have 2 rectangles grouped with both having different size Policy (one is fixed and one is fluid).

In this case, group UI resize option will show blank(but enabled) as this is the case of mixed state.

If we try to set size policy from group it will be pass on to both elements as both elements support that size policy.

2) Now consider we have grouped such elements where one supports different size policy (like Textbox doesn’t have responsive width height-RWH but

support stretch to browser width) and other different (image responsive width and height but not Stretch to browser width).

Now if we try to set some size policy like RWH over group, it will not apply to Textbox(as not supported)

but will apply to image frame.

3) Now consider a widget which does not support right now to set size policy from UI. If your grouped elements are containing only widgets,

Group will show size policy as greyed out.

4) Now consider your group is widget and rectangle where rectangle support size policy to set, this is case of mixed state and now if via group we

try to set some size policy it will be passed to elements which support setting size policy and group will keep showing mixed state.

If the greying out issues you are seeing does not fall into the above categories can you elaborate more on it?

It would be ideal if you can you share a sample Muse file where we can see the resize options greying out.

Also, please share the post about wrapping responsive element in rectangle. Are you referring to the post about vertical space issue where we suggested to create a blank rectangle? That was a temporary workaround which was solved by providing a mulib and is resolved internally to be provided with the next patch update.

I’ll share the video once we are ready with it.

Best regards,

Amit

[Skyler Kline]

Thank You Amit.

Regarding Edge Reflow, it was designed to mock up responsive sites, which were then to be hand coded by the user. While this is definitely different than Muse, I was just pointing out that it was by far the easiest interface for understanding responsive design (for me at least). Since it was an Adobe product, it sort of seemed like Muse was reinventing the wheel when it didn't need to.

Of course, there would be a lot of work to get the Reflow code into Muse (maybe not even possible), but as far as interface goes, it seems like it could at least provide inspiration.

Thank you again for considering making a video. I'm sure it will help us a lot... maybe the process will even help you guys come up with interface elements that make the underlying behavior more evident.

As far as the groups go... I'm still confused, but I think I'm getting a better picture.

I don't think you're understanding my original point though.

I'm not talking about the behavior settings of the group being greyed out, I'm talking about the behaviors for the individual elements being greyed out once they are grouped. The are always set to being pinned left (does this work for every design? Does it turn off percentage based scaling within the group?), and they seem to be set to whatever they were set to prior to being grouped. As far as I can tell though, the only way to experiment with different settings is to ungroup them, change the settings and regroup them...

I'm still not clear though... are the groups creating divs that are then parents to the contents of the group? ...or are they simply organizational tools within the Muse interface, with no bearing on the actual site structure?

I can't seem to find the posts regarding the use of blank rectangles to control which elements push down others, but I seem to recall that there was even a Muse Jam video where Dani advocated this technique. It definitely predates the current issue of the header not pushing elements down correctly.

It has more to do with when something resizes vertically, and the elements below it on the page don't respond to the size change correctly, causing overlapping, or in other cases larger spaces. It seems like it can also pertain to horizontal spacing issues, but I can't say I understand it well enough to verify that. I generally just experiment until my site works—I've still not distilled out a set of rules I can use the next time it breaks.

The recommendation has been to draw a blank rectangle precisely between the two elements, and to group it with the lower element.

This does seem to usually work, but as I mentioned before seems a little hacky... there certainly should be a better way to do this.

[Skyler Kline]

Also, regarding parent/child hierarchy:

I feel like this is a very crucial part of all computer graphics, and is an aspect of Muse that seems hidden from the user.

Is this something that's decided in the background, or am I just not seeing how it works?

[amitcs06]

Hello,

Sorry for the delayed response.  Regarding group, if we have the intention to control its grouped element together then only its makes sense to create the group. When someone is grouping it means that he/she meant to control its grouped element together.  Once again thanks for your feedback, I have taken your input and will discuss internally.

Thanks

-Amit

[Skyler Kline]

Something else I just noticed along these lines...

I have some pages where it's easiest for me to put the images that accompany the text inline, but I'm noticing that the images are no longer responsive.

Is this correct? It doesn't really work for my situation.

This is a case where I can no longer access any pinning or resizing options, because they are greyed out.

I can't figure out why this would be a beneficial design, as you would think that inline elements would need to resize fairly often...

In my case the images just protrude off to the right side of the screen when you get farther from the last breakpoint.

[Günter Heißenbüttel]

Images, rectangles, circles aren’t responsive, when used inline and they never have been.

Compositions and slideshows are since Muse 2017.1.

That means: If you need this feature badly (and you don’t want to place the image between two text containers), use a one-image-slideshow instead and place it inline.

[Skyler Kline]

Thanks G unter, I'll do that.

[Skyler Kline]

I'd like to revive this post....

I'm still in the same situation as when I originally wrote this. I build a page, go to fine tune the responsive behaviors, and again, have no solid logical framework to address my problems.

The funny thing now, is if I google my problem, I literally get my own post on this forum.

So, I'm re-requesting a comprehensive video on the underlying logic, and how we can precisely manipulate it to tell Muse what we are trying to accomplish with our responsive designs (or to know for sure that what we want to do might be impossible).