Tragic sans

If Comic Sans could talk ….

You think I’m pedestrian and tacky? Guess the fuck what, Picasso. We don’t all have seventy-three weights of stick-up-my-ass Helvetica sitting on our seventeen-inch MacBook Pros.

….

Sorry I’m standing in the way of your minimalist Bauhaus-esque fascist snoozefest. Maybe sometime you should take off your black turtleneck, stop compulsively adjusting your Tumblr theme, and lighten the fuck up for once.

….

People love me. Why? Because I’m fun. I’m the life of the party. I bring levity to any situation. Need to soften the blow of a harsh message about restroom etiquette? SLAM. There I am. Need to spice up the directions to your graduation party? WHAM.


While Avenir is practicing the clarinet, I’m shredding “Reign In Blood” on my double-necked Stratocaster. While Univers is refilling his allergy prescriptions, I’m racing my tricked-out, nitrous-laden Honda Civic against Tokyo gangsters who’ll kill me if I don’t cross the finish line first.

Pepsi vs. Coke

Pepsi vs. Coke Logo Evolution
Via: Online Schools

Funny but not exactly true.
Logo006

New site: Kanjiroo.com

Just wanted to mention my latest personal project, www.kanjiroo.com, a Japanese Kanji dictionary (a complete listing of 2000+ characters) in blog format. Essentially, I used the Wordpress publishing format to enable me to maniupate PHP to give me a unique web application.In other words, a dictionary-blog mashup.

Unconventional? Perhaps. But give it a try. Students of Japanese language will certainly find it useful.

(Hint: The top page is randomized, so if you bookmark it or set it as the default browser page, you’ll get some new kanji each day)

HTML 5: first impressions

While there’s been talk for some time about the future of HTML, including debates over XHTML 2.0, semantic web, and the like, the latest release of Firefox makes it more concrete by actually including some HTML 5 support. So I’ve been reading up on it a bit, and while it will fill in some holes — video support! — overall it seems somewhat muddled and disappointing.

Now we’re going to add all sorts of “semantic” items like nav, header, article, footer, which will absolutely not be compatible with older browsers.  (This ensures that  it will take years before it is considered “safe” to use. Pages such as this break in browsers as new as IE8!)  How exactly is this an improvement upon existing use of DIVs with class and id? You can use your DIV in any way you wish to accomplish all of these things. If a standard nomenclature was needed (like Dublin Core), that could have been standardized, as in <div id=”nav”> <div id=”header”> and so on. This works today.

The user will never see this anyway, and search engines could easily understand the semantic nature of these divs, since just about everyone uses the same names! (That was supposedly the basis of the research proposing these — they were drawn from he most commonly used div names) Google could easily — today — treat anything with an ID or class of “nav” as a navigation. Heck, it probably already does. So where’s the benefit for these major changes to the most widely-used document standard in the world? I’m not seeing anything that couldn’t have been achieved in other ways.

A while back, A List Apart had some suggestions for adding extensibility while preserving backward compatibility using attributes. (Ex: <div structure="header">) These were duly ignored. But the introduction is worth repeating:

I’m going to make a bold prediction. Long after you and I are gone, HTML will still be around. Not just in billions of archived pages from our era, but as a living, breathing entity. Too much effort, energy, and investment has gone into developing the web’s tools, protocols, and platforms for it to be abandoned lightly, if indeed at all.

Let’s stop to consider our responsibility. By an accident of history, we are associated with the development of an important tool our civilization will use to communicate for decades to come. So, when we turn our minds, idly or in earnest, to improving HTML, we must understand just how far-reaching the ramifications of today’s decisions may be.

This also seems a step back to the bad old days of font tags, b, i, etc. These were not only presentational, they were also not extensible or flexible. Class and ID enable great flexibility, so that new techniques can be developed and sites can be changed easily from a central style sheet. Now we are back to an array of one-trick ponies that are hard-coded into the HTML. And we will add more in coming years, which will also break compatibility.

Headings and sections

And then there’s those sections:

<section>
  <h1>Level 1</h1>
  <section>
    <h1>Level 2</h1>
    <section>
      <h1>Level 3</h1>
    </section>
  </section>
</section>

Maybe I am missing something, but the current usage of h1, h2, h3, h4, h5 and their child paragraphs are equally structural, giving clear hierarchy. Is it really better to only use h1’s in nested sections, rather than the less verbose use of numbered headings?:

<h1>Level 1</h1>
<p>Level 1 content</p>
   <h2>Level 2</h1>
   <p>Level 2 content</p>
      <h3>Level 3</h1>
      <p>Level 3 content</p>

Even the video element, which I welcome, might be messy: Is it clear that everyone will switch to OGG or Vorbis or whatever the spec says? All we need now is Microsoft and Apple strong-arming everyone to push their video formats as the standard. Isn’t this why Flash video took off in the first place — because it bypassed the OS makers video format wars?

So, is HTML 5.0 a consequence of the latest round of browser wars? Perhaps the rush to beat the competition has pushed Firefox, and soon the others, to rush into HTML 5.0 without adequate thought.

Also, is this a case of browser and OS makers strong-arming the W3C into making HTML a friendlier place for their web apps, rather than the ideal that the users, coders and designers would have wanted?

Many of the fixes in HTML 5 seem to solve non-problems. It is also not future-proof or extensible. In 5 or 10 years, they will need to add entirely new elements, and remove some older ones. So we are stuck with never have a truly extensible standard that is backward and forward compatible.

I’m not against progress, but I think they could have done better than this.

Sandbox theme

A quick note: I just changed my Wordpress theme* to Sandbox, the extensible, semantic WP theme. It’s used on Wordpress.com hosted blogs since people can’t edit PHP files. I can but wanted to try out Sandbox and see how much I can do with pure CSS. Right now I just pasted my tsooki css file but have yet to customize it fully. Stay tuned.

* My older theme wasn’t as “widget-ready” as I had hoped when I added a ReCAPTCHA plugin for comments.

Why attractive things work better

Over at the always-excellent A List Apart, an insightful piece on the debate between usability and aesthetics, with a bit of dabbling in psychology.

Perhaps that is why this is so hard to read. Technically, it’s not. It’s just unpleasant enough that it feels hard to read.*

* Hey, is any of that stuff peer-reviewed, any way?

The perfect photo-naming system

With something like 8 GB of new photos per year (and increasing) for my photo collection — and that’s after weeding out the bad shots — I’ve given a lot of thought of the ideal way to manage it. Here are some insights that might be helpful to others new to this:

  • Yearly folders: 2009, 2010 …
  • Monthly folders inside of those
  • Files named: YYYY-MM-DD — Year-Month-Date. This sorts automaticvally under Mac and PC file systems, and avoids the meaningless IMG_0001 filenames that come off the camera.You can use some free tools to set the filename automatically using the EXIF data (some metadata hidden inside the photo which records the date and other details when the photo was taken). Plus, if the photo is emailed or misplaced, or pulled off a DVD archive, it is immediately clear where it belongs.

As a bonus, if you want finer grained sorting, you can name them YYY-MM-DD HHMMSS — yes, that’s right, Year-Month-Date Hour-Minute-Second. I find this works well if I have taken photos of an event, and somebody sends me their shots of the same event. If the dates are correct, they will sort correclty, given you sort of a multidimensional view of the action. Colons between the HHMMSS would be best but are not allowed in names on most computers. (Adding dashes would make it look like a date)

(To take it to the extreme, you could use: YYYY-MM-DD HHMMSS NNNN. Some photographers like to keep the four digit number that their camera appends for cataloguingreasons and if they shoot bursts of multiple  photos per second. I haven’t found this necessary)

Why this date format? One thing I quickly realized, living abroad in Japan and Germany, was that there are numerous arbitray date formats which are not compatible and are confusing. The YYYY-MM-DD (optional HH-MM-SS) format is the best solution. The year at the beginning tells you you are not working with the America MM/DD/YYYY (or the European DD.MM.YYYY) style. This is also an international standard, ISO 8601, by the way.  More people (and companies) should use it. There’s no good reason to have every August sort together in a folder (08-2007, 08-2008, 08-2009…) or to have such confusion that airlines have to type out words for months (18-JUL-2009) to avoid ambiguity. But I digress.

If you need to add a title or label to a photo, I recommend adding it after the date, not before, or it won’t sort correctly: YYYY-MM-DD HHMMSS – Birthday party.jpg

Finally, these filenames are helpful for keeping every photo uniquely identifiable, but it is not sufficient. You really need to tag photos wih keywords (IPTC to be precise). You can do this with some free software like Picasa or iPhoto. The filename is more like a backup and organizer, while the keywords enable searchability. Together, you basically have a bullet-proof system.

To sum up, here’s the file system, including the folders:

YYYY/MM/YYYY-MM-DD HHMMSS – Filename.jpg

And here’s what a photo from the Fourth of July, at 8pm sharp, this year would look like under this system:

2009/07/2009-07-04 200000 – Fireworks.jpg