Tech
OS X to Fedora 20: The User Experience, Pt. 2
OS X to Fedora 20: The User Experience, Pt. 1
A little background here: I have been a Mac enthusiast for a number of years now. I would not say that I am religious about OS X, but if the OS X user experience is a philosophical application of “[opinionated][1] [software][2]”, then I find myself in agreement with most of the opinions that the Apple UX team has expressed.
However, I am also an open source developer. I’d like to believe that it is possible to create a similar and possibly even superior experience with a Linux-based desktop environment. And lo, this is what lead me, a few weeks ago, to get Fedora 20 running on a MacBook Air. If you’re interested in trying the same thing, check out Matt Hicks’ [invaluable blog post][3] on setting things up.
Over a series of blog posts I am digging into my impressions of the Fedora 20 user experience as I work through this total switch-over.
How not to optimize a site with AJAX
I’ve inherited a project that is seeing some performance issues. We knew this was at least partly to blame on the UI, but most of the problem is down in the application. Fine; we’ve got a plan for the application-level issue and that’ll get solved. But right now, I’ve been picking through the UI because even though inspection with FireBug reveals that the site is loading at a reasonable clip, it doesnt seem to be rendering the main page until every last linked resource is loaded in the browser.
As the subject of this post should indicate, this project features AJAX. AJAX isn’t exactly brand new, but this project represents the first aggressive use of AJAX in my particular custom-projects corner of the universe. And as far as I can tell, once the decision was made to “go AJAX!”, a side directive of “abandon sanity!” was also put in motion.
Heres what’s great about AJAX: You load the static elements of your page once, and then you refresh the dynamic stuff with a behind-the-scenes request that leaves the static page elements unchanged. In other words, it makes a web page behave more like a locally installed application. But let’s say you’ve just learned about AJAX and you want to GO the DISTANCE! Then, even though the static page elements should never change, maybe you dynamically request them, too! And then use JavaScript to discretely rewrite the whole page! In your zero-latency development environment, the difference in rendering time may be completely undetectable. Unfortunately, when half a planet’s worth of internet lies between you and the server, the effect is pretty different.
Your AJAX request is an extra layer of abstraction that just linking static elements from the page itself will completely avoid. And, because the associated rendering may not be possible until after you’ve finished loading all of the AJAX-related JavaScript resources, you leave your users staring at the bare rafters of your web site until the loading is done.
Moral of the story: identify static page elements and keep them out of your AJAX scheme. If you really want to do the whole thing in AJAX, at least give the user a meaningful static site to look at while all of the background requests are churning. They might stay on your site long enough to see what you’ve cooked up..
Sunrocket'd
When does a resume become a C.V.?
When you publish something! And let me tell you, its a page-turner. Oh well; you gotta start somewhere :-)