June 21, 2016

Responsive Design Enhancements and Comp CC: It’s a Muse update!

With today’s release, creating custom responsive websites in Muse is easier and more expressive. Scroll effects are now available for responsive sites on breakpoints set to fixed width. A new vertical move handle helps you work more efficiently by moving large groups of items at once. Under the hood, we’ve introduced efficiencies that can help increase the Google Page Speed ranking of your sites.

We’re also excited to introduce support for Muse within Adobe Comp CC as a new way of bringing your ideas to life. Comp CC allows you to create your layout anywhere, anytime on iPad and iPhone. Starting today you can finish these layouts in Muse and turn them into responsive websites! Download Adobe Comp CC and try it out by using the new “Send to Muse” button. See the whole workflow in action in this video tutorial.

These are just a few of the improvements in today’s release. For a detailed list check out our release notes. If you’re new to Adobe Muse, start your free trial today.

Creative Matchup

In case you missed it, to celebrate the release of responsive design in Adobe Muse CC in February we challenged two exceptional designers to create responsive websites. For both Hydro74 and Ashley Heafy it was their first project with Muse and we pitted them head to head competing to create the best site for a surprise client. The catch? We only gave them only 4 hours for the entire project – from their first meeting with the client to publishing a finished site.

We teamed up with the fabulous group over at Fiction and produced Creative Matchup, a series of two videos to tell the story of this clash of two design titans. Check them out!

Part 1:

Part 2:

Decision to Drop Support for Internet Explorer 8 and 9

As on ongoing process we evaluate browser usage trends and improve Muse output to take advantage of the capabilities of modern browsers while preserving your design intent on all popular browsers. Microsoft ended support for Internet Explore versions 8 and 9 in January of this year and usage has fallen low enough that we’ll no longer be testing the HTML output from Muse on these browsers. This decision enables us to make significant improvements to the code Muse creates.

As always, let us know what you think on the Muse forums.

6:00 AM Permalink
February 8, 2016

Responsive Design in Adobe Muse is available now!


Big news! We’re proud to announce that responsive design is available today in Adobe Muse. Too often we see designers getting boxed into cookie-cutter layouts due to the complexity of creating unique responsive layouts. Adobe Muse now makes it easier than ever to create completely custom sites that look great on any browser or device – without coding.

This release also includes Creative Cloud Libraries, which lets you share, access and reuse assets in other Adobe Creative Cloud tools. You can find, license and manage royalty-free Adobe Stock images and vector graphics directly within Adobe Muse. Select from 45 million assets, save your selection to your Creative Cloud Libraries, and then simply drag it into your website.

We believe Adobe Muse’s intuitive, free-form approach to responsive design will help break down any barriers you experienced before. We encourage you to play, experiment, and express your creativity with these new capabilities. Don’t forget to show us what you make by submitting it for consideration as a Muse Site of the Day.

These are just a few highlights in today’s release. For a complete list of what’s new, check out our release notes. If you’re already a Creative Cloud customer, you can update Adobe Muse from the Creative Cloud desktop app. If you’re new to Adobe Muse, start your free trial today.

Brian Thomas
Muse Product Manager


9:00 PM Permalink
November 30, 2015

Major Update Coming in Early 2016

In the midst of Adobe’s announcement today about new Creative Cloud updates, we’d like to share more details about the next release of Adobe Muse. Simply put, the upcoming version will be our most significant update since Muse was first launched.

As we mentioned during Adobe MAX in October, one of the major capabilities we’re adding is responsive design, enabling designers to craft websites that look beautiful on any sized screen. We believe this will be groundbreaking because Muse makes responsive design completely visual and freeform, without having to write a single line of code. Our goal is to help designers of any skill level conquer responsive design.

Another huge step we’re making is integrating Adobe’s signature CreativeSync technology into Muse. Designers will be able to access and reuse design assets such as graphics and colors with Creative Cloud Libraries, as well as browse and license millions of high-quality stock photos and vector graphics from Adobe Stock. Other upcoming features include improvements to SVG support, animated state transitions, and many usability enhancements. The next update of Adobe Muse will be the most significant release since it was first introduced.

Our team is putting the finishing touches on all these improvements, and is working nonstop to ensure the best in class quality you expect from us. The next release will be available via Creative Cloud as soon as it’s ready, sometime in early 2016. In the meantime, you can try a pre-production build today by joining our private pre-release program. Let us know what you think!

To get more news and updates, please follow us on Twitter and like us on Facebook.

Brian Thomas
Muse Product Manager

9:00 PM Permalink
October 5, 2015

Announcing Responsive Design in Adobe Muse

Today we are unveiling a major milestone – responsive design is coming to Adobe Muse! The capabilities we’re introducing are completely free-form and make it easy for any designer to approach and conquer responsive web design. Best of all, you won’t get boxed-in with restrictive templates or write any code. If you’re not familiar with Muse yet, learn more and get started at adobe.com/muse.

The Muse team has observed a major trend in the design community’s growing discontentment with rigid responsive methodologies. We hear about how current approaches can ultimately limit creativity and expressiveness on the web. This difficulty motivates us to improve the solutions we provide designers:

Noah Stokes on Why web design is losing its soul
Andrew Clarke about Creativity Over Predictability
Owen Williams on how Web design is now completely boring

Responsive design in Muse is about giving designers the power to bring spontaneity and originality to web projects. We set out to create an experience where it would take only minutes to make a responsive concept come to life and understand how it looks on any sized screen. Our goal was to build a responsive design tool that feels as playful as it does powerful. We can hardly wait to see what you create with it.

But you don’t need to wait. If you’re interested in helping us test the new responsive capabilities, you can try the beta now. It’s available for Creative Cloud members on museprerelease.com. Since day one, our loyal community has helped shape Adobe Muse into what it is today and where it needs to go in the future. We’d love to hear from you!

Brian Thomas
Muse Product Manager

PS: Be sure to check out the MAX keynote here: https://max.adobe.com/sessions/max-online, and and stay tuned for upcoming recordings of breakout sessions and demos of responsive design in Muse.

6:00 AM Permalink
June 18, 2015

Text on the Web: Pitfalls & Safeguards


The 2015.0 release of Adobe Muse features deep integration with the subscription font service Adobe Typekit. Even as you find typographic inspiration in this library of premium web fonts, it is imperative to keep your designs grounded in the realities of the web medium. This blog post takes a look at one such reality: the lack of consistency across browsers when it comes to text.

We will not focus on browser support for advanced typographic features; The State of Web Type is a great resource for this topic. Instead we will investigate inconsistencies in areas that designers — especially those with a print background — often take for granted:  fonts, text rendering, and text layout. We will also outline Muse-specific strategies to avoid or, at the very least, work around these vagaries.


When you choose an entry from the Standard Fonts section of the Muse font drop-down list, you are  really specifying a “font stack”: a list of fonts for the browser to try in succession until it finds one installed on the viewer’s computer or device. For example, if you choose “Verdana (Tahoma, Geneva, sans-serif),” the browser will render text in Verdana only if it is installed; otherwise, it will try Tahoma, and so on. The fonts in these predefined lists collectively cover most site visitors and have roughly similar traits (e.g., sans-serif with large x-height). That is a far cry from any reasonable expectation of consistent site visitor experience. For this reason, the 2015.0 release abandoned the term “web-safe” that Muse had previously used for these fonts.

Using web fonts is key to consistency as well as freedom from the monotony of standard fonts. It is no surprise that web fonts are becoming ubiquitous — in May 2015, for the first time, a majority of the sites analyzed by the HTTP Archive used web fonts.

But remember to use web fonts judiciously; too many on a given page can greatly increase load times. Typekit recommends a maximum kit size of 400K. The number of fonts this translates to depends on your choice of fonts as well as the character set. 4–6 fonts (counting each weight and style separately) with the “Default Subset” setting and 2–3 fonts with the “All Characters” setting is a good rule-of-thumb.


How a font ultimately renders on the web is something you, the designer, have little control over. The same text may appear crisp or blurry, smooth or jagged, “thick” or “thin” depending on the viewer’s OS, browser, and screen resolution. However, you do have control over aspects of the design that most impact text rendering:

Font: Not all fonts are created equal; some foundries invest great effort in optimizing their type designs for screen rendering. Perhaps even more important than choosing a quality typeface is using it in the context for which it was designed (e.g., “Display” or “Body text”). To that end, use the “Recommended For” filters in the Add Web Fonts dialog. If the same family supports different use cases (e.g., Minion Pro Display, Minion Pro Subhead, Minion Pro, Minion Pro Caption), pick the one that best suits your needs.

Font size and color: even subtle changes in font size and color can significantly affect text rendering. For example, slightly lower contrast (e.g., dark-gray text on light-gray background) often works better than black on white.

It is worth noting that these tips are just starting points; there is no substitute for experimentation and testing your designs on as many platforms as you can.

Layout: Baseline Positions

Browsers use different font metrics when positioning lines of text. This can lead to inconsistencies that are particularly apparent when another object is manually aligned with a text baseline, as in the following example. The baseline of the heading (set in Helvetica) is perfectly aligned with the blue rectangle in Firefox, but not in Chrome.

Firefox 38/Mac OSX

Heading in Firefox 38/Mac OSX

Chrome 43/Mac OSX

Same heading in Chrome 43/Mac OSX

The amount of variation in baseline positions is font-dependent. Discrepancies of the magnitude shown above are, fortunately, rare. Most web fonts served by Typekit have their font metrics normalized to behave consistently across browsers.

Layout: Line Breaking

Each browser has its own implementation of text layout (as does Muse). As a result, for the same text with identical formatting, line or word break positions will often vary from browser to browser (and between browser and Muse Design mode).

For text frames that are intended to fit one line (e.g., headings, labels etc.), you may end up with unwanted breaks as shown below. It is recommended that you make such text frames a bit wider than  what’s needed to fit the text in Muse Design mode.

Heading as designed in Muse

Heading as designed in Muse

Same heading in Internet Explorer

Same heading in Internet Explorer


The figures below illustrate line break variations for some body text. The same text fits in eight lines in Muse Design mode, but spills over to the ninth in Firefox.

Body text as designed in Muse

Body text as designed in Muse

Same body text in Firefox

Same body text in Firefox


One practical implication of such variations is that independently-positioned margin notes or images that relate to specific ranges of text may drift from the latter, especially in long, narrow text frames.

Independently positioned images that relate to text ranges

Margin notes or images: independently positioned


The workaround is to paste these items as inline text-wrapped objects and adjust wrap offsets to position them as desired.

Margin notes or images as inline objects

Margin notes or images as inline objects


The other implication of line break variations is the effect on the height of the text frame. How Muse deals with height changes and what you can do to guide this behavior is a topic worthy of a separate post. Stay tuned!

Meanwhile, we encourage you to give Adobe Muse 2015.0 a try and create inspired designs while carefully avoiding the pitfalls discussed above. We’d love to see what you create!

1:53 PM Permalink
June 3, 2015

Brackets for MuCow

When I Joined the Muse team in April I started researching writing widgets just to see what all the hubbub was about.

After a few days of editing without code coloring, syntax highlighting, etc… I decided to do something about it and wrote an extension for Brackets to code color the tags in a MuCow and add code completion so Brackets could help write the code for me.

Brackets Code Completion editing a MuCow

Code Completion List

The result was that I had an extension that would do all of those things but nothing prevented me or guided me into making sure what I was writing was valid MuCow. So I added MuCow validation.

Now on Open and Save Brackets will validate the MuCow and give me warnings when something is out of spec:

MuCow validation

Validating a MuCow

The bottom panel opens open whenever there is an error and there is a yellow Triangle

Warning Indicator

Brackets Status Bar with Warning Indicator

Now the MuCow validation is just simple XML validation. Muse can still detect a few problems that my validator can’t and, since it’s a standard XML validator, the messages can be a bit cryptic. For most cases, however, the messages are decipherable and, clicking on the line, should put the cursor where the problem exists.


Brackets Problems Panel with MuCow validation warnings

Checkout the video which shows the extension a little deeper and let us know what you think.

3:30 PM Permalink
March 20, 2015

Mobile-Friendly Sites and Google Webmaster Tools

In February, Google announced that starting April 21, it would include mobile-friendliness as part of its ranking signal. As part of that change, Google’s Webmaster Tools has been updated to identify pages of your site that will be affected by the new mobile-friendly criteria. In preparation for this change, we’ve evaluated Google’s processing of sites generated by Adobe Muse. This post describes our findings and provides recommendations for making your site more mobile-friendly if needed.

Google’s Announcement

Let’s start with Google’s announcement.

“Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices.”

The implication of this announcement is the changes affect searches performed on mobile devices.

What do I need to do?

If your site already has a phone page for every desktop page, then you are likely done. If not, follow the guidelines in the Recommendations. Muse will do the rest, including adding the appropriate SEO markup to the site.


1. Make use of Muse’s adaptive approach, which is supported by Google, to create an experience tailored for users on desktop and phone. More specifically, each desktop page should have an alternate page which has been formatted for viewing on a phone. Visitors will automatically be directed to the appropriate page based on their viewing device.

2. Run Google’s Mobile-Friendly Test (you may need to run it multiple times as it seems to yield inconsistent results). If no errors are generated, you’re done.

3. Understand the errors and warnings reported by Google Webmaster Tools and the scope of those results. The most common errors are caused by not having a page which has been formatted for viewing on a phone.

Note: Sometimes, people create pages that are intended to only be viewed from the desktop and as such, have no corresponding page formatted for viewing from a phone. Be aware Google will still inform you that the page is not mobile-friendly. For example, a five page desktop site can easily be reimagined as a one page phone site with the desktop content included as separate panels.


Muse currently offers a mobile solution that follows an adaptive approach which, when used as prescribed by Google such that every desktop page has a corresponding phone page, yields a green “Awesome! This page is mobile-friendly” result from Google’s Mobile-Friendly Test.


Adaptive vs Responsive

A website can take a responsive, dynamic or adaptive approach to being mobile-friendly and Google supports all three. Muse currently takes an adaptive approach to mobile support and as long as you follow best practices by creating phone renditions of your pages, your site will be considered mobile-friendly by Google.

What is a mobile-friendly page?

Google considers your page mobile-friendly if it fits within the width of a phone, the text is readable and the links are far enough apart to be touched. The full details can be found on Google’s Webmaster Central blog.


Let’s look at this beautifully crafted, Engineering Green, desktop site which is not mobile-friendly.

Sample Muse Page

Sample page for demonstration purposes only.

Google Webmaster Tools Result

When the above Desktop page, which has no corresponding alternate page for the phone, is loaded on a phone, the phone will by default zoom out to fit the entire width of the content in the view. As a result, the following errors are reported.

Mobile-friendly errors reported by Google for a Desktop URL with no corresponding Phone page.

Mobile-friendly errors reported by Google for a Desktop URL with no corresponding Phone page.

Making the page mobile-friendly

Both errors can be resolved by creating an alternate phone page and reformatting the content for the smaller view. By creating a phone version of the page Muse automatically adds the following link to the head of the desktop page to inform Google of the alternate mobile-friendly phone page:

<link media="only screen and (max-device-width: 380px)" rel="alternate" href="http://examplesite.com/.../phone/index.html"/>

In addition, Muse automatically adds a redirect to the head of the desktop page such that the browser will redirect to the phone page when viewed from a phone.

Finally, Muse adds the following information to the head of the phone page to inform Google of the relationship between the phone page and the desktop page:

<meta name="viewport" content="width=380"/>
<link rel="canonical" href="http://examplesite.com/.../index.html"/>

 If you have additional questions, feel free to reach out via Muse’s public forum.

6:28 PM Permalink
October 6, 2014

SVG in Muse CC 2014.2

The October 6 release of Adobe Muse CC 2014.2 includes support for importing Scalable Vector Graphics (SVG). SVG usage in websites has become more desirable because, unlike raster images which are simply a collection of pixels, SVGs are drawing instructions which beautiful at any browser zoom level or screen resolution.

The biggest challenge with building HD websites using raster images is that you need larger, higher resolution images for high resolution screens and these larger images take significantly longer to download to a browser. Hence, developers typically create low and high resolution versions of each image and choose which one to download and display based on attributes of the screen. SVGs, on the other hand, are typically resolution independent. I say typically because it is possible to embed a raster image within an SVG. For the typical SVG illustration, there is no need for multiple versions and therefore no penalty for rendering on a high resolution screen.

Browser Support

Basic SVG support is ubiquitous across modern browsers. The problem children include Internet Explorer 8, really old versions of iOS Safari (before 3.2) and Android versions prior to 3. Of these browsers that do not support SVG, IE 8 has the largest global usage at somewhere around 4% and shrinking. Muse generates a raster image fallback for these browsers that do not support SVG.

Importing SVG into Muse

Prior to Adobe Muse CC 2014.2, users could Place an SVG onto a page by choosing “Insert HTML…” from the Object menu and then pasting the <svg> embed code into the dialog. The <svg> would then be embedded in the HTML code for that page when exported and would render perfectly in browsers that support SVG. However, there would be no image fallback for older browsers and the design time rendering of the SVG may or may not have succeeded, depending on whether or not you were running Muse on Windows with IE 8 installed.

With the release of Adobe Muse CC 2014.2, users can import SVG in any of the following ways:

Place directly onto the page

Select “Place…” from the File menu in Muse and choose an SVG just as you would a JPG, PNG, PSD or GIF.

Placed SVGs within Muse behave more similarly to embedded HTML than to a placed image. At Place time, Muse will render the SVG using Safari on the Mac and IE on Windows to generate a poster image for design time rendering. Similar to embedded HTML, this poster image is regenerated every time you resize the placed SVG within Muse. At export time, this poster image is used as the fallback for older browsers that do not support SVG.


<img src="images/next.svg" width="48" height="48" alt="Arrow image" data-mu-svgfallback="images/next_poster_.png"/>


At load time, Muse will execute the following JavaScript to determine if the browser supports SVG. If it does not, then the ‘src’ attribute of the <img> will be changed to point to the fallback image and the ‘svg’ class will be added to the <html> element so that ‘.svg’ selectors will become enabled in the CSS.

var supportsSVG = document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1");


Note that the ‘width’ and ‘height’ attributes of the <img> element is determined by the dimensions of the page item on the page as sized by the user within Muse. It is up to the SVG code to render within these dimensions. That is, there is no scale being applied. Therefore, the SVG has the freedom to respond to different dimensions in different ways depending on how it was created. For example, it may change the crop or it may scale to fit within the dimensions as if it were a background-image with background-size set to ‘contain.’ Its behavior is unknown to Muse just as the resize behavior of arbitrary HTML pasted into Muse is unknown. It is primarily for this reason that Muse will regenerate the poster image after a resize operation.

Conversely, Placed images have a containing frame, basically scale when resized and are cropped by the frame. Their resize behavior is completely predictable within Muse.

Import as a background-image

Just as raster images can be imported as a fill for any page item, Page or Browser area, SVGs can be imported from the same Fill or Browser Fill panel. When exported, they SVG is applied using a background-image CSS property as follows:

<div class="colelem" id="u80"><!-- simple frame --></div>

<!-- Default CSS properties for the above div with id "u80" -->
      background: #FFFFFF url("../images/next_poster_u81.png") no-repeat left top; 
      background-size: 48px 48px;  

<!-- The following selector is automatically enabled when the 
     'svg' class is added to <html> element at load time if the 
     browser supports SVG. Otherwise, the SVG selector is 
     invisible and the fallback poster image is used instead. -->
.svg #u80 
      background-image: url('../images/next.svg'); 


SVGs imported as background fills can be set to “Scale to Fill,” which sets the background-size CSS property to ‘cover,’ or “Scale to Fit,” which sets the property to ‘contain.’ Muse does not regenerate the poster image for background SVGs set to Scale to Fill/Fit and therefore the design time rendering may be a bit pixelated. However, the browser rendering of the scaled SVG is high quality and does not require the SVG to have been saved as a Responsive SVG.

Copy/Paste from Illustrator

Copy a selection from your favorite illustration in Adobe Illustrator CC 2014 and paste into Muse. If you are using Adobe Illustrator CC 2014.1 or later, then text will be converted to outlines. If you are using Adobe Illustrator CC 2014.0, then the SVG Illustrator generates for the clipboard uses SVG settings based on the choices from the latest Save As SVG operation within Illustrator.

The output from Muse for pasted SVG is equivalent to the output from a Placed SVG. If you’d like the SVG to be embedded instead of referenced in an external SVG file from an <img> element, you can still paste the SVG code into an Arbitrary HTML element as in prior versions of Muse. However, using an embedded approach will not generate a fallback image.

Trouble shooting

SVG is powerful when authored well and the appropriate settings are chosen. However, if the wrong settings are chosen then various problems may arise.

Wrong font in some browsers?

There are numerous ways to deal with fonts within SVG, but we strongly recommend Outlining fonts. Subsetted fonts are not supported by Firefox. SVG fonts that are not subsetted will render correctly only if the visitor to the site has that font installed. For the best support across browsers, it is recommended that fonts be set to Outline.

Similarly, images within an SVG can either be embedded or linked. We strongly recommend embedding so that the linked image does not need to be managed.

SVG is cropping instead of resizing?

Muse exports Placed SVG as an <img> element with a width and height matching the dimensions of the SVG in the layout. Note there is no scale specified. The browser then attempts to render the SVG code within this <img> element. If the SVG has fixed dimensions in its code, it may not be able to render within the specified width and height and will crop instead. This behavior can typically be resolved by making sure “Responsive” is checked in Illustrator when saving the SVG.

SVGs imported as background fills in Muse are exported using ‘background’ CSS properties. If the fill has been set to “Scale to Fit” or “Scale to Fill,” then the appropriate ‘contain’ or ‘cover’ value is chosen for the ‘background-size’ CSS property to achieve the desired effect. Because the browser uses scaling to resize the background image as opposed to changing its width and height, SVGs used as a background fill do not need to be saved as “Responsive.”

Note that using any image as a background fill instead of as a Placed image on the page prevents the use of ‘title’ and ‘alt’ attributes for improved Search Engine Optimizations.

SVG renders as text instead of as a graphic in browser?

If the SVG fails to render as a graphic and instead you see the SVG code as if it were text, then your server is incorrectly configured. The problem and the fix are described here.

9:41 AM Permalink
June 18, 2014

HD Websites in Adobe Muse CC 2014

Smarter HD Websites
HD Handling of Placed Images
HD Handling of Background Images
The HiDPI (on/off) Button Widget
In-Browser Editing Anywhere
HTML Heading Tags for Improved SEO
The Benefits of Dropping Internet Explorer 7

The release of Adobe Muse CC 2014 includes significant improvements in both the application and the HTML/CSS code it generates, continuing our pattern of improving the quality of code with every release. Prior versions of Adobe Muse CC were built on Adobe AIR. Adobe Muse CC 2014 is a 64-bit native application and requires a 64-bit operating system. Users will begin seeing differences immediately as the interface has been updated to support high definition screens and provide freedom to arrange windows and palettes as in other Adobe applications. More significantly, we’ve added several improvements to the code generated by Adobe Muse CC.

Smarter HD Websites

Adobe Muse CC 2014 introduces support for Creating High Resolution Websites that render high-resolution images on high-resolution devices, standard resolution images on standard devices without the performance penalty of loading the high-resolution images, and an optional HiDPI (on/off) Button Widget that can be placed on a page to enable site visitors to disable HD rendering when viewing from a high-resolution device on a slow network.

On a High Definition (a.k.a. Retina) display the area occupied by one pixel on a standard display is replaced by at least four pixels. That is, each pixel is at most half as wide and half as tall. Therefore, taking full advantage of all these tiny pixels requires just as many pixels in the images displayed on a website. However, four times as much data means roughly four times as long to load that data and website visitors are impatient. The tendency of site visitors to abandon a site and give it negative reviews after only a couple of seconds is well documented in articles by the New York Times, Radware, KISSmetrics, and others.

Many HD websites have two problems:

  1. They download both the HD image and the standard resolution image, resulting in five times as much data even on standard resolution devices.
  2. They do not give site visitors the option to disable the HD rendering on HD devices running on a slow network.

For HD enabled websites, Muse automatically generates standard resolution and 2x resolution images and then loads the appropriate version for the device from which it is being viewed. Images that are Placed into a Muse layout are exported as HTML <img> elements. Images that are imported as background fills are exported as background-image CSS properties. In both cases, the images are imported into Muse at half their natural dimensions. At export time, an image is generated at half-resolution for standard displays and the high-resolution image is exported for high-resolution devices. The image that is rendered by the browser is determined based on the properties of the viewing device and whether or not HD rendering has been disabled using Muse’s option HiDPI (on/off) Button Widget.


HD Handling of Placed Images

Images Placed into Muse are exported as <img> elements. The standard resolution images are referenced by default in the ‘src’ attribute. The 2x resolution image has the same name as the standard resolution image with  “_2x” appended and is referenced by the ‘hidpi-src’ data property. At page load time, if the device pixel to html pixel ratio is at least 1.5 and HD rendering has not been disabled using Muse’s optional HiDPI (on/off) Button Widget, then the ‘src’ attribute will be updated to reference the HD image.

Default HTML for HD Image

<img src="images/loren.jpg" 
      alt="Loren at home" width="230" height="153"/>

HTML for HD Image on HD Display with HD Enabled

 <img src="images/loren.jpg"
      alt="Loren at home" width="230" height="153"/>


HD Handling of Background Images

Images imported as background fills are exported from Muse using ‘background’ or ‘background-image’ CSS properties.

<html class="html js">
     <div class="colelem" id="u74"><!-- simple frame --></div>
   background: #FFFFFF url("../images/loren.jpg") no-repeat left top;
   background-size: contain; 
.hidpi #u74
   background-image: url("../images/loren_2x.jpg");

Rendering of the high-resolution background images on the page is achieved by adding the ‘hidpi’ class to the html element as follows:

<html class="html hidpi js">

When viewed on a standard resolution device, the HD images are completely ignored thereby avoiding a performance penalty.


The HiDPI (on/off) Button Widget

Anyone who has attempted to watch an HD video on the web over a slow connection knows it is not enough to automatically switch to serving up HD content based on the resolution of the display. Ultimately, the site visitor needs to be given the option to disable HD content. Adobe Muse CC 2014 solves this problem by providing an HD Button which can be custom styled within Muse. When present on a page of the site, visitors who are viewing on a high resolution display can toggle the rendering behavior of the site by clicking the button.

HD rendering is active

HD rendering is on and supported by the display.

HD is available but deactivated.

HD rendering is available but deactivated.

HD assets are available but the display is not HD.

The display does not support HD rendering.



In-Browser Editing Anywhere

With the release of Adobe Muse CC 2014, the In-Browser Editing feature is available for any site that is published using the built-in FTP Upload feature.

One of the Muse team’s goals is to give designers the freedom to publish anywhere. Adobe Muse CC 5.0 introduced In-Browser Editing on sites published to Adobe Business Catalyst, where site owners could replace images or make changes to text from within the browser. That is, the content of the site could be updated without using Adobe Muse CC. When an Adobe Business Catalyst site was opened in Muse, Adobe Muse CC would merge any edits made via In-Browser Editing back into the Muse document.

In the future we plan to add new custom form features which can be used by sites published to any hosting provider supporting PHP. In addition, we plan to make it easier to publish to your favorite host directly from Adobe Muse CC.


HTML Heading Tags for Improved SEO

HTML heading tags (e.g., h1, h2…) clarify the page content structure, thereby improving SEO and accessibility. In previous releases, heading tags could only be specified using paragraph styles. Now, they are directly accessible from the Text palette.

h1, h2

Applying heading tags to paragraphs for improved SEO.


The Benefits of Dropping Internet Explorer 7

As noted in a previous post, we’ve made the conscious decision to drop support for IE7 in Adobe Muse CC 2014 to provide a better experience in more modern browsers. For example, in order to support 100% width elements in IE7, we used hand-coded JavaScript to adjust the width at runtime resulting in a performance lag. If you re-export your site from Adobe Muse CC 2014, the 100% width elements will use CSS to adjust the width resulting in faster performance and a better rendering experience. As always, you merely need to re-export your site from the latest release of Adobe Muse CC to benefit from this and numerous other code improvements and bug fixes.

8:03 AM Permalink
November 13, 2013

Extending Muse


This week we’re excited to announce the Fall 2013 release of Adobe Muse CC. This release introduces a large number of new features and enhancements—which you can explore on the newly redesigned muse.adobe.com website.


In this post I’m going to highlight one of the underlying themes of this release that we refer to as extensibility—which allows you to save, share, and download widgets or styled page items from the Muse Exchange site.


With the addition of the new Library panel, you can now save your designs of buttons, widgets, or any page item for future reuse. For example if you’ve styled certain widgets to match a customer’s brand guidelines, you can now save them for quick reuse in future projects.


Another thing you can do with your saved items is share them with the community on the Muse Exchange site. When you export your library item, Muse will create a .mulib [Muse Library] file that you can upload to the community or share with your co workers.



You can also download and import .mulib files created by others into your library by simply double clicking the .mulib file. The community files on Exchange allow you to quickly get started with designs that are already pre-made.



The second part of the extensibility theme is that you can now develop HTML widgets that are not currently available in Muse, and easily share them with others in the community.

As a designer you can install these widgets just like you would install the .mulib files from above (note: that if the widget is distributed as a .mucow file, you’ll want to bring it into Muse via the File Menu -> Place command). A great example of this type of widget is the Font Awesome Widget—created by musegrid.com—which allows you to add font icons that scale up cleanly on any screen.

As a developer you can learn how to get started creating these widgets that we call Mucows on this documentation page.

Let us know what you think

We are very excited about the new features in this release and about the extensibility theme. As always, your feedback is key to our growth as a product. Please feel free to provide us with feedback on the forum or in the comments below.

The Muse Team


8:30 AM Permalink