Monday, December 27, 2010

Book Review: Designing with Web Standards

Another book down! I just finished Jeffrey Zeldman's Designing with Web Standards (3rd Edition). This book is widely respected and Zeldman has had quite an impact on the move for designers and developers to embrace standards.

I took away a lot of good lessons from this book:
  • Standards should make things easier! This is not really very intuitive. Adding rules usually makes things more complicated. Standards, however, should make your code more readable, maintainable, accessible, and portable between browsers.
  • Standards improve SEO. I am admittedly ignorant when it comes to SEO. I really have no idea what makes a site turn up at the top of a search engine list. Zeldman's message is that the best thing you can do to improve SEO is to write standardized code with meaningful ids, classes, etc. This can get lost in translation when using a code generating program.
  • IE6 is a thorn in the web developer's side. Zeldman often paints a beautiful picture of how the standard works in all modern browsers. Then he goes on to make you cry over how IE6 butchered something and makes things not work. There are some workarounds in the book, but overall it is just painful to support IE6. It seems that Microsoft is behind the curve constantly when it comes to browsers. I won't let my bias come through too strongly, but surprise here.
  • It's important to stay on the cutting edge. Things are changing constantly with browser support of features, HTML5, CSS3, and web design trends. To stay competitive in web design and development, continuing education is critical.
I learned a lot of good theory and mental practices from this book. For what the book intended to do, I think it did a great job. I like to look at things from a more practical and hands on approach with a developers perspective and that was not the intention of this book.

Some things I would have liked to see improved:
  • No downloadable code! For as simple as it is to add the code examples to a website I feel like it should never be left out. There weren't a ton of examples, but I still wanted to try them out. Some of the code was very repetitive and not so much for learning as just getting a working example.
  • A lot of topics just skimmed the surface. If the book covered everything in depth it would be 10,000 pages long. I understand that not everything could be covered fully. However, without a lot of experience certain chapters left me desiring more explanation. The typography chapter was the toughest for someone without typography experience.
  • Code beautification. This is totally nit-picky, but I have serious issues with code that is hard to read because of indentation and trying to fit everything on one line rather than spacing things out. There were several examples in the book that were intended to be the right way to do things that were an indentation cluster. For a book focused on standards and making code easier to maintain and use I expected more.
Overall I enjoyed this book. It is useful for designers as well as developers. While I found this book educational, I think the companion book, Developing with Web Standards by John Allsopp would be more to my liking.

Sunday, December 19, 2010

Where There's Free There's Me!: Dive Into HTML5

I came across a free book on HTML5 this week.  I started reading it, but it's pretty long so I'm going to finish it up sometime in the future.  From reviews and reading the first chapter I can already say it's going to be good.  Mark Pilgrim wrote Dive Into HTML5.  It is released under the CC-BY-3.0 license so it's free to read online.  If you love holding a paper copy you can also buy the print copy from Amazon.

Monday, December 13, 2010

Book Review: Head First JavaScript

Yesterday, I finished Head First JavaScript.  This is my second Head First book and it was exactly as expected as far as the learning process was concerned.  I really like Head First's approach to learning.  It makes difficult concepts understandable to everyone.

This book is structured much like other programming language books.  Data storage, decision making, loops and functions are all covered.  Toward the end of the book concepts that are more unique to JavaScript are covered such as forms, DOM, objects, and dynamic data.

When I read Head First HTML with CSS & XHTML I had nothing but praise in my review.  The JavaScript book is a little bit different.  Although I thought it was very informative and worth the read, it had a few glaring weaknesses.

Keeping JavaScript functions in a separate file was briefly touched on and then rarely used throughout the rest of the book.  I am all about practicing good habits and I didn't feel like this technique was reinforced.

The examples were not as workable as the Head First HTML with CSS & XHTML examples.  The were much longer and provided by the book website.  This was fine, but I found that I could probably go the entire book without writing a line of code which was discouraging.  It took some self motivation to try to do some of it myself.

Finally, the book did not cover or even mention some important advanced topics in JavaScript such as Events and Try...Catch.  I realize everything can't be covered in the scope of this book, but at least some mention of them would have been nice.

Overall, this book was worth the read, but the time may have been better spent reading a more comprehensive JavaScript book.  Next time I read a JavaScript book it will probably be JavaScript: The Definitive Guide.

Saturday, December 4, 2010

The 4-Hour Workweek - Chapter 5 Comfort Challenge: Learn to Propose

The challenge for the last two days has been to learn to propose.  The goal of this challenge was to stop asking for the opinions of others and propose solutions.  When I read this challenge I knew it would be difficult for me.  I'm a very go with the flow person so my automatic response to "What do you want to do later" is "I dunno, what to do you want to do."

This challenge was harder to practice than learning to eye gaze because there are less opportunities.  Obviously, you make eye contact with people as long as people are around.  Proposing solutions doesn't come up in every conversation you have.

I caught myself in this situation a few times are tried to propose solutions.  Usually they were good, but at worst they started a discussion that at least made progress to a solution.  The only time I failed was suggesting having lunch outside and then getting stuck in the rain.  I wouldn't consider that a terrible failure though.

In one conversation I fell back into old habit when having a conversation with co-workers about what time we should start working on our off day.  My response was "whenever is good with you guys," which turned into everyone passing the torch and blankly staring at each other.  Proposing a solution would have made this conversation shorter, more decisive, and less awkward.

I'd like to make this a practice in my daily life.  I saw a lot of benefit to be part of the solution rather than a bump on a log.