Twitter github

Category “Software Testing”

If you do testing, you need more monitors.

Here I am at my desk, doing some cross-browser testing.  You’ll notice that I’m surrounded by screens.

three monitors

3!

I’ve been fortunate because I’ve insisted at my testing jobs that I have two or even three monitors and I have never been turned down.

 

Having more monitors leads to better testing because:
More supported browsers are open and easy to compare
More sessions are open so it is easier to see cause and effect problems
I can have more than one or even two or three users signed in with different permission levels.
Even though there are still several browsers open, I can also have some terminals open for grepping through log files and taking notes or logging bugs.

 

In the world of web application testing, this is the difference between noticing something and having it obscured behind too many screens where you will never see it.  In fact, if you have to switch to another tab or swipe to another space on your Mac YOU ARE TOO LATE.  The bugs are gone and laughing at you beneath your fingertips.

 

We live in a time of “do more with less” and, let’s face it, testing is usually where the money dries up.  It is easy to fall into the trap of thinking you will be seen as greedy if you ask for another monitor, but it makes the difference between being a good tester and being a great tester.  If your team really wants you to find all the bugs, they should make it possible for you to SEE THEM.  Believe me, they will crawl across your screens faster than you ever thought possible.

 

How do you ask for more monitors?

 

The three situations I’ve encountered from easiest to hardest (and naming no names):

 

If you see a monitor no one is using, just take it and hook it up.  This is exactly the time to ask forgiveness instead of permission, and the truth is some places really don’t care.  Hook it up, find some bugs and mention it to your boss.  On the positive side, if no one is using the monitor, you’ll be putting a resource to use that would otherwise be wasted.  At the worst, you might have to give it back and endure the “we have an allocation spreadsheet” talk from I.T., but if you can show someone the benefit before it’s taken away, you’ve got your case for more monitors started.

 

Ask in your job interview – when you are negotiating for salary is the time to ask for any special equipment you will require.  Ask for a laptop and not one, but two additional external monitors so that you have a total of three.  If the person on the other end balks, be sure you understand exactly why and be very clear that you will not find as many bugs if they don’t honor your request.

 

Here is a vga to usb adaptor I’ve had success with in the past.  The company seems to update their drivers for Macs more quickly than others vendors.

 

If you work at a place where developers (even developer interns) automatically get two monitors, argue that everyone doing cross-browser testing should get an extra too.  I’ve actually done this before and credit the group I was working with and the boss I was under for taking the argument to his superiors.  In this type of workplace, however, where management isn’t too dear with what they give to developers to get their job done, it only stands to reason that they would want those doing testing to have what they need too.  If you need to make a case, you might want to get some developer collusion going and have one of them test with you for an hour or so.  That’s usually all it takes for people to judge the effectiveness of more browsers.

 

If you work at a place where no one has an additional monitor, it is possible the assumption will be made that you are setting a dangerous precedent which means everyone will want more monitors. Go ahead and laugh but there are places where you will hear this.  If you happen upon this situation, strap on the guns and BE THE WICKED TESTER.

 

If better testing is dangerous, then I wanna go down in flames.

Flaming Skull

Flaming Skull (Photo credit: Tortured Mind Photography)

 

Enhanced by Zemanta

How’s it going with Tracker?

Pivotal Tracker

Pivotal Tracker (Photo credit: Wikipedia)

It has been nearly 3 months since I joined Pivotal Labs and the Pivotal Tracker team.  So far, the experience has been great.  While most of my time is spent writing email replies helping people get to know Tracker, I’ve also done plenty of testing and even committed a tiny fix. In short, I’ve been doing whatever the team needs done and it has all been fun.

 

There is plenty to write about with Tracker.  Aside from selling what I personally think is a great tool for managing software projects, there is how the Tracker team operates.  Obviously, we use the tool we make, but there’s another layer that is firmly grounded in the culture of trust I have found at Pivotal Labs.

 

Starting with this blog post, Tracker on the Agile Continuum, I am working along with my teammates at getting the Tracker Team’s story out.  You might want to follow the Tracker blog because I’m not sure how often I plan to do “content pointers.”  This is because I am more of a fan of having actual content in my posts, and besides, If you like my post, you might like some of my Teammates’ posts as well.

 

There are some phenomenal writers on the Tracker team, and next week, we’ll be welcoming another great writer and tester, Lisa Crispin, to our team.  Tracker’s collaborative energy is ever rising and I hope that by combining the building of an awesome tool with writing about our experiences, we can disseminate even more of that energy.  Working with it every day has been invigorating and I’d like to say thanks to all of my teammates for that.

 

Although the question in the title frames this post of how it’s going for me at Tracker, I’d love to hear about how it’s going for you with Tracker.  If you send an email to tracker at pivotallabs dot com, chances are, I’ll be the one who replies.  Send me your questions, your frustrations and your bugs!!

 

Enhanced by Zemanta

Writing bugs if you are not a tester (or if you are a tester and would like to review)

Software Bugs

Software Bugs (Photo credit: FastJack)

In the past month, I’ve had a few different people who are not testers ask me about filing bugs.  It always makes me happy when people ask me this question, because knowing how to write up a good bug is the first step towards getting it fixed.  The more effectively you write bugs, the closer you will be to getting your problem taken seriously and addressed.  Since computing is now so ubiquitous this goes for everyone from developers interacting to sales and marketing people or even end users interacting with support.

 

Write an effective title

In this day of scanning, bug titles turn into what everyone will look at the most in a bug.  In Tracker, they turn into story titles which is the most visible element of a story.  It’s worth taking extra time to make sure the title is as succinct yet as informationally dense as possible.

 

Take pains to write clear steps to reproduce the problem

While some bugs are worth capturing even if you cannot reproduce them, it always helps the person on the other end to understand your bug if you include clear steps to reproduce.  I make them painfully obvious, for example:

1.  Open the Firefox browser
2.  Open this URL:  <URL would go here>

3. Click on the big red button

If you can identify elements by their CSS class or ID, that is a great way to make things clearer, if not, do your best to describe what you see.

 

Include environment information

Which Browser, which Browser version and which Os?

If you are on a device, the name of the device (Asus Transformer) and operating system version will clarify what hardware you are using when you see the bug.

 

Expected Behavior vs. Actual Behavior

Explain what you thought you would see vs. what actually happened.  Often a feature works as the developer or product manager expected or you have uncovered an area of behavior that was not thought about when the feature was designed and coded.  For this reason, it is important to separate what you expect from what actually happens.

 

Screenshots

It is good to include screenshots if something is noticeably wrong.  Personally, I prefer a carefully written description as it gives me insight into what the author of the bug was thinking.

 

Manage your tone of voice – don’t write mean bugs

It can be easy to sound irate or self-righteous in a bug.  Testers know this.  After you’ve completed writing it up, read for and remove any overly emotional language.  This goes for obvious phrases such as, “THIS MAKES ME WANT TO SLIT MY WRISTS,”  “WTF” or “Really????????” and also more subtle language.  Such language will not get your bug fixed any sooner and will only alienate you from those who can fix the problem.  (I have learned this lesson from experience and have written a few mean bugs in my time.)

 

Don’t assign priority if you can help it

There is a difference between the severity with which a bug impacts your usage of a system versus the priority with which a developer will be able to fix the bug.  While it’s well withing range for you to right about how a bug has impacted the application you are using, you are not the one in charge of the development schedule.

 

Anyone who works on finding and writing better bugs deserves a pat on the back so, here, let me give you a virtual one: <Marlena pats you on the back/>

Enhanced by Zemanta

Webinar with me: Using Firefox Add-ons for testing

As a tester of web applications, I’ve become familiar with how web pages are constructed and rendered through the browser.  Firefox Add-ons provide a great set of tools for doing this and have been a mainstay of my testers toolbox for quite a while.  One of my jobs as a Mozilla employee was to show others how to use some of these addons.

 

Below is a chat I had a while back with a contributor (name anonymized for privacy) about Firebug and Firepath, 2 addons that I use all the time for getting information about the elements, called locators, on a webpage.  We use these all the time in Selenium testing and it is a taste of what I’ll be talking about in a free webinar I’ll be giving for the Software Association of Oregon on Tuesday, May 15 from 12:00pm to 1:00pm.  Registration is free :o)

 

In addition to Firebug and Firepath, I’ll be talking about an add-on developed at Mozilla, Mem Chaser and some browser functionality that started as an add-on but has made its way into the Firefox browser, Tilt.

 

marlenac  Have you used Firebug before?
olivier No i have heard of it
olivier  Its a firefox extension
marlenac  You’ll want to install 2 addons: Firebug and Firepath into firefox
marlenac  I use both of these all the time to help with the locators.  I’m also looking up a good link on CSS for you.
marlenac  This blog post explains some of it and has a bunch of other links for working with Selenium and CSS:  http://blog.reallysimplethoughts.com/2010/10/12/a-quick-introduction-to-css-locators-in-selenium/
olivier How does firebug help with locators?
olivier  Does it generate the expression?
marlenac  It allows you to inspect web pages so you can see what the locators are.
marlenac  If you’ve got it installed, choose an element on a web-page, right click and choose “inspect element”
olivier  Kk
marlenac  As an example, I’m on the homepage for addons: https://addons-dev.allizom.org/en-US/firefox/
marlenac  If I hover the mouse over the big “ADD-ONS”, right click, and choose inspect element
marlenac  It will split the window of the browser and show me the html of the page at the bottom.
olivier  Kk
marlenac  the line starting with “<a title=”Return to the Firefox…” is highlighted.
marlenac  Just above that is a css class “site-title”
olivier  Right
marlenac  If I want to select the link at “ADD-ONS”, the selector will be “.site-title > a”
marlenac  We can check that this is correct with Firepath.
marlenac  In the Firebug pane, there are several tabs at the top.  “HTML”, “CSS” and further over is “Firepath”
olivier  Kk
marlenac  If you paste in “.site-title > a” without the quotes, it will highlight the element for you.
marlenac  It’s pretty great!
olivier  Thx so much u just made my life easier
marlenac  I know!!!!!!  We’d all be suffering without Firebug and Firepath!!
marlenac  A couple of tips.
marlenac  Use .blah to specify a class name
marlenac  Use #blah to specify an id.
marlenac  Use the “>” to get to a child element.
olivier  What if there are many child element?
marlenac  You can keep going with it.
marlenac  or if there is a list, you can use “nth” to specify the 1st, 2nd, 3rd.
marlenac  This post has a great explanation of that:  http://saucelabs.com/blog/index.php/2010/01/selenium-totw-css-selectors-in-selenium-demystified/
marlenac  I’m just finding an example in our code as well.
olivier  I think i get it
marlenac  Cool!
olivier  I will ask i get stuck
olivier  Thx again
marlenac  You’re welcome :)

CSS & Web Performance – Awakening the speed demon

Greyhound in the "roach" sleeping po...

Image via Wikipedia

This post is a wrap-up of some of the things I’ve been learning about performance.  It includes some follow-up from my last post on isolating performance problems with Firebug

One of the comments from my earlier post  suggested that this is also baked into Chrome.  Although I work for Mozilla which means I spend most of my time using Firefox, I have no problem duly noting that Chrome contains some excellent tools for looking at performance as well.   In this post, I’m actually going to show how Chrome can be used to get a sense of front-end performance.  (If you think that Mozilla and Google are adversaries, you might want to have a look at this and this.)

 

Let’s put some definition around front-end and back-end performance.  In my previous post, I was looking at calls going to the back end server and how long those were taking.  That’s back-end performance.  When we talk about front-end performance, we’re concerned with HTML, Javascript and CSS performance.  Admittedly, I knew absolutely nothing about this side of performance before attending an HTML5 conference in September aside from some googling I did which resulted in this guerilla post.  Note that I wrote that post before I saw this talk by Steve Souders, creator of YSlow.  The talk itself was quite an awakening, and afterward, I knew I had lots more homework to do. (This link is to a similar presentation done by Steve at a JS Meetup a week or so later.)

 

After the conference, in addition to hunkering down and learning more about CSS, I started looking through both of Steve’s books, High Performance Web-sites and Even Faster Websites.  Both of these show that there is a lot which can be done for performance on both the front-end and the back-end.  Since he works for Google, there is some cross-pollination of his ideas and the information you get out of  Chrome’s developer tools.  An example of this cross-pollination is Chrome’s ability to do an audit of front-end performance. To get to this functionality, open Chrome, click on the wrench in the top right corner (I hear this is a spanner in the UK) -> tools -> Developer Tools.  This will open the Developer tools, from there, click on the “Audits” tab.  If you are already on the page you want audited, you can select select “load page and refresh browser” to get more accurate results.

 

Here’s a screenshot of an audit for addons.mozilla.org.

A Chrome Audit of Addons

Some of what I noticed in here maps to suggestions in the book, “High Performance Web-Sites.”  For example, one of the suggestions is that some of the components being downloaded need to be gzipped.   This is the same as zipping files so that they are small enough to send through email only in the context of a web-page and http request.  There is a header which can be added to http requests so that the response you get back from the server is zipped.  Who knew!!!

 

Although the Google Chrome Audit will catch some things, there are other suggestions Souders makes that it doesn’t mention.  For example, it’s worth understanding which images on a webpage should be included in a sprite.  Sprites are used to aggregate several images into one.  They are laid out in a grid and are accessed by coordinates.  Here’s an example of a sprite used for the addons.mozilla.org details pages.  If you’d like to see it in action, have a look at this page.  The icons are on the top right where it says, “add to this collection” and “share this addon.”

 

An example of something I plan to question more in the next quarter, is the usage of CSS expressions in addons.  Even though CSS is used to control the layout and style of a page,  it is entirely possible to include “if” statements in CSS via the expression method and the ternary operator.  Rule #9 in “High Performance Websites” advises against using this because the expression will be evaluated when the page is rendered, resized, when the user scrolls or even moves the mouse over the page.  I’d like to understand more about the tradeoffs when I see them used such as here.

 

An early observations about looking at performance is that this is an area awash in tools and it would be easy to just keep trying new tools without digging deeper.  Opening Chrome or Firebug and pointing them at a page is easy enough, but I’m ready to look through some of the front-end code, talk with the devs and begin approaching performance in AMO with more precision.  More to come in the new year…

Enhanced by Zemanta

Isolating a performance bug

English: Firebug's logo Français : Logo de Firebug

Image via Wikipedia

Last week, I isolated a performance problem that started with the failure of an automated test.  I’m blogging it because the bug has an interesting story which highlights some of the weirdness I’ve typically found when isolating performance bugs.

 

A teammate of mine, Alin Trif, noticed one of our automated checks failing.  It writes a review for an add-on. He replicated the failing test manually and wrote up the bug.  Since a few others in our group couldn’t replicate the problem, it was subsequently closed. In true tester fashion, Alin mentioned it to me anyway.  I thought “what could it hurt to try reproducing it.”  So, after opening our staging site, addons-dev.allizom.org, I went through the steps…and reproduced the problem.

 

Note that I did not just re-open the bug.  Personally, I think re-opening bugs is a great way to alienate people who are ready to move on from a particular issue and make testing more irrelevant on your team.  This doesn’t mean dropping the ball on a problem.  It means that it’s time to uncover more or better information which would likely result in a different bug being opened anyway.  If you read to the bottom, you’ll find that this was, indeed, something else entirely.

Two of my favorite web testing tools are Firebug and Skitch.  Although I generally use Firebug for inspecting web pages and finding the locators I need for writing Selenium-Webdriver checks, it will also show metrics for requests and responses.  To access this, open Firebug and click on “net”

Firebug -> Net

In this case, while the request was off in never-never land, I opened Firebug, switched to the net tab and took a snapshot.  When the request eventually finished, I took another snapshot.  This time, the culprit is pretty clear.

 

Although I was testing the addons staging site, the bug is actually for Browser-ID, Mozilla’s new solution for single sign-on.

 

With the screenshot in hand I logged this bug against browser-id.

 

Interesting take aways from this bug:

  • Unless you are actively looking for performance bugs, they are extremely easy to dismiss.  In this case, it looked like it wasn’t reproducible.  These are also easy to miss unless you are hyper-sensitive to slowness.  (Every tester ought to know their physical triggers of impatience for slowness.  Do you tap your fingers and/or roll your eyes and/or cuss at the screen?)
  •  If you’re frustrated about one of your bugs getting closed or marked invalid, it’s time to talk to someone about it vs. only leaving a comment.
  • Using Firebug and your screenshot tool of choice makes it fairly painless to document these bugs.  I’ve caught bugs like this before and ended up installing a third party tool for looking at the time taken for requests and responses.  This is now much easier if you download the Firebug add-on because the tool is right in your browser.

The next time, something “feels slow” or “slower” to you, give this a try.  You might find something you weren’t expecting.

 

Hat tip to Alin Trif for finding the bug and asking about it even after it was initially closed.  That’s good testing.

Enhanced by Zemanta

Anatomy of Switching Selenium from RC to Webdriver

Selenium logo

If you’ve ever wanted to see what it looks like to switch tests from the Selenium-RC api to the Selenium-Webdriver api, this github pull request will give you a very good idea of the changes that have to be made.

 

 

 

 

 

There are a few reasons why these tests are a particularly good example of what happens.

  • We use page objects.  If there’s ever been proof that page objects help ease the pain of refactoring, this would be it.  We made significant changes to our page objects, but the changes made to tests are relatively minor.
  • We have over 100 tests covering many of the areas in addons.mozilla.org.  It’s all open source, so you can see the tests, the website they are testing AND the code of the website they are testing.
  • Our tests are written in python which is a pretty easy language to read and get to know.

A few highlights and bogans:

  • When you’ve got css locators for list items and you are using “nth” you have to bump all of your numbers up by one because rc starts at 0 but webdriver starts at 1.  (Insert expletives here.)
  • When assigning locators, the format changes and makes the flavor of your locator much more obvious than it was in Selenium-RC.  It’s not that the information is COMPLETELY MISSING in Selenium-RC, it just isn’t in my favorite font-type OF ALL TIME. (<3 <3 <3)
  • Instead of using get_css_count, you have to get the list of items instead and test the length.
  • Native events don’t work as well on mac, so we had to set up windows vms in our selenium grid.  This was not a trivial task and deserves it’s own post which I will write if I get over the vm trauma of the past couple of weeks.
  • You can see Webdriver navigating across the different elements of a page which is really freaking cool!
  • You can write tests for hover elements.  We’ve got lots of this in addons at present and Selenium-RC was preventing us from tests that incorporated these.  (Open the diff view and search for “hover!”
  • Instead of working mainly with locators, Selenium-Webdriver uses Web elements.  If you don’t know, these are dom elements and have a bit more meat to them than locators.  Whereas a locator is a string describing a location in a web page, a web element encompasses tags and everything within them.
  • Currently, we have to run the tests sequentially in Firefox even though they can be run concurrently in other browsers.  This is, apparently, not a new problem.  Fortunately, after talking with the Firefox devs, they are working hard on a fix for us which should benefit anyone wanting to run webdriver tests in Firefox.
  • There are lots of lovely methods which can be chained together to mimic user actions.   I know it’s a machine and not a person with a brain running these tests, but personally, I can’t wait to write a mobile test that uses the “double tap” method.  Cue Zombies!!!!

There’s much more to this change, but I’m dog tired and it’s Friday.  Knock yourselves out with that pull request!

Special thanks to the team that wrote all of that code, Teodosia Pop, Florin Strugariu, Zac Campbell with special guest-star appearances made by Dave Hunt.

Enhanced by Zemanta

Zeitgeist

Seal birth 13 (2:32pm) by nutmeg66, on Flickr

Seal birth 13 (2:32pm) by nutmeg66, on Flickr

(If you like to listen to music while you read my posts, I suggest “Violent Dreams” by Crystal Castles.)

 

A couple of weeks ago, I presented at PNSQC on not being a testing asshole.  Although my presentation was the end of a lengthy personal journey for me, there was a moment in the middle of the journey which is preserved in a blog post.

 

You see, I had to find my way through a wall of my own emotional trauma in order to stand up in front of a paying audience and say that IT IS NOT OK TO BE A TESTING ASSHOLE.  We all have moments like this when we reach the bottom of something we feel will be endless.  For me this moment is preserved in my post, “Let’s Destroy the World.”  There’s no way you would know, but I was a weepy mess when I pressed publish on that one as a I was letting go of some really awful things.  I found myself at a bottom.

 

When you’re at the bottom of a tectonic shift happening in your life, it is not uncommon to question.  Where am I? Who am I? Am I going the right way or will I spiral back down again?  I asked myself all of these questions and more as I pressed publish on Let’s Destroy the World.”

Birth of Stars (NASA, Chandra, 10/7/08)

Birth of Stars (NASA, Chandra, 10/7/08)

 

This is the point where you start looking for signs.  I once had a beautiful friend who decided to join a monastery, and for him, the sign was a white rose.

 

For me “the sign” was this year’s announcement of the Google Test Automation Conference, “Test is Dead” which was serendipitously posted  5 days after “Let’s Destroy the World.”  My friend and fellow testing blogger, Chris McMahon called it Zeitgeist.  It should come as no surprise that I will be at GTAC this week.  (Hey attendees…us Mozillians are throwing y’all a party.  I’ll be the girl in the elevator between 7:00 and 8:00, wearing the red leopard print skirt.  ;)  )

 

There is plenty of criticism that can be heaped on those of us writing and presenting on the theme “testing is dead,” but as I wrote in my last post, I feel it as more of a transformation or rebirth.  There are people in this world who have no problem dealing with the messiness, chaos and defying of logic that come with birth and transformation.  I suggest that if you’re so attached to logic that change is inconceivable, you suspend your belief for a few moments and play with what “could be” instead of what you insist upon as “the way.”  Not everything we dream of will remain, but it’s the best way I’ve found of clearing a path into the maze of the unknown.

 

With GTAC, I once more find myself racing into a labryinth of unknowns and uncertainties, but I now know that this is where I live and feel most comfortable.  These are the people I work with, the people I play with and the people who feed my dreams.  You see, I don’t live in the future or the past, but when I look in the mirror I see them.  This week my mirror is GTAC.

 

Hey testers…how soon is now?

 

Apart from the upcoming GTAC, this post was inspired by an interview with William Gibson tweeted by @chris_blain

Stunt Hamster Alert: Elisabeth Hendrickson will be giving a talk at Mozilla next Thursday!

© Quality Tree Software Inc.

There are testers I follow, there are developers I follow…and then there’s Elisabeth Hendrickson.  Aside from being a consultant for agile testing, Elisabeth is the founder of Entaggle.  When it comes to software and building it in a collaborative way, she knows.  When I was getting started in testing, her cheat sheet helped me out many times. (I think everyone in testing must use it at one time or another.)  When I met her at the first Writing About Testing conference I didn’t tell her, but I was in a state of fangirl awe.  Elisabeth is a pragmatic wonderwoman of software as evidenced in posts such as:

 

Testing is a whole team activity.

Agile Backlash? Or Career Wakeup Call?

Specialized Test Management Systems Are an Agile Impediment

Why Test Automation Costs Too Much

 

Next Thursday, October 6 at 12:30 pm (PDT), Mozilla is lucky to have Elisabeth give her talk Lessons learned from 100+ Simulated Agile Transitions which she previously gave at Agile testing days in Berlin.  The talk will be broadcast on air.mozilla.com which means you are also invited.  If you are deliberating whether or not this will be worth an hour of your time, I suggest you read this blog post of hers.  Oh…and then there are the stunt hamsters.  (I’m not joking!!!)

 

By the way, Elisabeth is giving a rare public 3-day class on Agile Testing at Agilistry Studios which includes the word count simulation.  Believe me, if I weren’t giving a talk at PNSQC, I would be going.

 

Update… Fellow tweep @mubbashir put together this world clock for the talk so you can find the time closest to your locale.

Tilt Visualization and CSS Performance

Facebook City

Today, I’m blogging from the HTML5Dev Conference.  The house is packed, and I’m breaking out of my shell as a tester to have a look at all of this from the dev perspective.  Of course, the tester in me has tagged along.  What’s great about conferences in the age of twitter is that you are never in a bubble during these things.  One of my co-workers, Greg Koberger tweeted about some performance testing win for the lastest Firefox release, Firefox 7.

Greg's tweet

In taking a look at the lifehacker article he tweeted, I noticed that there was a category for css performance tests.  Since I spend all day, every day looking at selenium tests that have css locators and I sit next to a css dev (who has excellent taste in rap), css has been on the brain lately.  “Hmm…css peformance…LET’S GOOGLE.”  If you google for css peformance, the first link is for an article titled, Performance Impact of CSS Selectors, by Steve Souders.  Given, the article is talking about Firefox 3.0 so it’s obviously a bit long in the tooth, but it’s interests me for not one, but two reasons:

  1. I’m waiting for the talk “High Performance HTML5″ to begin.  It’s being given by Steve Souders.  (Serendipity or Coincidence?  I shall leave you, dear reader, to ponder.)
  2. The article has a list of different websites and the number of DOM elements in each one.

Since this is a guerilla blog post I’m finishing up as a talk starts, I have no intention of delving deeply into the guts of the article, at the moment.  What I can share, however, is a new Firefox addon I’ve been playing with called Tilt.  The picture you see above is my Facebook page, turned on it’s side in tilt.  Tilt visualizes a web page’s dom elements in 3d and was developed by a Mozilla intern who has recently been hired.  So if we filter the list in the article, Google has the least number of elements while Facebook has the most.  It should be no surprise that the Google home page has had its performance tweaked to oblivion.  Here we can compare the dom of Google visually with the Dom of Face book.

Facebook:

Facebook Tilt

 

Google:

Google tilt

 

I’m definitely forming a hypothesis about the CSS performance of these two pages based on their tilt results.

And that’s your guerilla blog post from the HTML5Dev  Conf.   They really ought to make this thing 2 days next year.  It’s pretty cool.