Four Kitchens blog

The masses have spoken! Four of the Four Kitchens’ web chefs will be presenting (you guessed it) four sessions at DrupalCon San Francisco 2010! Here’s the low down in case you want to catch any of these talks during the conference.

Day one

On Monday at 5:30pm, Todd and Aaron will present From Photoshop to Drupal Theme. The takeaway from this talk will be stressing the importance of “designing for a system” rather than just focusing on how individual pages look in Drupal.

Day two

On Tuesday we’ll have two sessions. Don’t sleep in after the first night of partying, because at 9:45am you’ll watch to catch Todd’s Accelerated grid theming using NineSixty, an in-depth discussion about grid-based design in Drupal.

Then at 4:15pm, David will be talking about Performance testing The Economist Online using The Grinder, which is an open source Java-based load testing framework.

Day three

And on Wednesday at 3pm, Diana will be presenting PHP for NonProgrammers, a great introduction for those web designers who have only ever touched HTML and CSS.

We are still 62 days away from DrupalCon San Francisco 2010, but in order to get truly excited about the event, you’ll want to start thinking about the amazing sessions you’ll attend. Beginning today, attendees are allowed to vote on those sessions they most want to see on the final schedule in April.

This year, Four Kitchens is both sponsoring DrupalCon San Francisco and offering to share our experience and knowledge with the community. If you’d like to see any of the sessions listed below, please vote! (And tell your co-workers, friends, and pets* to vote, too.)

Pagination is one of the hardest problems for web applications supporting access-control lists (ACLs). Drupal and Pressflow support ACLs through the node access system.

Problems with traditional pagination

• Because pagination uses row offsets into the results, browsing listings where newly published items get added to the beginning of the results creates “page drift.” Page drift is where a user already browsing through paginated results sees, for example, items E, D, and C on page one, waits awhile, clicks to the next page, and sees items C, B, and A. Going back to page one again shows F (newly published), E, and D. Item C “drifted” to page two while the user was reading page one. If new items are published frequently enough, pagination can become unusable due to this drifting effect.
• Even if content and ordering are fully indexed, jumping n rows into the results remains inefficient; it scales linearly with depth into pagination.
• Paginating sets where the content and ordering are not fully indexed is even worse, often to the point of being unusable.
• The design is optimized around visiting arbitrary page offsets, which does not reflect user needs. Users only need to make relative jumps in pagination of up to 10 pages (or so) in either direction or to start from the end of the results. (If users are navigating results by hopping to arbitrary pages to drill down to what they need, there are other flaws in the system.)

The Vancouver Planetarium. Photo by Qole Pejorian.

chx and I gathered last week in Vancouver’s West End for a two-person performance sprint during the final code slush days, allowing us to finish several key improvements to Drupal’s database layer. Right afterward, many more people joined us for another sprint to port key modules to Drupal 7. People worked in-person, voluntarily over IRC, and involuntarily over IRC (lost passport).

I can say — without reservation — that our work was successful. We kicked off the weekend with Drupal 6 versions of Coder and Views. (Though there had been a touch of prior work on the Views port to Drupal 7’s new database layer.)