Showing posts with label Apple. Show all posts
Showing posts with label Apple. Show all posts

Tuesday, September 10, 2013

New iPad Browser: Coast by Opera

Yesterday Opera announced the release of its newest browser, Coast, built specifically for iOS tablets (I would say just iPads, but if my fridge gets an iOS tablet UI then I'd be wrong and will have paid too much for a fridge).

Background

Recently Opera moved away from Presto as its rendering engine and hitched its future to Blink, the rendering engine born from WebKit that powers Chrome. Now instead of Opera worrying about the rendering engine, it is focusing on the user interface, the place where it can set itself apart from the other browsers.

Essentially Opera is removing the browser chrome (implying to the user that a web page is just an app) and adding gesture support. Given that Opera was the browser that introduced us to mouse gestures well over a decade ago, and given that a touch screen is an inherently gesture-based UI, this seems like a natural fit.

Bits for Developers

Sadly, my office wifi was down and I couldn't play with the browser immediately (my crusty iPad 2 is wifi only). So instead I took some time to read through the developer notes.

Tablet First

Overall Opera recommends general responsive design current best practices, though it promotes a tablet-first approach. Opera offers some CSS you can use to specifically target iPads Mini, 2, 3 and 4 (Retina and non-Retina), though it leans on vendor prefixes with only a brief note to also use other prefixes and unprefixed rules.

Responsive Images

It's also clear that Coast supports the new srcset option for responsive images. It even offers a code example: <img src="image.jpg" srcset="retina.jpg 2x">

Note: As Bruce was kind enough to inform me (because I missed it in the dev notes), responsive images will be supported only in iOS7 and up.

Update as of September 20, 2013

According to Opera, iOS7 did not come with a WebKit update. That means Coast cannot support responsive images via the srcset attribute without a polyfill. Nor can Safari, of course.

Tile Speed Dial Web App Image

Instead of "Speed Dial" icons/images, Coast now looks for a "web app image." If you don't have one, Coast will first look for a Windows 8 tile image, then an Apple touch icon, then a shortcut image, then just a favicon. You can, however, create your own 228 × 288 pixel image and stuff it into your site with the following HTML:

<link rel="icon" href="$URL" sizes="228x228">

User Agent String

Don't use this to do any browser sniffing. Browser sniffing bad. This is instead handy for recognizing it in your logs:

Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Coast/1.0.2.62956 Mobile/10B329 Safari/7534.48.3.

General Review

Getting going is pretty easy, just start typing into the only field on the screen. As you type you can see a Google preview on the left, which you can tap at any time to go to Google, or a list of icons on the right which correspond to sites you might mean. The icons start out just displaying the first letter of the site, and then identify the site's tile or shortcut image.

Screen shot of Opera Coast navigate screen.
Note the handy ".com" and ".net" options that appear above the right end of the text box.

Once you are on a page, you can go back by swiping from the left, forward by swiping from the right, or reload the page by pulling down from the top — but not too far or you get the iOS menu instead.

Vine of me playing with back, forward and reload in Opera Coast.

Opera Coast skips tabs and windows altogether and, frankly, feels a lot more like Internet Explorer for Metro than other current tablet browsers. It's pretty easy to see the open "tabs," flip through them, get more details, and discard them. It's also incredibly easy to forget you have so many tabs open. I regularly found myself littered with tabs because of all the links opening new windows.

Testing Opera Coast window/tab management.

While in that tab view, you can also see how "safe" the page is and can get to options to share it, email it, print it, and so on.

Screen shot of Opera Coast safety and share information.
The arrow on the right gives you all the share options.
Opera Coast print dialog.
I don't have a printer installed, so I'd love to hear feedback on how Coast honors print styles.

Adding and removing a bookmark, tile, whatever, is pretty easy. It took a few swipe-fails, but I got the hang of it well enough to show the whole process in one uninterrupted Vine:

It takes a little getting used to, but it's not too hard

Gotchas

There were a few things that threw me off. Perhaps because I am a power user, perhaps because I only played with it for one evening.

Swipe History

The swipe for back/forth is handy, but conflicts with behavior I have already learned. In Chrome for Android, swiping left or right has the infuriating feature of bringing me to the next or previous tab in the stack order. For those rare sites that implement a slide that is swipe-friendly, imprecise swipes will move me back and forth in the history instead.

Web App Images

Using the browser in portrait view, the additional screens of tiles (speed dial icons if you are already familiar with Opera) aren't immediately apparent. It wasn't until I turned to landscape that I saw them. The tiny dots under the Coast icon weren't enough for me to intuit that. They also aren't nearly large enough to tap to jump to a specific screenful of tiles.

Hit Sizes

The 9-box grid at the center bottom as well as the three rectangles at the bottom right are the only real browser chrome in play as you surf. They are also maddeningly small to tap. And I have dainty, lady-like fingers, so I suspect it may cause consternation for others.

Address Bar

If I am on a site and I want to change the address of the current page (maybe I fat-fingered and got to a 404, or I know a super-secret URL), I could not find a way to bring up the address bar and change it. It also made it impossible to know the current page address at any time. As someone who regularly looks at the URL for familiar addresses, indications of scam sites, quick commitment to memory, and so on, this alone takes it out of the running as an everyday browser for me.

Email a Page

I did not care for the email feature one bit. Not only does it embed a screen shot of the page (with a Coast watermark), the screen shot won't display on other devices. Outlook blocked the image because the attachment ended in .com (not .png or .jpg). Had it not come from me, I wonder if Outlook would have blocked it as spam. My Android email client couldn't display it because there was no file extension to give it a clue.

Screen shot of emailing a web page from Opera Coast.
What you see when you choose to email a web page from Opera Coast.
Screen shot of received email from Opera Coast.
Best case scenario of what the email recipient sees, though the attachment was blocked in Outlook and unusable in my Android email client.

Tweet a Page

Tweeting a page left me similarly dissatisfied. By default it includes a Twitpic screen shot of the current page with an Opera Coast watermark. When composing the tweet, I tapped the paperclip icon to see if it would do anything, but nothing happened. I opted not to tweet again.

Screen shot of tweeting a page from Opera Coast.
Tweeting a page from Opera Coast.

The resultant tweet:

Wrap-up

Overall, I like the browser. I like what it's trying to do for consumers. As a power user, however, It's not a fit for me though I'd be interested in bringing it in front of some other members of my family.

I also didn't get to try out unsafe sites, printing pages, responsive images (need iOS7), or poorly-built sites. My opinion might change as I continue to play with the browser.

Open Question

There are a lot of Android tablets out there, not just the four screen size offerings from Apple. So how long before we can see Coast on my Nexus 7, if ever?

Updates

I'm adding notes throughout the day as they come up.

Surprising no one, the following reviews from more mainstream sources completely fail to include any screen shots or videos that weren't pilfered from Opera. I only say that to remind you that by reading this post you have gotten the most in-depth review currently on the web and you should be excited and send me a thank you note and maybe read all my other posts and high-five me on the street.

These articles are, however, worth visiting just to see the comments and how others are reacting to it.

Tips from Bruce:

Update: September 18, 2013

Opera has fielded some questions about Coast and collected them into two posts (so far):

Update: September 25, 2013

Another FAQ post from Coast:

at No comments:
Labels: , , , , , , ,

Thursday, April 4, 2013

Chrome: Blink and You Missed the News

The new Blink logo. It's old news by this Thursday morning, but in case you had not heard, Google is forking WebKit to make its own rendering engine, Blink. Opera will be using the Blink fork of WebKit as its rendering engine.

A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn't offer my opinion, however.

I will format this the way I did when I provided my in-depth analysis of Opera's move to WebKit (away from Presto) less than two months ago.

So what does this really mean?

For Developers

Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.

Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.

If you aren't sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post "WebKit Will and Won't Be the New IE," where I provide a high-level overview of these variances.

For Users

At this point it doesn't mean a whole lot.

Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won't be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to "WebKit Will and Won't Be the New IE" for how poor testing can impact users, but that's not a function of the engines.

Because Apple only allows WebKit on iOS devices, and even then it restricts those browsers to a different JavaScript engine and thus a lesser experience, Chrome and Opera for iOS may still stay on WebKit. Over time as its harder to incorporate features from Blink back into the WebKit core, there may be feature divergence which may affect users.

That's just speculation on my part.

For Standards

For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.

With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto's wind-down (to be fair to Presto, it's expected to exist in the wild until 2020, but with no new feature development).

I am hoping that this is a good thing for standards.

Blink won't be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.

Technical Aside

From Peter-Paul Koch:

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Related

First some bits from The Twitters:

And now to the related links:

There's this one from 2010 by Haavard Moen that I thought worth highlighting: "Dear Google: Please fork WebKit."

Update, 5:35pm

A video Q&A from Google Developers about Blink (time markers available on the Chromium blog).

at No comments:
Labels: , , , , , , , , ,

Thursday, January 17, 2013

App Store Meta Tags

Screen shot of Dominos home page on Nexus 7.
Why yes, Dominos, I'd love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.

This may be old news to some of you, but I haven't found a place that collects this in one spot.

One of the most offensive experience I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site's app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don't expect to be served the page I came to see, but instead shunted to the mobile home page).

If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.

iOS 6

Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

  • app-id is required and references your app's identifier.
  • affiliate-data is optional and uses your iTunes affiliate string.
  • app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple's developer site: Promoting Apps with Smart App Banners

Windows 8

Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the "charms" feature of Windows 8.

This code is relatively simple as well, though it requires two meta tags and supports up to five:

<meta name="msApplication-ID"content="microsoft.build.App"/>
<meta name="msApplication-PackageFamilyName"content="microsoft.build_8wekyb3d8bbwe"/>

  • msApplication-ID is required and references your app's identifier.
  • msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.
  • msApplication-Arguments is optional and lets you pass arguments to your app.
  • msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.
  • msApplication-OptOut< is optional and allows pages to opt out of installing the app, switching to the app, or both./li>

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.

If you know of other apps tores that offer similar features, please let me know so I can update this post.

Related

There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.

Updated: January 29, 2013

I wrote a version of this post with an example at the Algonquin Studios blog. I'm pasting the example in here...

Real-World Example

One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.

Screen shot of the QuantumCMS custom meta tag screen.
Screen shot of the QuantumCMS custom meta tag screen.

If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:

Site on the iPad3 without the app installed. Site on the iPad3 with the app installed.
Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.

Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.

If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.

Update, March 8, 2013

What he said:

Update, April 24, 2013

There is a recap of recent rants over at .net Magazine in the article "Devs rally against mobile web doorslams."

Update: June 12, 2013

Google has just announced that it may penalize sites that promote apps with those awful interstitials. Yet Google offers no solution (as you see above) for Android apps through the Google Play store. You can get more detail in my post "Google Needs to Provide Android App Interstitial Alternative."

Update: March 11, 2014

I told you above that you needed to get the app identifier and package family name to make the Windows app banner, but I neglected to tell you where to get that information. Some kind soul over at Adobe's forums provided instructions.

Update: August 31, 2014

I keep forgetting to link this: jQuery Smart Banner, which uses jQuery to stuff a Smart-Banner-like feature into your site for old iOS versions, Android and Windows. I have not tried, so I can offer no feedback on whether it works well (or at all).

at 2 comments:
Labels: , , , , , , , ,

Thursday, March 22, 2012

iPad Retina Display Concerns and Tips

TL;DR

The iPad 3 retina display means a lot of apps and web sites are going to feel pressure for sharper (bigger) images. Knowing if you need to scale your images, the impact on end users and some ways to mitigate that impact is the right way to approach this.

What's All the Fuss?

With the announcement of the new iPad's "retina display," there has been quite a lot of buzz among web developers about what that means for graphics. Some are welcoming the change by diving right into their projects and kicking up the size of their images, and some are lamenting the ongoing unabated bloat of web pages and apps since images can quadruple in size.

If you don't believe Apple sees the potential for apps to grow in size, earlier this month it raised the cellular network download limit in the App Store from 20MB to 50MB. While there are many arguments on why Apple might have done this, knowing that the image assets for any app may bloat in size by four times when targeting the new display provides a rather compelling reason on its own.

David Sleight points this out in his post A Retina Display Reckoning for Magazine Publishers, using magazine page sizes as an example of the problem scaled-up images could produce:

The screen volume may have quadrupled, but the new iPad still ships with the same three memory options: 16, 32, and 64GB. As I noted on Twitter, the growth rate of the potential payload size just outgrew the growth rate of device storage exponentially.

Apple also understands that images on the web will grow in size to target the iPad 3. The method Apple employs to deliver these images is not only inefficient, if web developers user Apple's code as a baseline then all the sites they build will affect their users. From a post last week, How Apple.com will serve retina images to new iPads, Jason Grigsby outlines just what happens to the end user:

As far as I can tell, there is no attempt to prevent duplicate downloads of images. New iPad users are going to download both a full desktop size image and a retina version as well. […] The total size of the page goes from 502.90K to 2.13MB when the retina versions of images are downloaded.

This doesn't even account for the HTTP requests for the original images, the HTTP requests for the high resolution images, and the HTTP request to test if there is even a high resolution image to retrieve. All of this is wrapped in a browser detection script, something at which a seasoned coder may wince.

Josh Clark points out in his post 3.1 Million Pixels Are Heavy that responsive design is still a method-in-progress and that using techniques like Apple does to serve high resolution images can push down far more than a user needs:

Sending a full-screen iPad image (1536x2048) to an iPod Touch browser (320x480) is overkill to the tune of 25 times the file size. Over a wireless connection, that's gonna smart.

Peter-Paul Koch takes this a step further in his article The iPad 3 and Moore’s Law, where he talks about the impact that larger images will have on network speeds and ultimately user experience. Citing an example of an app that will bloat from 18.3MB to ~35MB, he brings the file size discussion to its logical conclusion:

Thus the Retina display puts incredible extra strain on the already-strained mobile web. Retina may be great for the end user, but the data networks simply cannot handle it (yet).

A common response to the scaling of images involves reliance on SVG images. Because SVG images are vector files, meaning the elements of the image are defined as scalable shapes instead of columns and rows of pixels, they can be sized up or down and still maintain the same file size and not lose any information. For images that are not photographic this sounds like a good workaround when targeting iPads only, regardless of SVG support in other browsers.

As anyone who has worked with vector imagery may know, however, vector images typically don't scale in ways that maintain the goal of the image. If you look at the icons on your computer and explore all the sizes, you may notice some elements change shape, relative size, or are even discarded altogether. The article About those vector icons by Kirill Grouchnikov demonstrates this in detail with some great examples. He also has a well-supported conclusion:

So no, SVG is definitely not the answer. At least not today.

The SVG solution is the common comment response to Brad Frosts' post iPad3′s Retina Display Will Wreak Havoc on the Web. As you read through the comments it's easy to see why I stress about the return of the browser monoculture, this time iPhone and iPad rather than IE6, as I wrote about a couple weeks ago (The Return of “Best Viewed in…”). Sadly, from that entire assault of comments pushing SVG or suggesting users just accept the bloat, only three comments even thought to mention responsive images, something the W3C is working to address now in a dedicated responsive images community group.

How to Adapt

I haven't reviewed all this to disparage the new retina display on the iPad 3. Instead an informed developer takes into account the pros and cons of every scenario and makes informed decisions that balance the needs of the user with the practicality of development efforts.

If you build stand-alone apps for the iPad, then you'll need to make many decisions about the images you use and whether or not they all need to be updated. You may find that getting the right icon size can be a bit tricky though, and Louie Mantia was kind enough to put together this iOS app icon template.

As for web development, a few posts have started to pop up that echo the same ideas good developers have used for years — evaluate the need, weigh the solutions, don't get too caught up in the bleeding edge. Here is a distilled list from the post iPad 3 and Retina Screen: What it means for your mobile commerce site:

  1. Prioritize important images;
  2. Make text into text;
  3. Boost button sizes;
  4. Make the logo bigger.

Brad Frost offers some tips in his post Optimizing Web Experiences for High Resolution Screens:

  1. Media queries (that sadly still lean on vendor prefixes);
  2. SVG, with a link to browser compatibility tables;
  3. @font-face to put icon typefaces to use;
  4. Detect network speed (its own special kind of train wreck);
  5. Get involved with the W3C Responsive Image Community Group;
  6. Don't forget some basic best practices:
    • Start with low resolution images first;
    • Make sure you optimize your images;
    • Use CSS3 for corners, gradients, etc.;
    • Use resolution-independent options;
    • Detect the network (when you can);
    • Know your browser compatibility.

My simplest tip on all this is to look at the logs for the web site in question and see if enough users come in on iPads to warrant the stress at this point.

Related

at No comments:
Labels: , , , , , , ,

Saturday, September 3, 2011

Patent Wars Sorta-Infographic

I'm giving in to the cool hip trend of infographics that has been popping up like pinkeye across blogging and tech sites lately. These infographics are typically nothing more than data points (sometimes just narrative) strewn about with mathematically suspect charts or somewhat-related design elements. But they seem to draw traffic, even when there isn't even data to graph (Browsers as Wrestlers "Infographic"). So I am using my lack of shame to power through this long weekend with three posts of three infographics from other sites.

In today's installment I am posting an infographic that has some (imprecise) charts and a couple process maps outlining the current state of patents called Patent Wars: A New Age of Competition. You can find the original image at Business Insurance Quotes site, where it has no accompanying explanation or background.

Image of patent wars, no accompanying text available.
Image of patent wars, no accompanying text available.

Related

at No comments:
Labels: , , , ,

Thursday, January 27, 2011

Apple.com (Not Really) Updated to HTML5

Apple has released a revamped version of its web site today, ostensibly in HTML5. Except it doesn't use anything from HTML5.

That Apple wants to move to the platform that it touts as the Flash-killer is not surprising. Apple refuses to allow Adobe Flash on its mobile devices and claims everything Flash does can be done in HTML5. While not totally accurate, it's certainly part of Apple's motivation along with its long-standing claims to support standards. I followed this for a while until it became just senseless bickering:

A few very pro-Apple sites have already carried the news about Apple's new move to HTML5, citing the new look, one even offering a screen shot of the first four lines of the HTML as proof that it's HTML5.

Except when you look past the first few lines of the code, or really past the DTD which identifies the page using the new minimalist HTML5 DTD, all similarities to HTML5 cease. I'm going to go after the low-hanging fruit here, mostly because I am writing this on a self-imposed deadline. When I opened the source code, I looked for some telltale HTML5 elements, specifically nav, header, footer or canvas (that last one is supposed to be the Flash killer). I found none of them.

Instead I see the standard tag-soup of divs being jammed into roles now replaced with the new semantic and structural elements of HTML5. As an example, this screen shot shows the HTML that drives the footer, all wrapped in nested divs. These could be replaced with the HTML5 footer element.

I understand that browser support is probably the driving concern here. Apple may not want to implement elements that don't have support in many current browsers. But this half-baked approach, which may be copied by Apple die-hards and HTML5 n00bs alike, does more damage to HTML5 than just leaving the site in HTML4. No, this is a case where prioritizing the marketing message along with ongoing battles with Adobe and now Google are causing Apple's web development team to fail to implement the specification as it is intended (or will be, when it is final). Which calls into question just how well they will implement any aspect of it, including its attempts to supplant Flash.

But this roll-out wasn't done with a mountain of HTML5 fanfare. It is possible that I am being too critical, that Apple's updated site is the first practical step toward future and ongoing implementation of the unique HTML5 elements as the browsers catch up. In that scenario Apple can be forgiven. Except I am not quite so willing to let Apple off that easily given how hard it pushed its HTML5 Showcase back in June. The showcase wasn't really as much about HTML5 as it was about Safari, and then what CSS3 and JavaScript can do. HTML5 itself didn't have much of a role in that showcase. It was just a great way to get people to download and use Safari, given that the content was riddled with Safari- and Webkit-specific features. I'm not the only one who takes Apple to task for it (for example, Apple's HTML5 Showcase Less About Web Standards, More About Apple at Webmonkey). Given Apple's prior behavior regarding HTML5 (pushing primarily CSS3 and JavaScript) and its motivations (Flash foil, Safari pusher), I'm not so sure Apple is taking the right approach with the new site.

Apple isn't the only one making this HTML5-but-not-really mistake:

Sadly, we are at a point in time where people are implementing HTML5 the way they implemented HTML4 (as in, poorly). It's like we just invented the screwdriver but everyone is using it to pound nails.

at 3 comments:
Labels: , , , , , ,

Wednesday, June 2, 2010

Smokescreen Brings Flash to iPad, iPhone


Smokescreen - iPad demo #1 from Chris @ RevShockAds on Vimeo.

Now that it's clear that Apple has no intention of letting Adobe Flash run on the iPad or iPhone, workarounds for Flash are even more compelling to developers. Smokescreen, primarily by Chris Smoak, bypasses the need for the Flash plug-in by pulling in the SWF binaries and decompressing them in JavaScript, yanking out the images and audio and putting it all back together with the vector data rendered as animated SVG. Simon Willison got the details and posted the technical process on his blog:

It runs entirely in the browser, reads in SWF binaries, unzips them (in native JS), extracts images and embedded audio and turns them in to base64 encoded data:uris, then stitches the vector graphics back together as animated SVG. Open up the Chrome Web Inspector while the demo is running and you can see the SVG changing in real time. Smokescreen even implements its own ActionScript bytecode interpreter.

You can see demos of Smokescreen running StrongBad emails and ad banners at the site. If you are running Internet Explorer (any version), then these demos won't work for you. In general, you'll need the most recent versions of Firefox, Safari, Chrome or Opera to see the demos. A couple of them run on the iPad or iPhone and there is even a video of it in action for those who don't have either device (see above).

The Flash movies don't run quite as quickly using Smokescreen as they would in the native Flash player, but that's to be expected when all the work is offloaded to the browser's JavaScript engine (8,000 lines of code weighing in at 175kb). I also noticed that sometimes text embedded in the SWF file either didn't appear at all or had some odd anti-aliasing. Given how new this is, however, I suspect these are surmountable obstacles. Given that Chris plans to release the code as open source, more developers will likely be able to contribute to pare this down.

What would make this even more interesting is if Adobe lent its support in some way. Since this has the potential to reverse the trepidation Flash developers now feel thanks to the increase in iPads and iPhones on the web, it may stave off any doomsday scenarios for Flash. It may also blow up Apple's plans to ultimately push Flash out of the market altogether unless they want to stop supporting the JavaScript and HTML5 that this utility uses to render the former-Flash movies. It's still too early to tell which way either company will go with this, if they do anything at all, but I suspect it will be interesting to watch.

Related Links

at 2 comments:
Labels: , , , , ,

Thursday, May 13, 2010

More Salvos from Apple and Adobe, to No One in Particular

I was out of the country when Steve Jobs posted his open letter on Flash to the Apple web site. Had I been around I would have dissected it. Today Adobe published its own open letter(s) about how great Flash is, why open markets are good, and even an ad campaign promoting choice. This passive-aggressive slap-fest is really just another reason for me to use my Apple vs. Adobe graphic that I spent nearly 10 minutes creating over a month ago.

To put my own preferences out there again, I have been critical of Flash for a long time (Jakob Nielsen roasted it 10 years ago now). The technology itself is mostly harmless, but developers have latched onto it for years to create confounding, inaccessible, and cryptic interfaces for web sites. To be fair, if they hadn't used Flash, they might have still made the same terrible chum, but Flash just enabled their poor behavior. Apple has always been the plucky upstart that despite being just another corporate computer company had somehow tricked masses of designers and wanna-be-cool-but-different (as opposed to being just different, like *nix users) folks in to giving them free advertising via legions of window stickers and the like. Except now people are recognizing them as the corporate juggernaut they are (When did Apple become uncool? at Yahoo! News).

Let me compare and contrast some points from the two letters.

Open vs. Closed

From Apple:

While Adobe's Flash products are widely available, this does not mean they are open, since they are controlled entirely by Adobe and available only from Adobe. By almost any definition, Flash is a closed system.

From Adobe:

The core engine of the Flash Player (AVM+) is open source and was donated to the Mozilla foundation where it is actively maintained. The file formats supported by the Flash Player, SWF and FLV/F4V, as well as the RTMP and AMF protocols are freely available and openly published. Anyone can use the specifications without requiring permission from Adobe. Third parties can and do build audio, video, and data services that compete with those from Adobe. [...] There are no restrictions on the development of SWF authoring tools, and anyone can build their own SWF or FLV/F4V player. [...] Adobe Flex, the primary application framework for Flash, is also open source and is actively maintained and developed by Adobe and the community.

As an end-user, I need help understanding Apple's point. How is what Adobe states any different from Apple's own WebKit? Because they claim it started as open source, whereas Flash didn't? The points in these letters don't speak to the average user, that's for sure.

From Apple:

Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. [...] HTML5 is completely open and controlled by a standards committee, of which Apple is a member. [...] Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

I'm going to let Adobe off the hook on this one. As I have said before, HTML is NOT a final specification yet. Apple is clearly pleased as punch that Safari supports much of HTML5, and good for them. But they are really pushing the canvas element as the Flash replacement. Given how quickly the W3C wraps up a spec, and browser makers get it into their browsers, and users download it, it's just not a good argument. It may be worth noting that JavaScript was originally Netscape's creation and is now known as ECMAScript.

Bear in mind that HTML5 has been handed off by the standards committee (W3C, of which Adobe is also a member) to the Web Hypertext Application Technology Working Group (WHATWG, of which Apple is a founding member). It turns out that Apple, Mozilla, and Opera were unhappy with the W3C progress on XHTML and HTML, and so broke off on their own. As a result, WHATWG is working on HTML5 alongside the W3C HTML working group, using the same human editor.

Touch Interfaces

From Apple:

Apple's revolutionary multi-touch interface doesn't use a mouse, and there is no concept of a rollover. [...] Even if iPhones, iPods and iPads ran Flash, it would not solve the problem that most Flash websites need to be rewritten to support touch-based devices.

From Adobe:

Flash was actually originally created as a technology for tablets with touch interfaces. And today, Flash has full support for working on touch-based devices. [...] For new Flash content developed specifically with touch in mind, Flash Player 10.1 provides a complete set of multitouch and gesture APIs.

Ok, Apple has a point, Flash does not support multi-touch. Multi-touch is relatively new, however, and Adobe promises it in their (much delayed?) Flash 10.1. I do take issue that Flash does not support touch devices. About 4 years ago we developed a Flash application to run on touch-screen displays for a kiosk, and it worked very well. The issue is again not with Flash specifically, it's with developers who are terrible at designing interfaces.

Security

From Apple:

Symantec recently highlighted Flash for having one of the worst security records in 2009.

From Adobe:

The Symantec Global Internet Threat Report for 2009 found that Flash had the second fewest number of vulnerabilities of all Internet technologies listed (which included both web plug-ins and browsers).

Erm, so who do we believe? Neither links to a report, but they both cite Symantec. So I went to the Symantec site and grabbed the document Internet Security Threat Report: Volume XV: April 2010. I searched in the PDF for Adobe Flash and found this:

In 2009, Symantec documented 321 vulnerabilities affecting plug-ins for Web browsers (figure 9). ActiveX technologies were affected by 134 vulnerabilities, which was the highest among the plug-in technologies examined. Of the remaining technologies, Java SE had 84 vulnerabilities, Adobe Reader had 49 vulnerabilities, QuickTime had 27 vulnerabilities, and Adobe Flash Player was subject to 23 vulnerabilities. The remaining four vulnerabilities affected extensions for Firefox.

Apple QuickTime had 4 more vulnerabilities than Adobe Flash? Did I mention that when I hit the Apple site, my browser keeps trying to get me to install QuickTime? There's also this quote:

The 321 total vulnerabilities in plug-in technologies for Web browsers for 2009 is less than the 424 in 2008. Of the total for 2008, 287 vulnerabilities affected ActiveX, which is significantly more than any other plug-in technology. Of the remaining plug-ins for which vulnerabilities were documented, there were 54 vulnerabilities identified in Java SE, 40 in QuickTime, 17 in Adobe Reader, 16 in Adobe Flash Player, and 5 vulnerabilities in Firefox extensions.

16 in Adobe Flash, 40 in Apple QuickTime. I really need some help finding Apple's point. I also need help finding Adobe's point. From what I see here, Flash is safer than QuickTime, even though (in further reading) it gets targeted more. If you want clear answers, you may need to read all 97 pages of the Symantec document, which was not linked from either Apple or Adobe.

Overall

Apple's letter clearly belies frustration with may have been Adobe's missed promised delivery dates. Apple also has a point that Flash doesn't hand off the video decoding work to the processor, eating battery life. Adobe has stated this is coming in the 10.1 release. Apple points to YouTube running as an app on the iPhone, but is silent on the fact that videos embedded in a page are inaccessible but does concede, backhandedly, that users aren't missing much video. And then Apple goes on about how Flash is designed to be cross-platform, and as such doesn't enable developers to write the best iPhone/iPad apps. And this is the crux of it all. Apple just wants the control and Adobe wants in.

Update (May 14): Read Adobe and Apple: Please Spare Us the Platitudes About "Open" over at Mashable for another take on all this.

Update (May 20): Read How secure is Flash? Here's what Adobe won't tell you at ZDNet where the writer also compares the Symantec report against Adobe. He missed the point, however, that Symantec recommends both Flash and JavaScript be disabled for a secure browsing experience, something that would hamper Safari's reliance on HTML5 in lieu of Flash.

at 2 comments:
Labels: , , , , , , , , , ,

Wednesday, April 21, 2010

Adobe to Drop iPhone Support, Target Android

And the saga continues. If you read my post Adobe vs. Apple or Flash vs. HTML5 from a few days ago, you already know that Apple and Adobe appear locked in a battle over Flash and the iPhone OS. It's clear Apple wasn't planning on backing down and it's certainly not in Adobe's best interests to continue the fight.

It should come as no surprise that Adobe is walking away. Mike Chambers, the Principal Product Manager for developer relations for the Flash Platform at Adobe (that's how he lists it on his blog), has said as much in his blog post, On Adobe, Flash CS5 and iPhone Applications.

He starts out with the clause from Apple that started this all, noting that developers can expect to see their Flash-developed applications slowly get booted from the iTunes store. However, Adobe has already built the export features into Flash CS5 that allows developers to target iPhones and iPads and plans to ship the software with those features still intact, even if Apple still blocks acceptance of applications built with that technology.

Instead, he claims that Adobe and Google have been working together to target Android phones and Android-based tablets with Flash 10.1. In short, all the work you have already done as a Flash developer to target the iPhone OS can simply be brought over to the Android OS. He provides links to some developers who are already making the switch, targeting Android now instead of iPhone.

There are some links in the blog post which I am including here. Since Apple has been silent on this entire dust-upand the general trend has been that Apple's licensing enforcement (both for app content and programming language) is arbitrary, I can't really offer counter-links or even counter-arguments. It also justifies my cheating and just parroting links from the original blog post.

at 5 comments:
Labels: , , , ,

Monday, April 12, 2010

Adobe vs. Apple or Flash vs. HTML5

Any of you watching the recent iPad coverage may already know that the iPad not only does not support Flash, there is no intention on the part of Apple to support Flash. Granted, the iPhone doesn't support Flash, but neither do most other mobile devices. iPhone users had been complaining about this for a while and Apple cited its policy toward acceptance of software from third-party manufacturers as a reason not to expect it ("Why Apple Won't Allow Adobe Flash on iPhone," Wired, Nov. 17, 2008).

With Apple's pitch that the iPad would replace netbooks and slide into the average user's hands as the de facto web surfing platform, hopes were high that the iPad would support Flash. The original iPad promos even showed Flash in use, but those were quietly changed without any acknowledgment from Apple ("Apple Pulls Flash Content From iPad Promos," PCWorld, Jan. 30, 2010).

In the last couple weeks things have heated up even more. Apple modified its iPhone Developer Program License Agreement (part of the iPhone OS SDK) to expand on a section covering how external applications can be developed:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++ or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++ and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

While Flash Player 10.1 is now available (or on its way) for other mobile devices (Android, Symbian, Windows Mobile, webOS and BlackBerry), the iPhone is still not having it. This new language essentially blocks a utility Adobe created to allow Flash developers to convert their Flash projects to the iPhone app format. And that utility still didn't bring Flash support to Safari on the iPhone ("Adobe Announces Flash Support for iPhone (But Only for Apps)," Mashable, Oct. 5, 2009). On the bright side, Adobe is also planning to support exporting to the HTML5 canvas element.

Apple has been quick to point out that anything you can do in Flash can be done in HTML5. Not only is this patently not true (primarily because HTML5 isn't even a finished spec yet — see "Too Soon to Advocate HTML5?" at this blog), the Safari browser doesn't support it all (CSS3 and HTML5 support checklist). Given how many sites use Flash for even basic features like non-critical content or add-on features, the average web surfer on his or her iPhone/iPad will just see blank areas where Flash should appear. Apple is free to limit its support at no cost to itself, but if companies truly want their Flash-specific features to work on an iPhone or iPad, they now have to consider not only how they might technically do that, but how much they are willing to spend to achieve it.

If you've known me or read my posts for long enough, you know I have generally considered Flash to be a usability and accessibility nightmare, primarily because Flash developers have often abandoned best practices and made up their own rules for interaction. And I'll just gloss over search engines by only mentioning them in this sentence, because that's just low-hanging fruit for an anti-Flash rant. But while Flash may not be my ideal method to build things, it's also a de facto standard for many aspects of current web design — animated objects, integrated video, interactivity. Yes, much of this can be done using HTML and JavaScript, but the Flash development environment allows many companies to develop features for their sites at a relatively inexpensive cost and not worry about cross-browser scripting issues.

A handful of companies are already re-orienting their sites or at least their strategies, but these are companies who know they have to target iPhone and iPad users ("Virgin America Ditches Adobe Flash for New Site" at Mashable, March 3, 2010). They are also companies who have the budget to do it. For the rest of us, the best thing we can do is continue to watch the battle between Adobe and Apple and see where it goes. I predict no winner. However, I do see the losers in this battle — end users and smaller organizations who cannot afford a rebuild.

Related News

at 5 comments:
Labels: , , , , , , ,
Subscribe to: Posts (Atom)