Category: jquery

Posted on

Remotely debugging mobile devices: Remote web inspection in Safari and iOS6

It doesn’t take a genius to note that mobile devices are pretty much overtaking the web, and that a huge amount of people – the majority depending on the statistics you pay attention to – are accessing the web via a mobile device such as an iPhone, iPad or other smartphone / tablet.

As such there has been a huge buzz about responsive design and how to make sites adapt well between a range of screen sizes and resolutions, and moving away from the concept of a fixed size of screen such as the ubiquitous 960 pixel grid framework. One of the biggest challenges in this new era of web design and development has been the lack of good tools to aid you in the process of creating responsive, adaptive websites.

Media Queries and Responsive Design

The ability to work in code and create media queries to handle various device widths and related styles has been possible for a while, but it can be a bit mind-melting trying to keep track of all of this and to test as you work through the development process. Fortunately we are now beginning to see a range of tools to help you develop responsive sites, one of the most recent being Adobe’s new Edge Reflow tool which is an app that lets you visually adjust the viewport and tweak the CSS of various media queries. It’s a simple, focused app that lets you resize the viewport and tweak the styles as you go. At the time of writing it hasn’t been released yet but when I get a chance I will definitely be checking it out and writing something about it.

Remotely Debugging Code on Mobile Devices

Another challenge with working with mobile devices is that you really need to test on actual mobile devices to get an understanding of the true behaviour of them. Although you can set the width of your desktop browser to be the same as that of an iPhone it won’t necessarily behave exactly the same way due to the differences in the way the browsers handle CSS or JavaScript.

One of the difficulties in testing on devices themselves is that it’s not very easy to debug when things don’t work as expected. On a desktop browser such as Safari you can use the Web Inspector to see the live code as you interact with it and also see any JavaScript errors that are triggered, but on a mobile browser there is often little available to help you detect the errors.

Thankfully there are now tools being developed to allow remote access to the code running on the device itself, Adobe developed a tool codenamed ‘Shadow’ (now formally released as Edge Inspect) which works by providing apps for various mobile devices such as iPhone, iPad, Android phones and tablets.

With these apps installed on your devices you then run a desktop app on your computer as well as an extension in Google Chrome. You can then view websites in Chrome and they will be simultaneously displayed on the mobile devices running the apps, but the key feature is that you can remotely inspect the HTML, CSS and JavaScript running in the app on those devices. A really excellent tool.

Remotely Debugging in Safari

Adobe Edge Inspect (formerly Shadow) is a great tool, but what if, like me, you prefer to work in desktop Safari as your main browser and don’t want to or can’t use Chrome to test sites? In case anyone thinks this is just down to a matter of personal preference of browser I can give a legitimate example of why having to use Chrome can be a problem – Chrome’s in-built support for Flash gets in the way of testing content that is intended as fallback or alternative content on the desktop.

Screenshot of Web Inspector settings in iOS6 on an iPhoneFortunately the recent release of iOS6 offers a new feature that enables remote web inspection of mobile Safari on iPhone or iPad.

To make use of it you need to go into the ‘Settings’ app on your iOS device, and drill down into ‘Safari->Advanced’ where you’ll find a new toggle button for ‘Web inspector’, (this replaces the old ‘Debug’ option in mobile Safari which really offered little functionality).

Switch this on and you’ll see a small paragraph of text appearing which explains that you need to connect your device to your computer with a cable for this feature to work.

Once you’ve enabled Web Inspector on your iOS device(s) then you should find them listed in the Develop menu in Safari on your computer, it should looks something like this:

You can select the device and then it opens up a menu showing the available applications that web inspector can open. Note that you need to have mobile Safari open on your iOS device for any sites to be listed in the menu, if they’re not open then you’ll get a message saying ‘No Inspectable Applications’.

Once you select a site from the menu then the familiar Web Inspector window in Safari on your computer will open, the difference is that you are seeing the HTML, CSS and JavaScript from your iOS device. You can then browse around and interact with the site on your iOS device and inspect all of the changes occurring right in Web Inspector. Here’s a view of the HTML from a site on my iPhone:

Debugging via the console remotely

Just as with the ‘regular’ web inspector you can interact, view and update HTML and CSS and then see these temporary tweaks appear right on your iOS device. The main benefit in debugging for me has been in dealing with JavaScript / jQuery code, I can make use of console.log messages and debug via the console just as I would when working on my computer:

In a recent jQuery mobile based site I was developing I encountered code that was failing in mobile Safari but working fine in Safari on my Mac – exactly the kind of situation I mentioned earlier in this article where code is handled differently in mobile Safari. But thanks to this new remote web inspector functionality I was able to easily add some console messages and figure out what was going on and adjust the code to work around the problem.

A Great Solution for iOS Web Development and Testing

iOS6’s remote web inspection functionality is definitely a huge improvement if you are making sites that you need to test on iOS devices. With the increase in Android-based devices such as Google’s Nexus 7 and Amazon’s Kindle Fire tablets you will of course need to test on other devices besides iPhones and iPads. So tools like Adobe’s Edge Inspect are definitely something you will need to make use of too for testing across the various platforms and devices, but the simplicity of this iOS-specific testing workflow is very easy to set up and work with. A definite two-thumbs up from me!

I’m going to take a look at some of the other tools available to aid in the contemporary web development workflow of responsive, mobile-friendly design and write some more posts about them soon. In particular an updated look at Adobe’s Edge Animate tool and also a look at the Edge Reflow tool once it has been released.

Posted on

Adobe Labs release Wallaby Flash to HTML5 converter

Adobe have released an interesting experimental tool called ‘Wallaby‘ over on Adobe Labs. It’s basically an app that tries to convert Flash FLA source files into ‘HTML5’ compatible animations. Note I’m using ‘HTML5’ in quotes as usage of the term here is more in the overall grouping of HTML5 and related technologies such as CSS3, JavaScript / jQuery, SVG etc. It’s worth reading over the Release Notes to get an idea of the current limitations, the biggest issues at the moment being WebKit browser support only and no conversion of actionscript or sound within FLAs.

I just happened to be playing around with Flash this morning messing around doing a little shape tweening with a couple of symbols I found over on The Noun Project website so I thought I’d use that FLA file and see how Wallaby coped with it.

Running Wallaby:

After starting Wallaby you get a very simple interface, a file select field that you use to select the FLA file and a large Status area that shows any errors and warnings encountered whilst converting your file. There are also Preferences that can be set which at the moment include automatically opening the converted file in your default browser and enabling logging.

After selecting my FLA file I clicked ‘Convert’ and after a few seconds it happily converted my file without any errors or warnings. I was interested to see what it would make of the shape tweened animation that I had made in Flash as this seemed like quite a challenge to convert.

Wallaby’s HTML output:

The conversion process results in quite a few files being exported as the animation is recreated using a combination of HTML, CSS and jQuery / JavaScript, here a screenshot of the files I got:

It turns out that to make an HTML version of our tweened FLA animation we need two JavaScript files, one CSS file, one HTML file and a folder containing 246 SVG frames. I think it’s fair to say that tweened animations are a bit of a challenge! Looking at the Release Notes it does state that it creates an SVG file for each frame of a shape tween. As a result the approximate sizes of the exported files look like this:

  • Energy-html.html: 75kb
  • Energy.css: 49kb
  • Energy.js: 2kb
  • jquery-1.4.2.js: 70kb
  • Energy_assets: 176kb

That’s a total of 372kb in order to recreate the tweened animation in HTML / CSS / JS / SVG.

Flash’s output:

So how does this compare with the files output by Flash? Well, not very well when you look at both the amount of files required and their file size:

  • Energy-flash.html: 2kb
  • Energy.swf: 4kb

A grand total of 6kb when it’s rendered as Flash swf output. That’s quite a difference in size, although admittedly Flash’s default HTML file doesn’t use any JavaScript such as SWFObject to embed the file which is generally common practice, so I would argue that the Flash output should really have the following additional SWFObject files added to it’s output:

  • swfobject.js: 10kb
  • expressInstall.swf: 1kb

Even with that it’s still only a total of 17kb, about 1/20th the total size of the files that Wallaby outputs.

Why not use video instead?

This particular animation is obviously a challenge for Wallaby to convert into anything closely competing in file size, so perhaps in this case it would be a better option to use a video clip to provide a non-Flash version of the animation? The same animation can be output as an H.264 video at the same frame rate and it comes in considerably smaller at 192kb:

  • Energy-video.html: 1kb
  • Energy.mov: 192kb

That’s about half the size of the Wallaby output. It’s also likely to playback much better on mobile devices such as iPhone / iPad / iPod touch as Adobe warn that the output of shape tweened animation can result in playback performance difficulties on iOS devices.

In the interest of being consistent I should of course add some additional JavaScript video embedding option such as JWPlayer as again this is common practice when it comes to adding video on web pages. Using JWPlayer would add the following additional files:

  • jwplayer.js: 104kb
  • player.swf: 96kb
  • yt.swf: 1kb

This adds 201kb to the total file size required so that brings it to about 393kb, almost the same as Wallaby’s HTML5 output. I’m sure there are possibly slimmer options compared to JWPlayer for embedding that could reduce that down a bit but I reference JWPlayer as I consider it to be one of the best cross-platform methods of embedding video on website.

Of course I haven’t mentioned anything about delivering video in alternative codecs such as Ogg Theora or WebM to serve browsers like Opera, Firefox and Chrome, this would further increase the files and sizes involved. However, given that Wallaby is trying to provide a way for animated content created in Flash to be output and made playable on devices such as the iPad and iPhone it could also be considered that providing any kind of Flash fallback for video is unnecessary, so we could ignore the JWPlayer / JS completely and just use the regular HTML5 <video> tag and a single H.264 video, so we’d be back to a considerably smaller size than Wallaby’s output in this instance.

In Closing…

Overall Wallaby looks to be a pretty handy tool for people that are struggling to find a way to get their content viewable on the millions of devices that don’t (and likely never will) run Flash. For animation that doesn’t involve shape tweening I think the resulting file sizes will be a lot more favourable and it will be a reasonably efficient way to create animated content using standards-based technology.

I would say that the primary target user for Wallaby, at least at first, is for people doing online advertising. This is an area that is seeing a lot of activity with tools like Sencha Touch appearing, there’s definitely opportunity for a ‘killer app’ that makes creating banner advertising using all of these new emerging web technologies in a way that people are used to doing in the Flash IDE. There’s a lot of challenges in there technically, as well as a lot of issues such as accessibility, graceful degradation etc, but I think a lot of companies are focusing on this challenge now, so it’s good to see that Adobe is thinking about various ways of providing tools for the job.

Sample Animation files:

I have included the HTML5 output as an iframe and also links to each animation in HTML5, SWF and H.264 formats. There is also a link to download all the assets of Wallaby’s output in a zip archive:

Wallaby’s HTML5 output:

View Wallaby’s HTML5 Output in new Window
Download the Wallaby HTML5 Assets as a Zip

SWF output:
View SWF Output in new Window

Video output:
View Video Output in new Window

Posted on

How to fix flashing background images in Internet Explorer 6

In the process of using jQuery on a website revamp I encountered a problem I’ve experienced once before – flashing background images when using jQuery hovers in IE6. It turns out the problem is that IE6 does not cache images properly.

If you’re a web developer then you have probably set IE6’s Internet Options to check for newer version of stored pages every time you visit it in order to see all the incremental changes you make during testing / debugging. If that’s the case then you’re very likely to encounter the IE 6 flashing background problem. A typical situation would be using jQuery hover code on an element with a background image specified in the CSS. In this situation you may find that each time you hover over an element the image is reloaded resulting in a flashing effect in IE6.

One solution to this problem is to change the default of ‘automatically’, however, you have no way of knowing if the end users of your site will have the same settings so it’s possible they experience the same issue.

Upon hitting this issue recently I endeavoured to find a solution rather than adapting my HTML / CSS to fix it as I have done in the past. I also knew that IE6 users would be reasonably common for my client ‘s potential website user base so it needed fixed one way or the other. A bit of googling came up with an article entitled “Dear IE6: Please Cache my Images.“, the article’s solution was a bit of jQuery code that makes use of a specific IE javascript command to force background images to stay cached regardless of settings used in Internet Options:

if(jQuery.browser.msie && parseInt(jQuery.browser.version, 10) == 6) {   try {     document.execCommand("BackgroundImageCache", false, true);   } catch(err) {} }

Add this code to your page and it will fix the flashing image issue with hovers in IE6! Quite a simple solution to an annoying problem that has previously caused me to change my HTML code to fix, I’m glad that I decided to Google a solution this time!

One other thing to keep in mind that is pointed out in the aforementioned article is that this script will enable the caching in IE6 until you quit the browser and restart it so it will affect all sites that you visit in IE6.