Yet another Holy Grail (3-column css liquid layout)

Posted in Development,Projects by ndt on the August 6th, 2008

In the quest of creating a rocking and flexible layout for Riff‘s redesign, I’ve started looking for the Holy Grail of the CSSs, the perfect 3-column css liquid layout. My requirements (self-imposed) where:

  • No tables (of course)
  • Use 100% of the available width
  • Fixed width left column
  • Right column with a minimun width, but scaling up when available width is enough. (This is because a site displayed on a 1900pixels wide screen, it’s useless to have the central pane with 1500px, the right column should start using some more space)
  • Both right and left columns should expand to the bottom, the content cannot wrap around them
  • Both columns must be collapsibles and the layout should continue working
  • Central pane should expand itself to the available width, regardless of the content not forcing it. This discards using “display: table” for the content div. (I had to add the display: table, otherwise the content wraps around (and behind!) the columns)

After digging in serious similar implementations like Matthew Levine’s which did not make it for me, because the content class uses padding at left and right to provide space for the columns and I need them to be collapsible, and the columns are not equal in height, or Faux Columns and this, and using the “padding: x/margin: -x” trick for the columns height, I ended up learning enough to put together something that (for the moment I think) works perfectly and satisfies my initial requirements.

Below are the Layout HTML and style with comments:

<div class="container">
	<div class="column left">Lorem ipsum</div>
	<div class="column right">Lorem ipsum</div>
	<div class="content">Lorem ipsum</div>
</div>

html,body
{
min-width: 500px; /* This avoids the html being compressed beyond this width */
}

.container
{
height:auto;
overflow:hidden; /*This hides the exceeding portion of the columns created by the padding/margin trick, thus avoiding the scrollbar of the browser to extend more than needed*/
}

.column
{
position: relative;
border-style: solid;
padding-bottom: 30000px; /*This extends the height of the column so the main content does not wrap around it*/
margin-bottom: -30000px; /*This 'reclaims' the extra height created by the padding*/
}

.left
{
float: left;
background-color: #0f0;
width: 200px;
}

.right
{
background-color: #ff453f;
width: 200px;
min-width: 25%; /*This makes the column start growing when the total width is greater than 200px / 25% = 800px.*/
float: right;
}

.content
{
border-style: solid;
background-color: #242eff;
display: table;

}

9 developers in one month

Posted in Development,Projects by ndt on the July 27th, 2008

It is well known in the project management world that adding manpower to a late software project makes it later. This is known as Brooks’ law. An analogy is that you can’t use 9 women to make a baby in one month.

A couple of days ago, at Manas we did the experiment of doing a one-day project with a team of 15 developers, architects and designers. The rules were:

  1. The only design artifact that we had before the day was an idea of what we wanted to built, there were no documents written or spikes.
  2. None could have their environment set up in advance.
  3. We chose to build the system in Google App Engine a new framework and language in which most of the team had no experience at all.
  4. The whole project from its inception up to its deployment needed to be done in exactly one day.
  5. Every member on the team was required to be fully committed to the project, no part-time allocations were accepted.

The result was amazing. We actually managed to start at 9AM with a general meeting and creating a Vision and Scope document in 30 minutes. We then split in some groups, one of them creating the user stories, the other defining the basic look and feel. During the coding phase everybody was pairing and we even rotated partners between user stories.

De-Bee Gantt

The nice thing was that we experimented almost every phase in a real project in just one day. By 3PM everyone was lost, none knew what the rest of the team was doing, we had finished every originally planned task and we realized that a lot of ‘glue’ tasks were missing to tie up together the functionality. We did another general meeting to review what we had and what we needed, reinforced the team morale and got back to work. By 7PM we were deploying the finished product!

It was a really fun and enriching experience and although stressing, the energy in the office was enjoyable.

You can check the result at www.de-bee.com, feel free to use the application and leave feedback at debee.uservoice.com.