By David Stephens
On October 29, 2012

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:

#page
{
	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/pie.htc);
	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>
         </div>
         <div class="f3s_bot"></div> <!--contents removed for clarity-->
      </div>
      <!-- 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>
         </div>
       <div class="f3s_bot"></div>   <!--contents removed for clarity-->
   </div>

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>
       <div class="f3s_bot"></div>   <!--contents removed for clarity-->
    </div>

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.