Posts from June 2004

Over at Daring Fireball, John Gruber pointed out that Tiger‘s Dashboard isn’t quite as much of a Konfabulator rip-off as it first appeared.  His primary point was that the principles in Dashboard and Konfabulator aren’t anything new, and haven’t been for a couple of decades.  However, it was his highlight of a comment by Dave Hyatt that really caught my eye.  Dave said:

I wanted to blog briefly to clear up what the widgets actually are written in.  They are Web pages, plain and simple (with extra features thrown in for added measure).  Apple’s own web site says “build your own widgets using the JavaScript language”, but that’s sort of misleading.  The widgets are HTML+CSS+JS.  They are not some JS-only thing.

So… with the skills I already possess, I can create my own Dashboard gadgets, as can thousands of similarly skilled designers?  How cool is that?  I’m already itching to get my hands on the Dashboard developer information, so I can find out what these things can do and how I can bend them to my will.  As a trivial example, if I can get information via SOAP, and I can’t imagine why I wouldn’t, then I can use the weather data service I recently linkblogged to grab the current and next-seven-days’ forecast for any location in the United States, not to mention present the resulting information in a really beautiful way via the Dashboard.  Since the service returns results for latitude/longitude coordinates, it would be best crossed with a dataset correlating city names to lat/lon coordinates.  That shouldn’t be terribly difficult.

In fact, Web services in general could get a huge boost from the Dashboard.  Search gadgets for Amazon, Google, and any of a thousand other sources would be a snap.  Infoaggregators, pulling in data from various sources into one place, would become very simple.  Creating point-and-click editors for OS and application preferences should be trivial.  You’d also have the ability to grab information about the machine itself (memory usage, disk usage, CPU activity, top listings, etc.) and present it in truly useful and beautiful ways.  The possibilities are nearly endless, and my few fairly pedestrian ideas likely don’t even begin to touch on what can be done by a really creative programmer.

That’s especially true if, extrapolating from Ian Hickson‘s recent comments, the Web Core contains XFormsWebForms 2.0 support, thus making advanced controls available in Dashboard gadgets.

Then there’s iChat AV.  I’d like to see it permit audio chatting with AIM users, as opposed just video chats, but then I think that should have been possible already.  What really got me stoked was (of course) the gratuitious eye candy.    As Apple says:

iChat for Tiger introduces a new kind of interface for video conferencing. In its three-dimensional view, your buddies seem more like they’re in the room with you, making it easier to follow the conversation. Their images are even reflected in front of them, just as if they were sitting around a conference-room table.

Well, that’s true if you often hold meetings around conference-room tables made entirely of smoked glass.  What Apple really needs to add to iChat is the ability to pick different surfaces for the “tabletop” beneath the video windows.  They could include a highly polished, dark mahogany surface, for example, to really convey that upscale conference room feeling.  Or a reflective granite surface, for a feeling of solidity.  Hell, how about having the video portals hang above rippling water, with the video images reflected in the waves?  It seems like Core Image has all the pieces necessary to make any of those things happen, and then some.

For that matter, making it simple to drag an image file onto that tabletop and have it mapped on seems a snap.  You should be able to put your company logo there, embossed or glazed or otherwise applied to the tabletop, whatever its base surface effect.  Basically, you should be able to make the tabletop look even more killer than it already does.  Why not?  If you’re going to include major eye candy, then no sense holding back.

Addendum: in the comments, Jason Lustig pointed out something I failed to mention, which is that the tabletop is good for much more than just awesome visual effects.  It also makes a great shared workspace, a place where one participant could drop a file for everyone else to pick up.  As he put it, “just like if you were passing out sheets at a real meeting!”.  Exactly—and, of course, the document could even resemble a real document by generating a thumbnail of the document’s actual appearance, and mapping that onto the virtual sheet on the tabletop.  Whee, more eye candy!  I hope the Apple programmers add that ability to iChat before Tiger is released.

Add things like Automator, and this definitely looks like an OS upgrade well worth buying.  I really hope that “the first half of 2005” means “in January, but we wanted to hedge our bets”.

• Tiger Watching was published on Wednesday, June 30th, 2004.
• It was assigned to the Mac and Standards categories.
• There have been eleven replies.

During my recent trip to San Francisco, I was asked over edamame and sake what interests me right now.  Taken literally, that isn’t something I could possibly answer in a single evening: far too many things interest me.  Like clouds, for example.  However, since the question was actually about the Web and information technology, I was able to answer in only a few minutes.

1. Ground-up semantics—the area of interest that is actually about the Web itself.  XFN was the first step down what could be a very long, complex, and richly rewarding road.  By leveraging features of HTML, XMDP opens the door to letting people add the kind of information they find useful, and to do so in a way that just about anyone can grasp, which was one of the keys to HTML’s success, you may recall.  The idea is to allow for a distributed creation of semantic information, grown according to people’s interests and needs.  As more bits of semanticism get attached, the possibilities scale up exponentially.  Basically, it’s a self-organizing ad-hoc semantic network.

2. The intersection of mobile devices and global positioning systems.  One of the most common examples is the ability to leave information “hanging in the air.”  The idea is that if you’re using an M/GPS system, you can call up reviews of all the restaurants within a hundred feet of you, as an example.  These reviews would be data left by other people using the same system.  Another example is the ability to leave a note at a meeting spot for anyone who shows up late and doesn’t know where everyone else went.  I can also envision a variant on geocaching, where “hidden” messages are left in remote spots for others to find.  Walking tours could be highly annotated.  With the right system, you could set up a maze with no visible walls.

   Actually, I have an interest in more intelligent applications of global positioning technology.  In-dash mapping devices for automobiles represent a useful first step, but the devices I’ve seen are kind of crudely limited even compared to what could already be done, let alone what near-future advances might make possible.  But taking those ideas to the limit and crossing them with personal mobile devices just seems far, far too cool.  I wish I had more of an engineering bent, mostly so I could work on designing such devices.

3. Self-organizing ad-hoc sensor networks, otherwise known as “smart dust.”  There have been articles in recent copies of Scientific American and The Economist, but the general idea is that you create a bunch of tiny, rugged sensors and scatter them around an area.  They take readings and pass them back to a hub using routing that’s determined on the fly.  One example I read about was affixing a hundred or so sensors to a redwood tree in order to better understand the fine details of the tree’s microclimate.  The possibilities are endless, as are of course the privacy concerns.  Nonetheless, these kinds of systems have too many uses to just go away.  Conservation activities could benefit hugely from this kind of technology.  So could installation defense, for that matter.  Again, it looks as though an engineering inclination would really be useful here.

I guess the common theme that runs through all three is pretty obvious: I’m fascinated by systems that use simple (or at least simple-to-understand) parts to enable deep complexity, and those that use self-organizing principles.  Whether those principles are expressed through software algorithms or based on leveraging human behavior doesn’t actually matter to me.  The appeal lies in trying to figure out simple rules that allow for emergent behavior, especially the kind that wasn’t in any way planned ahead of time, and most especially the kind that seems totally chaotic and random until the patterns suddenly become clear.

Yes, I am one of those people who will stare at clouds for long stretches, trying to pick out patterns and understand the fine details of what’s happning within the clouds themselves.  I’m even more intense about it when I’m in the air myself and can see them up close, see them from unaccustomed angles.  It’s a bit of an obsession, to be honest, and one that makes me a bit pouty when I don’t get a window seat.  Even when there are no clouds to be seen, I can satisfy the same impulse by scrutinizing the world below, tracing humanity’s engineering of the landscape and reading what patterns I can find.

So yes, there is a lot that interests me.  Since I was recently asked, I thought I’d share just a bit of it, if for no other reason than to help highlight a few of the patterns in what can sometimes appear to be a very chaotic mind.

• Patterns of Interest was published on Tuesday, June 29th, 2004.
• It was assigned to the Personal category.
• There have been no replies.

For no apparent reason other than I can, I’ve redone the sidebar to include a linkblog titled “Distractions.”  I did this by grabbing Markku Seguerra‘s wp-recent-links plugin and then hacking the holy bejeezus out of it.  I needed to add a “via” function, for example, and wanted to make the administrative interface a bit nicer.  That involved finding out how MySQL statements work (mostly by finding all the ways they don’t).  So, hack hack hack.  It was an interesting distraction.  I’ll make the files available in due course.

To make room, I took out the “Socialization” section because it seemed largely worthless; two of the services listed I hardly even look at any more, and the other one was mostly about me puffing up my ego in public, which nobody really needs to see.  I’m also thinking about taking out the Platelets because I don’t get to update it often enough, even though I have really soft spot for it in my heart.  We’ll see what happens.

Keen-eyed observers will notice that I backfilled a few entries from the past few days.  I needed test data, you know?

• Feeling Distracted was published on Monday, June 28th, 2004.
• It was assigned to the Redesign and WordPress categories.
• There has been one reply.

After I threw out my two cents on ID naming conventions, Andy Clarke revisited the subject and made some more detailed proposals.  As I said before, I think this is a good conversation to be having.  However, the reactions of some people make me think that I wasn’t entirely clear about why.

A standard nomenclature offers the ability to restyle sites, sure.  That’s kind of cool in an übergeek kind of way, like making jokes involving TCP/IP terminology or wearing a T-shirt that says SELECT * FROM users WHERE clue > 0.  That isn’t really the primary reason why I support the exploration of ID naming conventions.  I’d like to see those conventions emerge because they will serve as a useful starting point for beginners in the standards-oriented design field.  It would help reinforce the idea of structural naming, as opposed to presentational naming.

We’re all familiar with presentational naming.  It’s things like id="leftbar" and id="pagetop".  In terms of layout, it’s the equivalent of <b> and <font>.  Structural naming, on the other hand, encourages the author to ask “what role does this piece of the document play?”  Rather than obsess over the visual placement of the navigation links, structural naming gets authors to consider the document structure.  This can’t be anything but good, at least for those of us who want to promote improved structures.  To pick one set of examples from Andy’s recent post:

#branding

Used for a header or banner to brand the site.

#branding-logo

Used for a site logo

#branding-tagline

Used for a strapline or tagline to define the site’s purpose

While #branding is described as “Used for a header or banner…” you may note that the actual ID name has nothing to do with visual placement.  It’s all about identifying the (dare we say it?) semantic role of that bit of the document.  By encouraging that thinking, a structural-naming convention keeps the author in that frame of mind when he has to go outside the common set of names.

I see this as being much like the often-promoted ‘rule’ that link-state styles should go in the order link-visited-hover-active.  I even wrote an article explaining why that order is important.  Here’s the thing: once you understand why the order is important, you can break the ‘rule’ in creative ways.  For example, suppose you want your hover effect to apply only to unvisited links, whereas visited links should get no hover.  No problem!  Just put them in the order link-hover-visited-active, or even link-hover-active-visited if you want visited links to get no active styles, either.

(Side note: if you chain pseudo-classes, such as with a:visited:hover, then the ordering problem goes away.  If Explorer supported that syntax, we could all move on from the LVHA rule.  Too bad it doesn’t.)

Conventions and ground rules exist for a reason: to provide a lower barrier to entry, and to help guide those new to the field.  Once you become experienced, you can break the rules in creative ways.  It’s been said that the key to good jazz improvisation is a thorough understanding of the rules of music.  In other words, once you really know those rules, then you know how to break them.  In order to know the rules, though, there have to be rules.

That’s why I’m glad to see them starting to emerge in blog postings and the public thinking of people in the field.  The development of these rules is not a barrier to creativity, but an enabler of it.

• Structural Naming was published on Saturday, June 26th, 2004.
• It was assigned to the CSS and Web categories.
• There have been thirty-eight replies.

Yesterday I returned from a whirlwind four days in San Francisco.  The primary reason for the trip was to conduct training for folks at the California Digital Library, but of course all kinds of other things happened.  Here’s the brain dump.

• I can’t believe what great friends we have.  At a Sunday afternoon party at the gotomedia pad, we were joined by college friends from Oregon, others who live a four-hour drive from San Francisco, and another from Cleveland.  You read that right: one of our local friends flew out to the Bay Area to be at the party.  Well, that and to take a vacation in California, but still!  And that doesn’t even count the WaSP folks who also attended, like Simon, Porter, and Molly, who came from Kansas, Washington DC, and Arizona respectively.

  It was at the same party that I finally met Porter’s wife, so I can now stop referring to her as “Porter’s imaginary spouse.”

• If there’s one thing I envy about San Francisco, it’s the BART system.  You can get darned near anywhere, and it makes commuting from the city over to Oakland a snap.  This is particularly true when your hotel is on a stop, and so is the place you’re headed.  Despite this, I still got turned around in downtown Oakland and was very nearly late for the second day of training.  The only reason I was able to find the place at all was that we’d walked over to the training facility the day before, so I was able to identify and use landmarks to reconstruct our path, and thus find the labs.

• It turns out the BART ticket machines run on Windows.  I found this out by the usual method, of course.

• In a conversation about the presidential campaign and Ohio being considered a key battleground state because of its employment situation and political complexity, one of my hosts opined, “The Bay Area pretty much spans the political spectrum from liberal to extremely liberal.”

• At the WaSP and Friends after-dinner party on Tuesday, Tantek publicly announced his departure from Microsoft.  He refused to say where he was going next, although we’ve since learned that he’s headed to Technorati.  By Wednesday evening, I’d actually come to that conclusion without having seen the post, but of course I didn’t manage to post until now, so I look like a poser instead of eerily prescient… although if you’d take the word of a VP at Macromedia, he could attest to my prediction.

  Like others, in a way I’m sorry to see Microsoft losing such a passionate, intelligent, and committed standards advocate.  We could speculate all day as to whether or not there’s even room for people like him, but one could assume the same about AOL, and they funded a whole standards team for a few years.  In any case, Tantek firmly believes this is the right thing for him to do and seems happy with the life change it represents, so I can’t be anything but happy for him.  I can’t wait to see what he does at Technorati (and really hope the service stabilizes in the near future).

• I spent a goodly portion of Tuesday evening talking, at various stages, with Rebecca Blood about the Web, adoption, growing up in the Midwest, and more.  On my flight home Thursday, I was delighted to discover a mini-profile of her in a Time article titled “Meet Joe Blog.”  It’s kind of a weird feeling to open a national magazine and read about someone you’d talked to just two days before.

• Not only did Metagrrrl spend some time with my laptop at the party, so did Min Jung Kim.  Geez, this thing gets more action than I ever did.

• At one point during the party, someone was copying a movie to his or her laptop.  I observed this activity for a few moments, then turned to Jonas Luster (who managed to get a picture of me drinking some MS kool-aid) and said, “You know, in Soviet America, the movies rip YOU!”

  Okay, maybe you had to be there.

• Bay City Roller Coaster was published on Friday, June 25th, 2004.
• It was assigned to the General and Travel categories.
• There have been no replies.

A while back (so I’m slow), Andy Clark did a bit of digging and compiled a list of the most common ID names used to label pieces of layouts.  I’m out of step on every count except for the footer.  Does that mean I march to a different drummer?  Probably, given my musical tendencies.

Andy’s work interested me quite a bit, not least because he actually sifted through the markup of forty sites (this one among them) to compile his list.  I was also happy to see someone taking a practical approach to the question of naming conventions.  From time to time people ask me about CSS best practices.  While Andy’s conclusions aren’t necessarily the final word on naming best practices, they are a useful starting point for such inquisitors.  Some complained that by listing the ‘best’ (read: most common) names, Andy is stifling creativity, which strikes me as being faintly absurd.  Does the existence of blueprints for ranch houses stifle architectural creativity?  I mean, yeah, maybe sometimes they should, but in general I think the world is safe for Dutch Colonials and skyscrapers.

There’s certainly room for more detailed and extensive work on the subject of naming conventions, as well as other best practices (apparently people are souring on that term, but until I hear something better I’ll stick with it).  I just hope that more people do work like Andy’s, looking at what’s been done as opposed to endlessly theorizing.

Andy also mused:

Is it right to stick to ‘content’ and ‘main-nav’ for the sake of our users’ control or is that just too boring? And do we want to make it easy for others to change our precious designs on a whim?

I’m all for it; giving users the ability to restyle this site on a whim is what led me to propose CSS signatures, and employ one on this site.  Does my site design not serve your needs, or bore you?  Create something better suited to your tastes!  I promise I won’t mind; in fact, I’d like to see what you devise.  If a set of ID naming conventions does firm up, I’ll likely adopt it here so visitors can restyle my site consistently with others that use the same nomenclature.  This is, it seems to me, the least I can do.

• Elemental Nomenclature was published on Friday, June 18th, 2004.
• It was assigned to the CSS category.
• There have been twenty-one replies.

I hate (American) sitcoms and soap operas.  That’s a sweeping generalization, a trend that seems to be sweeping the Web of late.  No choice but to continue.

The majority of American sitcoms derive their humor—or, from my perspective, “humor”—from characters getting into embarrassing situations and then trying frantically to get out of them.  The laughs are generated by watching this person be humilated, often at length.  Generally, the humiliatee is receiving some form of just desserts: they got themselves into the situation through selfishness or arrogance or some other form of hubris, and end up paying the price.  In any event, they get to squirm and flail before our eyes and it’s funny!  Only it isn’t.

I dislike American soap operas not because they’re harshly lit and seem like community theater writ large.  I have no issues with the acting, which is actually fairly impressive in terms of the quality-to-quantity ratio.  I dislike soap operas because they’re nothing but sturm und drang, one melodramatic setpiece after another.  The number one rule is, nobody gets to be happy for long.  Anyone who does find happiness is just being set up for a major, major trauma, likely at the hands of whoever is currently making them happy.  (Although death is far less traumatic in soap operas than in real life, as people come back from the dead and aren’t even zombified when they do.  Which I suppose is good news for the power grid.)  There’s only so much of the constant chest-heaving, garment-rending dramatics I can handle before I glaze over and start to closely contemplate my cuticles.

Now why would I be talking about this when everyone else is talking about validation?  It’s a mystery, I agree.

• Valid Concerns was published on Thursday, June 17th, 2004.
• It was assigned to the Standards category.
• There have been three replies.

Chris Adamson has an interesting post over at the O’Reilly Network about code in books and articles.  In summation: should code be given a special license, separate from the actual text?

While CSS isn’t code, exactly, the same basic questions apply to the stuff I’ve written.  Let’s take my most recent title, More Eric Meyer on CSS.  It contains a copyright statement that says, in effect, you can’t reproduce the book’s text, in part or in whole, without permission.  There is no distinction there between the explanatory text (“Margin collapsing is an interesting problem in some cases, and here’s why, blah blah blah…”) and the styles.  Taken literally, the copyright statement says that you can’t re-use any of the CSS I created in your own designs.

This is clearly in opposition to what I think most of us would agree is the expectation, which is that you can use styles (or code) as you see fit but you can’t take the ‘narrative’ text and pass it off as your work.  But where’s the dividing line?  Suppose that, for whatever reason, you really like one of the designs in Project 4.  We can agree that you should be able to re-use the styles presented, but a whole design?  Is that fair?  I can imagine many arguments both for and against, many of them variants on the classic slippery-slope argument.

In my particular case, the situation is even less clear.  As anyone who drops by the book’s site will discover, the project files are freely available for anyone to download.  You aren’t even expected to own the book as a condition of using them.  That makes them less protected, I would think, than if they were on a CD that accompanied the book—but how much sense does that make?  Again, I can envision several arguments on both sides of the issue.  The same questions would arise for any author that provided code samples for download, as many do.

There’s also the question of what rights can or should be granted to the reader with regard to code.  I might hypothetically make the styles all freely available to anyone, but only under the condition that attribution be given to the source (either me, the book, or both).  Wouldn’t you, as a reader, find that rather annoying?  I would.  “You mean I have to give Eric credit just to use two CSS rules that create this cool effect?”

I’ve always operated on the principle that any markup or CSS I write about is fair game, because otherwise what would be the point of writing about how to use it?  I can see it now: “use of the CSS presented in this tutorial, including any derivative works, without the written consent of the author is prohibited.”  Yeah, right!  That would be something like a dictionary prohibiting you from using any words you look up, including all modifications and misspellings.

So should books contain an explicit license regarding use of the code?  If so, what kind?  I expect readers and publishers will have different viewpoints, although the more clueful publishers probably won’t be too far away from the typical reader perspective.  There’s a part of me that wonders why we even have to be explicit about this at all—after all, there’s been a sort of tacit acceptance of code re-use to date—but in a litigious DMCA world, this is an issue that probably has to be addressed sooner or later.

As I ponder the subject, I’m currently contemplating putting all my code samples under a Creative Commons ShareAlike 1.0 license, both now and into the future, just to make sure the bases are covered.  Then again, perhaps an explicit Public Domain license would make more sense.  Which one would be better, or is there a superior approach I haven’t considered?  Let me know.

• Code Constraints was published on Monday, June 14th, 2004.
• It was assigned to the Books, CSS, and Tech categories.
• There have been eighteen replies.