Get it All
Together

Small reference to one of my favourite authors, Tad Williams, in the title of this post. But the quote, taken from the Memory, Sorrow and Thorn series, really paints the picture I wanted for this post in terms of the lesson I found myself suddenly learning yesterday. I don’t know how useful an article this will be, but I guess I just wanted to write out my thoughts because they seem important to me. Guess that’s why they call it blogging, huh?

The system I’m building is a kind of a specialized content management system for my company’s website. As such, each “page” can define its own “template,” or layout system that defines the specific view. My boss was very impressed by this system, which is good, but later he called me with another idea: why not create two folders for templates, one for templates that are reusable, and one for templates that pretty much only get used for a specific page and never again.

On the surface, this seems to make some sense: we do have one-off pages that would require a template that never gets used again. But for reasons I couldn’t quite articulate at the time, I thought it was a terrible idea and still do. After a night to think it over, I realized that the challenge in programming is always the edge case and that the goal is to eliminate them, not create them. Here’s what I mean:

Lets say for example that we want to create two “buckets” of information, Category A and Category B. A specific set of conditions defines what qualifies for each bucket. We setup logic to compare a data set against this set of conditions and place it in the right bucket. Immediately, we have created a decision point. If the decision is simple and mathematical – size of a file, lets say – there are no edge cases. But if the decision is more complex or based on human decision making, there may be thousands of specific data sets that either fit into both or neither bucket. Then what?

Well, then we have to define a more stringent set of rules, don’t we? Or else more rules. Herein lies the problem, because you can drive yourself nuts trying to come up with a solution for every case. Worse than that, you can riddle your code with flaws and – as the title of this post suggests – create a set of rules so stringent that entirely separate parts of your code are immobilized for fear of violating those rules.

Such is the case with the current website, frankly. Its very well programmed, but unfortunately, so many rules and so many eventualities have been programmed for that its almost as if they’ve painted themselves into a corner. What was built to be flexible is now anything but.

Object Oriented Programming will not help this kind of thing. If the rules of one portion of the program obligate another part of the program overmuch, even cloud-based, OOP web services would grind to a halt.

So, what I’m getting at here is that any new decision point needs to be carefully considered in context. Does the decision represent a really necessary component of the system? Forget the perceived benefits of that decision point, what are the flaws or disadvantages that this decision point would eliminate? If there aren’t any, are the benefits really that valuable? Finally – and perhaps most critically – how many edge cases can you think of and is it really worth the brain power to figure out solutions for each one?

I think another bad habit of us programmers is that we are so enamored of our ability to solve problems programmatically that we feel the need to do so at every step. Here again is an opportunity to introduce new and mind-numbingly confusing edge cases where they’re not needed. Every web page does not need to be assembled by a foreach() loop, if/then decisions and switches: sometimes, plain old HTML with a few choice includes will do just fine.

Its an irony that, after really nearly thirty years of off-and-on programming in everything from BASIC2.0 to CakePHP, I’m only just now appreciating in definable terms: the logical conditions that make programming possible and programs flexible can also be over used to the point of farce.

The last few weeks have been absorbed in some freelance work for a local marketing company, which is a nice change of pace. But that also means I’ve not been able to get at my new pet project in that time, which has been a bit of a downer.

And since that new project is CakePHP driven and I’m only really learning the platform, time away from the project means knowledge lost or at least deeply buried. That makes getting back into it something of a challenge.

And indeed, I took the better part of the last two days figuring out a problem which turned out to have been rather obvious. Obvious, that is, if you know where to look. But with all that out of the way, I’m starting to make some decent progress on the project and am hoping to get something that at least looks nice by the end of the week.

Because more than one recruiter has said they want something like this to point to as a portfolio item. Everyone seems pleased with the direction I’m going in: they like what the project’s aim is. Sorry I can’t share that on this blog, but until I’ve got my domain name in place, I don’t want to screw myself.

But I really like the layout I’ve chosen for this project: very clean with big, friendly fonts to draw in the less-technical. The project is supposed to be about lowering the bar of participation in government, so it’s important not to cram too much information on any one page.

Hopefully by week’s end: a preview of my new CakePHP-powered web site!

Of course, FireFox currently supports CSS rounded corners for DIVs, but sadly, the same cannot be said for IE.  As developers and designers, we have to either accept that some people will not get the full effects of our website, or else we have to use the old methods to achieve parity for all browsers.  This post is just to show you the easiest way to get the rounded corners effect in the old-school manner.

The big thing is to plan on how big you want your rounded corners to be.  The reason is that you will have to fight with setting top and bottom margins of the same size as your corner radius, or just accept that there will be some space there.  This easy way of going about things assumes you’ll be ok with a 12px radius and a 12px margin to match.  We’re going to make a DIV 580px wide by 200px tall.

Start by opening up Adobe Illustrator or whatever other vector graphic tool you usually use for thsi type of thing and make a box that is 100px tall and 580px wide.  Fill that box with the color of your non-bubbled background – that part of the web page that lies outside your bubble, in other words.  My background color is #FFFFEE.

On a new layer, create another box with rounded corners of 12px radius, in exactly the same size.  This new box should for the most part completely cover up the old box and should be the color you want the bubble to be.  We’re assuming you want no border, but if you do, you’ll probably want to play around with this example a bit to figure out how it’s going to work best for you.

Now, you should have an image that looks like this:

Example of the DIV bubble background.

Example of the DIV bubble background.

Next we need to setup our CSS rules.  Because we have a box with all four rounded corners, there’s no need to create or load a second image for our borders, but rather set it up like this:
[code lang=”css”]
#bubble_wrap {
width: 580px;
display: block;
}

#bubble_top {
display: block;
margin: 0px;
height: 20px;
background-image: url(/wp-content/themes/akitsu_home/img/feature_bubble.gif);
background-repeat: no-repeat;
background-position: top;
}

#bubble_bottom {
display: block;
clear:both;
margin: 0px;
height: 20px;
background-image: url(/wp-content/themes/akitsu_home/img/feature_bubble.gif);
background-repeat: no-repeat;
background-position: bottom;
}

#bubble_center {
display: block;
}[/code]
We can then assemble the pieces like this:
[code lang=”html”]
<div id="bubble_wrap">
<div id="bubble_top"></div>
<div id="bubble_center">
<p>content goes here</p></div>
<div id="bubble_bottom"></div>
</div>[/code]

If you’re like me, you like to have a fair amount of control in the way your websites look to the user. As you know, this is not always easy based on the way browers were meant to behave. Browsers were meant to allow differently-sized monitors and windows show the same content, and thus allow for a lot of proportional widths, with the page stretching and scaling to adjust to the different readers. But in these modern days, we can anticipate certain screen resolutions and many pages conform to a rigid width.

Keeping this width is actually quite important from design, usability and branding perspectives, as a matter of fact: my keeping pages a consistent width, we increase the chances that people recognize our pages as something unique (branding), we allow our users to be accustomed to the locations of key navigational components (usability) and we decrease the chances that something unexpected on the page will break the overall design (design).

However, there are very real problems with fixed-width pages that many novices encounter, making fixed width pages a real bear to deal with. I thought I’d take the time to discuss the reasons that – even in a fixed-width page – using proportional sizes has benefits to the designer.

Continue reading →

This is just a “public service announcement” for those web designers looking for a fast way to get a nice, even hanging indentation on their pages. That’s when the top line goes all the way to the margin and the text below it is what is indented. You might use them for a non-bulleted list such as those in the typical WordPress sidebar. It is a very simple fix, but I’ve been surprised by the lack of adequate answers in Google and figure someone out there might be looking for an answer would appreciate it.

So, the fix is: create a left margin of Xpx, then use text-indent with a -Xpx value. Ho! Is that easy, or what? And it works with IE and Firefox, both:
[code lang=”css”]
#blogwire ul {
margin-left: 15px;
}
#blogwire ul li {
text-indent: -15px;
}[/code]

There’s lots of information available on WordPress’s codex about how to create themes for your blog, all of it dealing with the filters and actions you can use to manipulate the active content on your blog in cool ways. It goes without saying that those are important pieces of information, and in fact there are some outstanding tutorials for putting together a theme that you should definitely check out. WPBits is one such resource.

But I’d like to talk about some concepts that happen before you get to the active content: the HTML, and how you go about designing a theme which has to exist in all those varying pieces yet all go together to create one cohesive whole. This is a very high-level tutorial, meaning that specific details will be omitted in order to introduce the most basic concepts. I’m writing more about the workflow than about the process, if you follow me!

Continue reading →