For Infinite Scroll, Bounce Rate Is a Vanity Stat

Animation showing me scrolling an article at the Fortune site. The yellow arrow indicates when the URL changes. At that point leaving the site will not count as a bounce.

About a year ago I wrote a post with a checklist of items I feel you would need to satisfy before you can ever consider putting infinite scroll on a site. Surprising no one, the checklist hasn't really caught on (though it has generated a lot of traffic and discussion).

Worse, no one (that my Google-fu found) is challenging the most common argument in favor of infinite scroll: user retention, often described as a reduced bounce rate.

I've simplified it a bit, but the gist is that advertisers and marketers want to see a low bounce rate on a site (ideally one that continues to fall). This helps justify ad buys and is often used as a proxy for engagement.

Typically authors who want to write a pro/con piece on infinite scroll will cite user retention. The same is true for those whose success is measured by low bounce rates, as well as those who just really like the infinite scroll "feature."

Because content continues to appear, users find themselves scrolling and interacting for longer periods of time.

Infinite Scrolling: Pros and Cons at Design Shack

You stand a better chance of retaining the user because there’s nothing for them to do but scroll. It’s almost like a subliminal call to action.

The UX of Infinite Scroll: The Good, the Bad, and the Maybe at SitePoint

Since its March redesign, Time.com’s bounce rate — the percentage of visitors who leave the site after viewing only one page — has declined by 15 percentage points[.]

Mobile page views in June were up 30 percent over the previous 12-month average [on the redesigned NBC News site.]

Quartz estimates “readers view about 50 percent more stories per visit than they would without the option to scroll.”

Time.com’s bounce rate down 15 percentage points since adopting continuous scroll at Poynter

The numbers look great in a vacuum. As readers, we don't have access to the raw data. We can't see if the reduced bounce rate correlates with a (minimum) doubling of time on the site. We cannot see if the user gets to the new headline and just leaves the site. There is no metric for a second-step bounce rate.

I posit that the goal to affect the raw stats doesn't necessarily mean more engagement.

On these sites, when I keep scrolling to make sure I've finished the article, the URL changes. I haven't actively gone to another page. Whether or not I choose to read the next article, this is counted as retention. I don't count as a bounce simply because I scrolled, not because I have started to read (let alone finished) the next article.

A couple examples of this in action (in addition to the opening image)…

Animation showing the URL changing (when the yellow arrow appears) as I scroll down the page at the Time site.

Animation showing the URL changing as I scroll down the page at the Forbes site.

We should be wary of these engagement or retention claims. Measurements shouldn't be about solely bounce rate, and minor jumps in engagement time are also a poor proxy. Perhaps a bounce should count unless the user makes it to the end of the next article. Perhaps retention should only count if the user's time on the site equals or exceeds twice the average time it takes to read an article.

As always, unless someone who manages a content site with infinite scroll (that isn't a stream-based site like Twitter or Facebook) can show data to prove infinite scroll genuinely leads to greater retention and engagement, I won't trust the measuring stick. Neither should you when making a decision about whether or not to implement infinite scroll.

Related

• So You Think You’ve Built a Good Infinite Scroll at this site, May 31, 2014.
• Infinite Scrolling – Impact on Accessibility Series – #1 Common Issues from SSB Bart Group, May 1, 2015.
• Infinite Scrolling (mobile version of the page so you can tap the alt text) from XKCD.

Update: May 18, 2015

USA Today decided to ditch its infinite scroll, as reported by Digiday and its infinite scroll:

FTW’s implementation of infinite scroll, which displays a never-ending lists of article headlines below its articles, has been a major drag on the site’s mobile page loading times, so it had to go.

USA Today's FTW redesign ditches the infinite scroll, at Digiday

Another Update on May 18

Smashing Magazine asks the question, linking to this post:

Have you actually seen an infinite scrolling pattern working well for user engagement in your UI? A few notes: http://t.co/PiYGMfoMc0

— Smashing Magazine (@smashingmag) May 18, 2015

Announcing My Ring Warmer App

Animation showing the Ring Warmer in action.

If you have to wear a ring, then perhaps you have experienced the discomfort of putting a cold ring on your finger (maybe in the morning in a cold house). I decided that I could do something about that using the only tool in the modern developer's toolbox — the smartphone app.

I'm kicking off the new year by announcing that my Ring Warmer app is done. Well, it's a web app. Actually, it's just a web page. Living as nothing more than a block of code at CodePen. Regardless, I started this in late 2012 and then mostly forgot about it, so I'm thrilled to call it done.

The opening image is an animated GIF that shows how one might use the Ring Warmer app. I've also embedded the same animation as an Instagram video (or view it directly on Instagram):

My ring warmer app is finally ready for release.

A video posted by Adrian R (@aardrian) on Jan 1, 2015 at 9:23am PST

The idea here is that you can choose a ring size and a warmth level, place your ring in the designated spot, and wait patiently for it to work its magic.

The idea is, of course, absurd.

In the strictest sense, it can work. At the lowest setting (warm), only the red LEDs will light up, carrying one-third of the total heat a pixel can produce. As you move to the highest setting (hottest), all the LEDs are lit to generate white, so each pixel is producing its maximum heat as the red, green, and blue LEDs are all lit.

Of course, the amount of heat this carries is negligible. You will transfer more heat to the ring from the warming battery than from the pixels. The ring itself might not get very warm unless you also fire up the radio antenna (I left that feature out as a courtesy).

Now that I've gotten as much pranking out of this fake app as possible, I figured I'd at least write it up a bit.

Very simply, I use a border radius with some box shadows to make the glowing ring. Then I drop the white glowing dot (using box shadows and border radius) onto one edge and rotate the entire thing in perpetuity. It's a mess of mixed sizing units, questionable animation syntax, and useless elements.

Then I made a form so you can change the ring size and the temperature. The ring size isn't matched to any real measurements, except in Chrome on my Samsung Galaxy S4 the default size matches my ring. All sizing after that is based on ems, so it doesn't scale like a real ring. The temperature change is nothing more than colors with CSS transitions and some JavaScript that sets explicit styles instead of classes. In other words, it's a terrible idea to copy this code.

Regardless, here's the pen in action:

See the Pen Ring effects by Adrian Roselli (@aardrian) on CodePen.

This will not be available in any app store. You can load the pen in full screen view to trick your friends if you are that bored.

Accessible Bootstrap Frameworks

This post originally appeared on the Algonquin Studios blog.

If you work much with accessibility, then you might consider the title of this post to be an oxymoron, a self-contradicting mess. Frankly, I tend to agree. Barring a compelling use case, I never start a project with Bootstrap and I resist including it when explicitly requested (so far successfully in nearly every case). Of a few reasons, accessibility is the biggest issue I have with it.

There are, however, a couple options to mitigate the accessibility mess that is Bootstrap.

I should note that this post is a follow-up to the Q&A after my talk at HTML5 Developer Conference, Selfish Accessibility, where I gave some advice about Assets which, at the time, was using Bootstrap 2 (it has since moved to version 3).

Assets.CMS.gov

The Centers for Medicare & Medicaid Services (CMS), a division of the US government (specifically HHS), has emerged as an unexpected champion of accessibility for Bootstrap and made its own framework, Assets (first announced in late 2012). This may not be a surprise to many when you consider CMS's role working with people who are older and/or in need of some form of medical assistance (equipment or services). Arguably, its constituency stands to benefit the most of any division of the US government.

Assets was just updated to use Bootstrap 3 (which should make many a Bootstrap user happy). Assets promises you:

Section 508 compliant, cross-browser compatible UI components that you can use in your accessible web site or web application. Assets is an accessible, responsive, modern framework.

If you are an organization that works with the federal government to build web-based applications for the general public, then it may be a no-brainer to use this framework. Arguably your Section 508 accessibility requirements are met to a high degree, and where the framework fails you may be able to make a case that you are using a government-sanctioned tool. It doesn't let you off the hook for more fundamental accessibility failures (color contrast, images as text, infinite scroll, etc.).

The accessibility statement identifies the profiles used for testing. The documentation page links to all the UI components, which is handy. Jennifer Sutton has also provided links to tests she made with the calendar widget over at the WebAIM mailing list (though she was using version 2).

There are some caveats. On the spectrum of Internet Explorer versions, it only supports version 8 and above (the last version, built on Bootstrap 2, also only supported IE8+). The files are served from a US government CDN, which while not bad in and of itself, should require you to test them to make sure it serves the files as well as a commercial CDN. For example, icon font FontAwesome is served via the Assets CDN, though you may want to compare against others given its ubiquity on the web.

The Assets documentation also provides links to a Medicare style guide and a Healthcare.gov style guide, both of which require a login to see, severely limiting their value to sub-contractors.

PayPal's Accessibility Plug-in

If you refuse to use anything from the US government, you can head to the other end of the spectrum and use the accessibility plug-in from PayPal.

According to PayPal:

This plugin adds accessibility mark-up to the default components of Bootstrap 3 to make them accessible for keyboard and screen reader users.

Because it's an add-on to your existing Bootstrap 3 code, it should just work. It will make the following default UI components accessible: Alert, tool-tip, pop-over, modal dialog, drop-down menu, tab panel, collapse, and carousel. You can pop over to the demo page and test it out with and without the plug-in (use a keyboard to understand the benefits).

As with Assets, this doesn't guarantee that what you build will be accessible. You still need to consider the same items I cite above along with many many more accessibility elements which cannot just be handled with a plug-in nor a checklist.

Related

The Canadian government has created its own framework, also intended to be accessible, usable, interoperable, mobile friendly and multilingual. The Web Experience Toolkit (WET) has just moved up to version 4.

While not a framework nor an accessibility add-on, the United Kingdom has a handy style guide to make all its gov.uk properties look consistent: GOV.UK elements

There may be hope for government web sites after all, though just don't try to use Section508.gov with a keyboard.

Update: July 7, 2014

Heydon Pickering has updated his Revenge.css to work with some Bootstrap shortcomings. If you aren't familiar with Revenge.css, it's a handy CSS file you can call via a bookmarklet to highlight accessibility issues in your CSS file (like removing outlines, or forgetting the :focus selector when you use the :hover selector).

So You Think You’ve Built a Good Infinite Scroll

So you’re saying there’s a chance … that I’ll make it to the footer.

Last week Derek Featherstone posted Automatic infinite scrolling and accessibility, a quick rundown of why having your page just keep going without user input to do so can be such a hassle for users. Also, don’t do it.

In the comments someone trotted out an example of his own automatic infinite scroll that he felt was effective and was developed with the user in mind. I got a bit ranty and suggested otherwise. That wasn’t as productive as it could be, partly because I was commenting on one example that other developers might feel doesn’t apply to their own efforts at similar implementations.

I think maybe this could all be made a bit easier by offering a quick checklist of what to test, expect, and review if you attempt your own version of an automatic infinite scroll. Here is my attempt at one, but please feel free to suggest others (or corrections) in the comments below.

1. Can the user hit “back” and return to the exact same place?

There’s nothing quite so infuriating as loading a few screenfuls of content, following a link, and then coming back only to find you have to reload those screenfuls of content all over again. Not only is it a waste of time, it’s a waste of bandwidth.

2. Is there paging for when the JavaScript breaks?

Everybody surfs without JavaScript while the page is loading, and that load time can be extended by network lag. In addition, broken third-party scripts can take down your own script. Can the user still get past page one if the JavaScript has fallen down?

3. Does the page have a footer?

Now you’re just being a tease. The user will never get there, so don’t lie by showing the footer and implying he or she can get there. You might as well just remove it. It’s at least honest.

4. Can a keyboard user access all other content on the page?

Unless the content that keeps updating is (or contains) the last focus-able element in the source order (the linearized version of your page), then a keyboard user (as well as screen reader users) will never be able to get to that content. Just like the footer you might as well remove it altogether.

5. Can you share a URL to a specific place on the page?

After you’ve gone a few screenfuls deep you may have found a few links of interest. Can you copy the address from the browser and email it (or even tweet it) and expect the recipient will come to exact state of the page (a few screenfuls in and with that content visible in the viewport)? Remember, an anchor is useless if it hasn’t loaded yet (or has been co-opted by your script).

6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?

Consider a list of news. After a couple screenfuls you might glean that each screen loads a week (or a month or whatever time period). You want content from a few weeks ago (or a few time periods ago). In a traditional paged navigation you could jump ahead a few screens to more quickly get further down the timeline. If your approach doesn’t afford users this control, you’re wasting your users’ time and bandwidth.

7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”

Keep your favorite memory monitoring tool open and load a few screenfuls. Then a few more. Then perhaps all. Take a look at how much memory this requires and then compare to available memory on other devices (such as smart phones). Remember that a mobile browser may reclaim memory by dumping other resources from working memory, potentially purging the rest of your site and its assets from the user’s cache, resulting in more bandwidth overhead and longer download times on subsequent pages.

8. Is there a way to disable automatic infinite scrolling and lean on standard paging?

Can the user easily disable the infinite scroll? Forget browser configuration acrobatics, instead look for a very visible single-click/tap option for the user to disable infinite scrolling and move on.

9. Have you conducted any user tests?

Before you roll this out, make sure some real users sit down in front of it. Nobody from your organization. Nobody who is an IT professional, developer, or whose paycheck depends on making you or your boss happy.

10. Are you satisfying a use case that has come from research or user request?

Did this feature request come from users, or the client? Or your boss? Or your desire to flex your scripting muscles? If you don’t have a compelling use case or feature request to add it, you may want to put your efforts toward features that truly have value, like print styles.

11. Do you have any analytics/tracking to measure success?

If you do decide to launch your perfect automatic infinite scroll feature, don’t forget to put some tracking scripts in place to determine how many screens deep your users go, and how often they click. There are other things you can measure (like if the footer ever gets clicks on that page). After all, success isn’t measured by you launching, but by whether or not it works well.

Update: July 14, 2014

Remember the example site from my infinite scroll post? Site now does two-screen-at-a-time-only scroll: http://t.co/5bv9ogogd8 That's novel.

— Adrian Roselli (@aardrian) July 14, 2014

Update: November 11, 2014

I left this list as a comment on the SitePoint article The UX of Infinite Scroll: The Good, the Bad, and the Maybe. Mostly because there is no good. There is only bad.

Update: February 13, 2015

Another post that proclaims the benefits of infinite scroll, with nothing at all to back them up: Infinite Scrolling: Pros and Cons It does list some issues, but it's a woefully short list.

Make Getty Embeds Responsive

In my post What to Consider before Using Free Getty Images one of the many caveats I outlined was the lack of responsive support in Getty's iframe code. Of all the issues I raised, this one is actually pretty easy to get around.

Background

While the other points still preclude me from readily using Getty image embeds, I recognize its value to clients and want to be able to allow them to use these images without fear of breaking the responsive sites we've coded. I also wanted a solution that won't require my clients to do any extra work, such as embedding HTML wrappers, adding classes or IDs, inline script, or generally mucking about in code.

If you've read at least a few of my last 15 years of writing, you might know I have a general aversion to scripted solutions and generally start trying with a CSS solution. At first glance, there is an example dating back five years at A List Apart that I thought might work, Creating Intrinsic Ratios for Video.

Another post tackled other embeds (Vimeo, Slideshare) in 2011 using the same technique expanded just a bit. Five years on and a new article popped up (just a couple weeks ago, Making Embedded Content Work In Responsive Design) that is targeting more third-party embeds (calendars, Google Maps), but leans on the A List Apart technique — and by leans on I mean just uses it outright but for more services.

The A List Apart solution and its variations don't work for two reasons: 1) they violate my requirement of not making my authors create HTML and 2) they rely on knowing the ratios. Every Getty image can have its own aspect ratio that I can't expect my authors to calculate.

The Getty embed has another factor not accounted for in these other solutions — regardless of the image aspect ratio, there is always a credit box below the image at a seemingly fixed height. This bar will always occupy that height, so scaling the image's height based directly on its width ends up leaving an ugly vertical white bar on the right of the image. This precludes any simple ratio as a solution.

My Solution

I made a demo to show my solution (does not open in a new window).

I decided the best approach was to write a JavaScript function that accounted for the height of the image credit as it calculated the image ratio. Then it would apply width and height styles that would scale the embed without leaving the ugly white gap on the right (barring rounding errors, which are evident in the portrait images).

I opted for JavaScript instead of a block of jQuery because I knew this would be maybe a dozen lines of code in total, and requiring an additional 29-82KB (depending on your minification and zippage) for the jQuery library is, well, absurd. Also, I am not a fan of dependencies, particularly when most developers rely on hosted libraries.

I did some screen captures of Getty image embeds and identified the image credit bar is 69 pixels tall. That number may (will) change in the future. You may want to populate that variable from your chosen CMS so you don't have to do a full testing and deployment pass just to update one variable in your JavaScript functions file or page template (across all your sites) when Getty inevitably changes it.

The Getty iframe has no unique ID or class to make it easy to identify on the page, nor any other unique attributes, with the exception of the src attribute. So I loop through all iframes on the page and only grab those with the Getty URL.

I then get the iframe's width and height attributes, subtracting 69 from the latter, and calculate the ratio. From there I scale the iframe to 100% width and then get its new pixel width to feed to the ratio to calculate what its new height should be, finally adding 69 to it.

In my example page, I call the function at the bottom of the page and also in an onload in the body. There are better ways to do this, but given all the variations that are already out there (and that you may already employ), I leave it to you to figure out the best approach to handle for users who resize windows or rotate their phone/tablet.

What is compelling to me about this solution is that my clients (site authors) don't need to worry about adding or modifying any HTML on the page (most don't know HTML anyway), let alone CSS or script. When they paste the embed code, it should just work.

The Code

function responsiveGetty() {

  try {
    // Get all the iframes on the page.
    var iframes = document.getElementsByTagName('iframe');

    // Height in pixels of the Getty credits/share bar at the time of this writing.
    var crHeight = 69;

    for(var i = 0; i < iframes.length; ++i) {

      // Check to see if it's a Getty embed using the only attribute that's unique, the src.
      if(iframes[i].src.indexOf("//embed.gettyimages.com") != -1) {

        eachIframe = iframes[i];

        // Get the current ratio after excluding the credit bar.
        picHeight = eachIframe.height - crHeight;
        picRatio =  picHeight / eachIframe.width;

        // Set the iframe to fill the container width.
        eachIframe.style.width = "100%";

        // Set the iframe height to correspond to the ratio, adding back the credit bar height.
        eachIframe.style.height = ((picRatio * eachIframe.offsetWidth) + crHeight) + "px";
      }
    }
  } catch(e) {}
}

responsiveGetty();

Feedback

There are probably ways to optimize my code or factors I did not consider. If you see something wrong or that could be improved, leave a comment.

ARIA Tabs

Last week I spent my Friday afternoon trying to get my head around how to apply ARIA properly to a tabbed interface. I even got so far as to map it out on my whiteboard and snap a photo so I could mull it over during the weekend.

And then the very next day Marco Zehe, responsible for accessibility quality assurance at Firefox, posted Advanced ARIA tip #1: Tabs in web apps and suddenly my weekend of snow shoveling turned into fiddling.

Marco's post included sample HTML for tabs and an outline of how the script to control it should function, but did not include the necessary styles or script to make it behave as tabs. Since I was marking up a tab list anyway to incorporate ARIA, I'm sharing my code here for others to try, enhance, and so on. It's also on CodePen, so you can fork it and fiddle there.

The HTML

My code has minor differences from the example. For instance, I add a return false; at the end of the event handler. I also call the function that activates the first tab at the bottom of the page, so all tabs start as un-selected and no tab panels are visible until that function fires. You can just as easily put the logic into your HTML and CSS to have one pre-selected and skip that function call altogether.

<ul class="tabList" id="tabs" role="tablist">
  <li role="presentation"><a id="tab1" href="#panel1" onclick="showTab(1);return false;" role="tab" aria-controls="panel1" aria-selected="false">Tab 1</a></li>
  <li role="presentation"><a id="tab2" href="#panel2" onclick="showTab(2);return false;" role="tab" aria-controls="panel2" aria-selected="false">Tab 2</a></li>
  <li role="presentation"><a id="tab3" href="#panel3" onclick="showTab(3);return false;" role="tab" aria-controls="panel3" aria-selected="false">Tab 3</a></li>
</ul>

<div class="tabPanels">
  <div id="panel1" role="tabpanel" aria-labelledby="tab1">
  <p>
    Nulla tincidunt pharetra tortor. In dapibus ultricies arcu. Suspendisse at purus eu est tincidunt feugiat. Praesent et sapien. Vivamus fermentum, diam vel ornare vestibulum, nibh massa imperdiet lectus, eget tincidunt urna urna nec erat. Curabitur interdum. Nam lorem nunc, posuere quis, suscipit eu, hendrerit vitae, nisi. Etiam hendrerit tincidunt felis.
  </p>
  </div>

  <div id="panel2" role="tabpanel" aria-labelledby="tab2">
  <p>
    Vestibulum id eros eu lorem tincidunt sollicitudin. Suspendisse ligula. Sed nisi magna, elementum at, ultricies in, tincidunt imperdiet, quam. Nulla semper. Suspendisse potenti. Sed sollicitudin dolor aliquet purus. Aliquam dui. Proin arcu metus, porttitor eget, pulvinar nec, molestie dapibus, ligula.
  </p>
  </div>

  <div id="panel3" role="tabpanel" aria-labelledby="tab3">
    <p>
      Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Aliquam vel erat. Vestibulum egestas purus ut felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
    </p>
  </div>
</div>

<script>
  showTab(1);
</script>

The CSS

This CSS presumes you've already set your typefaces, your page background, and everything works as you want. I have put the minimum styles to make it visually look like tabs. You may notice that I use two different selectors for both a selected tab and for a hidden tab panel. One is by a class name, the other is by the value of the appropriate aria- attribute. Use the first for broader (older) browser support and the latter if you don't care. If you do target just current browsers, then you may adjust the script below to skip writing classes.

.tabList {
  list-style-type: none;
  padding: 0;
  margin: 0 auto;
}

.tabList a {
  display: block;
  float: left;
  border: .1em solid #000;
  padding: .25em 2em;
  margin: 0 0 -1px .25em;
  border-radius: .5em .5em 0 0;
  background-color: #aaa;
}

.tabList a:link, .tabList a:visited, .tabList a:hover, .tabList a:focus, .tabList a:active {
  text-decoration: none;
  color: #000;
}

.tabList a:hover, .tabList a:focus {
  background-color: #ccc;
}

.tabList a.selected {
  background-color: #fff;
  border-bottom: 1px solid #fff;
}

.tabPanels div {
  clear: left;
  margin: 0 auto;
  padding: 1em 2em;
  border: 1px solid #000;
  border-radius: .25em;
  background-color: #fff;
  display: none;
}

.tabPanels div.selected, div[aria-hidden=false] {
  display: block;
}

.hide, div[aria-hidden=true] {
  display: none;
}

The Script

The following script toggles classes for the tabs and the tab panels, as well as adjusting the aria-selected and aria-hidden attributes. There is no keyboard functionality in it at all, but I am always willing to take some from a kind donor. As I noted above, if you use solely the aria- attribute as a CSS selector, you can drop the part that changes the class for each element.

var OpenTab;

function showTab(num) {
  try{
      if(OpenTab!=undefined){
        var OldTabID = document.getElementById('tab'+OpenTab);
        var OldPanelID = document.getElementById('panel'+OpenTab);
        OldTabID.className = '';
        OldPanelID.className = 'hide';
        OldTabID.setAttribute('aria-selected', false);
        OldPanelID.setAttribute('aria-hidden', true);
      }
      var TabID = document.getElementById('tab'+num);
      var PanelID = document.getElementById('panel'+num);
      TabID.className = 'selected';
      PanelID.className = 'selected';
      TabID.setAttribute('aria-selected', true);
      PanelID.setAttribute('aria-hidden', false);
      OpenTab = num;
  }catch(e){}
}

An Example

The following is an embedded version of the tabs on CodePen. Because of how CodePen works, you'll see a few minor differences in styles, but this is at least a functional example which you can fork and tweak.

For example, on CodePen, the function to enable the first tab must be called in the block of script itself, but I prefer to call it at the bottom of the page.

For reasons I cannot figure out, the tabs on the embedded version of this Pen do not work. Visit the tabs directly on CodePen to see them in action.

Check out this Pen!

Wrap-up

That's it, pretty simple. If you have suggestions, corrections, or are a regular AT user and can offer further insight, please feel free to share in the comments or tweet me on the Twitters.

Update, August 6, 2013

Marco Zehe, the guy who wrote the article Advanced ARIA tip #1: Tabs in web apps (which I link above) offered some adjustments to make to my sample code. In essence, dump the aria-hidden from the HTML and use the CSS style visibility: hidden; in its place. His explanation:

@aardrian That would definitely be preferred over aria-hidden, since aria-hidden is not supported by all screen readers.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian Especially older versions of JAWS, which you'll still find a lot, will ignore it.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian So use visibility: hidden; in addition to display: none;, and you should be good. Leave aria-hidden out completely.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

Update, December 4, 2013

Heydon Pickering has an example of ARIA tabs as well, with slightly different approach (aria-controls instead of aria-labelledby). He also offers a tip for maximizing compatibility:

@aardrian RE @MarcoInEnglish's note, tying aria-hiden + display:none maxes compatibility... [role="tabpanel"][aria-hidden] { display:none }

— Heydon Pickering (@heydonworks) December 4, 2013

Letting Mobile Users See Desktop View of RWD Site

Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?

There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.

Clearly it's enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the "desktop" version of a site from a menu built into the browser.

Except that feature doesn't work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn't do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.

Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we're kind of stuck. While I have many ideas on how that might work, that won't address the issue today.

While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.

There are some core steps the hammer out in the logic of any solution:

1. Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.
2. In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.
3. Either using a round-trip to the server or client-side script, remove the media query logic and serve up the "desktop" CSS.
4. Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.
5. Now display a link to view the "mobile" version of the site. Again, this can be done with or without script.
6. If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.

This process is a bit oversimplified, but it covers the broad strokes.

There are some hurdles, of course. Your users might not understand what you mean by "desktop" or even "mobile." You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don't clear the link from the page for them. And so on.

You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.

These screen shots should give you an idea of what to expect when you visit the site:

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7, all styling determined by media queries.

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7 after clicking "View desktop layout" (with the zoom as the user would initially see it). The link to return to the mobile layout is at the top, though not as obvious as it could be.

This is what the user on an iPhone sees as soon as the desktop view loads—note the link to return to the mobile view is nowhere to be found. We did a poor job there and will have to fix it. Don't make the same mistake if you try this.

Related

• Turning off responsive web design, January 12, 2013 from Bruce Lawson.
• Opt-Out Responsive Design? September 12, 2012 at CSS-Tricks.com.
• Creating a faux ‘View full site’ button for responsive sites, May 26th, 2012 at NeilCarpenter.com.
• View Full Site Link for Responsive Web Design, April 12, 2012 at CreativeAndCode.com.

Update: March 25, 2013

In this post, Roger Johansson shows code the code behind making his similar technique work: Letting users disable responsive layout.

Update: March 29, 2013

Two more posts popped up this week around the idea of disabling responsive design, both of them looking a bit at the larger issue and then proposing an icon to toggle a design between responsive and non responsive: Thoughts on Toggling a Responsive Design On and Off by Jordan Moore and A suggestion for Responsive Design toggle icons by Andy Clarke.

I'm of the opinion that icons only mean something to a sub-set of users, so relying on them may be inadequate. I still like plain text.

Update: May 3, 2013

An article over at SitePoint asks "Should Users Have the Option to Switch Off Responsive Design?" The author tends to think that such an option is superfluous and many of the commentors agree. Many others point to bad RWD implementations as a reason to offer the option (though the developers of those bad RWD examples probably wouldn't care about letting users disable it). An interesting read if only to see more opinions.

Update: January 3, 2014

Depending on how you read these two tweets, they may support having an option to see the desktop version/view of a site:

Priceless :-) " Samsung have worked very hard to give my iPhone the screen resolution it needs so I can enjoy the full website". 1/2

— Stephanie Rieger (@stephanierieger) December 30, 2013

Context: an old comment on the Guardian site during their responsive launch...user complaining that he would prefer the full web site 2/2

— Stephanie Rieger (@stephanierieger) December 30, 2013

Update: January 13, 2015

Include a backup plan on #mobilefriendly sites. Make sure to keep visitors on their preferred version the whole time. pic.twitter.com/Z8SFMU9xoK

— Google Webmasters (@googlewmc) January 12, 2015

The text in the image (from Google Webmasters) reads: Include a 'Take me to the desktop-optimized version' option. It also includes the #mobilefriendly hash tag.

So here we are, two years on from when I wrote this post and three years on from a client implementation, and it looks like this approach is considered a best practice from Google. You know, the bigger search engine on the web.

2012 Advent Calendars for Web Devs

Now that the (Western, my favorite) holiday season is upon us, the tradition of advent calendars whose chocolate is replaced with web-related tips and articles is back. This year's crop is missing some from last year, but there's still good stuff to be found.

If you know of any others, please pass them along. For those not returning, I have listed them at the end.

1. 24 Ways

24 Ways, the one that pretty much defines the genre for me, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.

2. Performance Calendar

Performance Calendar dates back to 2009 (and still defaults to 2011 if you go straight to the domain). It focuses on techniques to speed up your site via scripting, CSS, and general mark-up, along with server tweaks and analysis suggestions.

3. Perl Advent Calendar

Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.

4. Webkrauts

Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page. Suggestion via @patrick_h_lauke.

5. 24 Jours de Web

24 Jours de Web has kicked off its first year as an advent calendar for web folk. Written in French it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me). Suggestion via @PhilippeVay.

6. Japanese HTML5 Advent Calendar

HTML5 Advent Calendar 2012 is in Japanese, and thanks to the wonderful powers of Google Translate, it was very little confidence that I suggest it is produced by volunteers who have each picked a day and written something about the web (based on this statement: 登録した日に自分のブログなどにエントリーを書いてください。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some not.

7. Web Advent

Web Advent is back. I had incorrectly listed it as not returning below, under its original address as the PHP advent calendar. With its name and domain change, it appears to be back again this year and keeping its streak from 2007 going strong.

8. HTML & CSS Advent

HTML & CSS Advent uses a rather self-explanatory name. Moving away from last year's advent-calendar-flap layout and to more of a list of articles, you'll find some experimentation with cutting-edge (or nearly so) features that may not make into client work just yet.

9. 12 Devs of Xmas

12 Devs of Xmas was also listed below as not returning (it has articles from last year), but I misunderstood — it will be starting the day after Christmas and going for 12 days from then. When all the other calendars have wrapped up, you'll still have one to read.

10. UXmas

UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos. Found this one via .net Magazine.

11. Freelancember

Freelancember 2012 is produced by the makers of Freckle time tracking software and targeted squarely at freelancers. Its daily entries will consist of downloadable gifts in the form of PDF worksheets. Think of this as less about web-tech and more about MadLibs for projects. Found this one via .net Magazine.

12. Mozilla Developer Network Holidays calendar

Mozilla Developer Network Holidays calendar includes brief links to resources or demos and suggests that you can edit them (if they are MDN resources). I had this one listed as non-returning because last year's address was very generic and the site has no navigation on the home page to direct users here. Perhaps that should be tip #1.

13. She Said It

She Said It is an advent calendar dedicated to providing general tips for the web industry in general, with quotes provided by women in the field. I only discovered this on Christmas Eve eve, so I've seen it fully populated by now. This calendar is produced in Sweden, but its contributors hail from everywhere.

14. 12 Days of Podcasts

12 Days of Podcasts, which I discovered on the day after Christmas, runs from December 26 to January 6, 2013. Each day will have a different audio-only interview with assorted web folks. You can stream them off the site or download the MP3 for later listening pleasure (perhaps during that terrible New Year party you're attending).

Not Returning

A handful of calendars aren't returning this year (so far), but content from previous years is still available. These include Font Deck's Adfont Calendar, and the Fronteers advent calendar (in Dutch).

Completely Unrelated

I discovered this one this morning and have no idea what to expect (other than the first day so far), but it might worth a look: Popperfont's Sciencegeek Advent Calendar Extravaganza. With such a compelling name, how can you not look?

Use Twitter's New Embedded Timeline without Slowing Your Page

Update: September 7, 2012

I misunderstood how browser load external JavaScript files when that load itself comes from embedded script. Ben Ward explained it to me and referenced this handy article, Thinking Async.

The gist of the article is that using JavaScript to write in a call to a JavaScript file causes the browser to load the external script asynchronously.

While it may be like wearing suspenders with a belt, I'm still going to leave my async edits in my Twitter embedded timeline calls.

Original Entry

Yesterday Twitter announced its new embedded timeline feature for web sites. The gist is that you drop a block of code on your site and users will see the timeline for the selected account as if they were viewing it on Twitter.com — embedded media, expanded links, etc.

This is a new feature and is likely to change, even if the how-to Twitter post isn't too clear on that. I say that it will change because of language in the developer documentation like No other customization options are available at this time, as well as the slew of requests for more type styling options (among other customization requests) on the Twitter Embedded Timelines Questions page(s).

There are also known bugs. If your domain has a hyphen in it, then this won't work. If you are using Opera Mobile, Android 2 or 3 default browser, or an iPad, then the swipe-to-scroll gesture doesn't work (I already reported that one).

Another issue that Twitter may not consider a bug is how the script to embed the timeline is loaded. Currently if you have an embedded tweet or the old embedded timeline on your page and Twitter is down (fail-whale down), then your web page will take quite a while to render. This is a function of how browsers load JavaScript. The browser won't finish rendering the page until it has loaded all the JavaScript or given up (a timeout, which can take minutes).

While there are JavaScript functions that can mitigate this, those don't come into play until the script has downloaded. Instead, HTML5 has a couple attributes for the script element that apply here — async and defer. Essentially these tell the browser it can render the page before the script is downloaded. Since Twitter content is often just add-on content for your existing page, this is the right approach.

Instead of spending a thousand words explaining how this attribute works, I refer you to the WHATWG specification using an embedded tweet where I manually insert the async attribute:

If you use JavaScript and don't know about async/defer HTML5 attributes, you should read up and use: whatwg.org/specs/web-apps…

— Adrian Roselli (@aardrian) September 6, 2012

The new embedded timeline feature doesn't make it quite that easy. Twitter gives you code to drop on your page that has no script element into which you can casually paste async. The script element is generated by JavaScript, which looks like this:

<a class="twitter-timeline" href="https://twitter.com/aardrian" data-widget-id="243755160277487616">Tweets by @aardrian</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

Many of the people who may drop Twitter timelines into their web site are not JavaScript coders. So I whipped up a quick modification you can make to that pre-generated script that will drop the async attribute where it needs to go:

<a class="twitter-timeline" href="https://twitter.com/aardrian" data-widget-id="243755160277487616">Tweets by @aardrian</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.async=true;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

The js.async=true; tells the Twitter function to drop an async into its script reference when it gets created. The generated chunk of code will look like this:

<script src="//platform.twitter.com/widgets.js" async="" id="twitter-wjs">

Now if Twitter goes down again (which it will) your page won't hang as a result. I have also asked Twitter to consider including async in its standard copy-and-paste code.

I have eight (8!) examples of this in play on my Buffalo food truck page, where I have embedded the timelines of the current crop of food trucks in the area so I can check them all at once while aimlessly wandering the streets in a hunger stupor.

If you have a better solution, I am all ears. Please drop it in the comments with any other feedback.

Codepen Has Handy Sharing Tools for Devs

There are plenty of online resources for playing around with code right in the browser, no server of your own needed, that you can then share with others. I have dabbled in them on and off but Codepen's recent entrance has a couple additional features that I have found handy.

Bookmarklet

Codepen has a bookmarklet which will find blocks of code on a page and, when clicked, queue them up to drop into a new project (or "pen"). In this example image you can see the code blocks on the page are highlighted and a box is anchored at the bottom of the viewport showing me what's been selected of what type (HTML, CSS, JS) and an option to jump right to the Codepen interface.

I tested this on my site (using The evolt.org Logo Using Only CSS2 and CSS3) and it recognized the HTML and CSS blocks of code for what they are. The HTML in my example has hidden characters inserted to prevent a bug from manifesting (thanks to a combination of how I coded the templates, the XML framework, XSLT transforms, and HTML rendering), so I had to manually clean that. The CSS came over just fine although for some reason it did not seem to apply properly until I manually pasted it in. Either way, I was able to start playing with the code almost immediately.

For all those tutorials on the web, this is a handy way to immediately grab and play with the code samples. Once I have sufficiently munged the code enough I can then share it using the URL Codepen provides or the embed feature I outline below.

Saving your project with a name and details is a little tricky and you'll want to be logged into Codepen beforehand (you can use your GitHub account for Codepen). Once you get past those two points you're pretty much good to go.

Codepen has a YouTube tutorial to walk you through the bookmarklet process:

Embed Code

Now that I've pulled code from a tutorial and messed around a bit (I didn't mess around with it, but let's say I did) I can write my own tutorial and embed the code directly into the page.

This is handy for people whose platform of choice makes it difficult to embed escaped code examples, who don't care to go through all the hassle of styling code for colors, or who just want readers to be able to interact with the code and mess around with it on their own.

The only real caveat is that it embeds on the HTML portion of your project. If the call to the Codepen JS file fails for some reason (which formats the display and creates the CSS and JavaScript boxes), users can at least see the HTML, but the CSS and JavaScript isn't included.

Using the Codepen project I created from my tutorial, I just pressed the "share" button and was presented with HTML to embed directly into my page. The results:

<p id="evolt">
<a href="http://evolt.org">evolt.org</a><br>
<a href="http://lists.evolt.org">lists.evolt.org</a><br>
<a href="http://browsers.evolt.org">browsers.evolt.org</a>
</p>

Related

• JSFiddle
• CSSDesk
• Dabblet
• JSLint
• JSBin
• jsdo.it
• The evolt.org Logo Using Only CSS2 and CSS3

Changes to jQuery Browser Support

Currently, up to and including the jQuery 1.9 release (not out yet, but coming), jQuery actively supports the following browsers:

• Internet Explorer 6+
• Firefox: Current -1 version
• Safari: Current -1 version
• Opera: Current -1 version
• Chrome: Current -1 version

According to jQuery's browser support page, any problem [in these browsers] should be considered and reported as a bug in jQuery.

As the jQuery team announced in its blog post, jQuery Core: Version 1.9 and Beyond, the 2.0 release (slated for early 2013) will drop support for Internet Explorer versions 6, 7 and 8. The 1.9 release will continue to support IE 6/7/8 and will even see parallel (to 2.0) development and bug fixes. There is even a code sample of conditional logic so developers can prompt browsers to load the appropriate jQuery library (based on IE browser, or not).

Readers have gotten a bit confused on this point, so much so that the jQuery team wrote a follow-up piece on Sunday, jQuery 1.9 and 2.0 — TL;DR Edition.

My concerns are two-fold. First, many web developers won't take the time to pay attention to the parallel track for 1.9 and 2.0 and may implement the new version as soon as it is available, penalizing users trapped on old versions of IE. Second, many web developers don't seem to know their sites' user base and may make ill-informed decisions to move up to the latest release (perhaps intentionally so), thereby penalizing users trapped on old versions of IE.

Looking at SitePoint's latest details on browser trends (Browser Trends July 2012: IE9 Strikes Back), and bearing in mind that every site on the web will likely have different numbers, we can see that IE 6/7/8 make up a combined 15.75% of users. In-your-head math tells you that for a site with a million users, that means 157,500 users will run into problems today if the site were upgraded to jQuery 2.0.

The browser numbers will likely change by early 2013, but perhaps not by much. If Microsoft's new forced updates work (The Skinny on IE's Update Policy) then this may all be a moot point.

Either way, site developers will still need to be smart enough to pay attention to their site statistics and respect those users who are trapped in a browser, instead of either forgetting about them or intentionally penalizing them.

As for why jQuery is making these changes, I understand both sides. Removing the bloat from the libraries by dropping IE 6/7/8 support should slim the files and reduce processing overhead. That's good for all non-IE users. The other side is nicely summed up in this tweet:

Yes, jQuery is bloated by IE fixes. But it's like a band-aid dropping support for wounds because the bleeding makes it difficult to stick

— Jake Archibald (@jaffathecake) June 29, 2012

Twitter Improves Site Speed by Dumping Hash-Bangs

Back in September 2010 Twitter changed how its site renders by pushing much of the processing to the web browser using JavaScript and hash-bang (#!) URLs. Today Twitter has announced it is essentially dumping that approach:

To improve the twitter.com experience for everyone, we've been working to take back control of our front-end performance by moving the rendering to the server. This has allowed us to drop our initial page load times to 1/5th of what they were previously and reduce differences in performance across browsers.

Surprising no one that I am the kind of guy who would say this: I told you so, Twitter.

The rest of the Twitter post explains why #! URLs are not the best solution for rendering content quickly and consistently. Sadly, not every type of Twitter page will see this update as I noted last week:

In early 2011 I wrote about #! in URLs as bad (rosel.li/020911). @Twitter has almost got it—#! removed from tweet URLs *only* so far.

— Adrian Roselli (@aardrian) May 23, 2012

Congratulations to Twitter for making parts of its site five times faster than its broken implementation.

Ongoing Misunderstanding of Flash and HTML5

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, "What the Demise of Flash Means for the User Experience." To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe's decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe's decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn't anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it's fair to challenge the claim that HTML5 creates "ubiquitous user experiences regardless of device" when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It's also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let's not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of "graceful degradation" and "progressive enhancement."

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author's math doesn't bear out the assertion — by the author's numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author's word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5's doctype [...]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn't tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn't need to change. The user shouldn't need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don't know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn't do anything to advance HTML5 and its related specifications.

I'd love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

Update: May 8, 2012

The BBC makes this same set of mistakes in its piece Coding the future: HTML5 takes the internet by storm.

Thoughts on Muse (Obvious Pun Avoided)

I downloaded and installed Adobe's new web design tool, Muse (code name) (also at Adobe Labs) out of morbid curiosity. Just like Adobe Edge (which refuses to launch), I had very little expectation that this would be a fully-developed sales-ready product. Instead of getting into extensive detail about the quality of its code, its accessibility support, and so on, I figured I'd do a very quick review of how I think it affects web developers.

The target audience is pretty clear from the Muse (code name) web site introduction:

Create websites as easily as you create layouts for print. You can design and publish original HTML pages to the latest web standards without writing code. Now in beta, Muse [(code name)] makes it a snap to produce unique, professional websites.

And this:

Design your pages
Focus on design rather than technology. Combine images and text with complete control, as flexibly and powerfully as you do in Adobe® InDesign®.

Right there is the gist of the product — enable print designers to convert their designs into web pages. Just like Photoshop would produce massive image slices to support Photoshop "designers," this product isn't about the code. With its integration of jQuery effects and Lightbox widgets, it seems almost like this would be a tool for a photographer to build a gallery site.

If you are a coder, or someone who cares about the code, this tool isn't for you. You will quickly see that the HTML is produces is not exactly structural or semantic, and that the piles of CSS and JavaScript aren't exactly necessary. Muse (code name) doesn't allow you to edit the HTML, so you still need to "publish" your work before you can edit it. If part of your coding process involves making your HTML meet accessibility standards or even just structure your content for good SEO, you will find it impossible.

If you are part of a web team, perhaps in an ad agency or interactive firm, then you will find that this tool doesn't allow you to collaborate well. If you get a favicon, for example, from another member of your team, Muse (code name) cannot import it; it only accepts PNG, GIF or JPG. If you receive a background image to drop into an element, Muse (code name) will crop the image, even increasing its dimensions to fill the element, regardless of your plan to allow more of the image to be revealed should the container change in size.

If you find yourself pasting HTML code from Google Maps or Twitter in order to embed third-party widgets on your site, you may find that is nigh impossible short of publishing your pages and then hacking through the HTML output. While I did not find a menu option to do that, even if it exists it will require a full "publish" step every time you want to tweak your embed code.

If you find yourself leaning on CSS techniques as simple as printable styles or as complex as media queries to support alternate display sizes, you will be disappointed. This tool is not intended to support liquid designs, adaptive layouts, document re-flow, or really anything related to alternate viewing.

If you support a web content management system, then for all the reasons above Muse (code name) is not a good fit. Just building a single page to use as a template will require a great deal of work to reformat the code to fit into most content management systems that are out there. Should you ever have to change the core template you either have to go back to Muse (code name) and repeat the process, or you will have to skip Muse (code name) for all future revisions.

In short, it comes down to these two key points:

1. Muse (code name) has the potential to be a great tool for the single graphic designer interested in showing off his or her work without having to learn a technology outside of his/her knowledge area (nor worry about accessibility, standards, alternate displays, SEO, etc.);
2. If you are a web developer (or web development firm), your job is not at risk. Muse (code name) is making no effort to replace you. If anything, it might keep you from getting fewer calls from people who might not be good clients anyway.

If you are looking for a pedantic review of the HTML output, I suspect plenty of others will cover that. Since Muse's (code name) target audience won't care, and anyone who does care will already know the issues just by playing around, it's not even worth getting into here. Besides, with 120,000 other people downloading Muse (code name) after the first day, I expect plenty of reviews of the markup will come.

Now to Examples!

These aren't intended to be open shots at Muse (code name), but instead I hope someone at Adobe can use them to help better it overall.

This image shows how Muse (code name) looks on my netbook (I may have tweeted my frustration last night). As you can see, the menus are off the top of the screen along with every other useful feature. I was able to close the application thanks to standard keyboard shortcuts.

Using the default page size settings (960 pixels with a min-height of 500 pixels), this is the sample site I quickly cobbled together. I did not start with a design or goal other than throwing some elements on the page, so don't tell me my site isn't as awesome looking as it could be. Because it couldn't be awesomer.

What about the file output you ask? Here is the /css directory:

File name	Size (bytes)
articles.css	5,106
bio.css	5,106
blog.css	5,106
books.css	5,106
contact.css	5,106
ie_articles.css	5,009
ie_bio.css	5,009
ie_blog.css	5,009
ie_books.css	5,009
ie_contact.css	5,009
ie_index.css	5,009
index.css	5,106
site_global.css	4,305

The duplicates are for IE support and you can expect to see all your content in every page twice as it relies on IE conditional comments to serve up one copy for IE9 and one copy for anything below IE9.

Here is the /scripts/0.9 directory:

File name	Size (bytes)
jquery-1.4.4.min.js	78,766
jquery.museMenu.js	2,382
MuseUtils.js	9,317
SpryDOMUtils.js	14,604

Without those script files, those simple-looking menus on my example just don't render.

That background image I mentioned earlier? Muse (code name) re-cropped it and converted it to a PNG file, increasing both the dimensions and file size:

File name	Size (bytes)	Dimensions
Banner_bg.jpg	11,271	627 x 80	original image
master_U355_full.png	41,800	960 x 97	Muse (code name) -ified image

Related

• Developers respond to Adobe Muse at .net Magazine.
• Adobe's Muse (code name) site re-coded as XHTML 1 strict, dropping from 78k to 5k.
• Added August 25, 2011: ZDNet asks, as a response to Muse (code name) criticism, What is wrong with bloated markup? I answer in the first comment.
• Added September 2, 2011: Even FastCompany weighs in on this: Adobe's Muse Lets Designers Make Websites Without Knowing Code