Colleen Jones’s book, Clout: the ART and SCIENCE of INFLUENTIAL WEB CONTENT, faces this problem from the outset. Right there on the cover it straddles the fence of condescension. Its subtitle invokes the renaissance and dares to use the word “influential”: Influence being the characteristic sought by all who write content for the web but never mentioned explicitly for fear of being judged manipulative.

In that way, Jones’s title teaches us the first lesson the book has to offer: Sometimes it’s better to be explicit than pretend to be something you’re not.

Inside the book, the lessons continue and it’s quickly evident that these are lessons for the less informed content creators. The reader is eased into the concept of content strategy. For the uninformed it’s an introduction while the informed are given some ready-formed arguments to help sell the idea of content strategy to those who need to buy it.

Jones’s book is a primer for content strategy, focussing more on creating content with a taste for the planning and analytics that go along with other parts of the strategy. She describes in appropriate detail why creating the right sort of content is difficult and how it’s a job that is never really finished.

Important for any introductory book, and successfully achieved by Jones, is informing the reader that there is still so much to learn before becoming an expert. Throughout Clout, she refers to the other leaders in content strategy like Ann Rockley, Kristina Halvorson and Erin Kissane, and she prescribes further reading into areas of marketing, planning, heuristics and analytics.

In Australia we’re particularly bad at explicit instruction. The title garnered some judgement amongst colleagues and judgemental looks on public transport. Our attitude is often “what could a book tell me about what I do?” The answer is: “A lot. Now, shut up and read.”

Clout puts the concept of content strategy into perspective for those who do it on a daily basis and those who are new to the idea. For those of us who work in the field, it serves as a reminder of what it is we’re trying to achieve and who to talk about it to those who have no idea.

We believe very strongly in semantic mark-up and getting things working as much as possible in as many places. We believe in graceful degradation. I believe in closing tags once they’re opened and I didn’t like how HTML5 didn’t demand a trailing slash on stand alone elements. That just seemed like chaos.

Jeremy Keith‘s new book, HTML5 for Web Designers is a no-nonsense 85 pages of the good and bad in the HTML5 specification. It explains how the spec is a lot more open and forgiving than previous specs. It also explains how much work was done to ensure better semantics than previous versions of HTML.

You’re probably thinking exactly what I was. How can any 85 page book tell me what I need to know about the largest HTML specification thus far? Is 85 pages even a book or is it more like an extended pamphlet? How can I take this seriously?

We bought the book largely because we trust the work Jeffrey Zeldman does. This is the first book he has published under Happy Cog’s new A Book Apart label. I thought that if anybody can get a writer to condense all the info I need into a short read, it’s Zeldman. But no pressure, JZ.

The important things it explains is how HTML5 can be used to include rich media on your websites, how it improves web forms (which got me really excited) and how it improves on semantics. And yes, it does actually explain them.

It explains these topics in enough detail that I could start using them today.

I want to keep learning and improving my knowledge of web-based coding. At the same time, I’m running a business now as well as continuing to produce a weekly podcast and trying to have a life. It’s hard to keep up with all the details of a new spec.

It turns out, all I ever wanted was an 85 page book that explained everything I needed to know and cut out all the stuff I’ll never use. I don’t need a beginner’s book but I also don’t want an expert’s tome. I want an executive summary and that’s exactly what this book is. If that’s all you need, look no further.

HTML5 for Web Designers by Jeremy Keith is available from the A List Apart store in paperback or ePub.

Much like everything else that needs doing when starting up, it is the most important thing to do. Books about building a new business are full of suggestions about the most important thing to do. I suppose listing something and just saying it’s a helpful tool for getting the business on track is just not strong enough for the self-help book market.

I first read about assigning roles in The E-Myth by Michael E. Gerber. It seemed to make sense. It’s a really good way to get a quick understanding of all aspects of the business.

We sat down and tried to list all the departments that a business has: HR, Accounts; Sales; Legal; Project management; etcetera. Then we started thinking about all the other tasks that don’t have a “department” as such: copy editing; version control; domain name renewals; social networking; anything else we could think of.

There are only two of us and it can feel silly to assign roles when there are only two people in a brand new business. The thing is, there won’t always be only two of us. We plan to grow quickly and well. The only way to do that is make sure we have all the roles in the business outlined so that a new employee can take over some of those roles.

The thing is, we’re both going to be working on every part of the business. So what we did, instead of saying “I’ll do this and you do that”, is to just split roles into who’s taking the lead on each.

That way there’s no demarkation issue on roles. We don’t step on each other’s toes or cut each other’s lunch. A partnership is still a partnership. We are both involved in every part of the business but now, when a process falls over, we can see whose responsibility it was. We can look at why it wasn’t taken care of.

And that is a really important part of running a business.

EYKACIW! begins by explaining how today’s web developer has hacked CSS to do things it was never designed to do, in much the same way that we hacked HTML tables in the heady days of the 1990s; floats, faux columns, negative margins, positioning, and, several more tricks now used as a second nature all get dishonourable mentions.

I’m not so sure

EYKACIW! points out that there is no CSS table equivalent of the col- and rowspan attributes in an HTML table, a method is detailed in the book to emulate these features with absolute positioning (also available on Kevin Yank’s Sitepoint blog). The method detailed brings to mind the very hacks we’re being discouraged from using.

Another problem I can foresee is that CSS tables will increase, rather than decrease, the amount div bloat required for a typical layout; replacing <table><tr><td> in an old fashioned HTML table layout with <div><div><div> – these otherwise redundant divs aren’t necessary for a basic layout, but seem to be inevitable for layouts requiring nested tables.

Hold your horses (and other clich’s)

These are my initial reactions to reading about CSS tables, in some ways it reminds me of my reaction – when learning CSS – to reading that the width of an element doesn’t include the padding or the border; my reaction back then was ‘but that’s stupid’, now it’s just second nature and the concept of including the padding and border is foreign.

EYKACIW! is about CSS tables, with an introduction to other CSS3 layout modules in the final chapter, modules that aren’t implemented in any browser – such as the grid positioning module and the template layout module – these modules excite me, CSS tables seem to require a different set of hacks, and – to paraphrase Regurgitator – I like your old hacks better than your new hacks.

It’s possible that the problem with Everything You Know About CSS Is Wrong! is that it was released too early; maybe it would have been better timed for a couple of years down the track when these new modules are in our browsers; regardless the book will cause a lot of discussion within the developer community about the direction in which CSS3 should go, and that’s only a good thing.