Sunday, April 8, 2012 In Boiler Room | trackback

Separation is king, mixing is toxic

Layering interfaces for web projects

I’ve been coding and designing for 15 years now. hard to believe! I can’t believe it myself. Here is one lesson I learned about coding in general, some of it is self-evident, some is exclusive, not that I have discovered it, but that I can’t find a lot who would agree.

Why Semantic HTML

The obvious reason is because it is more scalable and error-prone, if you use semantic HTML while developing on one browser, odds are very high that it would work on all other new browsers, mobile, tablets, and future browsers, and if you’re lucky, some screen readers too.

Another subtle reason is maintainability. It’s not following semantics that makes it easier to maintain, but that HTML5.0 semantics are much better to maintain than old HTML –343.000.33! One ever-lasting example: tables. To add a new column to a table, you need to use your favourite web-development tool with visual aid to add it, and merge columns on all the other rows. In an unordered list or definition list, the change is local.

My reason behind using semantic meaningful HTML is;

Mixtures are prohibited

I embrace separation, mixing layers is toxic. What I mean is separation of logical layers of a web project. It used to be really hard in 1995, but now if you don’t create separation early on, no one is going to cry with you later, when you stay up all night changing labels from “American English” to “Australian English.”

There is the deep back end layer called data layer. Only real data reside there, data that are either entered by a human being (not a machine, nor you, the geek!), or gibberish entered by the system, only the system understands. I have yet to see a fully separated database layer. This problem rises more evidently when dealing with multi-lingual sites. Open source platforms got it right. They implement translation labels way higher than data layer, and the interface drives directly from that translation layer. So you’re database either has “pages” table, with “title” entered by users creating them, or a look-up table of intTransitOxIdLabel. Where it gets its meaning? business, or interface layer.

Then comes the layer of business logic. Open connections, maintain connections, take orders, process orders, serve back. No real decisions to be made in business layer. The system is the only actor inside that layer. It never ever decides whether the content is “Uppercase or lowercase.” It never decides whether time logged is 12 or 24 format, or in what time-zone. It never makes a guess on whether the information is valid, or not. Ever! We have always called it “business logic!” but really, it’s as dumb as it can get. A junior soldier. Takes commands, serves commands.

Presentation

The Interface layer is made of multiple sectors, I know more about that because that’s where I live. The behind the scenes UI layer is where all logic and intelligence lie. Things like: “did you mean tomatoes?” or “Go fish! you have no access” are taken care of in that layer. But outputting them to the real human being outside is served through another “Etiquette layer” to make sure our geek is not misunderstood. This Etiquette layer makes sure it outputs “Sorry, you have no access. Our admin guessed you might like fishing, so we recommend couple of days on the shore of the Deadsea.”

Our translation layer serves pure language, no formatting, no logic. Sometimes though you do need your strings to look smart, like “Go fish! Mr Norris!” In this case, replacement strings come into the rescue. “Go fish! {0}!”

Thus, all textual labels exist i this translation layer (better called resources in .NET projects), and next time you deploy across the ocean, you have one folder to work with, and maybe even one file. Separation is king.

The last layer is the graphic interface layer, where HTML, CSS and images reside. But there is one layer that connects the graphical to the logical UI layer, it is the behavioural layer, consisting of HTML, and Javascript. There are yet two kinds of Javascript we are facing more often, interface-related, and business related.

If i start talking about specifics I might never finish, so I’ll speak cryptic and shorten my words.

Command your interface layer, each object should know the following about itself:

  • There is how I look. E.g. I look with a red asterisk in my upper right corner
  • How I react: I blush when commanded and speak a word or two
  • Who commands me: my self, sibling or parent
  • What is the command I get: “react” when I don’t have 8 characters, and say: Invalid password format.

Things that are also implemented but I do not have to be aware of:

  • Who triggers my commander: a button at the bottom.
  • What is expected of my commander, a signal to go forward or halt.

So your password input field (singular) looks something like this



Here, the commander is the same as the field itself, it’s taking care of itself. Next is when you have a parent to decide what commands to initiate:

So now that a parent exists, there is no need for the child to take care of command issuing, actually its a fatal mistake to make it do so.

The trigger fires a command-issue event for all parents (with data-validateme = true), which in turn run their own behaviour “ValidateMatchPassword” which in turn may or may not fire individual behaviours like “ValidatePasswordFormat,” and do extra few things like match the two fields, and “react” itself on this event… the reaction could be similar to that of its children or completely different. In this case, the parent is also an object that gets its commands to react by its sibling or “itself.”

In code, this will translate into a plugin to define the reaction no matter who or what triggers it, this is the interface-related Javascript layer , a higher level layer to define certain template for repetitive behaviours (like required fields and certain formats), and define the behaviour of the button command-issuer, then a final high level layer specific to the page itself, where it reacts for specific event. This is the business-related part of the Javascript layer.

Often mistakes

Some of the ever lasting mistakes that I recover from (sometimes with a price to pay) are; using a style defined in global stylesheet to define looks in my Javascript to define behaviour. I corner myself into making a nice looking blue pen sign dates, when I later I need to make blue pens that simply do write names.

Also, making a JQuery plugin handle a bit more than what it’s supposed to handle, like “blush, when you’re empty.” But blushing is a reaction, being empty is a condition.

Abstraction

It might sound self-evident, but mixing layers, making children aware of their parents, or lower ranks talk directly to higher ranks, is not easy to avoid. JQuery plugins are very low level (logically), so they are not supposed to be aware of user choices on higher level interface layers. It would be a killer to do something like this inside a JQuery plugin: $(“.myselector”)!

Another necessity of abstraction in UI-related Javascript, using something like “next()” corners designers into using the expected HTML syntax. Fortunately, I found abstracting JQeury plugins ands UI Javascript much easier than being specific.

Naming

Finally, naming mistakes. Especially in stylesheet selectors. Abstracting means defning a style according to what … well, style! “.myRedBoxBordered” can be used a million times without having nightmares, “.PasswordArea” cannot be used again on “Cart login area.” Even though the designer meant to use the same style. You can box CSS definitions easily to create packages, like “.Redbox” or “.ShineyGreyPanel” which defines more than just color.

So I’ll just wrap it up and say: mixing is toxic, separation is king!

Recently

Theory categories

Recent comments

Powered by Disqus
Shut your eyes, and look again, the whole world has gone upside down.

Shut Theory

By Shut Theory [http://shut.elmota.com]