Recap 2011 / a kiss goodbye
Recap 2011 / a kiss goodbye
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
With only a couple more days to go until the new year, it's once again time (check the 2008 and 2010 editions) to look back at the various web-related things I wrote during past year, selecting the articles I think were the most important, most relevant or most interesting. As always you won't find anything new here, but if you're still looking for some worthy web-related new year resolutions, there should be plenty that suits your needs.
2011 was a year of progress, but also a year of many hypes and community setbacks. A year where the web progressed at a faster pace then I witnessed ever since I started in this business, but also a year where many of the best practices we fought so hard to establish were tossed aside in exchange for quick gains and tacky show-offs. I guess this is aptly reflected in the articles I selected, which probably contain more rants and defensive writing than in all the other years combined. But with good reason of course.
10. writing about front-end
I should probably repost this article once a year, if only to remind myself how important it is to provide the proper context when writing about web development. When writing for the web we often forget our target audience, kidding ourselves that we're writing for professionals only. The reality is a bit different and in order to make sure people don't walk away with the wrong ideas after reading our articles, it's good to keep providing the proper warnings and to keep explaining best practices and why they matter, even when they seems trivial to ourselves.
09. ux design: the u-deception
At first I didn't feel too comfortable writing about ux design as it's not really my usual territory, but as a regular web user I believed I could still add something valuable to the discussion. The bottom line of this rant is don't overdo it. Don't make me feel like you're trying to engage me. Don't think you're smart with your analogies and witty humor. Just get me to the information or service I was looking for as quickly as possible. Then I'll think about engaging myself with your site.
This year I've been concentrating a lot on writing html. I haven't done too much css work this past year and I don't feel to bad about that. Tying in with my article on the death of the one-man-show web developer, this article explores the depth and range of what it means to write html and how this could very well turn into a full-blown job description. Complexity brings specialization and we're definitely heading in that direction.
07. graceful degradation pitfalls
As web developers we're always working with the latest tech. Graceful degradation is a valuable concept but providing others with a down-graded experience while we're getting the entire package certainly leads to a couple of interesting pitfalls. It's easy to ditch functionality and graphical detail if you yourself don't need to look at it all day, which is why it might be better to start adopting the progressive enhancement paradigm, ensuring the base experience is strong enough and working your way up from there.
06. form mark-up
Ah yes, what html to use for an entire form and how to tie it to data sheet mark-up. With more time to think about how to write quality html code, this is one of the crazy things that came out of it. Semantics, structure and consistency all wrapped together to create the mothercode of all forms. A bit verbose of course (that's html flexibility for you), but I'm quite happy with the resulting html structures. Worth a read if you're like me and you like to ponder on semantics, structure and reusable html code.
05. the adverse effects of social
Social is big, but the bigger it gets, the hollower the experiences it provides. Social these days is all about simple interactions, not so much about communication, and because of that we lost a very valuable function of the web. Discussion is moving away from the web once again, which is a real shame as what remains is random numbers of likes, shares and +1s that try to make up a binary web profile of our offline personas. Not a rosy future if you ask me.
04. html5 articles for content types
Choosing between the article and section element may be one of the most fuzzy areas of html5, so I took the time to figure out why the spec made a separation between these two element. I also came up with a better analogy, instead of matching the article tag to syndicated content (resulting in an ongoing discussion of what content could be syndicated and what not), it's a lot easier if you match the article element to what most CMSs call "content types".
03. in defense of semantic value
One of the articles that spawned the most front-related discussion this year was a rant on the (minimal) value of html semantics. My article was a direct reaction to that, coming from someone who just spent a year specializing in html and semantics. Needless to say I didn't quite agree with the original statement and needed to vent a little. The result is a pretty strong vote in defense of html semantics.
02. the design axiom
While html does a pretty good job of keeping up with the needs for the modern web, css has a lot more issues to deal with. My design axiom states that whenever css catches up with design, design moves away from css again, simply to stand out from the rest. We know that a lot of work is spent on bringing css up to par to current web design standards, but the very ideology of this is flawed at its core. And it's just something we'll have to live with.
01. dry htmling
My personal favorite of the year is an article on what I've been doing the most: dry htmling. I don't know too many other who (can) do this and it's quite a challenge at first, but it really does teach you a thing or two about html. The idea is to write html for a set of wireframes that is given to you without any hints of design or design input. Just write html for what you see on the wireframes and worry about the css later. If you do it right, you'll notice that your html should be strong enough to incorporate most design decisions (unless they are structural of course). A very neat challenge.
Opinions expressed by DZone contributors are their own.