Archives for category: Uncategorized

Once while interviewing for a technical analysis position, I was asked if I knew anything about Java. I knew something about Javascript, and I knew enough to know that Java was not the same thing. But that was it.

We front-end people (designers, content specialists, usability developers) hear about Java, .NET, etc., but rarely really understand how it all fits together.

What is Java?

Java is a programming language. (It is also an island in Indonesia, and an espresso drink I’m craving at this very moment.)

What does it do?

[Java] allows software designed and written just once for an idealized “virtual machine” to run on a variety of real computers, including Windows PCs, Macintoshes, and Unix computers. On the web, Java is quite popular on web servers, used “under the hood” by many of the largest interactive websites. Here it serves the same role that PHP, ASP or Perl might, although traditionally Java has been used for larger-scale projects.

WWW FAQs: What is Java?

Why is it cool?

Java applets allow interactive elements to be embedded within other applications, such as webpages displayed in a browser. And, in keeping with Java’s principle of portability,  “write once, run everywhere” means you’re not confined to only one browser.

OK, that’s not entirely true. You might need to download a Java plug-in, particularly if you’re running Internet Explorer, whose masters allowed their Java Standard Edition license with Sun Microsystems (now an Oracle Corporation subsidiary) to lapse.

There are pros and cons to Java. Some say programs and services written with Java run slower and require debugging to accommodate subtle differences in implementations. On the other hand: applets, people!


After a characteristically fruitless VP-mandated team “brainstorm” session on business goals not one of us has authority to influence, I was particularly refreshed to read Smashing Magazine’s recent post: Why Design-By-Committee Should Die.

As a content strategist trained on heavy artillery but often relegated to a BB gun, I would augment this title: Why Design-By-Committee Should Die–Slowly, and In a Fire.

An example.

My UX team and I had been working on a new interactive design for months. Balancing the complex, often-conflicting priorities of multiple stakeholders, we had finally arrived at an accessible, informative model based on research and industry standards.

The director of an adjacent department parachuted into one of our last meetings, having not attended previously, with this reaction: “Why are there so many words?”


You might assume that my gripe is with her question. It is not. She’s good at what she does, but what she does has absolutely nothing to do with the Web. I don’t expect her critique to be constructive, or even informed.

My gripe is that she was there in the first place.

How many brilliant products and services have bled to death on the altar of consensus-building? I don’t know. Is there a number bigger than a-hell-of-a-lot?

Now, I recognize how fortunate I am to have a job (at all, in this economy!) where I get to dig into so many communication channels even as they’re evolving. I love arranging and rearranging, learning and improving. I love content strategy! I only wish I could devote my time to it.

Instead, because of forces outside my sphere of influence, I spend much of my time in this sort of dialogue:

“I don’t speak Web.”

Allow me.

“What if my grandmother wants to use it and doesn’t know how to get back to the homepage?”

Your grandmother won’t want to use it. By the time you’re done with it, no one will want to use it.

Speider Schneider says it best: Most creatives choose to let it wash over them and collect their pay check. I suppose I don’t agree because I haven’t seen many pay checks made out to “Dance, monkey, dance!”

A word of advice to those of you who “don’t speak Web”:

I recognize that you don’t speak Web. I respect you for your expertise.

I do speak Web. Bring me your problem, then please stand back while I solve it.

A word to my colleagues and clients who do:

I promise not to bullshit you. If I made a decision based on my own preference, I’m not going to pretend I’ve got market research to back it up. But if I can back it up, let’s be done. We’ve both got better things to do than weaken this product with second-guessing and amateur input.

When everyone is steering, no one is.

When Wikipedia begins an entry with This article has multiple issues you know it’s not a cut-and-dry term:

Semantic Web is a term coined by World Wide Web Consortium (W3C) director Sir Tim Berners-Lee[1]. It describes methods and technologies to allow machines to understand the meaning – or “semantics” – of information on the World Wide Web[2].

I’m not going to reproduce the whole article here. Wikipedia would apparently appreciate your input.

Here’s my breakdown:

Semantic Web = automated connection-making.

There’s a lot of techno-babble in the mix (which, I have to admit, I kind of get off on), but when we break it down, that’s what we mean by Semantic Web: digital content that an automated service can crawl, make sense of, and connect to other digital content.

Semantic Web: Good Shovel, Not the Gold

As the “resident expert” (my expertise is relative to the context of my residency, I know) on Oracle Universal Content Management, I have a great appreciation for the technical groundwork that goes into developing for Semantic Web opportunities: metadata setup, HTML5, etc., etc., etc. It’s a beautiful Web we weave. But that Web still hangs on communication. Semantic Web is just another good shovel. Intelligible, relevant content is still what we’re digging toward.

Rachel Lovinger of Razorfish recently posted a presentation, There’s No Semantic Web Without Content and Data, about Semantic Web and intelligent content strategy.