June 3, 2009

Opti-Cal/Mag Vegi Caps: Where has all the simplicity gone?

I was just sitting down to eat lunch when a bottle on the table caught my eye. It looked like one of those bottles for vitamin supplements, so I didn’t think too much of it. Until I turned it around and took a look at the name of the pills.

Opti-Cal/Mag Vegi Caps.

What. The. Heck?

I glanced around on the front of the pill bottle for a while before I realized I had no idea what these pills did. However, I did find out that these were extra strength and contained a ratio of 2:1 of something. The front was just littered wtih useless catch phrases and buzz words. It was only after reading the very fine print at the bottom of the label that I realized that they were Vitamin and Mineral supplements (the label also says “plus other factors” which could mean anything really). Then I realized that it was overly complicated for no reason. If I had seen these on a shelf at the store I probably wouldnt’ even have looked at it twice. I had no reason to. After all, I had no idea what they were, and by looking at them, I had no idea what they actually did. I suppose if I had a few minutes I could stop by and closely look at them, but I’m generally a busy person. If I can’t get something right away I move on to the next attainable task.

Web design has achieved this same idea of simplicity. With the advent of the internet we saw a push for spinny buttons and flashy text and the dreaded blink tag. It was a terrible time to be a designer. But then things started getting good. All of a sudden there was this new movement in web design dubbed Web 2.0. It touted simplicity and aesthetic design over flashy-spinny bits. People still needed flashy, but now that this had become an actual design form, people were a bit more picky about what they put in to their layouts. After all, it would represent their work on the internet.

I suppose it really was a good thing for us. It allowed us to focus less on where to put a piece of the layout, and more on where not to. We achieved a balanced web layout by placing overly design-laden areas next to sparse whitespace holes. We learned to appreciate the beauty of a simple gradual gradient as opposed to bright pink text. We moved on from integrating these design elements into integrating the code. And then designers had to become developers. We had to see what it is we were going to do with our layout and then learn how to do it. It helped a lot because now you were working with someone who not only saw your end result in their head, but they worked tirelessly to make it happen.

So why talk about all of this? Why understand where web design evolved from? Simple, to figure out where it will go next. I personally feel that “Web 3.0″ (for lack of a better term) will integrate developers and designers tighter. Our designs will be linked to the code, and we will try and use code to replace various images. I mean, if I could do it in 40 lines of code and have it reusable always, why would I make an image of each element?

But more than that, designers will have to focus on how elements on their designs will interact with the user. Will a form have a tool tip when you over over it? Will there be a customized radio button? Will the banner fade in and out with different images? All these ideas will have to be integrated into the designers repertoire as they no longer design layouts, but move on to developing web sites. No longer can a designer get by on being just a designer anymore. They will have to learn new skills so that they have even more to offer their clients.

June 1, 2009

Verbose Arguments

Imagine if you will, reading an instruction manual that went a little like this

Place 3b into 2c while holding 4d adjacent to panel a4.

Now, any normal person will have absolutely no idea what’s being talked about. And that’s ok, because there isnt any kind of legend included within. For example, if I included a legend like the following, you would have no trouble understanding what I was talking about.

a4: Cabinet Side Wall
2c: Hole on bottom left of Cabinet Side
3b: Screw
4d: Cabinet Door

Hey now, magically that all makes sense. And in an instruction manual, where you have a set number of components, it’s alright to include things in an abbreviated manner.

But why would you apply the same logic to code? Why would you force variables into concise statements when it would make more sense to expand them? After all, L1 makes less sense than Line1 does right? This logic works great for variables, but fails a little when you move to function arguments. Essentially, the very fact that it is great for describing what a variables’ use is, causes it to be large, and accumulating upwards of 2 or 3 of these verbose variables into a function can become tedious. No one wants to read two or three lines of function arguments.

While thinking about the matter on a recent project that I have been working on, I realized that many frameworks had already stumbled upon the problem, and solved it rather quickly. The idea is that in a function, we can leave room for a variable length of arguments for any function, and still have “required” values. It is a little complicated but in a code example, we can see the value of such an idea:

Way 1: Concise
function call($var1, $var2,$var3,$var4,$var5)
{

}

Way 2: Verbose
function call($var)
{

}

No it isn’t a typo, Way 2, the Verbose way really does have only one argument, but it will be treated as an array. Not a regular array, because those are messy looking in practice, but a string separated by both colons and commas and returned to the function. The bonus of this is that when you go about developing an application, you can see what variables a function requires at a glance.

Concise Argument Definition:
call(135,12331,123,41344,384192′);

Verbose Argument Definition:
call(‘takeout: 135, initial: 12331, custid: 123, accountid: 41344, custphone: 384192′);

Now you can clearly see why they are called verbose arguments, but also why we would use them. When perusing your code after a few days, you seldom remember what a badly named variable does. In this way, you can, at a glance, see what variables a function will accept and you can define them in any way. In the first example, if 135 and 12331 were switched, you would get an error since you can’t subtrace 12331 from 135 without resulting in a negative number. However, with verbose arguments, you can’t go wrong. You can easily see what you are setting each argument to, and you can easily set things right, incase you mess up.

One could obviously argue that the same method can be achieved using arrays, but arrays are ugly, and since programming is an art form, we try and stay away from ugly.

As for verbose arguments, they are definitely a welcome addition to any piece of software, and it is well worth the few extra minutes of programming to cobble together a quick function that will handle everything for you. The function will take a string verbose input, and split it according these rules, and return the new array back.

Rules

  • Variable names are before a colon.
  • There must be no space between the variable name and the colon (ie. varname: is acceptable but varname : is not)
  • The value for a variable must come after the variable (with or without a space)
  • Multiple variables are separated with a comma after the variable value (ie. varname1: angelo, varname2: another)
function parse_args($args)
	{
		$e = explode(', ',$args);
		if(count($e) <= 1)
			$e = explode(',', $args); 
 
		$num_e = count($e); 
 
		for($i = 0; $i < $num_e; $i++)
		{
			$t[$i] = explode(': ',$e[$i]);
				if(count($t[$i]) <= 1)
					$t[$i] = explode(':',$e[$i]);
		}
 
		// Parse to array[key] = value format
		$num_args = count($t); 
 
		for($x = 0; $x < $num_args; $x++)
		{
			$tmp[$t[$x][0]] = $t[$x][1];
		}
 
		return $tmp;
	}

Hopefully, after incorporating it into your own applications you’ll see the benefit of something like this.