Yes, I've neglected this space for quite awhile. It wasn't intentional, really - it just happened. Every once in awhile, I'd glance over and notice the cobwebs, the dust, and think, "Hey, I should really do something about that." And for a short moment I'd ponder what to say, what to do. And then I'd find some other more pressing thing to do.

In the meantime, life has happened. Time has flown by and plans for the future have been replaced by memories. I've moved to an apartment in the city, within walking distance of a myriad restaurants, shops, museums, parks, and other distractions. I've designed more websites and publications at work. I've met new friend and seen old friends move away. I've grown a beard, shaved it off, and grown it again.

Am I back? Maybe. I still like this little place, I think it has potential, and I do want to visit it more often. I just don't want to promise anything ... in the meantime, I'll see what I can do about these cobwebs and that strange musty smell.

I'm not a fan of corporate mergers and the gradual consolidation of companies that seems to be happening across most industries, so news of Adobe purchasing Macromedia left a bad initial taste in my mouth. After a bit of reflection and reading a few early impressions (one, two, three) around the Web, I can say that I'm a little assuaged but still have quite a few doubts. Things will definitely change with the products each company offers, but I wonder whether users will welcome all of the changes.

The Good

This merger can only strengthen the position of Flash and SVG graphics for the Web. Adobe's SVG support has been growing by leaps and bounds in the last few releases of their products; with an influx of Flash developers and the industry clout of Adobe, I hope that we'll see SVG support grow not only in Adobe/Macromedia products but in browsers and other software as well.

Tighter product integration between the two companies' respective suites will almost certainly be an outcome. How easy can they make it to export Photoshop comps into Dreamweaver? Sure, most web developers will still prefer to have their hands on the code, but just think of the rapid prototyping possibilities. If you can create a workable prototype in half the time, you might not have to show up to client meetings with Photoshop comps and explain, "This is where you'd click to do X."

I think we could see better print-to-web conversion as well. Macromedia is almost universally recognized as the industry leader in web design technology, and Adobe's Photoshop and Illustrator software is the de facto standard in the print world. Even InDesign (though still a relative newcomer) is making huge leaps in acceptance with printers. Converting print documents for the web has been an issue for a long time; personally, I still prefer copying and pasting text from one program to another. If this merger can make that workflow easier, that alone will satisfy many people.

The Bad

No marriage is without its flaws. (Not that I can speak from experience.) What will happen to a number of competitive products after this merger has completed? I think it's safe to say that Photoshop, Flash, and Acrobat will exist more or less unchanged. What about Dreamweaver and GoLive? Will they be merged? Will one be dropped in favor of the other. Logically, it makes more sense to maintain Dreamweaver as it has a much larger market share, but it is Adobe buying Macromedia. ImageReady and Fireworks? This is tougher for me to call - a lot more people seem satisfied with Fireworks, but I'm not very familiar with it. I also hardly ever use ImageReady - particularly not the newer versions. (It always seemed like a mostly redundant copy of Photoshop to me.) And what about that bastard child of Macromedia, Director? Will it finally breath its last as Flash continues its inexorable climb to the top? (I have nothing against Director - my experiences with both, several years ago, left me favoring Director for multimedia production. Flash, I'm told, has come a long way since then, while Director seems to have stagnated a bit.)

The Ugly

Macromedia and Adobe are direct competitors and are two of the strongest names in the design field. As a single company with little in the way of major competition, can we dare to hope that they'll still strive to create amazing products that focus on the designers and developers that use them? Or need we fear that the Creative Suite will become the Microsoft Office of the creative world? Does this open the field at all to major competition from Apple? (With the iLife and iWork suites, is there an iCreate suite down the road?) What about Corel? (Hahahaha. No, seriously.)

The only thing for us peons to do right now, however, is sit and watch. We can cross our fingers and hope for the best, but somehow things will change.

SXSW Tips for First-Timers

First and foremost, come to have fun. Leave your work at home, and bring your hawaiian shirts if you have them. I made this mistake last year, bringing a few projects that had to get done while I was there. As a result, I missed out on quite a bit. I'm not making the same mistake this year. Don't you make it, either.

That said, bring your laptop if you've got one. A large part of the meeting and greeting I did last year was sitting in the hall next to the power outlets along with most of the other geeks. Yeah yeah, only geeks would consider power outlets a great meeting spot. And as Jeffrey Veen pointed out last year, Rendezvous and iChat make for a great way of discussing things in panels. (For those that have Macs at least - PC users, be prepared to be jealous.)

Also, bring business cards. You will meet a lot of people, and a lot of people will meet you. Your business card is just one way to help them remember.

Speaking of meeting people, come play kickball! It's always fun, it's a great way to meet people, and it's a great way to start out the conference. Even if you don't want to play, at least come to watch and cheer. Besides, everyone usually goes out to lunch afterwards.

Finally, yeah, there's a huge list of panels, and it's very hard to choose which to attend. But you don't have to commit to them in advance; in fact, you're allowed to change your mind even in the middle of a panel! (So long as you don't distract people leaving, that is.) Seriously, though - don't feel like you have to commit to specific panels or "tracks" - branch out and go to something that might not necessarily be your forte. You can learn as much or as little as you want while you're there. Into CSS? Check out a wifi panel. Big movie nut? Check out the journalism panels.

So, in short, here are my tips: Meet people. Have fun. Learn lots. Be your geeky self. Oh, and if you see me, stop me and say "Hey," because I'm pretty shy and can sometimes space out. But I would love to meet you.

At the Web Standards Project weblog a few weeks ago, Ian Lloyd pointed out a post on Web Pages that Suck entitled The Biggest Web Design Mistakes of 2004. In his article, Vincent Flanders claims that one of the biggest web design mistakes of 2004 is "Mystical belief in the power of Web Standards, Usability, and tableless CSS,"

There is nothing wrong with any of the above except they're being touted by...guess who?...people who offer web design services specializing in...guess what?...Web Standards, Usability, and tableless CSS. These are simply tools. Remember, nobody gets excited about the tools used to build a house ("Please tell me what brand of hammers you used!"). People get excited about how the house looks and performs.

From: The Biggest Web Design Mistakes of 2004

He goes on to discuss that businesses aren't interested in standards, usability, or the code behind a site; they are only interested in increasing traffic and revenue and turning over more customers. This is all very true (and something that, yes, standards zealots can sometimes ignore). However, the growing endorsement of web standards is based on more than just a mystical belief; it is the logical conclusion of intelligent designers and developments who see real results from their implementation of web standards and who hope to positively influence the future of a still fledgling industry.

Blueprints, Plans, and Walkthroughs

Don't look now, Mr. Flanders, but there's a problem with your analogy. You compare web standards and usability to "tools used to build a house." That's just silly. In keeping with your architectural analogy, web standards would be more akin to the building specifications, building materials (should we use wood? cement? brick?), and perhaps even local zoning and building regulatory laws. Those comparisons may seem a bit disparate, and they are. But web standards encompass several different concepts - not only the code behind the actual site, but also the specifications and code ideologies that code is based on.

Also in his analogy, usability studies would more accurately relate to architectural walkthroughs, industry best practices, and the regular discourse between an architect and a tenant that must happen for both sides to be mutually satisfied. It's funny how these are sounding less like tools, and more like the things that are worthwhile considerations from the client's side.

What Are the Tools Then?

So what are those tools that Mr. Flanders mentions (like the hammer)? The tools are the basic software and reference guides that go into producing a website. Like construction tools, these tools aren't necessary to hold the house together once it's built. But when you need to update your website, you can pull them out again.

You type up an email to send a file to a friend or coworker, and click send. Whoops, you forgot to attach the file. It's happened to everyone. Embarrassingly enough, I once did this three times in a row for the same file. Why is it so hard to remember? I'm not sure, but I suspect it has something to do with the foreign nature of attaching files in most email applications.

I've begun to rely on MarsEdit for updating this website, and one of the biggest reasons is a little feature that warns me before sending a post if I haven't filled one of the fields. (I can choose which fields are required for each weblog.)

This feature has got me thinking about email clients and how useful attachment reminders could be. As I see it, there are a few different ways to approach reminders:

1. Check the message for an attachment context. This could be difficult to implement. At its most basic, it would require a basic search of the email message for terms that might imply an attachment: attach (and all forms thereof), include, file, document, etc.

2. Always verify before sending. This would probably get annoying for most people.

3. Check only for certain recipients. Again, this would probably get annoying for some people, but if emails to certain individuals often or always include attachments, a reminder might be useful.

Is this too much to expect of software? Should software try to anticipate user error of this sort?

Tell my loved ones I love them. Tell everyone else, well, something endearing. The state of Virginia is about to be devoured by a demented hybrid of Barney and Yoshi. And I'm off to stock up on the essentials (maybe a generator so my World of Warcraft sessions can continue uninterrupted?). If I somehow manage to survive the 4 to 6 inches of slush that's been predicted, I'll try to send a post via carrier pigeon. Do they speak XML-RPC yet?

</sarcasm> Seriously, though, I'm glad winter finally decided to show up in Virginia.

When does this approach make sense? Perhaps if the links in a linklog are open for comment, but even then one could simply use the <comments> element, at least in RSS. (Why is there no similar element in the Atom documentation, I wonder?) Or if you want to track how many people are visiting links posted to a linklog. But then you should have a server-side link tracker, and you could merely use the links that generates.

Linklogs in MovableType

Here's how I propose a linklog should work, using MovableType. The Title should be set to the title of the linked website. The Entry Body should be whatever descriptive text you usually put for your link (including the link itself). And the Extended Entry should simply be the URL for the link. Let's try this with an example link:

Title: The AIGA Design Archives

Entry Body: The <a href="http://designarchives.aiga.org/">AIGA design archives</a> are an incredibly inspiring design collection encompassing many design fields. [via <a href="http://www.airbagindustries.com/">airbag</a>]

Extended Entry: http://designarchives.aiga.org/

Now on to making those RSS and Atom templates:

A Good RSS Template for Linklogs

For brevity, I'm only including the portion inside the <item> element. You can figure out the rest.

<title><$MTEntryTitle encode_xml="1"$></title>
<description><$MTEntryBody encode_xml="1"$></description>
<link><$MTEntryMore encode_xml="1"$></link>
<MTEntryCategories>
<category><$MTCategoryLabel encode_xml="1"$></category>
</MTEntryCategories>
<pubDate><$MTEntryDate format="%a, %d %b %Y %H:%M:%S EST"$></pubDate>

Or you can download the entire RSS 2.0 linklog template.

And an Atom template, Too

Again, I'm only including the portion inside the <entry> element. And again, you can figure out the rest on your own.

<title><$MTEntryTitle remove_html="1" encode_xml="1"$></title>
<link rel="alternate" type="text/html" href="<$MTEntryMore encode_xml="1"$>" />
<modified><$MTEntryModifiedDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></modified>
<issued><$MTEntryDate format="%Y-%m-%dT%H:%M:%S"$><$MTBlogTimezone$></issued>
<id>tag:<$MTBlogHost encode_xml="1"$>,
    <$MTEntryDate format="%Y">:<$MTBlogID$>.<$MTEntryID$></id>
<created><$MTEntryDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></created>
<summary type="text/plain">
  <$MTEntryExcerpt remove_html="1" encode_xml="1"$>
</summary>
<author>
  <name><$MTEntryAuthor encode_xml="1"$></name>
  <url><$MTEntryAuthorURL encode_xml="1"$></url>
  <email><$MTEntryAuthorEmail encode_xml="1"$></email>
</author>
<dc:subject><$MTEntryCategory encode_xml="1"$></dc:subject>
<content type="text/html" mode="escaped" xml:lang="en"
    xml:base="<$MTBlogURL encode_xml="1"$>">
  <$MTEntryBody encode_xml="1"$>
</content>

Or you can download the entire Atom 0.3 linklog template.

Note, most importantly, that in both templates, the <link> element isn't set to the <MTEntryPermalink> that it normally would be, but instead to <MTEntryMore>. With this set, your syndicated readers can now safely follow the link from your feed to the site you want them to see.

The Eiffel Tower's likeness had long since been part of the public domain, when in 2003, it was abruptly repossessed by the city of Paris. That's the year that the SNTE, the company charged with maintaining the tower, adorned it with a distinctive lighting display, copyrighted the design, and in one feel swoop, reclaimed the nighttime image and likeness of the most popular monument on earth. In short: they changed the actual likeness of the tower, and then copyrighted that.

From: Fast Company Now

I'm not even sure how to react to this, apart from sheer outrage. The purpose of the public domain has been circumvented so that the city of Paris could make a little more money from its most celebrated icon. In essence, any amateur photographer (including me) who might want to take photos of the Eiffel Tower and share them with others (whether for free or, say, as prints or postcards) must now get permission and probably pay royalties to the city of Paris. That's a big slap in the face.

The Copyright Loophole

Think this is a one-time event? Think again. Ever notice how many remakes of movies come out every year? I can think of several recent ones off the top of my head: Ocean's Eleven, The Manchurian Candidate, Planet of the Apes. These aren't just the result of a collective lack of originality in Hollywood, they're a calculated attempt by studios to maintain control over the copyrights for a work in perpetuity. (That and a shameless attempt to capitalize on new markets with the same old materials instead of investing in riskier, but more original new works.)

You can find the same thing in publishing - ever check the copyright on a book and find multiple dates? That's because the book was reissued multiple times in order not only to provide new copies to new readers, but also to lengthen the period of time before the copyright expires. And again in music with greatest hits collections, boxed sets, special editions, and so on.

The Corporate Copyright

When a work is created, its copyright belongs first and foremost to the artist (except in the case of work made for hire where the artist is creating something under contract). But the best way for an artist to make money from his work (book, movie, music, or otherwise) is often to find a distributing company or publisher (think movie studio, recording studio, publishing house) and give them the rights to their work. An artist may be able to choose which rights they give/sell, but very often these distributors will require most or all of the rights in order to enter into contract.

I may be taking a small leap here, but I'd say a large percentage of the creative work for sale is copyrighted to the corporations who distribute it and not to the individual artists who created it.

Where Does This Lead?

Unlike individuals, corporations can exist in perpetuity so long as they make smart business decisions. In the current state of things, nearly all material created from (if I remember correctly from my college copyright law course) 1928 onwards falls under copyright, automatically. Any artist who wants to use or reuse copyrighted material should first seek permission or risk litigation. To the average Joe, this may seem irrelevant, for when do they ever use copyrighted material illegally? Well, think of that home video you put to music - did you have a license for the song you chose? Think of your vacation photos from Millenium Park in Chicago - did you have permission to take photos of those sculptures?

Currently, the length of copyright for works owned by a corporation is 95 years (for published works). So, for instance, a film that was created in 1928 (the cutoff year after which copyright renewal becomes automatic) is protected until 2023. Works created after that are protected for at least 95 years after the registration of their copyright. Anyone want to place bets on whether there will be a frenzy of legislation to increase the term of copyright before 2023? At the rate that corporations are moving, there will be no public domain works for the last century except by explicit donation from copyright owners. And that is a scary thought indeed.

1. I'm going to be healthier. Over the last year, I've had a few warning signs that I'm not living as healthy as I should. (Nothing major, don't worry.) But I want to be able to enjoy life as much at 80 as I do at 24. Even more, if possible.
2. I'm going to be more productive. Turns out, I never lost my motivation - I was just ignoring it. Silly me. Now back to work! I've already got some great ideas planned for this year so stick around.
3. I'm going to learn to drive already. Yes, I know - shock and horror. World traveller and I can't even travel to the mall without a lift (well, okay, technically, I biked and walked there many times when I worked there). Well, it's time to get over my fear and rationalizations (rational though they are).
4. I'm going to move out and move on. I'm not going to be that guy, who at age 30 still relies on his mother's roof and cooking. (Actually, I'm the cook here.) Rent an apartment? Maybe. Buy a house? Perhaps. Move to another city? A definite possibility.
5. I'm going to be less materialistic. This will probably be the hardest resolution of the bunch - I hoard movies, books, and games like few others. (I've gotten better about gadgets, but probably only cause I've got them all.) Currently my to-read pile won't even fit in my big bookshelf. The number of games I own and have yet to beat is rapidly approaching double digits. Oh yeah, and I definitely don't watch some of those movies I promised myself I'd watch over and over again.

So that's what I've got on my plate for the year. There are also a few others that are a little more dependent on situations and finances (meeting a girl, more travel, and such), but these five should keep me busy for awhile at least.

The Same but Different

The three basic sections of the site have returned: the journal, the sidebar ("meandering") links, and the photojournal. There are few major differences, though. What used to be the photojournal is now what I'm calling a visual journal - I'm hoping to play more with video and flash so this area will not be restricted solely to photography. The sidebar links will be tagged and will have a more comprehensive archive. (In the last version of the site, I never built archives for links that had rotated off the homepage.) And the journal will remain much the same as it always has, though with more focus on building my writing. Topics will range, but it will be more personal and anecdotal. I may introduce a separate weblog on web design in the future on another site, but that's still in the beginning phase of development.

Tag Crazy

In the months since I withdrew from weblogging, tagging and folksonomies have really taken off. Not to be left out, I played around extensively with the two front-runners of the tagging crew, del.icio.us and Flickr. There was a great deal there to like, but being the control freak that I am, I wanted the data stored on my own server.

My tagging implementation (on both the links and visuals) uses MovableType's categories. I considered using keywords so that I could simply add whatever words came to mind while posting an entry, but ultimately decided that using categories was simpler and would require a lot less PHP hackery on the backend. On top of that, using predefined categories should keep overlapping synonyms ("mac" or "osx" or "apple"?) to a minimum. Right now, it's a fairly basic setup, but over time, I hope to build more functionality into it. (Like tag-based RSS feeds, pulling related links from technorati, etc.)

Visual Calendar

One of my favorite things about Flickr (apart from the tagging) is the calendar. It's an easy way to see when photos were posted and to navigate between large groups of photos quickly and intuitively. I decided to recreate that with MovableType as a calendar on a monthly archive page. The thumbnail images are set as an ID'ed table cell background in a stylesheet defined in the <head> of the calendar page. If there's an image on a specific calendar day, the ID of the table cell is set to the abbreviated month and day ("Jan23"). Over top of that is an <a> element that's defined as a block with the same size as the table cell (width and height plus padding). The background of the <a> is set to a 2 pixel x 2 pixel GIF with 2 transparent pixels and two darkened pixels (thanks goes to Dave Shea for the inspiration); eventually, the GIF will be replaced by a semi-transparent PNG, but I couldn't get that to work on a first try so I put it off for the present.

A Work in Progress

As most web designers will say, no website is ever complete. There are lots of places on this site for minor (and major) improvement, but I wanted to at least get something out the door. There's no point waiting for perfection when it's never going to come. Over the next few months, I'll be making tweaks here and there to the site, based on my own desires as well as any feedback I receive.