OOCSS, Page Layout and naming conventions

At this point, I’m investing some time to improve my technical skill on (X)HTML, CSS, page layouts and different skins for applications mostly based on CSS.

Of course I’m not a designer, and probably never will be. But I know for sure, every developer must know “the minimum” at least, or we will be in the #yerdoinitwrong category.

Studding a few Rails applications and how they implement different css skins for the same page, I get shocked.

There is no guide line to follow, pattern to apply, base layout to use, and most important: no naming convention at all.

So, I have searched the web for all these items just to get even more chocked.

Why? The only thing people agree is to disagree. They don’t even agree if it is fair to use a reset css or not.

So, I need to start making my own decisions and establish some rules by myself.

I want to explore css to the limits, avoiding JavaScript for a while. So, I need to create my css template and start applying it on my web pages, before I can use it on an application (Rails or not).

Reset CSS?

Let me start by the reset css subject. I will not argue about that. There is a lot of discussions over the internet: people considering pros, other considering cons about using the reset css.

After reading most of the discussions, evaluated and tested all the “reset.css” files listed in this collection.

I took the decision to use a “reset.css” file. But the one I have chosen was the W3C proposal.

It is a bit longer if compared with others, but it considers the phrase “a default style sheet must show an HTML page content into a readable and useful way”, seriously.

If you want to make your own tests, I have created and published a basic HTML test page.

In my tests most of the available “reset.css” files (including the popular YUI), turns the HTML content into an unreadable and useless format. That is my reasoning about using the standard W3C reset option.

Page Layout

Next topic, the page layout and element names, in this topic we have a few statistics and agreement about.

You can see a few statistics naming conventions.

Words I think we should consider when naming are: meaning, brevity, clarity, semantic, generic (thanks to Nicole Sullivan).

So, taking my own site as an example:

The main area proposal:

Words like “wrapper” and “main” are not so clear in my opinion. Inside the body, we simply have our desired “page”, that is it.

In our page we have three main areas we can consider a practical standard. The popular: header, content and footer.

And finally each of these areas will be divided into sections:

The left, the center and the right sections, are nothing more then columns.

OOCSS:

That points to the last topic: the oocss proposal, which can be used to put it all together.

You can find associated  links from the oocss home, or go to the project itself.

And it is very easy to define and combine columns using the oocss Grids “sizeXofY” classes.

I am a fan of the oocss way; despite disagreeing on some points and need to change it a bit for my specific needs, most of my class names and current css style came from there.

OOCSS has some key points:

•    use modular components
•    be consistent
•    use grids
•    minimize use of css selectors
•    use multiple classes per element to extend behaviour
•    separate container and content
•    new pages should not need new css

and key points to avoid

•    avoid location dependent styles
•    avoid styling by id
•    avoid specifying the tag a class applies to
•    avoid drop shadows and rounded corners over image backgrounds

According to Nicole Sullivan: “OOCSS isn’t really a framework … but a way of writing scalable, sane, maintainable CSS”.

You can have a First Look on Object Oriented CSS.

And a live sample (my own version) of OOCSS.

It is not even a final draft; it is a work in progress.

Any suggestions are welcome.

What Matters Most: Size or Pleasure?

Let me start talking about: People, Principles, Hardware and Furniture in the Web development environment.

There is a, considered by some, “epic” post reasoning about “Why Pair Programming Is Not for the Masses”.

People do or do not pair programming, for different reasons, and in totally different circumstances in US, Europe, India, China, Japan or Brazil.

Of course, an up to date hardware, a smooth and comfortable furniture, a cool and big enough workplace with a beautiful view will improve the life quality no matter where.

But the real question is: what does it matter most?

People & Principles or Hardware & Furniture?

I have being pair programming myself for a while and my boss doesn’t even know about that. Why? Because pair programming isn’t an acceptable practice where I work, so, we the craftsman, do some pair programming now and then, when we feel the need and we feel that is the best option to get things done.

And we do it wherever possible. A few months ago for instance, I was working as an outsourced resource inside the customer building, and my team mate at that time was from another third party company. My company occupies the 1rst floor in the client building. He was on the second, and the average hardware there was a dual core PC with 17’’ screen…

And YES, we do pair programming. We pair program at his desk on the 2nd floor, or at mine on the 1st. And we do it in cubicles.

Not by coincidence, this was one of the most successful recent projects on that client.

I was wondering if only our managers buy the agile idea, follow the principles, buy the hardware and furniture and sit the developers on a cool place, how better it could be…

In the end, lesson learned, about pair programming:

• You just need TWO PEOPLE fully accountable for what they do, no matter the hardware nor the furniture, nor the view.

• The (screen) size doesn’t matter, what matters most is the customer pleasure experienced when a quality product is delivered.

That is it.

Controlling and Documenting Software Development: a new approach

I’ve been reading a Tom de Marco’s article these days, where he reconsiders the “You can’t control what you can’t measure.” phrase.

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

“I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.”

Another great piece is the 1997 Bertrand Meyer’s satiric article. It is undoubted joking but most of it fits real and up to date for me.

http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html

“In its attempt to show that it has included everyone's pet ideas, it is a chock-full of symbol after bizarre symbol. Just the "Notation Summary" takes up 60 pages and has its own table of contents! UML is in fact as complex as a big and cryptic programming language, with generous use of "$" and "#" and "-" and "*" and "solid triangles with no tail" and rectangles and diamonds and solid lines and dotted lines and solid ellipses and dotted ellipses and arrows of all kinds and keywords such as "const" and "sorted" (not to be confused with "ordered") and different semantics for a class depending on whether its name appears in roman or italics; but at least a programming language, even the worst of languages, is executable! Here you have to learn all this monstrous complexity just to build diagrams of a possible future system.”

“For example I have tried to see if I could characterize UML as "object-oriented"; we all know this is a great compliment. Fat chance. Of course the authors make the requisite use of "object" and "inheritance" and so on. But a mere glance at the diagrams shows UML for what it is: an extension of entity-relationship modeling. The basic examples show binary and ternary associations, such as (page 16 of [1]) associations between "flight" and "seat" and "person"; this is the exact opposite of object-oriented design, where, as we all know, the world is structured in classes, built around object types, and every operation or property belongs to one class. Surely in object-oriented design you can't have a "passenger" link that treats "seat", "flight" and "person" symmetrically! In an object-oriented system it would belong to one of the classes; that's how you obtain the consistency, simplicity, modularity and reusability of O-O architectures; look at BON or at Eiffel to enjoy the results. The authors of UML know this, of course; to understand why they call UML object-oriented we must appreciate their famous sense of humor. Obviously they meant it in jest.”

“How could I criticize the method for not helping software developers or managers, when it does not care about software development at all, but only about developing a market for consultants and trainers? Everything started to make sense: the complexity and bizarreness of the notation, which I had foolishly taken for a deficiency, are in fact among its most attractive qualities, since they make for endless business opportunities, for Rational and perhaps even for others as well; so does its lukewarm adoption of object-oriented ideas, since it means a consultant does not even have to like or understand object technology to profit from UML.”

My growing interest on agile philosophy and methodologies, trying to convince my job mates (all levels), to give the software project control and documentation a much more soft touch, the Design By Contract approach sounds much more smart and agile to me now.

I like so much this practical approaching article:

http://devlicio.us/blogs/billy_mccafferty/archive/2006/09/22/design_2d00_by_2d00_contract_3a00_-a-practical-introduction.aspx

So, in the control and document software development subject, we have:

The don’ts (old fashion):

• Instead of hard control software development, try to deliver software that makes a difference.
• Function Points is not an effort estimation method; don’t try to estimate time spent using it.
• If the average managers try to deliver software on a seni
• or developer time line with a bunch of junior or even trainee developer team, why in the Earth do we need to over control software development? And worst, why to use FPA to measure it.
• Since UML is not simple, agile, or even OO, why in the Earth do we need to use UML when modeling or documenting software development?

The Do’s (new fashion):

• Manage the people and control the time and money.
• If you want to control something in software development, control its quality.
• Use Mind Mapping to barely document the software requirements (user stories).
• Use DbC to design the software.
• Use a smart and agile (like Rails) technology to implement it.
• Use XP methodologies when implementing it.
• Applying BDD, use executable specification and documentation techniques.
• If there is an obligation on measurements and control, use an agile technique like “AgileEVM” for instance.

And remember: what really matters to the customer is:

“BUSINESS VALUE DELIVERED PER SPRINT”

So, that is exactly what we need to focus on.

Applying agile methodology is a waste of time

People some times wake up “Agile” no mater what.

After a few years, working on the customer site, things change a bit, and now we are working for the same client under a new OUT sourcing contract, so, I came back to the “home” office.

The first thing I have noticed back to the office was the “java team agile style”.

There is a task board on the wall;
The Java source code is under CVS control using “sprint” branches;
They have regular meetings every week…

So I need to ask my VB team mates: You are not agile yet? Why? Does your working environment let you be or become agile?

A few weeks later I realized that the point is not agile methodology but agile PHYLOSOPHY.

If your working environment doesn’t embrace the agile philosophy, there is no way to become agile no mater the amount of agile methodologies you use.

Some practical examples:

The weekly meetings were not focused on the project sprint deliveries, and soon they were disabled for the “big project” the java team was working on. And the other projects are not “big enough” to be selected by this kind of weekly meeting.

I need to implement an urgent but simple feature on the original java application they were working on (the big project). So I asked on which CVS “sprint” branch I should work and was told to use the 5th sprint.

Then I asked when the user have received this sprint, and was informed “No there is no sprint delivery to the client, we are working hard the last 6 (six) months implementing the new functionality and trying to integrate it with the original application”.

Well that is my point, why do they waste their time applying some agile methodologies if the overall philosophy remains waterfall.

This brings me back to the source “The Lean Principles”.

• Specify value from the standpoint of the end customer by product family.
• Identify all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value.
• Make the remaining value-creating steps occur in a tight and integrated sequence so the product will flow smoothly toward the customer.
• As flow is introduced, let customers pull value from the next upstream activity.
• As these steps lead to greater transparency, enabling managers and teams to eliminate further waste, pursue perfection through continuous improvement.

If we can put it on just one phrase, the “Lean Philosophy” is:

Do nothing but what gives to your customer some value.

So which is the value to the client on using the precious development time specifying and modeling the full feature; calculating Function Points for it, creating a document detailing each aspect of it, and implementing each of the possible functionality, with no delivering at all.

At the end we can see: if the enterprise still waterfall there is no way to be agile.

First of all we need the enterprises to become agile; we need the managers on both sides to become agile.

There is no way you could be agile if your manager insists on detailed upfront schedules.

There is no way to be agile if your manager insists on FPA for each functionality.

There is no way to be agile if your customer demands a huge amount of documentation.

There is no way to be agile if your customer demands a lot of form to be filled out just to get a new version of the application deployed.

So, managers, please read a few books about being agile, starting here.

And you folks, developers and other professionals try to share the agile philosophy before the agile methodology.

If you try to use agile methodologies into a “waterfall” environment, you are wasting your time a bit.

Good luck.