Archive for the ‘Design’ Category

Developing a Usable Website Width

Thursday, December 17th, 2009

When you design a website, most folks try to minimize the amount of scrolling a user has to do.  Studies seem to indicate that while users will scroll, the less scrolling a web page requires, the more usable it will be.  Most websites attempt to limit the scrolling to the vertical direction, while minimizing or eliminating any need to scroll horizontally.

There are basically 2 ways to achieve this with a standard webpage.  The first is to fix the width of the page to a width smaller than the average user’s display width.  This design has the advantage that you can precisely position all the elements on the page because you are basically requiring a certain width.  However, if the user has a smaller window they will have to scroll horizontally to view the entire design.  In addition, this can create a large amount of empty space if the chosen width is too small for the average display width.

The second method would be to have the design “expand” or “shrink” to fill the available width.  This is usually accompanied with a minimum width to prevent the design from becoming unusable.  While this allows the user to size their window as they need to while still presenting as much of the content and design as possible, it can represent a much more complicated layout for the developer.  As I am not a designer, I usually pick this style so I can maximize the amount of actual content being displayed, and minimize the importance of the actual design.

Enter the Style Sheet

In many cases, making your site fill the available width can be as simple as adding a “width: 100%” line to your content class in your style sheet.  This will make the content fill 100% of the available width:

#ContentFull
{
width: 100%;
background-color: #DDDDDD;
float: left;
}

<div id=”ContentFull”>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
</div>

But what happens if you don’t want the content to fill 100% of the width, but only some smaller portion, leaving room for a menu bar or some other content next to it?  If you want the content to fill some reduced percentage, and want the other content to fill a proportional amount of the layout, then the solution is still simple:

#RightContentProportional
{
width: 80%;
background-color: yellow;
float: right;
}

#LeftContentProportional
{
width: 20%;
background-color: #DDDDDD;
float: left;
}

<div id=”LeftContentProportional”>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
</div>

<div id=”RightContentProportional”>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
</div>

So now both columns will adjust their widths in proportion to the percentage allocated to them.  So far, there haven’t been any complicated tricks, and has been pretty straight-forward.  The problem occurs when you have a 2-column layout where one column is a fixed-width and the other column needs to expand to fill the remaining space.

To solve this problem you need to perform a bit of magic using padding and containing elements.  Once you have the general idea, you can adjust it to meet your needs.  The basic setup is as follows:

#ContentWrapper
{
float: left;
width: 100%;
}

#RightContentExpandable
{
margin-left: 160px;
background-color: #DDDDDD;
float: left;
}

#LeftContentFixed
{
margin-right: -100%;
float: left;
width: 150px;
background-color: yellow;
}

<div id=”ContentWrapper”>
<div id=”LeftContentFixed”>
<p>
Fixed Width Content:
</p>
<p>
<ul>
<li>Item1</li>
<li>Item2</li>
</ul>
</p>
</div>

<div id=”RightContentExpandable”>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
</div>
</div>

Basically, what this does is create a left column that is fixed at 150 pixels.  It does this by playing with the left and right margins.  The left column has a RIGHT margin of –100%.  Essentially, this makes the right margin of the element the left side of the screen.  This means that when we float a second element, it will be position over the top of the left column.  Since we don’t want the content to overlap, we give the right column a LEFT margin of 150 pixels (in this case, I gave it a left margin of 160 pixels to create a bit of space between the columns).  What this does is cause the right column to start its left edge at 160 pixels from the right margin of the element next to it.  In our case, since we gave the element next to it a right margin all the way on the left, the right column will display an empty space where the fixed column is displayed, giving the impression that the left column is side-by-side with the right column (even though they are technically on top of each other).

So why do we need the wrapper element?  You may notice that the expandable element does not specify a width.  If we had given it a width of 100%, the resulting layout would have been 100% of the screen, plus the 160 pixels for the left column – we would always have to scroll.  To get around this, we size the parent element as 100% of the width, and then allow the right column to fill as needed.

Unfortunately, this means that the right column will only fill as wide as needed to display the content.  If the right column has a different background color from the background color of the containing element, the color will not “fill” the entire right side of the screen.  If this is a problem, you may need to play with different ways of solving the issue.

Open Sample Page

Bad API’s

Monday, March 16th, 2009

Bad API’s are the bane of every programmer’s existence.? They sap productivity and introduce errors into otherwise clean code.? They should be eradicated at all costs, yet they live on despite the best efforts to improve them.

How can you stop bad API’s?? The best way is to not write them in the first place.? This means paying attention to your design and paradigm.? This means taking the extra time to think about your problem.? This means that you will not be the first one across the finish line… at least for this race.

At least you can take comfort in the idea that some day some programmer won’t curse your stupidity for cleverly calling your simple AddItemToEnd method PutTheJunkInTheTrunk.? And they won’t throw things after discovering that you have to remember to increment a global count variable every time you use a factory to create a new object.? Trust me, it won’t be nearly as amusing after 10 hours of debugging, and it will be much harder to defend that decision.

Code is not your design, except when it is.

Monday, March 2nd, 2009

I’m a firm believer in the value of “designing” software before you start to write code.? Even a minimal amount of “pre-code” design is tremendously beneficial, if only because of the significant difference in cost to fix a defect in the early design phase as opposed to the later phases.? I am always annoyed by folks who want to design in code – I have found this to be an excuse to avoid thinking about what they are doing and inevitably ends up producing unmaintainable code that, of course, must still be maintained despite its quality.

I also have trouble with the code-as-design crowd because of the fact that while the code may be ground-truth, It is far more difficult to parse thousands of lines of code to derive the purpose of a given module than to read a simple paragraph description.? It is far easier to determine possible dependencies by looking at a class diagram than it is by reading through the implementation details of the class.? These higher-level abstractions make the problem of reading the code easier by providing context for a given class or method.? Future changes become much easier when developers are not forced to parse a method at only the code-level.? Multiple abstractions provide multiple entry points for understanding a code base.?

Unfortunately, whenever someone advocates the code-as-design method, it seems to be a thinly veiled attempt to avoid providing the higher-level abstractions that make the lives of everyone else easier.? Sure it may save time today, but eventually someone else is going to need that information, and the longer changes are made without it, the more difficult it becomes to make further changes.

However, I recently ran across an argument for code-as-design that has caused me to rethink my stance on the matter.? This is an intriguing and intelligent series of essays that argues convincingly the case that the code is the design and that accepting that as fact explains fairly well various trends and experiences in software development.? It also does not attempt to absolve developers from having to actually plan (or “design”) their code in advance.? The author (Jack W. Reeves) is merely pointing out that the code is the final design.? He makes no real attempt to promote any specific methodology other than to suggest that all the tools in our arsenal should be utilized to ensure that our final “design” is the best design possible, and proceeds to explain how certain trends in software development can be fairly well explained by this simple change in thinking.

All in all, I found the essays very interesting, and they offer a well-reasoned, logical argument for a position that is in my experience usually promoted as a way to avoid doing work that a lot of developers find “unpleasant”.

Task Estimator Design Iteration #3

Friday, February 6th, 2009

This is my final design for this version:

I changed some things around added some methods, changed types, added other types, but the basic concept is still the same.? The code for for everything behind this is complete, so I need to finish off the serialization component and then throw together an interface.? If I can avoid having to travel, I should finish up in the next couple of days.

Task Estimator Design Iteration #2

Monday, February 2nd, 2009

I've been trying to refine this design, and so here is the next iteration of the design.? I fleshed out some of the methods, fixed some of the connections, changed names of the items, etc., but the basic idea is still the same.? I don't like the way the Task and TaskItem classes are coupled together.? Ideally, I would like the TaskItem class to not need to know anything about the task class.? The problem that I am having right now is that TaskItem needs to account for the possibility of having subtasks that make up the item.? Since each of these subtasks might have an optional task item, they end up mapping back to Task:

I think at this point I'm just going to flesh out the underlying code and see how it turns out.? I should be able to stand up a prototype in a couple of hours, so I think it will be helpful to be able to see the design in action, and implementing it might jar some alternatives out of my current stupor.?

If you are curious, I separated out the UI and the storage code into different components from this one.? The idea here is that I'll be able to swap out either the Storage or UserInterface component independently.? This way I can iteratively refine specific aspects of the software without worrying about entangling myself in other components.? I will define specific public interfaces for the Storage component (and implement the factory pattern), so I can simply reference those interfaces instead of the specifics of a given implementation.? This Task component I am expecting to be pretty stable without any alternative implementations, so I don't see the need of making it easily interchangeable with a second implementation.

Task Estimator Design Iteration #1

Wednesday, January 28th, 2009

I've been forced to step away from this for the past several days because of work commitments with my real job, but I wanted to take a moment to throw up (pun intended) the first iteration of my design for the task estimator.? I don't actually like it at all, so expect to see further iterations coming soon.

I've left a number of things out – notably the serialization and GUI – but this is the core engine as it exists right now. Ugly, huh? This is about as far as I've had a chance to take the design so far due to other demands on my time, but I remain ever hopeful that my schedule will free up “in just another day or two”… Of course, it looks like I'll be traveling again next week, so maybe I'll have a chance to work on it then.

If you are interested, I have been working on the design in Visual Studio 2008's Class Designer tool.? It is very cool, and very helpful since it will automatically generate these classes for you.? Plus, with the addition of the Modeling Power Toy, you can export the image out as an image map, as I've done here.

If you are using Visual Studio and aren't using this tool yet, for shame!? All you need to do to get started is add a class diagram to a project.? Visual Studio will automatically analyze the project and create the diagram based on your existing code.? Of course, you can also start with an empty class diagram and do all your class design work from there.? That is what I'm currently doing.? I find that it is much easier to change my class design and structure when I am simply editing a diagram.? When I have to actually dig into the code to make these types of sweeping changes, I find it much more difficult to resist the code's inertia (things tend to be “good enough”)…