expiration notice

There are a lot of people subscribed to this feed in Google Reader.. I hate to be rude, but I’m going to delete it August 1. If you’re not all just bots and would like to continue seeing these posts, please update your subscription to the new feed address from this blog’s new home. The site is totally live and more or less stable, so it won’t be moving again, or if it does I’ll be able to set up a redirect. If, on the other hand, I annoy you and you’ll be glad not to see my posts in your RSS feeds anymore, you don’t have to do anything cause this is it.

For you Google Reader people, here’s a button:
Add to Google



So I’ve been stalking the domain name garann.com for years, waiting for its registration to lapse. I could probably trace this back to never being able to find my name on the souvenir mini license plate racks in gift shops as a kid, but I prefer not to examine it too much more deeply than that. I like having shit with my name on it, the same way my cat likes to rub his head on everything (i.e., these are my THINGS!). Today I happened to notice it was up for sale again and went and snapped it up right quick.

This whole blog’s been moved over to the new site, so this will be the last update here.

10 web revolutionaries

This is sort of a reaction to Mashable’s “10 Founding Fathers of the Web”.. Those guys appear to belong in several very different categories, like someone was just randomly throwing out big names. The comments on that post give a much more accurate picture of people you’d be likely to think of as “founding” the web. Everyone listed helped move the web forward, but the mixture of guys who created fundamental parts of the web’s infrastructure with guys who sort of improved on existing concepts is confusing.

Regardless, thanks for founding the web, dudes. It is a very nice web, and much appreciated. However! This is Independence Day and sitting on the lawn drinking Budweiser and pointing bottle rockets at your neighbors isn’t something you do to celebrate quiet perseverance in service to science and progress. You do it to celebrate revolution and fucking shit up. In the spirit of the latter, these folks are ten of my most favorite web revolutionaries:

1. Joe Burns

In terms of revolution, I see Mr. Burns as a kind of Martin Luther, bringing HTML to the people. Specifically, in my case, bringing it to people who were teenagers and without HTML Goodies, wouldn’t have known where to begin researching the fledgling art of web development. It became the primary resource I pointed other beginners to during my time as a community leader at Geocities. Eventually it stopped being relevant to what I was doing, but I continued recommending it to people just starting out for years after I quit actually using it. There were a lot of sketchy resources at that time, a lot of conflicting information, dogma, and superstition – it wasn’t the most technically advanced guide in the world, but it was more reliable than many and accessible to anyone.

2. Jennifer Ringley

I have to admit I never actually saw JenniCam, so I guess this is all kind of hearsay, but I remember plenty of discussions about it. It was strange and crazy for this woman to set up a webcam in her dorm room. It changed the web socially, but I think it’s also fair to say Ringley and subsequent camgirls played a part in changing it technically. If video on the web hadn’t moved beyond pictures of fish and into voyeurism and pornography, I don’t think we’d be talking about video in HTML5 today. Certainly at some point, but not today.

3. Craig Newmark

In contrast to the oversaturation, the technical complexity, and the questionable motives of most of the web, Craigslist is plain, small, and genuine. Not such a big deal when it started out, but I think its refusal to change with the times is what makes it revolutionary. Sometimes changing with the times is bullshit. While the rest of us throw every damned OAuth connection and -moz-cupholders:5000 we can find all over our websites in hopes of generating more interest than the thousand other sites we’re competing with, Craigslist does one thing very well and continues doing just that one thing, without gimmicks. Ignoring the very minor tweaks along the way, there’s something to be said for that kind of stubbornness. I could post this same thing almost anywhere on Craigslist and more people would see it than will ever read it here. As Facebook overtakes MySpace overtakes Friendster, Craigslist remains constant and eternally popular.

4. Nate Oostendorp

At the time I discovered Everything2, I didn’t know of anything else like it. Livejournal may have been around at that point. Wikipedia most certainly was not. Flickr, the site that bears closest relation as far as I’m concerned, was just a twinkle in some young developer’s eye. A decade later it continues to exist and there’s still nothing like it. It’s similar to Craigslist but also completely opposite. The nature and purpose of E2 changes with each successive wave of moderators, features come and go in slow reaction to technological fashion, and it remains completely fucking obscure and yet a huge part of the lives of a relatively small group of people. Given that what makes it revolutionary is its unceasing anarchy, it seems a little weird to hang it all on one person. On the other hand, I think I’m probably correct in believing E2 was the first site to ever be so fully handed over to its users, and for that he’s a pioneer.

5. Zeldman

Seriously you should probably just take your can of Budweiser and go re-read “To Hell With Bad Browsers”. It’s way more inspiring than this drivel.

6. Dave Shea

I remember using CSS Zen Garden and the ALA article mentioned above as a two-pronged attack against my boss’ policy that we were going to keep marking up our website in tables until armed terrorists broke in and made us stop it. CSS Zen Garden was sort of like Stalin to ALA’s Marx. It’s also one of the most elegant proofs of concept that I’ve ever seen. Not only could this professional design guy style carefully structured markup to look more or less like what a client wanted, tons of other web guys and girls could style exactly the same bare-bones markup to look like any goddamned thing they could imagine. I still think it was a huge fucking deal.

7. Holly Bergevin

I’m resisting the urge to extend the Marxism analogy all the way to its breaking point here. Instead I’ll just ask where we’d be without the Holly Hack? I fear it’s always going to be the case that the dominant web browser is a decade-old version of IE. Without IE hacks, the web would be nowhere.

and 8. John Gallant

And the problem is never just IE. I’ve torn my hair out over all the others, too. PIE made it possible not to give up. Idealism is awesome, but we’re always going to need someone documenting the realities and, in doing so, keeping the pressure on.

9. Crockford

Last week at work I was in an argument about whether we were going to offer a version of a product that didn’t require Javascript. Imagine that five years ago. Imagine even considering not having a noscript alternative then. A hell of a lot of people contributed to this massive shift – some of them mentioned in the Mashable thing – but Crockford stands out to me because he’s promoting all the “good parts”, not just one specific technique or library. I’m not going to go on about it. You know why Crockford’s awesome.

10. Nicole Sullivan

I don’t see anyone better poised to do for CSS what Crockford et al have done for Javascript. And god knows CSS needs the help. Even as the web collectively freaks out over the potential of CSS3, people are coming up with all kinds of crazy ways to avoid actually writing CSS and I’m getting in fights on Facebook about how CSS is fundamentally broken. I’m hopeful that Ms. Sullivan’s work is going to help CSS evolve to suit those of us who already love it (instead of to pacify the h4terz) and to get the respect it deserves.

All pretty subjective, but hey..

Happy Fourth. 🙂

defending terrible things

I’m sure all this has been said before, but it’s a minor obsession of mine. Ignore HTML5 for a second, and all the interesting things happening with Javascript and CSS. I’d like to discuss the kids in leather jackets smoking cigarettes behind the gymnasium of web development: <b> and <i>.

And WordPress is going to make my first point for me. I’m typing this in their WYSIWYG and the buttons for bold and italic are a little b and a little i. When I toggle one on, it becomes /b or /i. And yet the HTML that gets inserted is <strong> or <em>. Why?

Point 1: The bold and italic tags do exactly what the fuck it says on the tin.

If you want something in a division on a page, there’s a tag for that. If you want something to be a heading, there’s a tag for that, too. These tags, like all others, accomplish what they do only through conventions of browser manufacturers, but can nonetheless be relied upon to get you some semblance of what you want even if your CSS should be mysteriously and tragically abducted in the middle of the night. Like the bold and italic tags, they tell you very little about text they contain. But nothing in HTML tells you about the text it contains. It does, however, sort of tell you what it’s going to look like in a webpage and describe the role it will play in the page’s structure.

Point 2: If you want semantic markup, use XML.

XML is a very handy little language that will let you describe your precious digitized text as precisely as you want. You can style it and present it on the web and get exactly the same thing you would from a document full of non-semantic <div>s and <span>s. Or, hey, put even more <span>s in and give them all seventeen class names and call it a microformat. I hope you have a really, really fun time doing that. If, on the other hand, you’re willing to consider that your consumable data and your pretty website need not be the same beast, you could just keep the XML somewhere else and if anyone ever actually wants to scrape all the air dates and titles of the Buffy the Vampire Slayer episodes you recorded on VHS, let ’em just grab that.

Point 3: Why this webpage is shouting at me!!

You know what strong and emphasis refer to? They refer to verbal inflections. You know what most peoples’ web browsers don’t do? Talk to them. You know what would annoy the shit out of me if I were using a screen reader to read a bibliography on the internet? Listening to a goofy-sounding computer voice try to emphasize every single word of Journal of the Study of Obscure and Mostly-in-Latin Canine Diseases Affecting Generally the Respiratory System but Also Sometimes the Lymph Nodes or something. I don’t know that this is still a problem, but the idea is ridiculous in and of itself. Italic does not always mean emphasis, nor does bold always mean MAKE THIS LOUD. Certain conventions of formatting require the use of bold or italics, but actual writing rarely does. If you need to place emphasis on something, you can do that with word choice. (Or anyway I hear it’s possible..)

Point 4: Character count

When I first started doing professional web development, lots of things weren’t digitized. Therefore I spent a lot of time marking things up, enough that I began to have those horrible almost-nightmares where you’re doing the same task over and over and you can’t stop doing it or thinking about it. If semantic markup had been a buzzword back then and every <b> had to be a <span style="font-weight:bold;">, I probably would have gone back to working at Chevron. The bold and italic tags are short. The emphasis tag isn’t bad, but the strong tag is way too long to be a good value per keystroke. This is to say nothing of what you should actually be doing if you want to keep your presentation and your tags altogether separate, using a span with a CSS class describing the content and not merely the fact that you want it extra heavy. I mean, sure, I will always use CSS to bold or italicize something if there’s already a tag around it. Nine times out of ten a bold or italic tag would be inappropriate there anyway as the font weight or style is purely decorative. On the other hand, if something needs to be weighted or styled differently and has no containing HTML element, fuck it, I’m using <b> and <i>. They’re shorter.

Point 5: Dirty tricks

I add <b> and <i> to things I don’t necessarily want bolded or italicized. I do it because they’re some of the shortest elements available and they provide a hook to style child elements in larger repeated widgets with very precise, complex layouts. If I have to wrap every word of text in a tag just to accomplish some goofy layout, I’m using the smallest thing available. Especially if the widget in question is something I’m inserting dynamically and I want to keep it in a string without spaces and still be able to sort of recognize what’s in it without needing four monitors just to view the whole thing at once. Again, if Something Better exists, I always do that first. But there are times when nothing you can do is going to be semantic, screen-reader friendly, or anything you’d want your mother finding out you’d done.

One of the most beautiful things about the web is its imperfections. We don’t write firmware for missile guidance systems, we write applications that let you pretend to steal your friends’ cartoon cows. There are places for flawlessness and obsessive semantic control, but this isn’t one. When you can write elegant code, it’s awesome, and I think most of the time everyone tries to. But it’s important to realize that at the end of the day, this is all kind a series of epic hacks, and sometimes the most sane thing to do is just embrace it.

CSS, live(), and application state

An idea I ended up thinking a lot about as a result of the application rewrite I just did was managing client-based application state with CSS classes. I’ve been making mental lists, trying to figure out how far you could take it and whether it would be useful. I was thinking there was probably some performance caveat or something, but then I read this post on the relative speed of live() and now I’m thinking maybe it’s something worth exploring more.

Using (what used to be) my application as an example, I can see a few possible states..

  • Edit mode for the object’s owner
  • Display mode for the object’s owner (so, surfacing links to access the edit mode)
  • Display mode for non-owners (no edit links)
  • Live mode (same as above, but possibly with more data about what the object is doing in whatever context it’s been published or released to)
  • Error mode (tracking needed corrections)
  • …?

You couldn’t use switching classes alone to manage those if there were roles certain information had to be hidden from – you’d have to take care of that on the server, obviously. And you’d have to check permissions on any type of update, but presumably you’d be doing that anyway.. For my application it would work fine, though. For certain pieces of the application, I implemented a pared-down version and it’s pretty successful.

What I actually tried was really simple. I just applied a CSS class to a container, causing pieces of the interface to be shown and hidden. Event handlers for those elements were attached with jQuery live(), so that as stuff gets added and removed, its event handlers are already (usually) set up and switching states merely reveals or hides the elements that trigger them.

Examples of WTF changing the “state”/container class actually does..

  • Show/hide edit buttons
  • Change an element’s event handler
  • Enable form elements
  • Change layout to reveal spaces where new elements can be added
  • Hide error messages
  • Disable iframes (I need them – don’t judge)
  • Determine whether areas that contain actions that aren’t automatically surfaced react to hovers
  • Reveal state-specific information

Especially with regard to changing event handlers, I’m assuming jQuery live() was designed with this use case in mind? What I mean is like:

$("div.editable a.editItem").live("click",function() {
$("div.error a.editItem").live("click",function() {
alert("Nice try. Fix whatever you screwed up, then we'll talk.");

I think this is just handy as hell, but every time I try to google information about how other people might be doing the same thing, I come up with nothing. So in the absence of any best practices or warnings, I’m still playing around with it on my own. I think it’s cool.

bra of uncertainty

Seems I may never know how the jTemplates experiment would have turned out. Same with the WYMeditor experiment, which I haven’t mentioned here, but trust me, has been lengthy. I’ve got an amount of time somewhere between zero days and two months to get my ducks in a row and make whatever further enhancements I want to make before moving on to something different. The team I’m currently on will continue with the same product for a while, but without a UI person. Considering that a large portion of our product is the client-based application I just rewrote, that means that in a substantial way, the product is entering maintenance mode.

The new project is cool, though. Last week I got handed a list of things to prototype, and I love prototyping. Imagining the best way you can think of to have a user accomplish something and then architecting the solution around writing the sexiest possible code is the best part of development – frontend or otherwise. Once you add the business’ opinions and the edge cases it can get to be a slog, but that comes later. I’m looking forward to making perfect little creations that don’t have to know a damned thing about SEC regulations.

But, there’s uncertainty.. My team is the only team with a UI Engineer that won’t be working on this new initiative. My other peers are staying with the projects they (or their positions) have worked on for over a year. They know their roles within their teams and how to work with their backend and QA people. I’m a little adrift, pulled into this as an extra body. I’ve been on the same team for over a year as well, and though I think they’re a little dismissive of the frontend, I’m comfortable with them.

They say you dress for the job you want, and they say clothes make the man or woman. It’s not bullshit, even in an industry where our fashion sense is just about the last thing we’re known for. Dressing well makes you feel more confident. If you’re a woman, you can’t overstate the role a decent bra plays in dressing well (or the role a shitty bra plays in making you look and feel like a broke-ass college student again). I’m told it’s the same for dudes and their shorts. So I feel excited but also freaked out about my job right now, I need the confidence to try and make a place for myself on the new project, and guess who’s going to Nordstrom this weekend?

I started buying good bras – big girl bras, the kind that don’t come off the clearance rack at Target – shortly after getting this job. Over the past ~2 years, I think I’ve become a much better developer. As good foundations go, buying decent underwear ranks right up there with learning C.

the jTemplates experiment

So it took a heck of a long time between the first proofs of concept and actually going live, but I rewrote a pretty complex client-based web application to use jTemplates. It started out with 12k+ lines of code (the numbers in that previous post don’t reflect various utility files, just the two main ones) and when I totaled it up on Monday, the new count is 3834. I’d been estimating it at about 5k. Less than 4k is better than I’d hoped. Even more impressive is that the previous figure did not include all the HTML templates that provided the pages their basic structure – the 3834 includes the jTemplates (since they’re all Javascript), meaning that’s it.

Summary: I am now a fanatical jTemplates convert.

However, I had a conversation over the weekend that’s got me questioning whether I’m sacrificing too much performance for maintainability. I won’t pretend the new application runs a lot faster than the old one. Its issues are different – this takes a long time to load, whereas the old one leaked memory over time – but it’s not blazing fast by any means. Part of the problem is the immense data object that the jTemplates process. All the information about a specific object is passed down at once when the page first loads, and then has to be pulled down again whenever the user switches between the four tabs in the application because of some irritating issues with the web services (the only thing they return is error messages, so if a new element is added, for example, it takes an additional XHR to find its ID) and data getting stale. I’m wondering, if I’m pulling down all this data anyway, if there’s an argument for putting jTemplates on the server and just getting the markup pre-loaded with the data points.

Of course, this is a .NET environment where I have pretty much no control over the backend, so it’s not likely I’ll get to try jTemplates on the server. I can’t find evidence that anyone’s ever tried that, so who knows, maybe it’s impossible.. Instead I’m going through all my notes from txjs and applying every performance enhancement I can find to any code I’ve touched over the past couple days. It’s not giving me an improvement so far, and I’m beginning to feel this is a design problem. If there were a way to split up the data being pulled down and lazy load interface elements, I think things would speed up a lot. Sadly, there’s (currently) not.

I’m left with 4k lines of Javascript I’m very pleased with having shrunk and no clear path forward, which fucking sucks. But the application is clearer and more well organized. I guess the experiment continues..

RSS Recent posts on the live version of this blog

  • An error has occurred; the feed is probably down. Try again later.