Monday, June 21st, 2010

From zero-install to instant-install

Category: Editorial

Aaron has a nice editorial piece on going from zero-install to instant-install in which he discusses the notion of web apps:

Bringing back a lightweight notion of installation offers an interesting way out of Web constraints. If an author uses APIs like window.open() and desktop notifications in an annoying way, his app will be uninstalled. The UA can make it easy for the user to discover the uninstall button, so there’s a strong incentive for authors to not be assholes. Since there are a manageable number of apps installed at any one time (by definition, since they were manually installed), UAs can offer permanent storage to apps. If the apps abuse the privilege, the user can easily scan a list, see which one is doing it and uninstall it.

He discusses the revolution of the “zero install” Web. We pass people URLs. We link to things. We don’t think of this as “running apps”. He then brings up the issues of this freedom. Since my mum doesn’t think of this as running apps, we shouldn’t grant access to these URLs, and we end up with a strong sandbox, which limits functionality.

With “installable web apps” we get some of the best of both worlds, but it doesn’t quite feel like we have matched a perfect equilibrium yet. As a power user, I am excited about taking a strong sandboxed model and opening it up with APIs that all go through the sandbox. This means that I can monitor everything that is going on. Add to this social monitoring (so if something bad happens it quickly moves through the social network to be fixed and blocked) and I look forward to a blended world of permissions. We have long had the ability to break through the sandbox in browsers. Unfortunately, these methods are browser specific, and result in annoying prompts that drive you nuts. As we scale out the permissions, this becomes more annoying. To get around this, some platforms are asking the user to accept permission at install time. You have the advantage that: a) the user has to agree before anything is even downloaded; b) one click, at the time of install, and you are off to the races.

However, there are huge problems: When prompted at this time, there is a strong likelihood that the user is trying to do something and will thus say YES YES YES no matter what. Some may question an 8-ball app that asks for deep permissions, but even then…. we run into the same prompty neglect that we get on the desktop. Have you ever downloaded a Mac app, ran it, and then when the “this app came from the Internet” dialog showed up…. said “you know what. Naaaah”? And what about nuance? Weather apps ask for access to the GPS. What if you want to use the app (and search for an area) but don’t want to give location information? Some systems won’t let you download the app (this is where the Web Geolocation API is great!)

Installable == special powers. Uninstalled == less powers. I still have hope that after these first steps we get the right metaphors that offer simplicity for users, but nice fine grained control and awareness.

Posted by Dion Almaer at 5:44 am Comment here

<!-- -->

Monday, June 21st, 2010

Studying perceived performance of Firefox and Chrome

Category: Browsers, Usability

“A man’s got to do what a man’s got to do.” said the cowboy John Wayne. Mozilla’s new intern with the same name knows that Mozilla needs to do… and it needs to do performance. It isn’t just about JavaScript performance though, the battle for the hearts and minds is perceived performance. This is a tough game for Mozilla as the average user giving Chrome a shot is doing so on a fresh browser with no history, bookmarks, or add-ons. If you download a fresh Firefox nightly you may be surprised at how fast it is!

John has been doing some analysis comparing the perceived performance compared to Chrome:

and came up with some recommended actions for the team:

• With just a few changes in the Firefox start-up process, we could greatly enhance the feeling of Firefox’s speed. The changes listed below are recommendations to help better the overall Firefox experience.
• Draw the OS spinner icon as little as possible, but one solid break isn’t bad and might be better than one really long spinner.
• Draw the browser chrome while the window is being animated (drawn) to size. So that most of the drawing happens simultaneously rather than sequentially.
• Make a new ‘website loading’ icon with less visual weight that animates faster but is slightly larger (would allow a user to ‘see’ the faster animation).
• ‘Lazy’ load tabs that are being restored (already being talked about).
• Load upgrades and add-on updates upon browser close, not browser start.
• Delay loading the website’s title until the website is ready for interaction.

Posted by Dion Almaer at 5:21 am 6 Comments

<!-- -->

Sunday, June 20th, 2010

Do LESS with Less.js

Category: CSS, JavaScript

Dmitry Fadeyev has a great writeup of less.js, the implementation of the LESS styling language in JavaScript itself.

Traditionally you would write a less file such as:

and then you would precompile it to some CSS. Not anymore, now you can natively link to the less:

Now less.js will unpack the file and do its thing... making sure that the final CSS will be fully cacheable. Less.js has been written as a CommonJS module so you can run it on the server via node, or in the browser on the fly.

Dmitry answers the perf question (runtime HAS to be slower!), and talks of some cool features:

Wouldn’t live processing lag? Not really. Two reasons for this. One: Less.js has been written from the ground up for great performance, so even browsers with poor JavaScript implementation should still run it very well (Less.js is about 40 times faster than the Ruby implementation—so suffice to say it’s a lot faster.). Two: On modern browsers that support HTML5, Less.js will cache the generated CSS on local storage, making subsequent page loads as fast as pure CSS.

There are other cool features built into Less.js. For example, there’s a “watch” feature available in development mode. This feature will refresh the CSS on your page whenever your .less file is saved with new changes. The best thing is, it won’t refresh the whole page, just the right bits of CSS, live.

Less is certainly more. Even though it is tough to make the performance trade off in production, for development, and for the ability to use less for applications that don't have a server (e.g. I am excited to use this in webOS and mobile Web apps in general! ;) is palpitating. Sencha Touch uses the step cousin, SASS.

Posted by Dion Almaer at 7:02 am 13 Comments

<!-- -->