November 13, 2013

Output improvements in Muse CC 7.0

The release of Adobe Muse CC 7.0, which was announced on November 13th, includes many features and improvements. This article describes some of the output improvements, which continue the trend described in Muse 5 Code Improvements and IE7,  Code Improvements in Muse 4, and earlier posts.  Adobe Muse CC 7.0 includes improvements to images, changes to produce consistent leading across browsers, and a mechanism for developers to build and share their own service based widgets that inject code into the website. These widgets are built using the MuCow (Muse Configurable Options Widget) SDK and were the foundation for the social widgets shipped with Adobe Muse CC version 7.

Image Resampling

Adobe Muse CC 7.0 uses a Bicubic Sharper algorithm to produce higher quality images when resampling is required due to resizing an image smaller. Earlier versions used a more generic Bicubic algorithm. The difference between the two algorithms can be seen in the following images exported from different versions of Adobe Muse CC.


Adobe Muse CC 6.0 Output: Bicubic resampling of an image reduced in size by a factor of 6.

Bicubic Sharper

Adobe Muse CC 7.0 Output: Bicubic sharper resampling of an image reduced by a factor of 6.

Continue reading…

8:17 AM Permalink
June 17, 2013

Muse 5 Code Improvements and IE 7

On June 17th, Adobe released Muse CC 5.0 as part of its Creative Cloud offering. This update to Muse CC includes numerous features such as Scroll Motion animations (also known as parallax scrolling), the ability to use Muse Forms with any hosting provider that supports PHP, In-Browser Editing of Muse generated sites hosted by Business Catalyst, a new Layers Panel, and Vertical Text. This release also includes several bug fixes, minor code-gen improvements to simplify the HTML and improve fidelity in older browsers and a significant improvement to the handling of rotated objects.

In my post about Muse 4 code improvements, I described an improvement in how Muse deals with rotated objects in Phone and Tablet layouts in which the CSS3 transform property is used to rotate objects in the browser instead of rasterizing the objects. There are multiple advantages to this approach including higher quality rendering, less data to download to the local browser and therefore faster performance, and text remains selectable and searchable. Muse CC 5.0 extends this approach to desktop layouts. That is, rotation by itself is no longer a cause for rasterization in any Muse layout and all you need to do to get this improvement is republish your Muse site from Muse CC 5.0.

So what was the hangup and why were we able to release the improvement for phone and tablet layouts in Muse 4? CSS3 properties like ‘transform’ are supported by modern browsers, including those on phones and tablets. However, older browsers, which primarily includes Internet Explorer 8 and older, do not support CSS3 properties and therefore require custom JavaScript code to implement the missing browser feature. For rotation, this JavaScript code had to be tailored to work on both IE 7 an IE 8 because there are significant behavioral differences in the two IE versions. If we could have ignored IE 7, we would have been able to release the CSS3 rotation improvement in Muse 4 without restrictions. However, because we promise to preserve Muse layouts across supported browsers, including IE 7, we decided to delay the improvement for desktop layouts until Muse CC 5.0. This delay gave us time to improve the JavaScript implementation for rotation to support both IE 7 and IE 8. This example leads to several questions including who uses IE 7, what about graceful degradation, and why not give users the choice of whether to use a feature that can only be viewed from modern browsers?

Who Uses Internet Explorer 7?

Chances are, not you.

In 2012, Microsoft began automatically upgrading the browser installed on Windows XP, Vista and Windows 7 via Microsoft Update. For Windows XP users, this update results in IE 7 being replaced with IE 8. If you are using Internet Explorer 7 and not doing so for testing purposes, then you are running an old version of Windows and chances are either do not have access to the internet, perhaps because you are behind a firewall that prevents access, or you have disabled Microsoft Update.


Those who monitor browser usage are reporting a steady decline of Internet Explorer 7 usage. According to, global usage of Internet Explorer 7 dropped from almost 3% in March, 2012 to 0.54% during May 2013. Internet Explorer 6 usage in May, 2013 was 0.24%.

StatCounter Browser Version, May 2013

Global usage of Internet Explorer 7 is down to 0.54% in May, 2013…and dropping.

Also, according to analytics from our CDN data, fewer than 3% of visitors to Muse sites in May 2013 were from people using Internet Explorer 7 and that number is dropping.

What about Graceful Degradation?

Graceful degradation is a fault tolerance strategy for situations where a browser does not fully implement a feature. Instead of taking the approach that a browser is either fully supported or not at all, the idea is to employ a strategy that more broadly defines browser support and introduces the notion of levels of support.  There is a very good description of Graded Browser Support at that I encourage you to read. For the most part, Muse has employed a strategy of attempting to make a page look the same in all browsers. Typically, that means either rasterizing in cases where there isn’t support for an HTML feature or writing a JavaScript polyfill to add support in older browsers. However, there are already examples of graceful degradation in Muse. For example, Internet Explorer 7 and 8 render drop shadows as solid and opaque where as shadows in modern browsers can have transparency and are knocked out by the object casting the shadow. In order to prevent the Internet Explorer 7 & 8 shadow from bleeding through the object, we disable shadows in Internet Explorer 7 & 8 if the object casting the shadow has a transparent fill while preserving the shadow in modern browsers.

IE7 default rendering of shadow on item with transparent fill.

IE7 default rendering of shadow on item with transparent fill.

IE 7 with shadow disabled as a graceful degradation.

IE 7 with shadow disabled as a graceful degradation.

Modern browser rendering of shadow on transparent filled item.

Modern browser rendering of shadow on transparent filled item.


Considering that Internet Explorer 7 is becoming so little used, diverting development resources to preserving the layout in that browser doesn’t make a lot of sense. That said, there are still a significant number of people using Internet Explorer 8 and we are committed to fully supporting that browser by continuing to write JavaScript polyfills when appropriate. Using graceful degradation as a strategy for Internet Explorer 7 gives us more freedom to use HTML5 constructs. This rotation example begs the question, why not include a set of features that are only available for modern browsers so that users can decide when to gracefully degrade the rendering in older browsers in favor of a better experience in modern browsers?

Modern Browser Only Features

HTML5 includes a number of features that older browsers do not support and some features that only some modern browsers support. Moreover, there can be and often are significant differences between modern browsers in how they render or support various features. For example, HTML5 supports a border-image property where an image can be rendered as a border pattern. However, there is a wide variety of support for this feature in different browsers as you can see from the following screen shots.


Chrome rendering of the CSS3 border-image property.

Chrome rendering of the CSS3 border-image property. Notice the clipped portions at the corners.


Firefox rendering of the CSS3 border-image property.

Firefox rendering of the CSS3 border-image property. Non-uniform scaling is used to prevent clipping.

Internet Explorer 9

Internet Explorer 9 does not support border-image.

Internet Explorer 9 does not support border-image.

Would you be in favor of Muse CC adding a set of features that can only be rendered by modern browsers as long as it was made clear that they will not work in older browsers or will be gracefully degraded in older browsers? What if the rendering of a feature differed significantly between modern browsers? Note that taking this approach in Muse 4 with CSS rotation wouldn’t have helped get the feature into Muse 4 because we didn’t have enough time and resources to add the proper user interface for such a feature.

Back To Internet Explorer 7

The Muse CC team will be reducing its investment in supporting Internet Explorer 7 by taking a more graded approach that uses a strategy of graceful degradation. Muse CC sites will not drop content when viewed in Internet Explorer 7. However, the Muse CC team will no longer be writing custom JavaScript specific to IE 7 to enable a visual effect. For customers, that decision might be considered good news as it frees up resources to develop other features or solutions. This decision also gives us the opportunity to revisit some of our code and improve the use of HTML5 constructs. That said, it is always our policy to gracefully degrade whenever possible so you shouldn’t worry about whether visitors to your site can access the content of your site. With only 1 in 200 people surfing the web using Internet Explorer 7 and decreasing, you might ask what took us so long? We take browser support very seriously so you don’t have to. As always, you design, we code.

9:10 PM Permalink
May 6, 2013

Muse Update Announced!

The next update for Adobe Muse has been announced, and includes a number of exciting top-requested features and enhancements.

New In-browser editing allows you to let site owners make simple edits to their live sites via a web browser, for sites hosted on Business Catalyst.

You can now create incredible motion effects with just a few mouse clicks—make images and elements move in different directions at different speeds with the scroll of a mouse, using new Parallax scrolling.

Contact forms will now work on sites that are hosted with the provider of your choice.

We’ve added a new Layers panel, similar to the functionality found in InDesign.

And much more… Coming soon, watch for the update in June.

Learn more

11:01 AM Permalink
March 5, 2013

Code Improvements in Muse 4

On February 26th 2013, Adobe launched version 4 of Adobe Muse which includes several improvements to the HTML/CSS that Muse generates for websites. These improvements continue the trend of improving Muse output with each release that I described in Code Improvements in Muse 1.0 and 2.0 and Have you looked at Muse lately. This post describes some Muse 4.0 improvements that improve rendering and performance in Internet Explorer and mobile browsers.

Internet Explorer Improvements

Internet Explorer is the problem child of desktop browsers, especially versions 8 and earlier. Most modern desktop and mobile browsers natively support the ‘border-radius’ CSS property to specify rounded corners, the use of ‘rgba’ to specify a transparent color as a background fill, drop shadow or gradient stop, and support the ‘opacity’ CSS property for specifying the opacity of an entire element and all of its children.

There are multiple strategies that can be employed for dealing with object opacity, transparent background fills, transparent shadows, rounded corners and other properties that IE does not support. An ‘-ms-filter’ can be used for object opacity and transparent gradients. A JavaScript libary, such as CSS PIE, can be used for a teransparent background color and for rounded corners. Generating a solid shadow color that closely matches the transparent color by tinting the shadow color by the alpha value and matting against a color that is behind the shadow can sometimes be effective. However, mixing these strategies can yield very undesirable results as libraries like PIE do not blend well with ms-filters. Let’s look at how Muse 4 deals with some of these issues.

Transparent Background Color (‘rgba’)

rgba solid fill with rounded cornersThe following CSS describes 3 different backgrounds for a rectangle with rounded corners. All browsers should recognize the first ‘background-color’ property as it simply specifies a 100% opaque ‘rgb’ value expressed as a hexadecimal value. The second ‘background-color’ property is recognized by most modern browsers, which will use this property instead of the first because it appears later. The third property, expressed as a ‘-pie-background’, is recognized by the CSS PIE JavaScript library which will use it to render an ‘rgba’ color in IE 7 and 8 but will ignore it for IE 9 and newer.


    background-color: #7F7FFF;
    background-color: rgba(0, 0, 255, 0.5);
    border-radius: 10px;
    -pie-background: rgba(0, 0, 255, 0.5);

It is worth pointing out that the first background color is carefully chosen to be a 100% opaque version of the transparent color that closely resembles the ‘rgba’ color if it were on a white background. Muse tints the ‘rgb’ portion of the color by the alpha value and mattes the color with a white background. Early versions of Muse would have simply dropped the alpha value and used the ‘rgb’ portion unchanged. Unfortunately, if the desired opacity is quite small such as 5 or 10%, you would instead get a very vivid 100% version of the color.

The difference between a 50% tinted blue matted against white compared to 100% blue.

A 50% tinted blue matted against white compared to 100% blue. Muse 4 outputs the 50% tinted blue as a fallback for browsers that do not support ‘rgba’ nor PIE.


Transparent Gradient

Simple rectangle with transparent gradient fill.There are at least three approaches to representing this gradient fill in our CSS. Muse chooses the optimal approach depending how other effects, such as rounded corners, will be represented.


Approach 1: Image Slicing As A Fallback

The first approach, which early versions of Muse adopted, takes advantage of the fact that every horizontal slice of the gradient is identical and simply creates a 1 pixel tall image and sets it as the background and repeats it vertically. This approach works well except for cases where the width of the rectangle might change and except for the fact the image must first be downloaded to the client machine before it can be rendered in the browser.

    background: url("../images/u84-grad.png") repeat-y left top;
    background: linear-gradient(to right,rgba(255, 255, 0, 0.5) ,rgba(0, 0, 255, 0.5) 100%);

Approach 2: Use PIE for IE 7 and 8

The second approach is to use a JavaScript library, such as CSS PIE, to render the gradient in IE and native support for a ‘linear-gradient’ set as a ‘background’ CSS property for all other browsers. This approach works well for opaque gradients and for all browsers except IE 8 and earlier because PIE does not support transparent color stops.

    background: linear-gradient(to right,rgba(255, 255, 0, 0.5) ,rgba(0, 0, 255, 0.5) 100%);
    -pie-background: linear-gradient(left,rgba(255, 255, 0, 0.5) ,rgba(0, 0, 255, 0.5) 100%);

Approach 3: Use -ms-filter For IE 7 and 8

The third approach is to use a ‘linear-gradient’ set as a ‘background’ CSS property for all browsers that support it and use -ms-filter for IE 8 and earlier. This approach works well as long as PIE is not used to render some other IE deficiency such as rounded corners. This approach is the most preferable because it avoids having to load the PIE JavaScript and there is no delay while PIE renders the fill.

    background: linear-gradient(to right,rgba(255, 255, 0, 0.5) ,rgba(0, 0, 255, 0.5) 100%);
    -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr='#7FFFFF00', endColorstr='#7F0000FF', GradientType=1)";

Muse 4 prefers the third approach but will fall back to using one of the other approaches if JavaScript is needed to render another effect and that JavaScript conflicts with the -ms-filter.

Browser Rotation Via CSS 2D Transforms

CSS 3 introduced two dimensional transform properties that allow you to simply specify a rotation amount, for example, and let the browser rotate the object for you. Rotation in older browsers like IE 8 is typically accomplished by creating an image of the rotated object. The advantages of using 2D transforms are numerous including avoiding the costly expense of downloading an image of the rotated object, preserving the high quality rendering of vectors such as text and borders, and maintaining the ability to select text that has been rotated. In general, the rendering and performance is substantially better. IE 7 and 8 support rotation via an -ms-filter. Unfortunately, they do not rotate about the center point like modern browsers do forcing the adjustment of the objects margins. Doubly unfortunate, the effect of adjusting the margins causes different behaviors between IE 7 and IE 8. These problems are solvable using a polyfill and we’ve laid a lot of the groundwork to support rotation in IE 7 and 8. For Muse 4, you can take advantage of CSS 2D transforms in phone and tablet layouts and we expect to support 2D transforms in desktop layouts in the near future.

Rotated text using CSS.

Above is an example of a rectangle that has been rotated using CSS. Try zooming in or selecting the text.

Above is an example of a rotated rectangle that has been rasterized. Try zooming in to see the pixelation compared to the CSS rotated version and note you cannot select the text.

Muse 4 includes several other improvements and we are actively working on improvements for future releases.


5:50 PM Permalink
February 11, 2013

Create Super Widgets in Muse – The Mobile Flyout Menu

“Where is the flyout menu shown in Dani’s tutorial?” you might ask. Well it’s actually just a Composition Widget in disguise… Jump in and we’ll explore how to make this widget fly out from the edge of the screen.

Just like in the previous posts, I’ve provided a sample file at the end of the article to get you started.

The Flyout Menu

Here is a demo of the end result. When the user taps the trigger button, the menu flyes out from the right edge of the phone screen.

Pluralist Flyout Menu

The Recipe

This super widget is essentially a Blank Composition Widget with two items. The first item is invisible, while the second item holds our menu. Here is a diagram of the design:

Flyout Menu Diagram

  1. If you haven’t already done so, create a Phone version of your site in Plan mode.
  2. Now open up the Phone Home page.
  3. Drag and drop the Blank Composition Widget onto the top of the page.
  4. Remove the third item from the widget.
  5. Now place the Triggers at the top of the page, above the containers.
    Composition Widget
  6. Add the Menu widget to the second composition item and style it to taste. By placing it on the second item, it will allow us to achieve the effect of sliding from the right.
  7. Add an arrow icon on the trigger to indicate a sliding menu.
  8. Now click the first trigger.
  9. Set Fill opacity on that trigger and its container to 1.
    Fill Opacity
  10. We’re almost there, the next step is to set the widget settings to match this screenshot:

The Result

Below is a screenshot of the Muse example in the sample file.

Muse Flyout

One Important Note

We now have a pretty powerful widget. However there is one caveat to this design that you need to be aware of: In the instructions, we made the first item in the composition have a Fill opacity of 1. By doing this, we don’t actually make the container disappear from the screen, it’s just not visible. What this means is that the container is still there, and if you have anything clickable under the composition widget, it wont register the click.

The reason this pattern works in Dani’s design is because there are no clickable items under the menu. So make sure that you accomodate your design to not have clickable parts directly under the composition widget. If you do want clickable items under the menu, I sugest using the Expanding Mobile Menu that I presented in the previous post.

Stay Tuned for More

I hope you find this Super Widget to be useful. It’s a nice design pattern if used in the correct context. Stay tuned for more posts and more examples of super widgets.

Download the Sample File

You can download the sample file here.

11:16 AM Permalink
December 11, 2012

Create Super Widgets in Muse – The Expanding Mobile Menu

This week we’re excited to announce the release of Muse 3.0 which gives you the ability to create mobile and tablet websites. Designing the navigation for these types of websites is often challenging—as you need to strike the right balance between exposing the site’s information architecture without taking up too much space. A common solution to this problem is a toggle menu that can expand and collapse when touched. I’ll demonstrate how to create this widget in the latest version of Muse, and provide you with a sample file at the end of the post so that you can get started right away.

The Expanding Mobile Menu

Let’s start by looking at real world examples of this super widget.


Here is the pattern



Vritti is a real Muse site using
this design approach.

The Recipe

The widgets in the latest version of Muse are automatically touch and swipe aware. You can simply design them like you did in the previous version of the product. With that in mind, the steps required to create this widget are actually pretty straight forward.

  1. Open up the Phone Master Page. To navigate to the Phone Master, simply click the Phone button in Plan mode.
  2. Place an Accordion on the page, and set its options to “Can Close All” and “Close All Initially”.
  3. Remove all of the default items except for the first one.
  4. Place a Vertical Menu inside of the Accordion container and style to taste.
  5. Next, move the Header guide down to the bottom edge of the widget.
  6. Finally place all of your page contents on the Normal (non Master) pages.

The Result

Below is a screenshot of the Muse example in the sample file. Visit the URL on your phone to interact with this super widget:

More is Coming

One of our main goals for this release was to allow you to make mobile and tablet sites in the easiest possible way. A lot of hard work went into making the learning curve small so that you could feel right at home with the new version of the product. We hope that you enjoy the new functionality and that it adds value to your business. Stay tuned for more examples of mobile, tablet and desktop widgets in the coming weeks!

You can download the sample file for this widget here.

10:59 PM Permalink
November 26, 2012

Create Super Widgets in Muse [Part 1]

With a few small steps you can take the existing set of Muse widgets and turn them into powerful new elements–which can show and hide content on demand. In this first post I’ll show you how to create a Sliding Dropdown Mega Menu, and present examples of the widget in the real world. I’ll also provide a sample file at the end of the post to get you started.

The Sliding Dropdown Mega Menu

You can see an example of the Sliding Dropdown Menu on Odopod’s website. This widget can be very useful when you want to mix navigation with featured content, or if you simply want more control in the way a menu behaves.

Another example is on Google’s main page:

The Recipe

The steps required to create this widget in Muse are very simple:

  1. Place an Accordion on the page.
  2. Set it’s options to “Can Close All” and “Close All Initially”.
  3. Remove all of the default items except for the first one.
  4. Place a Vertical Menu inside of the Accordion container.
  5. Add any other content that you’d like into the container.
  6. Style to taste.

Here is a diagram explaining the structure of this super widget:

The Result

Below is a real Muse example. Click here to see it live.

Stay Tuned

When we first created the Muse widget architecture, the vision was to provide a foundation for our users to mix and combine pieces to create the desired elements that they needed. The goal of this series will be to present you with examples in creating these super widgets. Stay tuned for more recipes and examples in the coming weeks.

You can download the sample file for this widget here.

3:07 PM Permalink
October 29, 2012

Code Improvements in Muse 1.0 and 2.0

In my previous post, I made the claim that the code generated by Muse is improving with each release and that users can benefit from these improvements by simply re-publishing their sites. How frequently are new versions of Muse being released? Let’s look at the record.

Adobe Muse Releases
Beta 3 Beta 4 Beta 5 Beta 6 Beta 7 Muse 1.0 Muse 2.0 Muse 3.0
09/2011 11/2011 12/2011 02/2012 03/2012 05/2012 08/2012 ?

To help describe some of the improvements that went into Adobe Muse 1.0 and 2.0, let’s look at some benchmark results from a site that was first published using one of the pre-1.0 releases in the Spring of 2012.

Ben’s Site, A Case Study For Code Improvements

The following charts are for a particular site from a customer we’ll call Ben. I first investigated Ben’s site in the Spring of 2012 using a pre-1.0 Public Beta build of Adobe Muse. The pre-1.0 Beta 6 build took nearly an hour to export the entire site and generated over 4000 images. As you can see from the following charts, subsequent releases of Muse have been significantly better in terms of both code size and the number of images exported.


Figure 1: Ben’s site exported from various builds of Adobe Muse


Figure 2: Total number of rasterized elements and placed images exported from Ben's site using various builds of Adobe Muse.
Figure 2: Total number of rasterized elements and placed images exported from Ben’s site using various builds of Adobe Muse.


How did we do it?

In order to identify and address opportunities for improvements, we started by collecting customer documents. Designers create a wide variety of sites so it was important that we used real world sites to identify problems as opposed to sites created in-house to test particular features in the product. Next, we built automated benchmarking systems that would iterate over the customer documents and perform a battery of tests while collecting and recording numerous metrics such as those included in the charts above. These automated systems help us to track improvements over time and make sure that we do not introduce new problems. We then ran profiling tools, read and analyzed code, identified the cause of particular behaviors and worked very hard at making changes to improve the quality and performance of the sites generated by Muse.

Gradients, Shadows and Glows, Oh My!

Not every site is going to see the same degree of improvements that Ben’s site has. However, the improvements we made that had the biggest impact on Ben’s site should benefit most sites and if they don’t some combination of the other improvements we’ve made will. In the case of Ben’s site, a number of issues quickly bubbled to the surface. The site had 133 pages filled with numerous accordion widgets, navigation menus and buttons that made heavy use of gradients, shadows and other effects.  These effects caused early builds of Muse to rasterize the object and export it as an image. Moreover, if the object was copied and pasted onto other pages, these early builds would generate a separate image for each copy. Hence, the roughly 4000 images.

We made a number of significant changes to address this particular problem of gradients, shadows and outer glows causing large numbers of images to be generated. In Muse 1.0, we addressed the sharing problem. If, for example, the same object appears in multiple places in the site and the object has to be rasterized, then we would rasterize once and reference that image from each of the duplicate elements. In Muse 2.0, we started using native CSS to render gradient fills, drop shadows and outer glows in order to eliminate the rasterization altogether and were able to make this change because most browsers have strong support for those particular CSS properties.

What else changed?

These two changes (i.e. avoiding duplicate exports and using CSS to render gradients, drop shadows and outer glows) were significant, but they weren’t the only changes. Here is a non-exhaustive list of other significant changes.

Code Generation Improvements in Muse 2.0

The following improvements in Muse 2.0 result in faster browser load times because we take advantage of the HTML 5 capabilities of the browsers, generate far fewer images to represent frames with visual effects and therefore have far less data to download, the images are more highly optimized and better named, and the JavaScript that is exported from Muse to support runtime behaviors is smaller and more highly optimized.

1. CSS 3 Linear Gradients for Background Fills

Muse 1.0 represented gradient fills as repeating background images. For sites that made heavy use of gradient fills, this approach could generate a large number of small images. A much more efficient approach that is support in all of the browsers for which Muse optimizes its output is to use the CSS gradient background property. The syntax is different for several of the browsers. For example, to create a horizontal gradient that fades from red to black, the CSS would look something like the following:

	width: 960px;
	min-height: 500px;
	background: -webkit-gradient(linear, left center, right center, from(#ED1C24),to(#0071BC));
	background: -webkit-linear-gradient(left,#ED1C24 ,#0071BC );
	background: -moz-linear-gradient(left,#ED1C24 ,#0071BC );
	background: -ms-linear-gradient(left,#ED1C24 ,#0071BC );
	background: -o-linear-gradient(left,#ED1C24 ,#0071BC );
	background: linear-gradient(to right,#ED1C24 ,#0071BC );
	-pie-background: linear-gradient(left,#ED1C24 ,#0071BC );
	behavior: url(scripts/1.1/;
	border-width: 1px;
	border-style: solid;
	border-color: #000000;
	margin-left: auto;
	margin-right: auto;

Horizontal Gradient fill for a page in Muse 2.0

2. Shadows and Outer Glows via CSS 3 box-shadow

Muse 2.0 generated websites use the CSS box-shadow property to represent drop shadows and outer glows. This improvement reduces the number of files generated by Muse, simplifies the HTML because we no longer have to create a separate <div> for each slice of the background image that Muse 1.0 would generate to represent the frame and its shadow, faster upload times and faster load times in the browser. Moreover, it also resolved problems where the shadow and outer glow affected the dimensions of the element such that clicking in the shadow were treated as clicks on the element.

3. Dynamic Image Resizing via CSS 3 background-size

Muse 2.0 makes use of the ‘cover’ and ‘contain’ settings for the CSS 3 background-size property such that modern browsers can automatically resize image fills as the element resizes. As a result, you can now have an image fill on a page or in the Browser Fill area and set it to automatically resize itself as the page or browser window resizes.

4. Better naming of Muse Generated Images

There are several scenarios under which Muse will rasterize a page item and export it as a PNG or JPEG. Sometimes, these scenarios involve page items that are not also an image such as a rotated frame or a text frame that uses a system font. For these generated images, we need to generate a unique name. However, sometimes we have to rasterize an image if it is being significantly cropped. When the rasterization involves an image, we attempt to choose a unique name that is prefixed with the name of the original image file that was placed into Muse. This improvement makes it easier to find the associated JPG or PNG on disk and potentially replace it with something else at a later date without re-exporting from Muse.

5. Cropping at Browser Runtime instead of at Export Time

If an image was being cropped by its frame in Muse, then at Export time, Muse would crop that image instead of passing it through and wrapping it in a separate div to crop it at browser runtime. For some images, this approach resulted in significantly smaller image sizes and therefore faster upload times and faster page load times in the browser. However, it also prevented us from sharing the image if there was a separate instance of the same image in the site. Muse 2.0 is more careful about when it chooses to crop images at export time and will instead chose to pass the original image through if a small portion of the image is being cropped or there are multiple instances of the image in the site.

6. JavaScript Improvements

Adobe Muse 2.0 contains a new JavaScript library used by our native widgets, such as slide shows, to implement various runtime behaviors. This updated library is smaller than the Muse 1.0 library, is based on jQuery instead of Spry, and has numerous features we plan to expose in future releases.

7. Reduced use of State-Based Groups

What is a state-based group? To answer that question, we need to talk about the three ways that state-less elements can be represented in HTML.

  • Simple element with CSS styling. This approach is used if there are CSS 2 properties that can be used to render the element to look the same way it does in Muse at design time. For example, a rectangle with a solid fill and 1 pixel wide black border.
  • A raster image (i.e. an <img> element). This approach is used for things like rotated page items (Internet Explorer 7/8 do not support 2D CSS transforms), images with a bevel or inner glow effect applied, some cropped images and text frames that use a system font.
  • A 3-sliced or 9-sliced frame with background images. This approach is used if the frame can be represented separately from its contents, or it has no contents, and the frame must be rasterized because it has an effect that cannot be represented in CSS. By slicing the frame into separate divs, it allows the frame to grow if its contents grows.

Now, imagine that you have an object with two or more states and each state has properties that require a different approach to rendering. For example, a solid filled rectangle in the normal state that has a bevel effect in the rollover state. In Muse 1.0, this scenario resulted in each state being represented by a separate HTML structure where the visibility of the structure was controlled via CSS based on the current state. This approach yielded very complex HTML and duplication of content and caused various hit detection bugs because structures would change their visibility property during a click event.

In Muse 2.0, we’ve reduced the number of cases that will result in a state-based group to those that require one of the states to be completely rasterized. Any combination of the other two approaches to rendering will generate a single HTML structure whose styling is controlled via CSS. This improvement yields much cleaner HTML output that avoids many of the bugs we were seeing related to click events.

As an example, let’s look at the Muse 1.0 generated HTML for a filled rectangle with a bevel effect applied to both the Normal and Rollover states. You can assume that some other property, such as the fill color, changes between the states.

   <div id="pu67-4"><!-- state-based group -->
      <!-- Normal State -->
      <div id="u67-4">
         <div class="f3s_top"></div> <!--contents removed for clarity-->
         <div class="f3s_mid">
            <div id="u67-4position_content">
               <p>Lorem Ipsum Dolor</p>
         <div class="f3s_bot"></div> <!--contents removed for clarity-->
      <!-- Rollover State -->
      <div id="u67-8">
         <div class="f3s_top"></div> <!--contents removed for clarity-->
         <div class="f3s_mid">
            <div id="u67-8position_content">
               <p>Lorem Ipsum Dolor</p>
       <div class="f3s_bot"></div>   <!--contents removed for clarity-->

Muse 1.0 HTML for a rectangle with a bevel effect in its Normal and Rollover/hover states?

Note that in the above example, two separate HTML structures are created: one for the Normal state and one for the Rollover state. Each structure contains a div for each of the top, middle and bottom slices where the CSS for these divs will have a background-image property set to a sprite image containing a rasterization of the corresponding slices of the frame.

Now let’s look at the same object output from Muse 2.0. In this output, there is one HTML structure for both states. The CSS is responsible for changing the styling of the two states such as using a different background-image for each of the three slices via the :hover selector.

    <div id="u67-4"><!-- group -->
       <div class="f3s_top"></div>   <!--contents removed for clarity-->
       <div class="f3s_mid">
          <p>Lorem Ipsum Dolor</p>
       <div class="f3s_bot"></div>   <!--contents removed for clarity-->

Muse 2.0 Output for the same object.

This approach yields simplified HTML that is more readable and easier to modify and less prone to errors with click events.

Code Generation Improvements in Muse 1.0

Here’s a list of some of the improvements in Adobe Muse 1.0 compared to the Public Betas.

1. Keep the same unique id for each div instead of a running id.

Before, HTML running ids were generated for all divs, for example, n1, n2, and so on. Whenever a div is added or removed, all ids of divs that came after would be changed. To address this, each object in Muse is exported with a unique id in HTML, from one export to the next. This improvement reduces the likelihood that a small change to one page will result in updates to more HTML and CSS files than you would expect.

2. Avoiding browser cache problems

We revised how Muse generates references to CSS, JavaScript and Favicon files in the generated HTML. Browsers should no longer use obsolete cached versions of these files after you update your site, so returning website visitors will see the new properly formatted pages.

3. Use the target attribute on <a> tag

The <a> tag’s target attribute was considered deprecated in a previous version of HTML, but is no longer deprecated in HTML5. Therefore we replaced the use of special classes for different targets with the target attribute instead.

4. Shared CSS

Muse now outputs the CSS for each master page just once and shares CSS across pages with the same master page applied. This reduces the amount of CSS generated for individual pages and improves web page load times by allowing browsers to cache the master CSS sheet.

5. Shared rasterized images

Images are exported from Muse for one of the following reasons:

  1. They were imported into Muse as either a background fill or a placed object.
  2. They were rasterized by Muse because the appearance during Design time in Muse cannot be represented in one or more of the browsers that Muse supports. For example, a text frame that uses a system font or any page item that has a bevel effect applied.
  3. A container needs to be rasterized separately from its contents so that it can be sliced and repeated as background images. For example, a text frame with a bevel effect will be sliced into three images, the top edge, a middle slice that gets repeated vertically, and the bottom edge. The text is not part of these slices (assuming that it is a web-safe font). Instead, it is a child of the middle slice so that it can be live. Note that the three background images get combined into what is referred to as a sprite.
  4. Gradient Fills in Muse 1.0 are represented using either a 1 pixel tall image repeated vertically or 1 pixel wide image repeated horizontally.

When possible, Muse 1.0 will share images instead of producing one image for each rasterization. This optimization reduces the number of image files generated which results in faster export times, faster upload times, and faster page load times.

6. Removed redundant CSS

Previously, duplicate CSS rules were generated for each paragraph. The common paragraph properties are now moved up to the CSS rule of a text frame div. This decreases the size of CSS files.

Export Performance Improvements in Muse 1.0

1. Incremental Export

In the public betas, during Export or Publish Muse would generate all the data for the site, but only write files to disk or upload files if the data for the files had changed since the previous Export or Publish operation. This approach minimized the time spent in the upload portion of Publish and only changed last modified dates during Export for the files that really changed, but it still required all the data for all the pages to be regenerated every time.

Muse now tracks what pages have been changed internally and only generates the data associated with a page during Preview, Export or Publish if the page has changed since it was last Previewed, Exported or Published. This makes re-Publishing, re-Exporting or re-Previewing after a small change much quicker for most sites.

SEO Improvements in Muse 1.0

Improved SEO and Accessibility

Allow setting a title attribute on links or images – user can now set a title attribute on a link, <a> tag, via Hyperlink popup panel, or an image, <img> tag, via context menu in Assets panel. This is to provide advisory information, where most browsers display it as a tool tip.

5:07 PM Permalink
September 27, 2012

Have you looked at Muse output lately?

There is a lot of misinformation going around about Adobe Muse. Much of this misinformation is rooted in evaluations of early Public Beta versions of the software which were released many months before the initial release of Adobe Muse 1.0. Adobe released Adobe Muse 2.0 in August, 2012 and the code is quite different from those early pre-1.0 Public Betas.

You Design, We Code

The promise of Adobe Muse is that it allows Designers to design without worrying about the code. Adobe keeps this promise with frequent releases of Adobe Muse with new features for Designers and significant code improvements.

Muse is a tool that targets traditional Designers so that they do not have to know about code. Therefore, we put a lot of emphasis on creating features that are familiar to Designers such as master pages, paragraph and object styles, ruler guides and other graphic design paradigms. However, as engineers and developers ourselves, we care a great deal about the quality of code that Muse generates. From the very beginning, our mantra has been “Please the Designer, Honor the Developer.” To that end, we continue to make significant improvements to the code that Muse generates. All you need to do to obtain those improvements is to re-publish your site with the latest version of Muse.

How do we evaluate code improvements?

We are committed to improving the HTML/CSS/JavaScript code that Muse generates and we evaluate it based on the following criteria:

  1. Cross-browser compatibility
  2. Load performance of the site
  3. Accessibility and Usability

We also work to ensure all of our code follows good SEO practices and guidelines whenever possible.

Frequent Releases

Adobe Muse is offered via subscription, which allows Adobe to release updates as soon as they are ready. Adobe Muse 2.0 was released in August, 2012, three months after the initial Adobe Muse 1.0 release and it is packed with a number of new features for Designers as well as significant code generation improvements. Latest Features

Some Benchmark Metrics

We frequently put Muse through a series of automated tests to not only find bugs and improve stability, but also to analyze the output. Let’s look at some of the metrics collected for Adobe Muse after publishing a collection of sites using the various public releases of Adobe Muse.

One measure of output is the total size of the site including images, HTML files, CSS files, Javascript files and all other assets. There are limits on how small a site can be made without sacrificing rendering quality, but the reasoning goes that the smaller the total data, the less time it takes to load in your browser. Similarly, the fewer the number of files, the fewer the number of http requests to load the contents of those files.

Benchmark metrics across Adobe Muse releases
Metric Beta 5 Beta 6 Beta 7 Muse 1.0 Muse 2.0 Avg. Improvement
Total Output Size 7643K 7764K 7947K 6915K 5966K 22% smaller
Total HTML Size 1498K 1549K 1527K 1428K 922K 38% smaller
Total Image Size 4239K 4231K 4224K 4208K 3781K 11% smaller
Total JavaScript Size 222K 224K 226K 226K 193K 13% smaller
Total Number of Images 547 541 433 187 109 80% fewer
Total Number of JavaScript Files 10 10 10 10 8 20% fewer

Note: Averages are from a collection of customer sites published from the listed releases. Results vary based on the design of the site.

This table of metrics shows that there is a concerted and continual effort to improve load times by decreasing the overall size of the site as well as the total number of files generated.

Specific Code Improvements

What specific changes led to these size improvements? That will be the subject of my next post.

11:33 PM Permalink
September 25, 2011

Code Improvements in Muse Beta 3

Today we released the Beta 3 update of Muse. Muse enables graphic designers to create professional HTML websites without writing code. Muse has generated an enthusiastic response from the design community with over 260,000 designers downloading it in the first 40 days. We’ve very excited at the number of people who have been participating in our support community, logging bugs, asking questions and giving feedback.

When we announced this technology last month, people in the web community voiced strong concerns about the quality of the code generated by Muse. The Muse team has taken that feedback to heart.  To that end we are very aware the HTML/CSS/JavaScript code generated in the first beta of Muse had lots of room for improvement.

The Beta 3 update includes improvements in two key areas:

  1. Fixes to over 40 bugs discovered by the Muse user community. For a full list of bugs fixed visit
  2. Some initial improvements in the code Muse generates which help reduce page load times and data usage of websites created with Muse.

These improvements to code are a first step in an ongoing process that will continue through the beta and subsequent releases of Muse. Existing Muse sites can be improved by downloading Beta 3 from and simply re-exporting the site.

The rest of this post will focus on the details of the code improvements in Beta 3.

How do we evaluate improvements to code?

We are committed to improving the HTML/CSS/JavaScript code Muse generates and evaluate it using several criteria including—

  1. Cross-browser compatibility
  2. Load performance of the site
  3. Search Ranking via SEO
  4. Accessibility and Usability

The primary focus of code improvements in Beta 3 are around cross-browser compatibility and reducing page load times and data usage.

Note: All results are based on tests conducted by the Muse engineering team by comparing Beta 2 vs Beta 3. Tests were conducted using three websites:, and

HTML Improvements

1. Removed duplicate HTML in IE conditional comments

Certain designs created with previous beta versions of Muse had duplicate markup in Internet Explorer (IE) conditional-comments. This was clearly an inefficient way of achieving cross-browser compatibility in IE. Designs that use rounded corners, transparency on fills (rgba) and transparent png triggered this behavior resulting in duplicated markup, CSS, text content and in some cases even images.

For Beta 3 we’ve removed the duplicate IE markup and standardized on single markup for modern browsers, relying on HTML5 cross-browser poly-fills for legacy browsers.

Beta 2 Output

HTML snippet from Beta 2 – markup for modern browsers

HTML snippet from Beta 2 – markup for modern browsers

HTML snippet from Beta 2 – duplicate markup for IE8 and below

HTML snippet from Beta 2 – duplicate markup for IE8 and below

HTML snippet from Beta 2 – additional CSS file for Internet Explorer

HTML snippet from Beta 2 – additional CSS file for Internet Explorer

Beta 3 Output

HTML snippet from Beta 3 – single markup for all browsers; IE handled via poly-fill

HTML snippet from Beta 3 – single markup for all browsers; IE handled via poly-fill

HTML snippet from Beta 3 – eliminated CSS for Internet Explorer

HTML snippet from Beta 3 – eliminated CSS for Internet Explorer

What was the impact of this change?

Total size in Kb of HTML and CSS files
Site Beta 2 Beta 3 % Difference 2807 2296 -18% 493 220 -55% 554 220 -60%

From Beta 2 to Beta 3 the savings in files size are 18%—60% depending on the design.

Total number of CSS and image files
Site Beta 2 Beta 3 % Difference 242 242 -0% 124 84 -32% 396 198 -46%

From Beta 2 to Beta 3, the number of CSS and image files are reduced 0%—46% depending on the design.

2. Removed empty divs for clearing floats

Muse uses HTML floats for representing complex layouts, groups and widgets.  The older implementation used an empty div to clear floats so its parent container would stretch to contain the floats.  This clearly resulted in numerous unnecessary empty divs leading to code-bloat. We’ve replaced this in Beta 3 with a more modular approach to float management using the :after pseudo-element.

HTML snippet from Beta 2 – empty “wrap” div used to clear floats

HTML snippet from Beta 2 – empty “wrap” div used to clear floats

HTML snippet from Beta 3 – modular float management using clearfix

HTML snippet from Beta 3 –modular float management using clearfix

3. Reduced extra nested divs

We took some steps to remove extra nested divs not required for layout to simplify the structure and reduce size of the HTML. There are clearly more avenues for savings in the future.

What was the impact of removing empty divs and extra nested divs?

Number of DOM elements on index.html page
Site Beta 2 Beta 3 % Difference 349 247 -29% 977 906 -7% 277 215 -22%

Between Beta 2 and Beta 3 the number of markup elements were reduced 7%—29%.

4. Using anchor tag as blocks

When hyperlinks are applied to block elements, Muse Beta 3 exports <a> tag as block, taking advantage of this feature in HTML5. This change results in better usability of hyperlinks such as allowing users to right click and copy the link address or open the link in a new tab etc.

CSS Improvements

5. Removed redundant CSS

There were many cases in Beta 2 where Muse generated redundant declarations for CSS properties such as border-radius. We’ve also removed many duplicate CSS properties generated for a:hover selector. This change reduces the size of the generated CSS.

6. Shorthand CSS properties

In Beta 3, Muse now exports shorthand CSS properties such as border-radius, border, margin, padding and background when possible, resulting in more compact CSS.

7. Shared CSS

CSS rules that are shared between pages have now been moved to a global style sheet shared across the site. This decreases the size of CSS files for individual pages and allows browsers to cache the site global sheet.

What was the impact of the changes to CSS?

Total size in Kb of CSS files
Site Beta 2 Beta 3 % Difference 1321 947 -28% 244 96 -61% 249 95 -62%

From Beta 2 to Beta 3, the total size of CSS files are reduced 28%—62% depending on the design.

JavaScript Improvements

Many of the JavaScript changes made in Beta 3 enable better progressive rendering of pages and allow for greater download parallelization in the browser, thereby improving page load time.

8. Moved JavaScript from document head to end of body

With Beta 3 we’ve moved most JavaScript not required before the DOM loads from the document head to just above the end of the document body. This includes external JavaScript files and calls. This change speeds up initial rendering of the page because browsers will no longer wait to synchronously parse JavaScript before rendering the page. See move scripts to the bottom for details.

9. Combined external JavaScript files

Many JavaScript files are now combined to reduce number of http requests and size of download. This improves page load performance. See combining external JavaScript for details.

10. Reduced inline JavaScript

Reduced unnecessary JavaScript calls when multiple widgets were used on a page. Now regardless of the number of widgets on a page, showing them is taken care of by just one call to reduce size of generated JavaScript.

11. Widgets appear sooner

Most Muse widgets will now appear before the page DOM fully loads allowing users to interact with widgets such as menus sooner.


12. Exported file names

Exported file names are now always lowercase. This avoids problems due to differences in case-sensitivity of filenames between web servers.

What Next?

We recognize there are numerous opportunities for continued improvement. Beta 3 focused on cross-browser compatibility and page load performance. We’ll continue to work on those areas, in addition to search ranking/SEO and accessibility for future releases. Stay tuned!

Muse Engineering Team

7:00 PM Permalink