Articles by Ben Schwarz

Stress, and creation

I was recently having one of those “life, the universe and everything” conversations with a close industry (web) friend.

Mid-conversation I dropped that I’d identified three kinds of stress that we face as creators – it felt somewhat poetic at the time, so I thought I’d take some time to describe it.

Physical, the kind of stress you’re under when you’ve been eating poorly, drinking too much, exercising too little, or working too long. We’ve all been there, but for the most part, it’s manageable.

Mental, you’ve got things floating around your head that are manifesting into bigger problems or you’re lacking the focus to handle what the real issues are. This is the hardest to self-diagnose, and is firmly linked to physical stress.

And finally, emotional stress. This can be the most difficult aspect of your working life (if you’ve got the first two covered) – it relates to how you’re feeling about your projects, clients, coworkers, bosses, or pretty much any other work-related situation. In my personal experience, this kind of stress can be the hardest to deal with, because you usually have to change something that you don’t really want to.

Having said all of that: I’m confident, ready, willing and able to deal with anything the world throws at me, but only as long as I’m producing work at a level that I’m satisfied with—That is, I’m defined by what I create.

To quote Ben Pieratt, “Creation is a deeply personal and rewarding activity, which means that your Work should also be deeply personal and rewarding. If it’s not, then something is amiss.”

I firmly believe that we – as creators – trade a lot more than just time to practice our craft. We delve ourselves into our projects, and there are many costs incurred to build truly amazing things…

False fears

I recently read the conscious startups manifesto and it made me realise a few things about the way that I, my friends, my clients all run our businesses, projects and generally, lives.

It’s often a part of my role to ask clients if they really need something that they asked for, to understand their domain and make rational calls on what they should spend their budget (and my time, but that’s another story) doing, and as an arbiter (consultant) its very easy to do without emotion or fear.

So I got to thinking, why aren’t I releasing more projects?, my own apps, the things that sit half finished on my computer somewhere to never been seen by someone? It certainly isn’t a commitment thing—sometimes I love these things to death and for whatever reason they don’t live.

I think it’s false fears at work, we place them over every decision that we make—it needs this or that feature, or “the customers” (I hate calling people users) won’t like it because of x or really, whatever. It’s paralysing. I’ve dropped ideas before because I was scared of the ‘opportunity cost'… I’m getting old here, I can’t do everything, and I feel indebted to my projects.

There is no value in hoarding away your treasures. If you’re genuinely creating things that you want to share with other people, then put them out there, fail, make mistakes and poor judgements… but for gods sake, do something!

I’m working on it too. Good luck.

Stepping into attribute selectors

For years we’ve been using IDs in our markup: #wrapper, #page, #header, #footer, #sidebar and other friends. One of the efforts of HTML5 has been recognising these common patterns, and for a for a few years now we’ve had tags like <header>, <footer> and <aside>.

These tags go quite aways to replacing the commonly used IDs in our markup, although due to the nature of document hierarchy, there are commonly many headers and footers within a HTML page.

So, the practice that I’ve been following alongside using the newer tags is the usage of some simple ARIA roles to semantically describe my content.

Specifically, “banner” (“A region that contains mostly site-oriented content, rather than page-specific content”), “main” (“The main content of a document”), and finally “contentinfo” (A large perceivable region that contains information about the parent document).

For those of you who aren’t targeting IE6, or better yet, totally not supporting it, the good news is that IE (7+) supports attribute selectors… and, of course if you wanted to continue to support IE6, you could drop in selectivizr and move on with your life.

HTML5, for web developers

Today marks a very special day — I’m proud to announce the official launch of the WHATWG HTML5 specification for web developers.

It features find-as-you-type search, offline access, beautiful typography, technical references pulled inline, and alternate styles for handheld devices or low resolution displays.

The aim? To produce a companion specification for web developers to use on a regular basis. All details that are considered “for browser vendors” are omitted.

Back in March 2010 I started a now rather well documented project to restyle all of the W3C’s specification pages, to make them more readable.

This project was moderately successful, I presented and launched the results with Mike™ Smith at Web directions south.

Time passed, and a lot of things happened, but in January 2011, I started logging to IRC—basically, to become a part of the web standards community.

Within 10 minutes of joining the WHATWG IRC channel (Read the transcript) Ian Hickson had granted me approval to continue with my own build of the spec, targeted for web developers.

In closing

Last week I wrote about participating actively in web standards. What you see above is the result of my participation with the WHATWG and W3C. As this project draws towards the end, I look forward to working with the amazing people who helped along the way—

Anthony Kolber (the other 50% of AB+C) Paul Irish, Ian Hickson, Jonathan Neal, Michael™ Smith, Oli Studholme, Bruce Lawson, Divya Manian, Lincoln Stoll & Dion Almaer, all—Thank you.

Taking the web back

Since the bookmarklet and W3C restyle project that I kicked off last year, I’ve been extremely fortunate—people, companies and opportunities have presented themselves to me like never before (let’s call it karma, but that’s just an aside) which has meant that I’ve had more first-hand exposure to working groups than most people.

Most web developers seem to have strong opinions about the W3C, without anything to really back it up.

That is, their frustration with the whole web standards movement has lead them to believe that the W3C are incompetent and act as a barrier for the web to move forward.

What I have witnessed first hand with the W3C as an organisation is that its representatives are extremely motivated people who genuinely care about the web as a medium, they are frustrated also, not only are they tied to an organisation that as moves slowly as an academic institution or a bank, but the unrealistic expectations that the web industry have of them.

To put a few things straight;

The W3C are not a figure of authority
The W3C do however attempt to act as a central hub of documentation for technical specifications that make up what we know as the web
The W3C don’t “make standards” they “create recommendations”
Some of their projects can be considered experimental

I don’t think that there is anything wrong with this, rather than construct a document of fiction, I’d rather pull together a real world use case.

As an aside, the mozilla developer center (MDC) has now shifted its focus to become a greater source of documentation for the web—in general.
I’ve begun to use this as a reference alongside the specifications.

Fact is that the W3C and WHATWG working groups receive a lot of feedback after the point; Many web developers do not realise that they must use existing communication channels to influence the future of web technology.

So, you… humble reader with opinions: Get your (virtual) ass into irc^{1, 2}, up on to the mailing lists^{3, 4} and form professional relationships with the people who are writing the specifications and making judgement calls.

Create a large and well considered feedback loop. After all, the web doesn’t belong to the W3C, WHATWG, apple, google, mozilla or anyone else. It belongs to all of us.

I personally not only want to understand my tools, but I want to shape the way that I interact with them also.

Lets take back control of the web together.

Citylink's new site

In Melbourne we have a traffic authority who have an automatic tollway / gate system that deducts funds from your account. Now, like every public service, people have their grievances†.

In the case of transurban, it’s how ‘citylink’ choose to conduct their business and treat their “customers”. (Its probably not worth going into what I’ve seen, but just think “like a bank ”)

Recently, @pda alerted me to the fact that they had indeed updated their website. Visually, its a reasonable improvement, however—

† Here comes one of those grievances

All logged in sections of the site use Adobe® Flex for the interface.

This is a web tragedy:

I can’t check my account status on my mobile phone
I can’t check my account status on my iPad
If I was using a screen reader, I’d be fucked

From the Adobe Flex documentation

"By default, Flex accessibility features are not enabled. 
When you enable accessibility, you enable the application 
to communicate with a screen reader."

I find it beyond incredible that a “professional” web developer would choose such a technology, for a government entity, for such a deployment.

The original designer of the site @michaelcassius tweeted that he designed it four years ago. I guess that’s a fair insight into transurban.

Update: Michael Cassius mentioned to me that while he worked on the project, it was done so while he worked with the team at Citrus.

W3C Design

While preparing my HTML workshop, I’ve been re-reading W3C specs in far further detail than I ever would’ve imagined. The reading experience is far from delightful. Not only is the text the entire browser width in measure, but it’s dense and laborious to read. No wonder browser vendors have traditionally missed subtle details.

Directly working on the improving the writing and review process would be far too difficult, I needed something and I needed it now. I set off to make the reading experience better.

My goal was to add some sane styles to the pre-existing spec pages that would vastly improve the reading experience.

I whipped up a quick bookmarklet to load some custom CSS. I was already happy. I wrote to Anthony; a typical kind of email that we would trade:

I promptly pushed my progress to github and added Anthony as a contributor.

Having attempted to read through some of the specs myself, I had to agree. They are by nature very dense documents, made all the worse by a lack of proper typographic consideration. Neither of us was up to the task of rewriting the specs themselves, but improving the readability of the page was a good starting point.

The typefaces

I wanted the titles to be large and image-like. No spidery, thin text; it needed to cement the content that followed. I chose Chunk from The league of Movable Type and used @font-face.

The main body typeface specified by the w3c is font-family: sans-serif, which resolves to Arial on Windows and Helvetica on Mac OS. Not a terrible choice, but while these typefaces give a clean, structured feel to the page, they are less ideal for large blocks of text. We switched out sans-serif in favour of Matthew Carter's Georgia, whose larger x-height and excellent hinting makes it much better suited to extended reading on screen.

The measure

When a typographer refers to “the measure”, they mean the width of the text body. Simply put, when copy is too wide or poorly spaced it becomes difficult to read. This was the first issue that I had; physically scanning back and forth over the text was annoying and frustrating.

The general rule for a comfortable measure is around 60–70 characters per line. Taking into account that each character averages out to around 0.5em in width, setting a measure of 33em should keep each line within the optimum range.

Useless information

Why do I want to know about this version, the previous version, editors and previous editors before I’d read any of the spec or its introduction? Perhaps this is useful internally, but for the rest of us, its just visual noise that could be removed.

Poorly defined hierarchy

A spec is hard to scan, its even harder to decipher the different levels of hierarchy. We decided to make a visual feature and pull the numbering out to the left, creating a column that overhung the original left margin.

We added an additional colour palette based off #066 to help clarify the multiple levels of headings. Colour variation is much easier for the eye to differentiate than the hierarchical number system the w3c currently employs. Additionally, #066 blends easily with the black body text — letting us emphasise links without them interrupting the reading flow. It also gives a nice tonal range to work with, all the way down to #cff which works well as a background tint behind black (which we used for the main code blocks).

#000 #033 #066 #399 #6cc #cff

Putting it together

Next up, a userscript version was in order.

The script is really simple; it just adds the styles and script tags into spec pages. The external script and style files are currently hosted straight out of the Github repository.

Going forward

We have spent a bit of time writing override rules to clean up the w3c's table and list styles and to reduce some of the more unwieldy page sections. Due to the complexity and variety of spec pages, it's an ongoing project. The styles will continue to be updated as we come across more awkward type treatments throughout the specs.

We haven’t styled every single element that we’ve come across through the W3C specs, so if you find something that looks out of place and feel like getting your hands dirty, please fork the project and send me a patch.

What would we like to see happen with this alternate stylesheet? w3c adoption. Until the w3c put further respect in to the standards that they govern for the world, we will continue to live in a web environment that has a poor understanding for its medium. Now, with WHATWG, communication and transparency and a “do-over” in HTML5, we can change the face of the future of the web. Now thats a project worth working on.

Before/After

– Best, Anthony + Ben

Stop writing plans

I’m often surprised when a client or co-worker decides to record the plans made during a feature design session when it has been decided that the feature won’t be completed during the next iteration. Seen someone take a photo of the whiteboard? How many times have you actually ever referenced those whiteboard photos?

I think I can personally count the occasions on one hand.

From what I’ve seen over the last few years of developing web applications is that the cream always rises to the top. That is, if you’ve discussed a feature idea through its courses, everyone in your team should be able to coherently dictate the concept.

When you decide to put a feature off, the notion of even considering its inclusion one day is a waste of time, that is; Muda (無駄). So why write it down?

Of course, there are always details that the project leads need to discuss in detail and occasionally put into words. But it should never impede on the creative process. Recording an idea is like making a contract that reads “we will build this one day”, this can be vastly damaging to the development of an idea or a business, and its why we see toolbars like this.

A “Good idea” can skew your vision and cause you to miss your real goals. Skeptics will say “Well, I have to tell our customers what we’re delivering.”, and sure; I get it. Really though, they’re thinking about it the wrong way around.

Write down the user story or scenario, not the implemented result that you’ve pre-conceptualised. That is, write about the problem that you’re aiming to address.

If it still applies in 6 months, go for it, plan it then with the new constraints of your application, not those that existed when you thought of the idea. An application is an ecosystem, not a series of features.

We all have great ideas, but to be fair to our craft, sometimes we have to forget them.

Web design with grids

If you’ve ever at all worked as a designer or peeked into the world of typography you probably realise that “grids” are used to structure content.

Interestingly, working with grids (on the web) has only really come to popularity over the last few years. This is thanks to the work of people like Mark Boulton, Khoi Vinh and Garrett Dimon and, I must say it has certainly helped me begin to grasp information architecture far better.

In 2009 Tim Lucas kept a sneaky easter egg in the Web Directions South “Tweeps” mini-site. Basically, files named h-grid-12.png, h-grid-6.png and h-grid-1.png could be displayed using a secret modifier code (Its Shift+H, sorry Tim.)

The red tubes are “columns”, the gaps in between are known as “gutters”.

People, including myself are building sites using grids. Now it seems to me that when you’re designing in a browser† you want to be able to follow the grid’s principals all the way through the process.

Getting practical

When I first built my own web site (the one you’re looking at now) I used the following CSS technique, you won’t see it in action now though (I’ve moved on to the latter solution).

.col { float: left; margin-right: 20px; }

This sets an element to sit alongside any neighbouring floated element, in order of HTML appearance.

The element that sits in your last horizontal column probably doesn’t need a right margin, for that I used .col:last-child { margin-right: 0; }

Now while this is all very well and good, you’ll need to set some widths to get the columns filling out.

.one    { width: 100px; }
.two    { width: 160px; }
.three  { width: 220px; }
.four   { width: 340px; }
.five   { width: 400px; }
.six    { width: 460px; }
.seven  { width: 520px; }
.eight  { width: 580px; }

To apply grid widths to the design, I went through and added classes to my markup:

<article class="col eight">

This technique works pretty well, in fact I really like that you can jump into an element inspector (Webkit or Firebug) and change a column width to see how your content might better flow if it were arranged differently.

Criticisms

Now, this provides a pretty blissful working environment. Its simple and pretty quick to get started. (Also, we’re not doing anything scary in CSS to achieve this) I really feel that I can do better than this. I’ve never been a fan of littering your markup with no-meaning class names.

This is also the very same rationale that prevents me from using a framework like Blueprint CSS. Most of the blueprint users that I’ve come across say “its easy to comprehend, I can get a reasonable looking design quickly — and without a designer.”

Doing better

People who know me might already know that one of my biggest qualms with abstractions is that they prevent people from understanding the code or process that they’re abstracting. I feel very different about LessCSS — It uses real css, with some smart extensions.

So, my aim is to keep my HTML clean, semantically correct and reduce the addition of strictly presentational classes.

LessCSS provides some basic mathematical and “mixin” (explained a little, below.) features (Amongst others). These functions are run through an engine that returns good old regular CSS, it basically means that you get to write in a more powerful manner, producing wonderful machine-readable CSS.

Time for a deep breath!

.column (@width: 0) { width: 100px + (60 * @width); float: left; margin-right: 20px; }

This wonderfully powerful line of Less is a “mixin”, it means that I can “drop in” this style to another element selector.

article { .column(8); }

My articles will be exactly 8 columns wide, it’ll also handle the gutters!

Whats more is that there is also a default in there (the @width: 0) so if I wanted to set a selector to be a single column wide, I could use .column; and thats it!

Thankfully I can also be selective about elements that sit within the last column. Less is smart and won’t include the gutter (width-right: 20px;) when I do something like:

.selector { .column; margin-right: 0; }

For now, this is how I’m going to run. I still find it fast for layouts and easy to manipulate. If you’ve got some commentary or ideas on what would be better, be sure to drop me a line.

Hacking ruby's autoload

Recently, I wrote transcoder as a means of parsing common web formats (json, xml, rss/atom anyone?) without being too concerned about what a web service or API was returning to you.

I pushed out 0.1.0 hastily and went for sake, glorious, comfortable sake. I knew however, that something wasn’t quite right.

When transcoder was required' it would bring in all of its dependencies, so if you were only hoping to parse a yaml file, you got everything: json, xml and rss. Not good, too much.

Ruby’s autoload

Autoload is a Ruby kernel method, you give it a constant and a filepath, when the constant is found to be undefined, it attempts to load the filepath. Fantastic right? Well, sadly. No.

Autoload will only load from your $LOAD_PATH, so I decided to roll up my sleeves.

Now, I’m sure that overriding Object is pretty much a no-no in nearly every circumstance, but Kernel as well? Ludacris!

In closing

No matter how bat-shit-crazy you might think this hack is, its actually very awesome.

Conclusion

I wrote this post full-well knowing that this was a pretty dirty solution – certainly not one that you would want in library code.

Where do you turn? To Evan Phoenix, thats who.

I explained the design problem that I was faced with to Evan. One of the most magical things about the Rubinius project is that Evan and Brian are implmenting Ruby IN RUBY.

They’ve probably thought about or wrestled with similar design issues or requirements while implementing the core ruby language.

Evan explained a design solution, and I implemented it. Hopefully I didn’t trample too much over this. A big thanks is due to Evan.

Growing up

In January, Tim Lucas pulled together a shiny new site and boosted his article quality dramatically. I thought “he’s doing it right”, I really wanted to get my site together. That was January—here I sit the day before August staring into textmate typing the first article I’ve written in almost 2 years, I haven’t even bothered to move those old posts. It wasn’t worth it.

During this year I’ve made more open source releases and contributions than ever before, I’ve lapped up various technologies and concepts, wrote my first DSL with ruby and felt like I was pushing through to another level, mentally anyway.

Its not hard to say that leaving my salary paying job and moving to consulting was one of the best things I’ve done. It felt selfish to leave the team for a reason none other than “I needed time away”. That was a year ago. Since then I’ve had more time to reflect on life and importantly, development.

Juicy details

You might notice that the new site has a bunch of links to various web services. I’m pulling my “about the author” image from twitter, “upcoming events” from upcoming, “projects” from github, “presentations” from slideshare, “links” from delicious and recent images from flickr – all using Smoke, not only that, but I do so using only about 45 lines of source code.

I was inspired by Yahoo’s “Pipes” but frustrated with the strange act of dragging elements around the screen. While knowing what I wanted to do, I found that I could probably write a custom parser faster. A vast majority of the research or ‘learning’ projects that I’ve put together consume web services. Now, with Smoke I can pull services together, mash them up, cut them to pieces and re-interpret the web the way I feel it should be.

The article facet of this site is pinched straight from Tim Lucas' site, I dropped it in, it worked, I drank beer.

I typed a series of commands (maybe, 5?) and my site was running on Heroku. Job done. I’ll probably leave the beer alone tonight though. What an awesome experience that was, I’m a fan of doing it yourself, but this quick win felt so good.

For now, I’m going to run without comments, if you’ve got something to stay ensure that you drop me a line, I’d love to hear about it.

The markup used on the site is HTML5, thanks to Lachlan Hardy it even displays pretty well in IE6. No hacks are used, perhaps a few CSS methods that don’t appear in older browsers, however the fallback is indeed graceful.

I’m responsible for the design of the site. Anthony gave me moral support, slapped some layout tips and rules on me when I asked for them. I think he found it really hard to watch me go through the process of putting the site together. Generally, when we work together he is the design part of our voltron machine. In future I’ll leave our client design work up to him.

In closing

A web site is never “done”, I hope to evolve this site and keep it as fresh as I can for as long as I can (using technology, of course). Perhaps I’ll end up writing better… God, I failed english in high school because I preferred to skip it to eat chinese and play pool with my friends. If it doesn’t kill me it’ll only make me stronger, right?

RubyKaigi, a western perspective

I booked everything only 3 days before. Rushed around to shutdown the office for a couple of weeks and get everything in order. I woke up the day I was to depart feeling like I was getting a cold. I avoided packing until an hour and a half before I left for the airport.

As the plane descended into Narita I felt a throbbing pain in my ear that felt like the side of my head was going to explode like an ACME bomb on a roadrunner cartoon.

That lasted for at least two days, I had managed to take a full jar of echinaccia by the third day. Appropriately, I shook the bug before it settled in – Anyway, this was the most disorientating feeling I’ve ever had. I was partially deaf, that is; I had to turn my head to my right ear to understand conversation with (english speaking) people.

What a contrast from the Melbourne winter! (max 14ºc) Tokyo was 33ºc and around 90% humidity. If Tokyo wasn’t already disorientating enough with the bright (like daylight) city lights of Shinjuku, the visual noise of the subway maps and the sheer volume of people everywhere.

During the week of the RubyKaigi, we managed to have dinner and drinks in a michelin star rated restaurant, hang in an awesome japanese metal / rock bar, attempt to go to the fish market (straight from the awesome bar) and scream “ruby ruby ruby” along with the kaiser chiefs most nights (at least once in an ‘all you can drink’ karaoke bar)

The visual impact of Tokyo streets blew me away. As did the friendliness and acceptance of the japanese people – even with the 5 or 6 japanese words that I poorly executed to get my way around.

Although I was the invader, I found many japanese locals to know far more english than I did japanese.

On my first night in Tokyo, while running late to dinner the manager of a small connivence store walked me from one end of a massive train station to the other, where I needed to be to catch a specific line. He also taught me how to fish, rather than just showing me where it was. I thanked him, he bowed and trundled back to his store.

Where is this going anyway?

Not really anywhere, it was a long way home from Tokyo and I thought this post during a warm embrace with my headphones and iPhone.

Rubykaigi is almost more than 60% japanese content

Leonard Chin was a superstar, he had live translations on a second monitor in all of the japanese sessions that I attended. Anyway, I skipped more than 60% of the talks at Railsconf this year (having a current technical talk at these big conferences is almost impossible). Most times conferences are more about going to meet and hang out with other like minded people. RubyKaigi was awesome and it’ll be pretty hard to not attend next year. See you there?