Neatly Sliced

Note: I have updated this post several times since the original publish.

At long last, the July winner is announced. Congrats.

The notes from the judges regarding my entry (I am #12) really did not extend much beyond my own observations.

Tony wrote that my .bug class is superfluous. I wholeheartedly disagree, for if the design were to change to add currently nonexistent divs that are not bugs, it will potentially complicate the code. Those elements will require classes. Then, where do you draw the line? Which divs require a class, and which do not, or should both have classes? I find it applicable to use the .bug class here, and were I to code it again, I would design the markup (for this section) in an identical manner. Plus, it makes more sense semantically when browsing the code.

JD noted that some stylistic elements were off. I know, I know, and I noticed them after I sent it in. I wrote about it in my aforelinked observations. He did not like the placement of the dots. That is a situation where, in coding the layout, I would call the designer to my desk and ask for his or her feedback. It is part of the challenge of this competition: trying to read the mind of the designer. In this practice, I inch toward the betterment of my own design skills. The variances between my mind and JD’s were the downfall of this entry, but with his feedback I have a better understanding where I might improve next time.

I will refrain from comment on Ott’s winning entry. It renders poorly in my Safari browser (along with the greater number of the entries), so I don’t want to pursue the discussion any further, other than to elucidate the obvious problematic elements in Safari:

• The rust border around the search boxes are not flushed. It looks silly, and this is exactly why I refrained from implementing it.
• The dots are a few pixels off from the grey borders, in a highly noticeable manner.
• I would think that CSS Off wrote this entry on spacing with the winning entry in mind. What! Then why did it win? So weird. How does this one win when the judges explicitly write a post highlighting a flaw that the entry bears in full?

Ott’s is a nice fluid layout, other than the Safari flaws. There’s no hate, Ott, just my browser that never gets any dev love.

I’ll still participate in the next contest, for my own CSS practice and article inspiration. In any vein, this contest is good because it gives me a rounded perspective of my front end dev skills, although I cannot refrain from expressing one more time my confusion over the explicit flaws of the winning entries of this competition and the previous. Okay, scratch that – they are not explicit flaws, but just… averages. The winning entries were average, not extraordinary or particulary noteworthy or clean, but just overwhelmingly normal and average. They are entries that I would see get the bronze medal – good, but better around who swoop in for the gold.

I absolutely adore the detailed notes on each entry. From skimming, I noted a few things I will give a second look (see: elastic rounded corner yellow box). I encourage all to peruse the notes.

The following remark by the CSS Off guys struck a particular chord with me:

As web programmers, our job is to translate a design to the web. That means taking into account different monitor dimensions and resolutions. And then designing the site to look good in them. A site loses trust points immediately when the design doesn’t look “finished.”

It is the mindset we ought to have, as sometimes we focus too much on the back end of a site to remember that key fact of good-looking sites reigning. The original point of the statement was to utilize the space of the screen, but I apply it in that we must to have a hand in the design nearly as much as the designer, and must keep a keener eye on our results.

And I got a good chuckle over the judges’ references to my namesake (neat!). Thanks for the linklove, judges! Keep up the good work.