That’s where Custom Write Panels come in: they let you create slick-looking panels that allow users to enter all the additional information you want for a post.

These ‘can help you leverage the power of WordPress 3.0′s custom post types to even greater effect. (And I) show you how to wield them, so your clients will see you as a true WordPress wizard.

To have a read, check it out.

In any web page, the order that your browser downloads your content is simple: it retrieves the HTML, which tells it the other files to request from your server, while your CSS provides all the styling to make it display as needed.

Improving front-end performance is shown to have an impact on overall conversion, including click-through rates, average time on site, sales, and even Google rankings.

Have a read. I think I’ve covered some interesting points.

A web page will make many requests. The first is for the HTML of the page you’re viewing. From that, your browser will request more resources to display the page. A single request has two phases: your browser asks for a file–be it an image, a CSS file, or a JavaScript file–and waits to hear back; then it downloads what the browser sends. Therefore, there are two optimizations that can be made: by decreasing the number of requests, you reduce the amount of time the browser spends waiting to hear back from the server; and by limiting the file sizes of the objects being requested, your browser downloads less information to display a page.

An overview of the posts to come, so have a read, but I delve into the nature of requests (and how browsers handle them), and optimising CSS/JS/Images.

With the latest incarnation of the Adobe Suite, Illustrator CS5 brings a slew of new features and improvements to one of my favorite apps.

Thankfully, Adobe has considered what worked and, more importantly, what did not: the main feature additions center on actual drawing.

Have a read

Early designs; I started to work out the heirachy of information presented...

After a few versions of working and reworking the UI for the Hudson Global Dashboard, I quickly realised that it needed a rethink of how the UI elements were displayed.

The primary problem was priority: not every element of a build is as important to the others, and not every build as whole to the other builds.

After discussing it with my peers (the people who, ultimately, would be using it), I discovered that they were interested in achieving different goals than I originally anticipated.

• The title was the most important thing. Full stop. Also, it should be able to be read across the room (whilst being displayed on a 19″ monitor.
• The health of a build. Is it passing? And if not, how long for?
• Everything else is secondary.

I tried using the alignment to display health. Aligning right meant everything was all right...

I had the original breakdown of elements like this: a build could be green, blue or red (passing, testing, or failing respectively). This was the background colour. The stats of a build (it’s health over the last five builds, it’s IP address, it’s description) were displayed very small across the bottom of a build for those interested, but it wasn’t important to the passer by. Every build was the same size, and the builds as a whole expanded to fill the screen.

This worked, I guess, as it’s users could, at a glance whilst walking around the office, know which builds were failing.

Surely there had to be, however, a better way to mix elements of the build with it’s appearance. So I started looking.

Infographics are awesome things; they let a casual viewer glance at immense amounts of information, and immediately take in some information without having to read lots of text.

So what is really important when it comes to builds? I figured out, in descending order:

1. Which build?
2. Is that build passing?
3. How healthy has that build been?
4. Everything else: the IP address, it’s description, etc…

Which build?

This one is easy to tackle. The title. It has to be big, so it can be read across the room from a small monitor, so much larger font size than everything else. Also, colour schemes have to be contrast-y enough so it doesn’t blend.

Is that build passing?

Also easy to tackle. Colour. I decided a simple red – green – blue scheme, with it getting progressively less luminance as the importance of details decrease; A failing build is red, with the brightest red for the title, and less bright for the details as they go down in relevance.

How healthy has that build been?

I found a nice grid structure shows health nicely.

I had a bit of fun with a build’s health. I do show the build’s health in text (although it is of less importance to if the build is passing right now…), but instead had a think of what the health of a build actually means to the end user (a developer, or a business unit guy, etc…).

If a build isn’t healthy; as in, it hasn’t been consistently passing for a number of progressive builds, then there a problems that need addressing.

Be it lax attitudes of the developer’s part (committing untested code… naughty naughty), or problems with environment consistency (tests pass locally, but fail on the CI machine, or vice-versa), or fragile tests (those that need to be run in a certain order, or fail one-in-every-x-number-of-times), this is the stuff that directly impacts and hampers development velocity.

Hence, size. The larger a build (and hence, less healthy), the more devs and business units are going to be concerned with it. If it is getting larger, then that build needs an investment of time and energy to get it back on track. Hudson’s JSON API lovingly provides a description of a build’s health, in percentage (it is really out of five; 0 means a build has failed all of the last five runs, 1 means one of the last five, etc…)

So we ended up with some really large, red builds indicating neglect (as we have Hudson set to run a build every now and again; I think it runs them daily if no pushes occur). You can also have a moderately large green build (as it has finally passed a run!), but with luck (and work to keep it so) the build will decrease in size and stay green.

Ideally, you want small, green builds. If they are all small, the problems you have keeping them so is small. If you have big, red builds, then you have large problems.

But where it works is when you have multiple teams (or pairs, depending on your structure) showing multiple build sets. In this case, you’ll probably get a mix of healthy (small, green) builds interspersed with builds in need of some love (big and red). This I think would be especially useful for project managers; they can see what builds are in trouble, and send in those who are better at testing to help out and upskill. I’ve found in the teams that you’ll have one or two testing gurus, who can make tests sing and fix those pesky environment problem.

Caveats

Naturally, there are caveats. Some builds are just old and haven’t been removed. These naturally will decay over time and as their dependencies are altered, removed or decay themselves these builds will go red and get larger. I’ll be building in a selection option so you can opt out of displaying these builds when the time comes to cull them, without necessarily having to remove them from your Hudson builds.

Also, sometimes builds will go through rough patches… A flurry of commits to try and sort out a build may temporarily make it look a problem, but then get sorted within a few days. Keeping the business units calm during these periods would, hence, be necessary.

Environment problems are just a pain. They crop up from time to time, and can plague builds for ages until they are sorted, if at all.

How was it built?

I’d already rebuilt it on Padrino, so using that I reworked the templates to give it a semantic HTML5 layout.

I’ve been playing with David DeSandro‘s JQuery Masonry, which lets you build stronger grid layouts by absolutely positioning around floated objects. Have a look; this guy is a genius…

Colour scheme is a combination of four or five Adobe Kuler sets; ever a great combination of colour palettes for a designer.

Where to?

So it’s mostly done. Of course, it’s a prototype, and I’ve written no tests around the app that handles testing (I know! Horror!).

Depending on commitments, I’d like to rewrite it, and clean it up where I had a bit of code smell.

Also, I started to write in a TramTracker block that fits in the layout, so you can see when the next trams outside the office are coming. Of course, some of the guys I work with suggested not showing this block until every build is green…

…

I thought of that, but then we’d never get to go home.

We created median price graphs, using FLOT, a JavaScript JQuery plotting tool. It’s very customisable, and allows for awesome, interactive mapping of data. These were shown inside a custom JS tab block. FLOT by default wants JavaScript arrays jammed in page, which is fine, but for accessibility reasons we built a table reader into the initialisation that reads a table of the data, and builds a graph in a corresponding sibling element. FLOT out of the box allows for customisation of colours, and drops tooltips in for you.
To get the appropriate formatting of data (so the graph knows the difference between numerical and financial amounts), we had to create custom initialisations for the differing blocks by a mix of class names and our own DOM walker, that traverses the DOM finding named elements and adding the JS to them.

Using a combination of our own stats and the stats platform we use (in regards to the number of users hitting the properties in that suburb), against the number of properties available in that suburb, we created our Supply & Demand graphs. These graphs were well received by our users as they could see, at a glance, how competitive the suburb in question is. Also attached to this block (by the tab block) is an interest rate graph. This (although primarily an ad) shows Standard Variable Rate (from the major lenders) against the Reserve Bank of Australia Cash Rate, all in the custom colours of whomever had bought the rights to that block. At the larger sites, it is often hard to create new advertising ideas (due to a desire to travel the safe, well-worn roads), but by using supported content we could find a happy medium; something users will use, and raise brand awareness at the same time.

In it’s full glory, the page offers in-depth information on any given suburb. It has surpassed both usage expectations and ROI, and has made me a little proud to see it get out the door and into the wild.

From it’s inception, it was designed to work across a diverse range of mobile devices, progressively enhancing to adapt to any device. It (on the iPhone) asynchronously loaded properties straight from the results list, reducing the amount of page load and making for an significantly improved fluid search, rather than the “click-on-property, reload-page, back, repeat” users saw on their desktop.

The smaller screen offered challenges to how to best use the available space to it’s maximum, yet remain uncluttered. Key learnings from this were:

• Don’t try and remake your whole site, with every feature, on a mobile. Do what people need, and what people need on a mobile is different to what they need on a desktop.
• Different users use a mobile to a full site. We found much higher ratios of (mostly likely) younger people were using the mobile site, and the difference of search for Buy verses Rent was much closer on the mobile site rather than the full site (which saw Buy searches having the majority).
• If you are going to do browser detection, do it right. We had a simple regex-based solution initially, and it worked well for a while. As soon as you want to fix things for individual devices (especially those used by the business leaders of the business, heheh), without a more robust solution it is hard. However, the trade off is more work up front implementing a solution that is scalable. We found some Apache level ones, but there are lots of options available.
• Optimise the hell out of images. We found that the same images, uncompressed from the data centres, could add ~200kb to a page of twenty property listings. Jam those down to JPGs, and up the compression. For desktop, you want to sit around 80% quality, but on a mobile, especially for thumbnails, 20% seemed to work fine for us!
• Really simple, good, semantic HTML is key. Browsers (I’m looking at you, BlackBerry) on the older phones just don’t support all of HTML, or CSS on certain elements. And it can be hard to debug why. Write simple code, and whole bunches of problems just go away.

As my original mobile site has now been replaced with a new one, leveraging a newer platform, I’m happy to show it here. My pet project has grown up and left the coup, and hopefully will take a life on its own. Check out the new one at m.realestate.com.au.

Step definitions are the bridge between human readable tests and actual tests that cucumber can understand.

Essentially, step definitions can be broken into two parts:

• The regex part, where the human readable test can be match appropriately to a step.
• The actual tests, where actions are taken or assertions are made.

I’m just going to jump right in, and explain line by line. Here is an example of the step definition for a given step, which is testing the navigation to a group of pages.

1
2
3
4
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

  visit 'http://www.example.com/' + state.downcase

end

It seems that there is quite a lot going on, but it’s really not too bad.

1
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

This is the regex part of the step. It is matching on any step that contains the string ‘the buyer is on the “some state” state search page’.

The ([^\"]*) in the middle will match any terms between ‘the buyer is on the ‘ and ‘ state search page’. Now, when used with ‘do |state|’, it will take whatever the term inside the regexed string and make it available as a variable. So, if in the feature file the step read:

Given the buyer is on the VIC state search page

It would match the step definition, and the variable ‘state’ would equal “VIC”.

1
2
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

Now, knowing what state equals, we do some work with the string. If it’s more than three characters (in this example), we match it against a list of state names to find out what we meant. This is so we can enter both VIC and Victoria as strings.

1
2
3
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

  visit 'http://www.example.com/' + state.downcase

This is what given steps will usually do. Given steps (depending on the project) usually do one of two things: having users at pages, and setting up DBs or previous things that are assumed to have happened before the test begins (such as creating users, setting permissions, etc). This step goes to the page using the visit method.

1
2
3
4
Given /^the buyer is on the "([^\"]*)" state search page$/ do |state|

  state = state.length > 3 ? State::AUSTRALIAN_STATE_NAMES.index(state) : state

  visit 'http://www.example.com/' + state.downcase

end

And finally, the ‘end’ ending the step definition.

As you can see, this is where the human readable part of a feature meets actual code doing some tests.

‘Then’ steps are where you can see some assertions happening. All assertions happen in the steps; there shouldn’t be any assertions anywhere else (mainly, keep them out of the page model).

1
2
3
4
5
Then /^the "([^\"]*)" link will have a new icon$/ do |link|

  on_page_with :sub_navigation do |page|

    page.sub_navigation_item.url.should eql link

  end

end

The on_page_with method calls the page model, which we will go into later. For now, we set up methods against the page. The next line is what we are interested in:

1
    page.sub_navigation_item.url.should eql link

The page has a method called sub_navigation_item, which in the page model has a css selector to find the list (inside a li inside an ul) in question, and checks it has a url from the link passed in via the feature.

Tests will grow in complexity, and this is okay, but always strive to make your tests as simple as possible, and as readable as possible. When an assertion can be written as:

page.sub_navigation_item.url.should eql link

and read as “the page subnavigation item has a url that equals this link”

Since we build on Rails, automated testing is handled using cucumber. The tests are split into two main parts: features, which are the human readable tests, and the step definitions, which are the actual tests, converting the human readable parts into ruby so we can actually make assertions against what we are testing. The page model also gets mixed in, but I’ll get to that.

I’ll only go into features for now; I’ll get to the step definitions and page model work later.

It is, however, very easy to start making mistakes when writing tests that makes life later much harder, especially when it comes to refactoring time (either for manipulating features, or speeding up a build).

Features

• The features are meant to be as easily read as possible.
• Though it can be great to re-use existing features (especially around when setting conditions to go to a page), you really shouldn’t trade readability for ease of testing. Try and find a happy compromise, or rewrite the existing tests to make them more generic (where appropriate). Be careful, though, to not prematurely over-generalise tests, as they make it a really hard slog later.
• The features should be able to be read, and understood, by non-techs. Business / Product owners and business analysts, as well as QA, should really know what’s going on when they’ve read them.
• Basically, they should be based on the feature cards created by business stakeholders / experts.

They are broken into three (and a third) parts.

Given steps

• Given steps are used only when there are things that have to have happened prior to the test. There are no actual assertions in these (so nothing actually gets tested), and page models shouldn’t be involved yet.

1
Given articles have been written by an editor

When steps

• When steps also have no assertions. They are for when a user (or equivalent) performs an action against the page. Clicking links, opening menus, or performing searches are all When step material.
• Also, When steps start to have actions against the page model (explained below).

1
When the user clicks on the "delete post" button

Then steps

• Then steps are the assertions. Something has happened (be it a page load, or a link clicked, etc), and hence, there is a test against it. It is oft best to only test one thing per step, but there are exceptions, and my personal preference is to test one element at a time, so when I test a link, for example, I’ll usually test the href, the title, and any rel attributes as well as the anchor text.
• Then steps also have actions against the page model (explained below).

1
Then the user will see the post has been deleted from the list

And steps

• And steps aren’t steps in their own right, but they perform the same type of step as the previous one. It lets you chain up a series of user interactions, or assertions.

1
2
And the user will see the post flash to alert the user it has been deleted

And the user will see the post displaying the "Deleted" text

Put it all together, and you get a nice test.

1
2
3
4
5
Given articles have been written by an editor

When the user clicks on the "delete post" button

Then the user will see the post has been deleted from the list

And the user will see the post flash to alert the user it has been deleted

And the user will see the post displaying the "Deleted" text

In conclusion

I hope that makes some sense. The cleaner you write your tests, the easier life comes later. In conclusion, one simple rule to live by:

Write your test as simply as possible, so it’s meaning is clear and someone else (who isn’t developing the project) can understand what’s going on.

I’ll get through the other parts of writing tests (the step definitions and the page model) soon.

Many people love the simplicity and expressiveness of Sinatra but quickly come to miss a great deal of functionality provided by other web frameworks such as Rails when building non-trivial applications.

Our goal with Padrino is to stay true to the core principles of Sinatra while at the same time creating a standard library of tools, helpers and functions that will make Sinatra suitable for increasingly complex applications.

Relatively quickly, after writing the first versions of the Hudson Global Dashboard using Sinatra, it started to get a little too big for it’s boots.

Sinatra quickly let me get something out there; I could handle the routes, and perform simple tasks to display the appropriate JSON feeds in a meaningful way. But there were features I wanted; features that, should I add them, would mean probably pushing Sinatra beyond what it was meant for.

Enter Padrino. Luke Cunningham (a rubyist and UI guy of equal measure) put me onto it, and helped me through getting the hang of how things are put together with it.

It’s the next step when your app grows too large for Sinatra. My main requirement was wanting an admin panel, so users could add Hudson servers willy-nilly, and not have to hard-code them.

Padrino is the step up from Sinatra, and a step below the complexity of a full Ruby on Rails stack. And I’m a bit of a fan. It’s really easy to bolt new sections onto, yet still letting you hit the ground running. Give it a try.