Engineered Web

Visualize Your Page Size with Browser Size

Matt — Fri, 05 Mar 2010 16:39:49 +0000

I was recently asked to review the look and feel of a website for someone. When I first looked at the site I was surprised at how wide the content region was. Sitting at close to 1200 pixels wide I thought to myself, there's the first red flag. But, when I pointed it out to the site developer he didn't think the width was a problem. After talking to him for a few minutes I discovered that he was under the impression this was now an acceptable resolution to use.

He was under a false impression. But, how do you show someone they are wrong? Browser Size is a tool that can help do just that. It takes a look at page size and shows you what percentage of browser users can view how much of the page.

If we take a look at 1200 pixels we see that only 50% of those surfing the web can view that width without having to horizontally scroll. Yikes!

There are exceptions where 1200 pixels might be appropriate. An internal organization web application where the organization controls all the monitors is one example. The web at large is just not a place for that.

Showdown: Blueprint vs. the 960 Grid

Matt — Thu, 04 Mar 2010 12:46:56 +0000

I've head a lot of great things about using CSS frameworks in site builds. Two of the more popular options I'm interested in are Blueprint and 960. When I tried to find a good comparison between the two I found, for the most part, opinion pieces on why one was better than the other. I couldn't find a detailed enough analysis to feed my need. What is an inquiring engineer to do? I did the analysis myself.

Introducing 960

960 is what its name implies. It is a 960 pixel wide grid. The grid has 940 pixels of space for content and 10 pixel gutters on the right and left. The 10 pixel gutter on the left is very important. When a browser window is smaller than 960 pixels there is a gutter between the edge of the browser window and the content making it more readable than if the content went right to the windows edge.

Included in 960 is a 12-column grid with 60 pixel wide columns and a 16-column grid with 40 pixel wide columns. Each column has 10 pixels of space on the right and left creating 20 pixel gutters between each column. If you like even more columns, included in 960 is a 24-column layout with 30 pixel wide columns with 5 pixels of space on the right and left making 10 pixel gutters.

960 pixels is used because it makes for pretty math. All of the numbers listed here are clean numbers. Nothing ends in a decimal that a browser would try to round. Additionally, a 12-column grid is nicely divided up for the golden ratio.

Sometimes a 960 grid is not what a project calls for. For those times there is a grid generator based on 960. The number of columns, column width, and gutter width are all configurable. Once you have something your comfortable with (there is a live preview) you can download CSS generated from it.

960, also, includes a reset stylesheet from Eric Meyer and a basic typography stylesheet. 960 doesn't handle typography. This is the basics for rapid prototyping. As Nathan Smith, the developer of 960 puts it,

One of the glaring omissions, or nice features, depending on how you look at it, is the way the 960 handles (or doesn’t) typography. There is a text.css file included, but this is mainly to ensure that there is at least a something in place, so that as you do rapid prototyping, common elements such as headings, paragraphs and lists have basic styling.

Nathan Smith is the developer of 960. This project is, for the most part, a one man show. Some features have come from others, like the push_XX and pull_XX classes that enable source reordering.

Along with the grid there are templates for all the major design programs and a printable pdf with the grid for sketching. The 960 grid is dual licensed using the GPL and MIT licenses.

Introducing Blueprint

The Blueprint grid is a 950 pixel wide grid with 24 columns. Each column is 30 pixels wide with a 10 pixel gutter. The 10 pixel gutter is on the right side of each column. This grid, also, nicely works with the golden ratio and in 950 everything ends in nice round numbers.

If a 950 pixel grid isn't right for you, included with Blueprint is a Ruby script that can generate different grid sizes. Don't worry if you don't know Ruby. There are detailed instructions and it works like other command line applications. If you are looking for web based generators you need to look no further than the community of developers around 950.

The grid provides source reordering with push, pull, append, and prepend classes. This is handy when you want to have your source in one order for good SEO and your presentation in a different visual order.

Like the 960 grid reset, Blueprint provides a reset stylesheet based on the work by Eric Meyer.

This is where the similarities between 960 and Blueprint end. Blueprint goes beyond a grid to provide much more. Some of the additional elements in Blueprint include:

Typography - Provides typography size and spacing defaults.
Form Styling - Default styling for forms and some classes that can be used to add to forms.
Print Styles - Print styles are important and often overlooked.
Plugins - CSS (and sometimes images) for buttons, tabs, and sprites.

A PSD template is available for Blueprint from the Blueprint repo. If you go beyond the Blueprint repo there are generators for CSS files with different dimensions and templates for other tools from the community of Blueprint users.

Blueprint is the work of a team. The original creator has handed Blueprint off to two admins and several contributors. Much of the CSS used comes from the work of big names in the design community.

Blueprint is distributed under the GPL and a modified MIT license.

My Notes

While reading through the sites, looking for the similarities and differences, and seeing what I liked or disliked about these two frameworks I took some notes that some may find useful.

Blueprint content butts up to the browser window on the left when the window is smaller than the content area. This can cause problems for readability of content. A designer can add a gutter to the left side of the content to account for this. I tested several sites and often found the text butted up to the left side of the window.
In most of the designs I work with the designer has chosen the typography, look of the forms, and other visual elements. A framework that provides these is not useful when a designer is customizing the look for the branding of the site or the organizations branding is dictating parts of the design.
If someone is not a designer but is throwing a design together the defaults provided by Blueprint would be very handy. There are far to many ugly developer sites because of bad defaults.
I don't really like the gutter all being on one side of the column in Blueprint. It feels unbalanced. Like a person who has short hair on the right side of their head and long hair on the other. Maybe it's just me but it doesn't feel right.

Conclusion

Blueprint and 960 are very different setups. They offer different features and have a different purpose. Picking between them is more a matter of preference. The approaches are just different. 960 is additive. It provides a grid and the design elements are added to your CSS. Blueprint is subtractive. It provides a lot of functionality. If you want to go a different route you need to subtract or override what you don't want from Blueprint.

Both solutions are solid, well tested, and well used. With either choice you aren't going to go wrong.

More Git GUIs

Matt — Tue, 02 Mar 2010 17:04:46 +0000

After posting about SmartGit in a recent post I was contacted about numerous other Git GUI programs. While I think SmartGit is the best all around solution for your average users there are other programs for Git GUI users to consider. The nice part of these programs is that they are free for commercial use.

Git GUI

Git GUI is included with a git installation. From the command line you can type git gui to start it up. Git GUI provides most of what you need to work in Git.

Why didn't I recommend this previously? I don't believe Git GUI is very intuitive. If someone isn't familiar with the intricacies of Git it can be easy to get lost in the interface. So, for your average user I wouldn't make it my first choice.

Two notices for Mac users:

If you are on a Mac and would like to open a project right into Git GUI there is a Droplet for that.
If you are on OS X Leopard you may get an error about a missing framework. To use it you'll need to install the framework.

TortoiseGit

If you are a windows user familiar with TortoiseSVN or any of the other Tortoise version control interfaces than TortoiseGit may be for you.

Since I am no longer a Windows user (except for some Internet Explorer testing) I cannot really provide a review. I hear good things about it and it expect to be in the same line as many of the other Tortoise applications.

GitX

GitX, a mac application, is not like the other GUIs I've written about. The other GUIs provide the base features your average user can use. GitX doesn't provide those. GitX lets you visualize the source tree, see diffs, and visualize where a project repo is at. You can't commit, checkout, or do other basic commands in GitX.

For what GitX does, it does it well.

While I have shared these other tools I still believe SmartGit is the best option for average users at this point.

Pluggable Entity Operations in Drupal 7

Matt — Mon, 01 Mar 2010 13:38:06 +0000

In Drupal 7 core all the common objects, like nodes, users, comments, and terms, are called entities. Entities are a base level conceptual object designed to be used as a base for objects in core and contrib. But, there is a problem with the core entity pattern we can improve on in our contrib modules.

Entities have a controller used for their loading operations. The controller is a class that can be swapped out for alternative controllers when developers want to do something fancy, like have their own node caching setup. But, only the load operation is on the controller. The other CRUD (create, read, and delete) are hard coded in functions like node_load, node_save, and other object operations. The CRUD control for entities can't be completely swapped out. Let's take a look at a base pattern to use for completely swappable controllers.

Why a completely swappable controller?

There are several reasons to provide a fully swappable controller. There are different use cases that are important to different developers. Let's look at a reason that is becoming fairly common.

Alternative databases are becoming all the rage. MongoDB and Drupal are already on their way to being used together where they can. Some developers will want to store entities in alternative locations like a MongoDB database. To do this all of the CRUD operations need to be swapped out.

The Pattern

Lets look at a code example to see how completely swappable CRUD would work. We start by looking at hook_entity_info where the controller is defined

/**
 * Implements hook_entity_info().
 */
function example_entity_info() {
  $return =  array(
    'example' => array(
      'label' => t('Example Entity'),
      'controller class' => 'ExampleEntityController',
      'base table' => 'example_entity',
      'fieldable' => TRUE,
      'path callback' => 'example_entity_path',
      'object keys' => array(
        'id' => 'id',
      ),
      ...
    ),
  );
  return $return;
}

Here we create a basic entity called example and specify ExampleEntityController as the controller. We cannot specify the default controller provided by core because it only has the load operation. But, we can extend the default controller allowing us to use everything it has and add our own additional methods.

class ExampleEntityController extends DrupalDefaultEntityController {
 
  public function save($entity) {
    ...
  }
 
  public function delete($entity_ids) {
    ...
  }
 
  public function create() {
    ...
  }
}

The pattern in Drupal is to have functions for the CRUD operations. For example, node has node_load, node_save, and node_delete. In keeping form with these we should create example_load, example_load_multiple, example_save, example_delete, and example_create functions that call back to the controller. For the most part these functions should be pretty simple. For example,

function example_save($entity) {
  return entity_get_controller('example')->save($entity);
}

Calling entity_get_controller('example') returns the controller for that entity. In this case we call the save method and pass in the entity object to be saved. The idea is that the crud functions simply pass though the functionality to the controller.

Why not Entity Module?

The Entity Module is attempting to provide a base to do something like this and more. But, it does a lot more than provide a pattern for swappable operations. It introduces Entity objects, the facade pattern, and more. At this point I'm not ready to recommend its approach.

How we go about advancing entities beyond pluggable operations still seems to be under a bit of healthy debate. This post shows the first step in a better direction. There will be more to follow as the healthy discussion turns into solid approaches.

Farbtastic 1.3u

Matt — Fri, 26 Feb 2010 16:16:56 +0000

Farbtastic 1.2 was released years ago. In that time jQuery has changed creating a need for farbtastic to change as well. For example, internal logic in farbtastic was calculating the offset but changes in jQuery caused it to not calculate it accurately in all cases. Switching to the jQuery.offset method, which was added after the release of farbtastic 1.2, fixed the problem.

So, when I recently moved Farbtastic over to GitHub to continue development I created a tag called 1.3u (the u stands for unofficial) containing updates that were already being using in production sites.

The complete list of changes, from the changelog are:

Updated style to use anonymous function wrapper per http://docs.jquery.com/Plugins/Authoring#Custom_Alias.
Now it uses the .offset() method available as of jQuery 1.2.x.
Works with JavaScript aggregators and compressors.

Downloads are available by tag on Github.

SmartGit - The Best Git Gui So Far

Matt — Wed, 24 Feb 2010 12:41:40 +0000

As Git becomes more popular and widely used a GUI becomes even more important. This was especially important when Drupal recently looked at what version control system it was going to switch to. (If you're interested in the Drupal (unofficial) decision checkout Angie Byrons post on groups.drupal.org)

When I surveyed the Git GUI landscape SmartGit stood above the rest for your standard user.

For Your Average User

Git is an extremely powerful program. Powerful enough that there is a manual called Git for Computer Scientists which dives in really deep. There are advanced features within Git that I can't imagine how to build a GUI for.

That being said, the common features that most of us use can be easily encapsulated in a GUI and SmartGit does just that. For a typical user, including front end developers, weekend warriors, and anyone who just doesn't need the advanced abilities, you have access to it with SmartGit.

And, since it was written in Java it runs on Macs, Windows, and Linux.

GitHub Integration

The most popular site for public Git repos is Github. The interface is slick, the documentation is easy to understand, and it just works. This is where projects like jQuery and TinyMCE are hosted.

SmartGit provides integration with Github.

If you've provided your Github login information into SmartGit clicking on "Select from Github..." will bring up the list of projects you have on Github and let you clone them to your local system to work on them.

Paying For Commercial Use

SmartGit is not an open source project and it is not free for anyone to use. It's free for non-commercial use but, for commercial use you need to pay for a license.

If you want a GUI for commercial use but are looking to only use Open Source or free software there are alternatives. For your average user none of them is as nice.

I've had the chance to use several Git GUIs. Many of them are great at what they do but are not right for your typical user. SmartGit hits that sweet spot.

Building Your Own Git Server

Matt — Tue, 23 Feb 2010 12:13:54 +0000

Many of the projects I work on are not appropriate for public version control systems like Github or Sourceforge. They might be client projects or code I am tinkering with but am not sure what I'll eventually do with. In these cases it's good to have a private version control site. Since I am now a Git user that server needs to be Git based. Luckily there are a couple great choices.

The two prime candidates for personal Git servers are gitosis and gitolite. Where they differ is in the launguage they are written in and how they handle repo permissions.

Gitosis

Gitosis has been around longer than Gitolite but has fewer access controls.

Permissions are handled on a per repo basis. Each user has their public ssh key stored in gitosis config. Then each repo has a list of users associated with it. These users can read and write to the repo. It's that simple.

Additionally, individual repos can be set to allow anonymous user checkouts.

If you don't have complex access rules Gitosis may be great for you.

Gitolite

Gitolite started out as a souped up version of Gitosis. The original goal was to add per branch permissions. From there it changed languages and grew into something with more features with more fine grained permissions.

If you have complex access rules Gitolite might be more up your alley.

Gitweb

Gitweb is the de-facto standard web GUI for git. So much so that it is now included in the Git source code. Gitweb is a perl script enabling you to view the repos on a server.

Both Gitosis and Gitolite integrate with Gitweb. For example, you can tell Gitweb to only display the public repos and the ones that anonymous users can't access are not displayed.

Switching to Git

Matt — Mon, 22 Feb 2010 16:57:52 +0000

I recently switched to Git to manage the source code for projects I work on. I still use CVS to manage Drupal modules on drupal.org and SVN for many client projects. But, when I have a choice I choose Git.

Git, for those of you who don't know, is one of the most popular Distributed Version Control Systems (DVCS). A DVCS can be used in a traditional central repo style setup or a distributed approach. For more details checkout the Wikipedia article on Distributed Version Control.

Why I Switched To Git

When I initially started using a DVCS and moved away from SVN I turned to Bazaar. It was easy to switch to bzr because the syntax is similar to SVN and the basic usage is fairly straight forward and simple. I knew git was powerful but the lack of good Windows support left me wanting something that could be used more universally. That is no longer a problem thanks to msysgit.

What caught my attention about Git wasn't so much the impressive technology. It was the community surrounding Git. If I wanted a tutorial, application to interface with it, hosting service, or most other things I wanted in a version control system, it was there for Git.

Tutorials To Help With Switching

Git does things very differently than other version control systems. Sometimes this is due to the features and other times it's just because Git wants to do its own thing. In some cases it is quite annoying. Especially when the command to do something in CVS or SVN simply has a different name in Git. Needless to say, the Git learning curve can be more than a little steep.

Thanks to the wonderful Git community there is more than one tutorial on the topic:

Git Ready - Learn git one commit at a time.
Learn Git - How to with git from the people at github.
Everyday Git - Git in 20 Commands

If you're looking to make a version control change or want to jump on the bandwagon of coming changes git Git a try.

Downloading Dependencies With Drush Make

Matt — Fri, 19 Feb 2010 12:55:02 +0000

Quite a few Drupal modules rely on outside libraries to work. Some are JavaScript based requiring outside plugins and others are based on outside libraries. When users install these modules they, also, have to download and install the outside library. This is a pain that drush make and the Libraries API in modules can help with.

A typical setup will have a drush make file with a project and associated libraries defined within in them. The author who puts together the profile or top level make file will need to know the library and where it needs to go.

A little known feature about drush make files is that all projects can have make files and drush recursively builds each one out. So, if a module has a make file and the module is included in another make file the modules make file will be executed as well.

A simple use could be a module that uses an outside JavaScript library. That module could define a ModuleName.make file telling drush to download the library. A good solution would be to tell the script to go to the libraries directory alongside the modules and themes directories. Then, the module could use the Libraries API to grab the libraries location.

An Example

In this example we have the Super Awesome module using the awesome JavaScript file. So, in superawesome.make, which sits alongside superawesome.module, we have something like:

core = 6.x
 
; Libraries
libraries[awesome][download][type] = "get"
libraries[awesome][download][url] = "http://example.com/awesome.js.zip"
libraries[awesome][directory_name] = "awesome"
libraries[awesome][destination] = "libraries"

This will tell drush to download the awesome library and stick it in a directory called awesome within the libraries folder. The libraries folder could be in profiles/profileName, sites/all, or sites/someSiteName.com. Since the file has the zip extension drush will know how to unzip it as well.

Since the files could be placed in one of several places we can use the Libraries API. To get the path in our module we can use the following:

  $path = libraries_get_path('awesome');

Some Things You Should Know

There are two issues to be aware of with this approach.

If a project (modules or theme) is included in a make file but already exists elsewhere (like a profile or site make file) you'll get an error. Drush make doesn't, currently, handle a project being defined more than once.
If there are only libraries and no projects defined in a make file a warning will be thrown. Everything works as expected. There is just a one line warning for each make file without a project.

But, Is This A Good Idea?

Doing something like this would move control from profile builders to module developers. So, we need to ask if this control shift is a good idea? At this point I'm not clear on the answer.

Farbtastic is Dead, Long Live Farbtastic

Matt — Wed, 17 Feb 2010 16:38:07 +0000

Farbtastic is one of those widely used jQuery plugins you may not have realized you were using. One place many people have seen it in action is on Twitter. If you've changed the colors on your twitter page and used the color wheel to select the color you've used it. Farbtastic is the color wheel in Twitter, identi.ca, Drupal, Wordpress, and many other tools and services. While farbtastic is widely used it does have one major problem. Farbtastic is dead. The latest release of Farbtastic is version 1.2 written to work with jQuery 1.0. Remember how long ago that was?

Why Farbtastic is Great

Color wheels are a great way to select colors. Different spots on the wheel have different meanings. For example, If you pick a base color and want to find a complimentary color you jump to another part of the color wheel to find it. This is color theory and color theory uses color wheels.

For people who don't know color theory or care about it the color wheel is a neat way to select the color.

Why Farbtastic is Dead

Steven Wittens, the original author, wrote farbtastic for Drupal. As many people know, he is no longer actively contributing to the project and this plugin fell by the way side. With the official site for the plugin being his personal site it was difficult for someone else to take over.

Some time ago I approached Steven about moving the codebase to Google Code. It was moved there, updates we had been using in Drupal to keep up with newer releases of jQuery were incorporated, and Steven even wrote a 2.x version that utilizes canvas to draw the color wheel. It seemed like a resurrection of the plugin.

But, Steven is a very busy and talented developer. He became busy and farbtastic fell to the side again. The 1.3 release, that's already used on numerous production sites, never happened and the 2.x version was never shared with the world.

Long Live Farbtastic

Farbtastic is still strongly in use and the version used by Drupal has been tested to work with jQuery 1.2.6+. that includes the new jQuery 1.4. In an effort to share this I've migrated the codebase from the SVN repository on Google Code to Github. Please use it, fork it, and grow it.