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=""/>

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=""/>

 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("", "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 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—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

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