Gadgetopia

When digital cameras first hit the market, they were kind of a novelty.  My mother bought one, but she didn’t love it because it was just an expensive, complicated way for her to get a physical photograph.

And that’s all that mattered to her – the physical photograph.  The digital version was an annoying step in the process.  My wife was the same way for a long time.

Related to this, two years ago, I posted a short item about how global paper use is declining.  In it, I quoted this:

“Paper is no longer the master copy; the digital version is,” says Brewster Kahle, the founder and director of the Internet Archive, a nonprofit digital library.

This has also become true with pictures.  We had family portraits taken a couple weeks ago.  They turned out great, and my wife made an appointment with the photographer to pick the ones she wanted.  She asked me which ones I wanted, and I was a little taken aback by the question.

“Well, I want all of them,” I responded.  “Can’t you just get a CD?”

“Maybe,” Annie said.  “But which ones do you want…for real?  Like, to put in an album?”

“Um…none…of…them?”

I honestly couldn’t figure out what I would do with a paper photograph.  I was at a loss of what the value was.  It seemed so…limiting.

I just got 400+ pictures from a friend of her vacation to Italy.  I put them on my iPad, which is fantastic for scrolling through large sets of pictures.  This is frankly all the photo album I think I will ever need.

So, image media has officially been reversed.  The digital version used to be an annoying stepping stone to a physical version.  Now, the physical version is almost a weird afterthought.

A month ago, Blend gave every employee an iPad.  We did this for two reasons.  First, because it was just a fun thing to do.  But second, we did it because it highlights a shift we’ve been seeing in our industry for a while: the shift away from the Web.

Now, I know, Wired explained this better than I ever did in their recent story, The Web is Dead. Long Live the Internet.  If you haven’t read it, it’s worth taking a look.  In it, they discuss the shift away from Web pages in a browser and toward Internet-enabled apps – thick clients, essentially, that have functionality designed around specific tasks and just use the Net as a data transport layer.

A decade ago, the ascent of the Web browser as the center of the computing world appeared inevitable. It seemed just a matter of time before the Web replaced PC application software and reduced operating systems to a “poorly debugged set of device drivers,” as Netscape cofounder Marc Andreessen famously said.

[…] Those push concepts have now reappeared as APIs, apps, and the smartphone. And this time we have Apple and the iPhone/iPad juggernaut leading the way, with tens of millions of consumers already voting with their wallets for an app-led experience. This post-Web future now looks a lot more convincing. Indeed, it’s already here.

For the record, I’ve been thinking about this thing long before Wired published this story.  In fact, I had a little epiphany a few months ago when watching a commercial for Microsoft’s Kin of all things.  The Kin died about 10 minutes after they released it, but for some reason the commercial just resonated with me.  I saw all these status updates and social media…nuggets, and I realized these things might never see the inside of a browser.  They might live an die solely in the “Kin world.”

I know that Microsoft’s plans for the Kin (certainly their commercials) were a little overblown, but taken in conjunction with that Wired article, its really got my mind spinning about the possibilities of a post-HTML Internet.  We’re not ones to sit around and say that the Web is going away anytime soon, but it’s undeniable that its influence is waning.  A lot of functionality is drifting off into the land of apps.

Over the years, I’ve seen this with Gadgetopia.  The fact is, Gadgetopia’s RSS channel is much more active than its HTML channel.  I’d say there’s a really good chance you’re reading this in an RSS reader right now, in fact.  The primary distribution channel has drifted away from HTML over the years, and towards RSS.

I wrote about this exact same thing a year ago in a post entitled Beyond Web-Centricity in Content Management.

[…] sometimes we (as Web developers) get too caught up in the “Web” part. Sometimes we get very Web-centric about our content, when we really should be looking at content from a completely presentation-free perspective.

[…] It strikes me that an “announcement” in the context of the enterprise doesn’t necessarily correlate to a Web page. It’s really a pure…nugget of information, uncorrupted by presentation. It has properties like a title, a body, an author, etc. that are universal. They transcend presentation.

So, what do you call a piece of information, unencumbered by concerns about its final destination(s)?

I think you call this — gasp! — content.

Blend is a Web development firm, so we should be in a total panic right?  Well, no, actually.  Because we’ve taken a look at the future, and the future is…content.  That’s the unifying thread that floats through everything.  I don’t care if you have a Web site, an iPad app, or a carrier pigeon – you are delivering content to someone, somewhere, through some medium.  And in this world, that content needs to be managed in a universal, channel-free method.  And that’s what we do.

This has me thinking about job titles.  Are we “Web developers,” or should we rename ourselves to reflect the fact that we’re just managing content, regardless of its final distribution?

This would make us…”content developers,” right?  And Blend would become a “content development” firm?  Right?

It’s worth thinking about.

Frink: I’ve gotta say I’m a little intrigued with Frink.  It’s a programming language…sort of.  It’s more a calculation engine, really, for real world physics-related information, with all sorts of real-world constants built-in.

Need to convert feet to meters?

Simple enough.  How about finding out how many standard oil barrels filled with water it would take to equal a half-ton?

How many gallons of water would it take to fill your bedroom?

How much would that weigh?

It goes beyond physics.  Frink does things with strings too:

"I will not buy this record; it is scratched." -> Spanish
No compraré este expediente; se rasguña.

"Én már nem vagyok fert?zött." -> guessLanguage
[hu, Hungarian, 0.42290825, false]

And dates:

Money, in historical terms (how much would $1,250 from 1867 be worth today?):

Current exchange rates

You can embed Frink in Java.  Love to see an embeddable version for .Net.

Wireframes are wonderful things.  You can put anything on a wireframe.  Once you’ve designed the basic layout for your article, you can load up the sidebars with all sorts of fun stuff – related links, today’s weather, promotional widgets for all sorts of stuff, etc.

Sadly, wireframes can’t write code.  It would be neat if they could, because then you could just say, “Okay, snazzy wireframe, now write the code to go get all that stuff…”  But, alas, I have never seen a “Export C# Code” menu option in Photoshop or Illustrator.

Consider the (admittedly terrible) wireframe below:

The article (and its headline) are the “Core Content”  of this page.  This is usually the easiest part to manage.  In general, content management systems are very good about letting you model, manage, and display Core Content.

But then you have all the other stuff, which I call the “Surround.”  This is all the stuff on the page that isn’t the Core Content, but is usually related to it in some way.  “Related Links,” obviously, are related to what’s on the page.  The local navigation menu will also be different depending on what’s being view right now.  The promotional items, as well, will likely be swapped out based on the content on the page.

How do you do this?

Globally. It’s the same for everything (so, the Surround is expressly not related to the Core Content of the page).  This wouldn’t work for something like “related links” which are, by definition, “related” to something, but for a small site (think brochureware), this could work.  If you just have one menu, and you want your promo boxes to be on every page…sure, you can do this.

Explicitly.  For each and every content item, you manually pick all this stuff.  You pick the menu, you pick the related links, you pick the promo boxes, etc.  Obviously, this is a disaster – it’s tedious, and not manageable in the least.

Contextually. This means that each piece of content “lives” in some larger construct.  It belongs to a “category” or lives in a “content branch” or some other grouping that enables you to abstract the Surround away.  So, you have some logical construct to which both (1) core content, and (2) the surround gets assigned.  This is where those two “meet” and are associated with each other.

This is probably what you want.

You see, content doesn’t live in a vacuum.  Almost as important as what’s in the specific content, is how it relates to other content.  Where it “lives” within the larger scope of all the content in the domain.

This is called “context.”

A core question when integrating with any CMS is: how do determine the context of any given piece of content?  How do I determine what larger construct this content lives in so I can make decisions based on that?

(In this case, we’re concentrating on using context to resolve design and layout issues, but just about anything in a CMS depends somewhat on context.  Take permissions and workflow – these will like be different based on what context a certain piece of content lives in.  A press release will likely be handled differently than a blog post.)

In my experience, here are some common options for determining context.

Based on template.   You assign Core Content to a template, and that template has elements of the Surround hard-coded within it.  So, for your university site, you have a template called “biology-department.aspx” and that template has controls on it for the correct menu, sidebar items, etc.  You create your page on the upcoming “Arachnologists Meetup,” assign it to this template, and – voila! – your Core Content appears in the correct Surround,.

I don’t love this idea.  My problems with it are things which result in a lot of templates.

1. You usually have to have a single template for every combination of items (not always, but often). So, if you want to swap out one of the items in the Surround, you often find yourself creating “biology-department-with-arachnolgist-calendar.aspx.”  Fundamentally, this is related to the granularity of the surround (discussed further below).
2. This blurs the line between using templates for (1) the content of the Surround, and (2) the layout of the page.  This is when you start seeing things like, “biology-department-no-sidebar.aspx” and “biology-department-two-column.aspx”.
3. A new template usually means a developer has to get involved at some point, and this is an obvious problem.  Wanting a certain calendar to appear next to certain other content should be an editorial problem, not a development problem.

Based on type.  The content in the Surround is based on the particular type of the Core Content.  You see this a lot with home-grown systems, as the Surround content is often somehow related based on type.  A sidebar element called “Top 10 Movie Reviews” would probably be appropriate when a movie review is loaded as the Core Content of the page.

Based on location.  This is really common in systems with a strong content tree or other sense of “place” for content.  For systems like EPiServer and eZ publish, there’s a clear way to isolate branches of the tree.  eZ publish lets you divide the tree into “Sections,” and EPiServer lets stick data to places in the tree via “dynamic properties,” you you can designate branches of the tree as being an identifiable “place” – the Biology Department, for instance.

Ektron has a content tree as well, but was very weak on how to define where a piece of content “lived.”  You could get the ID of a content item’s immediate folder, but that was about it.  So I wrote an add-on for Ektron, called Togo.  (When I started in investigating EPiServer several years ago, I showed this to them and asked how to do the same thing.  When they showed me dynamic properties, I about cried – someone actually understood me…)

(Also, even if you don’t work with Ektron, perhaps go read the page on Togo.  It gives you a good description of the problem, and explains that particular solution, which would be helpful in wrapping your head around the idea of context.)

The problem here is that many systems just don’t have a sense of place.  Content doesn’t “live” anywhere in relation to other content.  Take Drupal, for instance – there’s no larger structure to its content.  It’s a big, flat pool of stuff.

Which leads me to…

Based on arbitrary conditions. Drupal has an interesting module which I just found called Context (this discovery prompted me to write this post, in fact).  It does fundamentally what I’ve been explaining above:

Context allows you to manage contextual conditions and reactions for different portions of your site. You can think of each context as representing a “section” of your site. For each context, you can choose the conditions that trigger this context to be active and choose different aspects of Drupal that should react to this active context.

With Context, you define different conditions that “trigger” different contexts.  As an example, this is direct from their README.txt.

1. Add a new context on admin/build/context
2. Under “Conditions”, associate the pressroom nodetype, the pressroom view,
   and the media kit book with the context.
3. Under “Reactions > Menu”, choose the pressroom menu item to be set active.
4. Under “Reactions > Blocks”, add the contact block to a region.

Now, this is powerful, but I think it can get confusing.  With this, you can “stack” contexts, so something could be in two contexts, and what if their reactions contradict each other?  I don’t claim to be an expert, so I can’t say for sure.

But, regardless, this is a neat thing that lets you made arbitrary conditions to determine how a piece of content should react with the rest of your site.

A couple other points about context, which are helpful when evaluating a particular system

Granularity.  Say your context dictates 10 things that happen in the Surround.  When you want to change one of these things (load a different calendar, for instance), is that an entirely new context?  Or can you swap out pieces of a context?

This is my problem, generally, with using templates for context.  If you want to change one thing, you see people rolling new templates for it.  Maintainability plummets in these situations.  You can only manage so many templates floating around.

EPiServer handles this very well with their dynamic properties.  You can set a property at a position in the tree, and that property will cascade down the tree to be available for all the content below it, unless overridden further down.  So, you might have some dynamic properties set on the root node and never over-ridden – these would effectively be global.  Other properties get set and over-ridden in different sections and sub-sections.

(Worth mentioning, too, that this model is the exact same thing I was getting at with Togo – the architecture is the same.)

Drupal’s Context does something similar by letting something exist in more than one context.  So, one context could handle the promotional boxes, another could handle the calendars, etc.  Multiple contexts would be invoked to handle different elements on the page.  As I mentioned before, this strikes me as confusing, but I’m no expect and Context seems to be well-adopted, so I’m assuming they’ve solve that problem.

API Support.  The API of any given CMS needs to have good, solid support for context.  At its most basic level, understand that your template is going to have to ask questions of your Core Content.  Consider this conversation between a template trying to render its Surround and some Core Content.

Template:  Okay, so I need to figure out what menu to show on the left.  Do you know what I should load there?

Core Content: No.  How would I know that?

Template: Well, what are you about?

Core Content: I have some tags….let’s see…”ferrari,” “sports car,” “phallic symbol”…any help?

Template: Um, no.  Where are you located?

Core Content: [looking around]  I have no idea.  The folder I’m in is called “Page Content,” does that help?

Template: Not really.  What about the folder above that?

Core Content: I don’t know, I can’t see that far out.  [awkward pause]  I know that I’m a “page” content type.  Anything based on that?

Template: No.  What about taxonomy node?

Core Content: I’m assigned to seven of them.

Template: But I can only load one menu, not seven!  Which node is the main one?!

Core Content: I don’t think it works like that.  None of these nodes are labeled “main.”

Template: [slowly, barely containing rage] Well, when they were putting you in this folder, did you see anything on the way in?  Any other folder labels?

Core Content:  No, I closed my eyes.  It was scary.

Template: You suck.

[And….scene!]

These questions are going to come up.  How well can your system answer them?  Does it have a strong contextual API that lets you interrogate Core Content to determine its context?  It’s amazing some of the crazy information you need to extract and work with based on context, and poor API support will frustrate you like nothing else.

Working with content management implementations day-in and day-out, I find that context gets totally overlooked in most places.  You see this happen at the wireframe and design  level.  Wireframes are gloriously straight-forward things that often have no basis in reality because no one has asked the obvious question:”

So, how do we get the Biology calendar to show up on a page in the Biology department?

Ask that question, next time you get a wireframe.  Look at every single piece of information in the Surround, and ask yourself, “how does this get here?”

Depending on the CMS, the answer might be harder than you think.

Man Lives In Futuristic Sci-Fi World Where All His Interactions Take Place In Cyberspace:Wow, The Onion wrote an article about me.

As if it were just a natural part of his day, Royce calmly surveys a torrent of classified cyber messages that flicker before his eyes in a mad rush. It’s a chaotic scene, but Royce doesn’t panic, for he is the lord and master of this virtual dimension.

A lone cyber-wolf, he prowls not the bustling streets of the analog world, but the electric avenues of the metaverse.

“I found these really cool shoes on Zappos the other day,” Royce says […]

When Sysadmins Ruled the Earth, by Cory Doctorow : Here’s a great little short story from Cory Doctorow about what would happen if the world ended and sysadmins were left in charge.  A group of them happen to be in a bio-safe facility in Toronto when the world kind of ends.

“Attacks on major cities all over the world have left emergency responders in chaos. The attacks are electronic, biological, nuclear and conventional explosives, and they are very widespread.

[…] “We’re holing up here for the foreseeable future, at least until the bioweapon has been identified and dispersed. We’re going to staff the racks and keep the networks up. This is critical infrastructure, and it’s our job to make sure it’s got five nines of uptime. In times of national emergency, our responsibility to do that doubles.”

Cory tells the story of what happens when sysadmins try to keep the Internet running.  They consider their own form of government, they collaborate with other sysadmis across the world, and they keep pulling up Google’s home page to see how long it stays online.

Few authors write hacker fiction like Doctorow.  He has a deep understanding of geek tech that I’ve only ever found elsewhere with Daniel Suarez.

This will take you 30 minutes to read.  Worth it.

Short rant here – authors, can we please start writing shorter books?  We’ve talked about this before, but now I have a specific example.

I’m trying to learn more about encodings – you know, character sets, Unicode, stuff like that.  I read Spolsky’s article, which was great, but I want to go deeper.  So, I thought, I’ll get a good book.

Here are the choices:

• Fonts and Encodings; 1,040 pages
• Unicode Explained; 688 pages
• Unicode: A Primer; 528 pages
• Unicode Demystified; 896 pages

Now, I’m not a wuss.  I read a lot – more than anyone I know.  But the shortest book there is 528 pages.  (I’m reading The Fountainhead right now, and that’s about the same size.  I’m going on two months now with The Fountainhead.)

Is it too much to ask for, say, 250 pages?  I realize that there’s enough subject matter here to probably fill 1,000 pages, but could someone distill it down a bit?

Two years ago, I wrote this:

I used it think [size] was an advantage — the bigger, the better — but as I get busier and my company accelerates, it’s increasingly a liability. I’ve started to be greatly attracted to smaller books — or thinner books, more accurately. I’m more and more interested in concise books that cover a more detailed point than broad monsters that try to hit every base.

Length is a liability here.  Because of the length, I’m not going to buy any of these books, and will just get by on free resources on the Net.  So, some author, somewhere, was just deprived of revenue because all the books on the topic are just too long to fit a read in.

There seems to be no middle ground.  Either I get by on articles off the Net, or I launch into a book big enough to kill someone with.  There has to be a better way.

Netflix Stays One Step Ahead of Creative Destruction: Netflix has been planning for the demise of its core business ever since it began.  They started the company with the ultimate plan of streaming video over the Net, and developed the mail business to bide time until technology caught up with their vision.

The company was formed in 1997 with the idea of sending movie DVDs, then a new technology, through the mail. But Reed Hastings, the founder and chief executive, and early employees, recognized that delivery of movies over the Internet would replace the mail carrier soon. They named the company Netflix, not Mailflix or DVDs by Mail.

[…]  It was only last year, more than a decade after its founding, that streaming movies started to take off. But it was Netflix pushing people to do it, even though it meant that the company might rent fewer discs by mail.

The DVD-by-mail concept is dying, but that’s okay because Netflix planned for it to happen that way.  It’s passively trying to kill the mail business by pushing people into using the streaming service, where Netflix always assumed they would end up anyway.

Netflix’s stock has been on a steady climb and is trading somewhere neat its high.  Meanwhile, Blockbuster is begging for a one-month extension on its debt to give it time to file bankruptcy.

Build a better journalism career by shifting your focus from writing stories to creating assets: Here’s a good argument that journalists (bloggers?) should strive to create enduring content “assets” in addition to the latest and great stories.

Look first toward creating evergreen assets that readers will continue searching for years in the future. These pieces should be written with search engine optimization in mind, and be stored at unique, easy-to-link URLs that are prominently featured in your site’s navigation.

He continues with a common theme here on Gadgetopia:

I’ve long advocated that journalists and newsrooms create “wiki”-style explainer articles  for stories of enduring interest in their communities. Edit them in-house, but link to them whenever you write a post or piece about that story, as a way for infrequent visitors to get “up to speed.” They’re great search engine bait for the curious, as well.

I’ve discussed this numerous times, most clearly in this post about the Wikipedia coverage of Hurricane Ivan:

With Wikipedia, you’re not seeing a series of posted items. You’re seeing a single body of information, continually updated and groomed. Thus, the basic information stays right where it’s easy to see. Wikis are more “speak to me like I know nothing” information, rather than “tell me the very latest nuance” information.

Other good post on this subject: Ruminations on Posts vs. Pages

Yes, I’ve really said that.  Sadly, I sort of meant it.

The NY Times printed a short but very thoughtful essay about Tweeting (and, by extension, social media in general).  In it, the author discussed how Tweeting has changed how she experiences the world.

[…] when every thought is externalized, what becomes of insight? When we reflexively post each feeling, what becomes of reflection? When friends become fans, what happens to intimacy? The risk of the performance culture, of the packaged self, is that it erodes the very relationships it purports to create, and alienates us from our own humanity.

Josh Clark does a great job of putting this in more practical terms:

I experience a day differently when I’m carrying a camera, or an event when I plan to share it on this blog. I look for the narrative rather than simply living in the moment. There are good and bad things about this. In the pro column, I’m more engaged in my surroundings, processing them with an intentness that I might bring to a museum gallery or a film screening. I see the world with more clarity and attention. Things slow down, and the world sharpens into a higher resolution.

In the con column, this means I lose a measure of flow and fluidity. I’m no longer strictly a participant, I’m an observer. A gauzy filter intercedes: I process events and evaluate them for their interest to others. The moments are still mine certainly, but I now share them with an anonymous audience. This phantom company changes my experience.

Josh compares it to the Heisenberg Uncertainty Principle, but I beg to differ.  I think it more closely correlates to the various Observer Effects.  Like, in physics, for example:

[It] refers to changes that the act of observation will make on the phenomenon  being observed. This is often the result of instruments that, by necessity, alter the state of what they measure in some manner. A commonplace example is checking the pressure in an automobile tire; this is difficult to do without letting out some of the air, thus changing the pressure. This effect can be observed in many domains of physics.

The intention of conveying the moment has the effect of altering our experience of the moment.  In a way, we’ve stopped living for the moment, and now we delegate our current experience of the moment in exchange for a future representation of the moment.

I always felt this phenomenon begun when digital cameras got popular.   Now that we were liberated from film and could take as many pictures as we wanted, people started carrying cameras all over the place and recording everything.  I got to wondering how this changed their perception of things.  Could they truly enjoy something if they were stressed out about somehow getting the perfect shot?  If they did get the perfect shot, did that somehow lessen their need to experience the moment as fully as possible? Did their desire to preserve the moment actually destroy the moment?

I remember taking a break from a conference in San Francisco once and driving up to an overlook of the Golden Gate bridge inside the Presidio.  The view was amazing – the kind of thing that would sell a million postcards.  Just breathtaking.  (This view, essentially.)

I remember kicking myself that I forgot my camera.  Then, I suddenly felt a great relief that I had forgotten it.  Without it, I didn’t have to stress about taking the perfect picture anymore.  I could sit there and enjoy the view for what it was – drink it in as deeply as possible, and know that it existed for me only in that moment.

I think because I forgot my camera that day, I remember this moment more vividly.  Years later, I can feel this moment intensely with very little effort.  If I had my camera, I would have mindlessly delegated the moment to a picture, knowing that I could just re-live the moment vicariously through it at some undetermined point in the future.

After this event, I found myself much less interested in taking pictures of everything.  The only time a take a picture now is when I specifically want to show something to someone else.  As for me, I’ve learned to live on the memories alone.

WikiLeaks ‘Snitch’ Hacker Adrian Lamo Faces Wrath of His Peers: A summary article about how and why Adrian Lamo – former cause célèbre in hacker circles – turned Pfc. Bradley Manning over to authorities for leaking the Collateral Murder video.

Evidently the 22-year-old Army intelligence analyst [Manning] was something of a fan. He knew a lot about Lamo when he contacted him on May 21, and no doubt he believed he was reaching out to a kindred spirit.

But Lamo quickly became concerned by the amount of classified material Manning had lifted. […]

Fearing such a breach would jeopardize national security, Lamo passed on what he knew to his ex, who happened to work for Army counterintelligence. His suspicions were apparently confirmed.

[…] Lamo and Manning chatted for only five days, but for the last three, Lamo was secretly cooperating with federal agents. While he regrets not being a better friend to Manning, he said, “the needs of the many” trumped “the need of the one to have a friend.”

Too many times in the past I’ve been guilty of getting too wrapped up in templates.  These are the magic things in content management that let you “drop” content into various “holes” on a page. It’s a wonderful concept – “dropping content into holes” even sounds fun – but sometimes we take it too far.  You see, what happens in the hole is really important too.

Too many times, we disregard the hole.  We know there’s a hole where we “Enter Content Here” (i.e. – the header graphic on Seth’s blog), but as developers, we’re not really too concerned with it.  Designers can even be guilty of it too.  “What’s this big white area on the design here?”  “Oh, that’s where all the content goes.”

When you get too wrapped up in your template, you lose site of the fact that the CMS editor “lives in the hole.”   That magic, neatly-defined hole in the middle of the template where they drop their stuff?  That’s 90% of what matters for them, and they care very much about what it looks like.

But, no problem, you say, we have CSS rules that make it all pretty!  Well, there’s more to it than that, which is where you have to leave your anti-septic little server-side world and think like a user:

• Have you considered typography at all?
• Is their WYSIWYG editor configured?
• Have you shut off all the buttons they’re not going to need?
• Do you have the styles they need?  Is there a dropdown box or something full of styles?  Do they know where each style goes?
• Can they insert and style images well?
• They’re going to want to caption a photo at some point.  How can they do that?
• Does the WYSIWYG editor accurately reflect the styles of the site while the editor is creating content?
• Do they have a style guide? Do they know what headings they should be using?

These things are important because the editor takes a very micro view of their experience.  They are concerned with this piece of content right now.  Developers, on the other hand, take a very macro view – we look at the entire landscape of the project and the content domain.  We can’t be bothered with this little, single piece of content you’re struggling with.

(In fact, let’s be honest – how many times have you turned a CMS over to the client without having actually created much of any content with it?  Sure, you stubbed out a few pages, but not enough to even get past the Empty House Syndrome.)

This is, of course, the exact wrong view of it, and here’s why: an editor’s first experience with a CMS will have a huge impact on their overall feeling about the CMS in general.  If they can’t make a nice page of content easily right out of the gate, they’re going to be soured on the whole thing.

A few years ago, we did a Web site for a tile and home surfaces company out in California.  I remember being all concerned about the templates and the CMS and such, but I never did bother with worrying about what the editors were actually going to do inside the WYSIWYG editor.  I spent no time configuring it – just handed it to them raw, at the defaults.

The result was a disaster.  The marketing director called me up very upset saying everyone hated the CMS and they couldn’t get it to do anything right.  They had been wrestling with it for days trying to migrate their content, and she was beginning to think the whole project was a big mistake.  (Wherever you are Wendy, I’m sorry…)

This was all my fault.  I hadn’t paid one minute of concern to things are banal and provincial as an editor actually trying to make a decent page of content.  After the fateful phone call, I spent an hour configuring CSS and their WYSIWYG editor and it was a revelation.  Their entire tone and feeling about the project changed.  But it was never as good as it could have been because of their first experience.

The first experience matters.  And the editor doesn’t see your magnificent API or database model or the conceptual elegance of your code.  They have a WYSIWYG editor and a page they want to create.  How’s that gonna go for them?

What I learned at the Emerging Languages Camp: So, you think you’re awesome because you program in Haskell?  Try some of these up-and-comers:

• Go
• Thyrd
• Frink
• Newspeak
• Coffeescript
• Trylon
• ooc

Want to invent a new language?  Just string some letters together, apparently.

please welcome back to our stage: This is a short post, ostensibly about the Jay Leno-Conan O’Brien thing (Ian is a screenwriter by trade), but it includes this gem:

To me, if you get rid of dramas and put a celebrity talk show in its place, you’re beginning a death spiral where there are a hundred talk shows with nobody to talk to. Leno at 10pm replaced the very shows that would have created the stars he wanted to interview. It was like tearing down a Victorian mansion to build a Center for Victorian Mansion Preservation.

Yeah, I know that’s too lofty a pedestal for most television dramas, but the point stands. It reminds me a little of our current digital lives - so many places to connect, so many Facebook messages, so many tweets, so many platforms - yet little original content, causing social media to spend a lot of time talking about itself. It’s not a bad thing from the get-go, but it is unsustainable.

New Zealand bans software patents: I wonder if this decision will cascade outwards.  Could this be the first domino in a long line?

New Zealand is passing a law which makes most software unpatentable. The only exception, added yesterday in an amendment, is to allow patents on inventions that contain embedded software.