Working with Adobe Muse's responsive tools

Lance Evans takes you though some tips for working with Adobe Muse's responsive tools.

With the latest release of Adobe's Creative Cloud-based Muse web design and website layout package, a lot has changed. So much that one look at the new interface can make a user think, 'oh boy, a lot to learn'. Most of that revolves around the new responsive web design site creation tools.

Having just worked with the shipping version a short time now, here are a few tips, thoughts and ideas I have gleaned thus far.

Sticking with the old workflow

I've received a few emails from users that liked the old way of working. Fear not, you can still choose to work the way you did before. Although for some reason Adobe has made doing so needlessly confusing.

First off, when you create a new site and choose 'Fixed' to work the older way, or 'Fluid' to work the new way, you will notice that the options offered are almost identical (see image below).

Working with Adobe Muse s responsive tools

Fixed and Fluid working is curiously similar

Regardless of which workflow you choose, you no longer see the DESKTOP, TABLET and PHONE layout options in the wireframe interface. Even in Fixed mode, Adobe has inexplicably moved those to a menu-only location, here: PAGE>Add Alternate Layout>Tablet/Phone.

But oddly, those layout options are available for Fluid as well as Fixed sites. Why would you want those layouts with a Fluid project? I don't know, and would suggest you just ignore these options when in a Fluid workflow.

Equally odd: open a 'Fixed' layout and what do we see at the top? The new Breakpoint controls. Why? Again, I really have no idea and it seems needlessly confusing. Though it is worth noting that right-clicking on the Breakpoint bar allows you to enable/disable a 'Fluid Width' option. Still, I would ignore this confusion for now and simply hide the Breakpoints when in a Fixed workflow. Hide Breakpoints with a right-click option on the bar itself, or hide and show them under the View menu.

New responsive tools

Let's take a quick look at some of the new tools for responsive design. The first one is a new tool, or a setting really, that is easily overlooked (see image below).

Found on the very bottom of the left side tool pallet, this setting determines whether the text editing you are doing will effect the text box just in the current Breakpoint ('Format text on current Breakpoint', the single 'T' icon), or if it will effect all Breakpoint instances of the text box being edited (Format text across breakpoints', the multiple 'T' icon).

Keep this option in mind before you touch a text box. In most cases it is a lot safer to leave it set to effect just a single Breakpoint. Turn it on to effect all zones if the text box is set to act responsively, see next section.

Responsive text and text boxes

Much of all publishing work is about formatting text. Or 'massaging' it if we want to be artsy. The web has always made that harder than print, and responsiveness adds even more twists and turns. One might think that you should be able to click on all the 'responsive' settings for everything and – whoopee! – life would be great.

Well Muse does give us that option, we just have to learn to use it properly. New 'Resize' menus can be found both at the top of the screen, and by right-clicking on a page object. This option is available for both images and text boxes, though they are obviously treated differently.

You can reach these new responsive settings in two locations: the controls above and via a right-click

Set a text box to 'Responsive Width' and Muse will change its width proportionally with that of the browser's width. This sounds like a good thing, and it can be for many situations.

But for we control freaks, it adds yet another variable that might mess up our vision. The thing to keep in mind is that we now have other toolsets to address these issues as well, for example, Breakpoints. So rather than setting a text box to be responsive, instead keep its width locked and modify it as needed in each of the various Breakpoint zones that you create.

Essentially, this is almost like treating each Breakpoint as if it was a fixed page, like we have done with the desktop, tablet and mobile pages in previous versions of Muse. This just seems like a 'best of both worlds' way to work. Though it is more labor intensive than choosing the Responsive Width option and letting things go.

Generally speaking, we will always need more control over our headlines than over our body text. So while most body text can be set to Responsive Width, I'm less inclined to do that with the headlines without a lot of testing. Instead, the headlines are perhaps best handled by relying on breakpoints. But this all depends on the design. Remember: test, test, test.

Pinning vs responsive positioning

In addition to a responsive text block width, if not pinned in one way or another, Muse will also responsively shift the horizontal placement of an item on the page. This is a great thing, when it works.

I have noted that when changing the browser width, some items placed in the dead-center go awry. My solution is to pin it to the center, as seen here. Again, testing is your friend.

Variables per breakpoint

With all of Muse's new responsive tools, the heavy hammer is of course the Breakpoint controls. Each new Breakpoint allows the designer to start with a fresh canvas, at least if needed. Granted, this is not the way you want to work. Ideally, you would flow as smoothly as possible from one browser width to another.

In fact, ideally you would rely mostly on the new responsive controls listed above, and only use Breakpoints as a last ditch solution, when other solutions won't work. Theoretically you could create a responsive site with only one full-width Breakpoint and have all the elements scale automatically. Granted, this would probably necessitate it being a rather simplistic site. In any case, you probably want to try and have as few breakpoints in a project as you can.

But as a fail-safe, Breakpoints can be used gently, or with brute force. Gentle use involves waiting until page elements begin to break, then creating a new Breakpoint width where you fix that element. Brute force techniques involve completely removing a page object that exists in one Breakpoint zone (you can right-click to 'Hide in Breakpoint' or 'Hide in other Breakpoints'), and replacing it with a new item in another zone. Or perhaps just removing an item altogether as the browser width narrows.

For more granular tips and insights, visit this page on Adobe's site.

Page testing tips


Let's start with a tiny one. If you used Muse's built-in PREVIEW function in previous versions of muse, it may be time to shift your workflow here. Preview doesn't let you test responsiveness. The only option is to use the new 'Scrubber' control, which is part of the Breakpoint ensemble. Of course, this is in the layout window so you will not see a real preview of many functions. Instead, get used to using the keyboard commands for for page preview (Ctrl/Cmd+Shift+E), and for full site preview (Ctrl/Cmd+Alt/Opt+E).

Number the instance zones

By placing an identifier on the page of each Breakpoint zone, you can identify which zone you need to make changes to. I simply make a text box for each zone with the pixel width value of that zone.

Make sure each identifying text is only visible in its proper Breakpoint. And also make sure to turn them all off before you publish. An easy setup would be to create a new layer for all labels. Then you can simply turn them all off with one button.

One other thing to note: keep the tag really, really small and away from other items whose positioning could accidentally be effected.

As can be seen in the image above, I have added a Breakpoint tag to each zone. Now I can easily see which zones have issues I need to address. In this example we can see that the narrower version of '768' needs some tweaking.

Breakpoint zone identifying tags save time! (Template from

If the text boxes can be fixed to work well across the entire zone, then great. If not then we might want to consider adding another Breakpoint to deal with it independently. Another option: expanding the zone we call '550' to be a bit wider to encompass the problem, might just solve it.

Words: Lance Evans

Lance Evans is creative director of Graphlink Media.

Liked this? Read these!