Your Toast (Part 2): The Two Apathies

OK, I’m back. (wipes hand son pants)

So, let’s talk about these different kinds of not caring. There’s a singular word that sounds much better to describe this attitude: apathy. Since I defined two different forms of apathy above let me further define them here and divide them into two distinct and opposing terms: Developer Apathy and User Apathy.

User apathy is me staring at the toaster, waiting for my toast. It’s your boss or client staring at you with those eye lids half closed saying, “Just get the job done”. In some sense it is a nearly absolute manifestation of expectation. Please me now, or cease to exist. No, wait, AMAZE me now or I will hate you forever. I want, what I want and I don’t care how I get it.

Developer apathy is the toaster, toasting. It’s aware of that “darkness” setting but of almost nothing else. It doesn’t even know if there’s bread in there, it just knows that the handle was depressed, the desired setting set and when that temperature and/or time is reached it’s going to eject something out and turn itself off! Done. Anybody want some more toast? I did my job and I don’t care who I did or didn’t please. I did what I was asked to do. End.

Of course, the complete disconnect between end users and engineers has been recognized for millenia. That’s why we have design and usability and accessibility teams and countless other aestheticians sitting between the people with the toolboxes and blueprints and the general public. That’s why the Sistine Chapel isn’t just a sturdy building with an all white interior. That’s not the point I am driving towards. What I am trying to remind myself and yourself of is that even as a Software Engineer that the level of ignorance that had crept into my work habits was unacceptable especially from an engineering stand point. The HTML/CSS/JS that applications produce is still something far removed from the end user, the mark up really isn’t for them, it’s for the user agent. It’s for the browser, the phone, the kiosk. It’s still well within the realm of my discipline and control as a developer. The essence of the realization is that myself and others should be paying more attention.

So, I started caring (a lot) and went back to the first principles that had made me a good enough Software Engineer to keep myself gainfully employed for so many years and applied them to the challenge. What was the output of the applications I was building supposed to be, really? Was it really so indefinite, so arbitrary?

At this point it might be instructive to roll the clock back a couple centuries to the time when the Internets and the Googles didn’t exist. When computers were barely able to calculate the number of donuts in a baker’s dozen. What did the target output of those machines look like?

I’ll tell you. Tables.

Matrices to be more exact and as we are all well aware. Here’s a quick snapshot of one:

This is turning out to be a long, multi-pronged post. I need to get up from THIS table right now. I’ll jump back into THOSE tables as soon as I get back.

Your Toast

I like toast. Because I like toast (a lot) I never skimp when I make the bi-yearly trip to Target or Sears to upgrade my middle of the price range toaster. I get the best my kind of money can buy, since, as I stated before, I like toast (a lot).

I don’t ask a lot from my toaster. At least I don’t THINK I do. I place slices of bread of varying shapes, depths, widths and heights in, drop that handle down and wait, expecting one thing as a result: hot, cooked bread. I can of course, select from a spectrum of desired “darknesses” before initiating the sequence, but my expectations remain the same. That based upon my one initial selection that I’ll soon be munching on something warm, brown (or black) and crisp. Simple machine really.

Input: Bread

Output: Toast

I accept that for my kind of money that the lifetime of the apparatus is limited. I also accept the responsibility of selecting the darkness of the toast. I don’t even care how it gets the job done. Electrically heated metal coils are just as fine to me as would be some ultra-sonic, dark matter radiated model circa 2027. I really don’t and shouldn’t care. All I want is toast. That’s my target, that’s my goal.

Of course, this article, like all others on this site, isn’t really about toast. It’s about markup and user interface implementation. So, now that I’ve seeded your mind with visions of tasty, butter melting goodness, let’s get to the point of the analogy.

The important part of the analogy above has to do with me not caring. I said I didn’t care about how my bread gets toasted, and I don’t. I know who the target audience is for the bread (me) and I know how it’s going to be used (I am going to eat it standing up in front of my kitchen sink because I am usually massively impatient and hungry if I have chosen toast as a meal option).

The core point is that I used to have the same attitude toward markup (XML/HTML/CSS, you know the roundup) as the toaster has toward my toast. That’s because I used to think that markup was the EASY part of web development. Anybody and their second cousin can and does write HTML and CSS. In comparison, writing all that Perl, PHP, Java, SQL etc. (showing my age here) seemed infinitely more complex and demanding of my attention than the piddling afterthoughts and minutiae of defining what the HTML and CSS that the output (ultimately) of the application would be. So there, there it is, the core defining and most telling sentence of the article. I had knowingly ceased to care what the output of the software I was creating was. This is, in short, BAD.

Of course once I started examining this attitude for more than 30 seconds I awoke (matrix like) to discover that my own mindset was stuck INSIDE of the toaster. And believe me, your toaster doesn’t care anything about you or your toast. It just toasts.

Now, in fact, if we want to stay true to our analogy, this KIND of not caring is the exact opposite of the kind of not caring I had originally mentioned. What I was originally referring to was my not caring about how the toaster got its job done. Remember, I just wanted toast. This is about role reversal and expectations. This is about the interface and the machine that produces it. This is about services and consumers and that thing (the interface) that sits between them. See now how all this toast talk is suddenly relevant?

That first kind of not caring is the kind that the users of your software have. But in today’s multi tiered, ultra distributed, service oriented and mashup addicted world we really need to bring clearer definition to a couple oft interchanged terms: users and consumers. I’ll attempt to do that in just a minute.

That second kind of not caring is the kind of thing that crept into mine and many other developers minds over the course of the past decade. The reasons for this are too personal and numerous for me to try to elucidate here. Suffice to say it all had something to do with the expectations of what exactly the output of a web application was supposed to look like and who the true audience was that would ultimately be consuming it (web browsers or other human beings). I’ll connect this point to the previous one moving forward as they are so intimately tied together.

That’ll need to wait until the next post though. I am getting hungry, be back in a minute….

Hey Buddy, You Got a Challenge?

I have to admit it. I have problems. We all do. Wish I could say it wasn’t true but we’re all in the same boat as far as that is concerned. And one of the only things I am absolutely certain of is that I don’t need any more.

That’s why I’ve always resented the idiom of presenting technical tasks as “problems” to be solved. Now this is going to end up sounding like a lot of blue sky thinking and if your eyes are already creeping upward and back into your skull, just give me a minute for some clearer definition.

Problems in the context that I am referring to are absolute limitations, situations that must be resolved in order for any future constructive action to take place. No car to get yourself to work, that’s a real human problem. Not the kind of car you LIKE, not a problem. That latter one, that’s a challenge. A challenge to figure out a way to improve a situation, not just make it viable.

So, with that said let me get back to the challenge of stating technical tasks to be achieved as something other than problems.

Like most of the US population I grew up dreading being forced to bend my intellect toward the remote drudgery of mathematics. One of the honest to goodness reasons for this in retrospect were the ways in which the materials were presented. They were all problems. Math problems were something I didn’t want to deal with, they were the tapping foot of an unfinished chore, glaring and impatient. They needed to be solved, you had no choice.

Challenges, instead, were FUN. Friends challenged me to beat them at video games, to jump off roofs, to arm wrestle and put firecrackers in things but also to beat them at Connect 4, to create a better Halloween costume and learn to play a musical instrument.

No, none of them ever challenged me to solve an equation, but looking back now I wished they had. I wish we knew that we could do that. But the big linguistic take away from all this is: Your enemies give you problems, and your friends give you challenges.

So, in this blog, when I’m presenting technical tasks that I have been asked to perform I will never be referring to them as problems, but challenges.

Just wanted to get that out of the way. So, on to the next challenge.

Markup Strategies: Web Based User Interface Development in Practice

Let’s get this started with a quote:

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

I’ve had this little quip from our old friend Abe Lincoln taped to the white board in my home office for more than 6 years now. I’ve cleaned the office out a number of times since then and I’ve reached mechanically toward this little slip of paper, only to withdraw my hand as it sensed the properties of something essentially useful. Something the room would be lessened by in absence.

But what does the quote above have to do with HTML, XML, CSS, JavaScript or even web development in general? The simple answer is, whatever it means to YOU.

I began this blog for a simple reason. As a store place for all the energy I have poured and am pouring into the many axes I have sharpened and will sharpen again. My profession being web development, and particularly user interface implementation, the axes stand as metaphor for all the above technologies (and many more) whose use I refine in my day to day exploits.

Hopefully the content here will serve as both a journal and compendium of the struggles to put forth a better product, capture best practices for continued use and record of the most useful failures.

At its essence though, this blog is about the PRACTICE of web based user interface development, not the THEORY. About what has worked in what situations, what didn’t and why.

So let’s do something a little more perfectly. Let’s get practicing.

Here’s the strategy……