Semantics of Comments

Hey, what happened to June? You tell me.

Here’s a quick brainstormer: what would be the correct semantic markup of comments? The overarching structure is easy: list of comments is an ordered list, so we’ll use OL and LI elements to convey that.

What about the content of each comment? According to CommentAPI, here are the elements defined for each comment:

  • title — title of the post
  • link — link to the home page of comment author
  • description — text of the comment
  • author — email of the comment author
  • source — name of the comment author’s site (blog)
  • dc:creator — name of the comment author
  • permalink — permanent URL of the comment.

The last one is not really part of CommentAPI, but nevertheless important to have. Now, how would you express this in XHTML? My inclination is to treat this as a data row, and use DL element (DT for the title, individual DDs for all other content):

<ol class="comments">
 <li>
  <dl>
   <dt>
    <a href="permalink">Comment Title</a>
   </dt>
   <dd class="author">
    <a href="mailto:authorEmail">Author Name</a>
   </dd>
   <dd class="source">
    <a href="authorSiteUrl">Author Site</a>
   </dd>
   <dd class="description">
    Text of the comment
   </dd>
  </dl>
 </li>
 <li>
  ...
 </li>
</ol>

What about using CITE and BLOCKQUOTE? Are we really citing and quoting here? Any other semantics that might need to be conveyed? Thoughts, critiques, and ideas are appreciated.

Beware of the Ubiquitous Baton

Last night, somewhere in North London, a hollow object was launched from the secret base of the Web Forms 2.0 for Internet Explorer project. In a perfect parabola, the object crossed the ocean, entered the airspace of the United States, and landed squarely on my head. Boink.

Total volume

A measly 1.24Gb in my hard drive, around 200 CDs in my car. Yeah, I know.

Song playing right now

Morning birds chirping outside. That’s not really a song, that’s the actual birds making their birds sounds. Which reminds me of this joke:

A cowboy is sitting in a bar. Suddenly, a monkey runs up to his glass and ehm.. urinates into it. Dumbstruck, the cowboy jumps off his stool and barks, pulling out his gun: “What tha..!? Whose monkey is it?!”. Bartender looks to the piano, where the musician is working his magic, unaware of the developing situation. “Your monkey peed in my scotch!”, the cowboy roars in rage at the musician. Catching the barrel of a gun with the corner of his eye, the poor guy frantically scrambles to the keys: “I think I know this one! Yeah, I’ve got it! Your mo-oonkey peed in my scotch! Your mo-oonkey peed in my scotch!”

Five songs (albums) I listen to a lot or that mean a lot to me

  • Eternal Sailor — Peresvet
  • We are the Robots — Kraftwerk
  • Luminitza — Balanescu Quartet
  • Front 242 — Up evil
  • Journey of Dreams — Ladysmith Black Mambaza

Five people to whom I am passing the baton

TILT: How to Stop Feeling Bad About Using Tables for Layout and Start Enjoying Your Markup

You must be really living out in the sticks if you haven’t heard by now that using HTML tables for layout is bad. Markup is for content, CSS is for presentation, we learned.

You must be living in the land of magic mushrooms if you haven’t realized by now that making CSS do exactly what you want is easier said than done.

See, in the ideal, happy-go-lucky world, everything is just right. The content, custom-tailored by suave professional markup writers, fits perfectly into the widths and proportions of your template. The browsers support standards at exactly the same level and in exactly the same way.

Too bad we don’t live in Mayberry. With the loony Czar “The Exasperating” CSS 1.50304 ruling the presentational realm, it is surprisingly hard to build templates that are not brittle. Even The Man himself is battling with the idiosyncrasies of the dominant Web browser. And he’s the sole content contributor to the site! What if the entries were written and posted by someone who neither knows nor cares about the quality of markup, which last time I checked, is the absolute majority of your typical content contributors?

The issue becomes even more complicated when the layout is fluid, because its exact sizes are not known at any given time. And when the business requirements call for more sophisticated visual concepts than your typical “two-column”, “three-column”, and “three-column with coke and fries”, it becomes clear that the old Czar alone may not be able to hold the kingdom together.

The “Stretchy Pants” test

One of my favorite TV characters, Frank Barone of “Everybody Loves Raymond”, was ecstatic to finally find a pair of slacks that fit just right his lesser than strapping figure. Nevermind that his wife Marie had secretly purchased them at a maternity store — Frank loved his “stretchy pants”, in which his beer-drinking, cannelloni-devouring gut would never feel too tight. In a very similar manner, your layout must accommodate the fact that the content may sometimes grow a bit of cellulite here and there. Therefore, in order to be deemed ready for the real world, any page layout must withstand this simple test:

In each area of the layout that will have changing content, place markup whose presentation exceeds the width and/or height that is originally allocated for the area. Doing so must not cause the areas to:

  • Rearrange and change (break) the layout
  • Bleed one over another
  • Hide content of other areas.

This condition should still hold true if the browser window is resized to any width or height.

The ones with the heightened usability sense would add that these changes must also not trigger the appearance of in-page scrollbars. Go ahead and play with the pure CSS-driven sites. Download the source code of their pages, test it. View these pages in IE, view them in Mozilla, maybe even check them out in Opera. You will see that hardly any of them pass the test. In fact, if you find one that passes it and has more than one column, let me know.

The secret that CSS gurus have been trying to hide from you

But guess what? The table-driven layouts (if designed properly) pass the “stretchy pants” test with flying colors. Perhaps nobody enunciated the issue better than Andy Budd and Dave Shea in their insurgent strike against us structural markup purists: tables are bad, but they may be necessary to keep the layout intact in real-life conditions. Olav Junker sums up the problem in his comments:

CSS is perfect for basically single-column layouts. Secondary blocks like sidebars can be placed outside the main column with float. This solves the layout requirements of many websites, but requires the designer to rethink the layout as column-based rather that grid-based. It’s not just a case of moving some attributes into a slightly different CSS syntax.

However, sometimes you really need blocks aligned in two dimensions. You can emulate it with positioning and fixed sizes, but this will not, like tables, adjust gracefully if content is changed.

So my point is, it’s not a case of CSS being harder to learn and tables beeing more familiar (the same could be said of font-tags then, but i dont think many uses them any more), its a case of CSS not supporting 2D grid-layouts.

As painful as it is to admit, the amalgamation of rendering engines that’s currently available on the market simply does not provide a robust enough implementation of the 2-dimensional layout grid. You can float and slide your divs and spans all you want — these hacks will still remain hacks, because they only provide a simulation of the layout that’s aced by those darn tables.

We can rebuild him. We have the technology

So, what’s the solution? How do we keep provide a 2-dimensional grid to support the layout of our markup structurally correct markup? Well, how about this: let’s augment the rendering engine with the missing layout capabilities.

Huh? Are we trying to build a new browser now? Hopefully not. Just want to improve the existing ones with a slight twist of Javascript. Pull out the old trusty blade of client-side scripting to enforce the placement of your content areas in a 2-dimensional grid. Many of you ‘scripters probably just saw an elaborate mesh of “onresizes” and hidden iframes to account for various size changes flash before your eyes. No, it’s actually much simpler than that. Let’s think for a second. Don’t we already have a nice logic that does exactly what we need and is already build right into each and every one browser on this planet? Let’s see, what do we call those…? Tables, was it? You betcha.

The gory details

Here’s the gist of the technique: using standard DOM methods, inject a table where it is needed to support layout. Let’s use this composition as an example. Now, you fancy design folk might start pooh-poohing the awful choice of colors and lack of style, but let’s try to keep our focus on the topic.

First, we write the markup for the content and its structure:

  <div id="Page">
   <h1 class="Title">Your Company Name</h1>
   <ul class="Tools">
    <li>
     <a href="#">Home</a>
    </li>
    <li>
     <a href="#">Site Map</a>
    </li>
    <li>
     <a href="#">Search</a>
    </li>
    <li>
     <a href="#">Contact Us</a>
    </li>
   </ul>
   <div class="Content">
    <p>
     Lorem ipsum etc ...
    </p>
   </div>
   <ul class="Links">
    <li>
     <a href="#">Related Link</a>
    </li>
    <li>
     <a href="#">Another Related Link</a>
    </li>
    <li>
     <a href="#">Vaguely Relevant Link</a>
    </li>
    <li>
     <a href="#">Just some link</a>
    </li>
   </ul>
  </div>
 

Next, we inject our tables:

  var page = document.getElementById("Page");
  var pageItems = new ClassNameBag(page);
  var pageTable = new LayoutTable(2, 2);
  pageTable.appendChild(1, 1, pageItems.Title);
  pageTable.appendChild(2, 1, pageItems.Tools);
  pageTable.appendChild(1, 2, pageItems.Content);
  pageTable.appendChild(2, 2, pageItems.Links);
  page.appendChild(pageTable.node);
 

And finally, we use CSS to complete the composition. Looks simple enough? Let’s examine the injection code line by line. Line 1 should be pretty self-explanatory: the element by id of “Page” is retrieved. Basically, we grab the root of the DOM tree that represents mentioned above markup.

Line 2 is just creating a ClassNameBag instance, which doesn’t relate to the technique directly, but is useful, because it creates an object with properties, each containing the child of the element, supplied as a constructor argument, and named after the child’s class name. Now, for instance, I can access <ul class="Links"> element simply as pageItems.Links.

On Line 3, the actual injection magic begins: a new object named LayoutTable is instantiated. The LayoutTable encapsulates the “to-be-injected” table and its constructor has the following signature: LayoutTable(columnCount, rowCount [, className]), where columnCount and rowCount specify how many columns and rows, correpondingly the table will contain, and the optional className parameter allows to add an extra class name qualifier to table’s “class” attribute (which already has “Layout” class name assigned by default).

The LayoutTable provides nprovides a single method appendChild(column, row, node), which is similar to your typical element.appendChild method, except it appends the element, supplied in the node argument in the specified row and column of the table. Lines 4-7 distribute the contents of the Page element to their corresponding locations in the 2D grid (a.k.a. layout table).

And finally, on Line 8 we attach the layout table back to the Page element. The LayoutTable has one property node, which contains the actual DOM node of the table that was built with the code above. At this point, the injection is complete, and the table becomes part of the DOM.

In order to allow for more styling flexibility, each table row is given className of “ry“, where y is the number of the row (“r1” and “r2” in our example), and table each cell is assigned className of “cx“, where x is the number of the column (“c1” and “c2” for our table). This simple naming trick lets us control the presentation of rows, columns, or even individual cells in the layout table. For instance, “table.Layout tr.r1” will select the whole row 1, “table.Layout td.c2” will select the column 1, and “table.Layout tr.r1 td.c2” selects just the second cell of the first row.

Suddenly, CSS and tables are friends again. The old nemesis of structural markup comes back to the good guys’ side and saves the day. The barriers are broken, problems are solved, the happy end ensues, and tears of delight flow down the cheeks of sentimental readers.

What’s your name, stranger?

Now hang on just a second. Obviously, we have a technique here. And as far as I can tell, nobody had named it yet. Maybe I should try my hand at the Four-Letter Moniker Wheel of Fortune. Let’s see here… It’s a Table Injection Technique! Well, that’s only three letters and a couple of notches past PG-13. How about this: BOTOX, a quick way to smooth over nasty old wrinkles by injecting normally toxic stuff into the facial area of your page. Clever, but nah… I can just smell the lawyers circling around my head with this one.

Wait, wait.. I think I got it. The Table Injection for Layout Technique, or TILT! Woo wee! I think I just got me my own 4-letter abbreviation! Yup, TILT it is. Are you ready to TILT it?

Surgeon general’s warning

Just like anything that sounds too good to be true, TILT comes at a certain price.

  • Using client-side scripting to add extra layout functionality to your browser’s rendering engine requires, uhm, client-side scripting, which may or may not be available on the browser of your visitor.
  • TILT modifies the DOM tree of the page, which is something that has to be accounted for if you are doing DOM work for other purposes.
  • Using tables for layout while keeping the markup clean is addictive and may lead to inexplicable waves of feeling joy and urge to hug and kiss co-workers and even total strangers.

Ok, maybe not the last one. However, when all said and done, this technique definitely deserves a good look. It has potential of making your hacking with CSS columns and floats obsolete and clearing up the way for you to actually starting to enjoy your markup.

Graphics and Structural Markup: Keeping “pretties” out of content

Pet peeve time! Let's talk graphics. You know, the catchy visual dujibobs that have been part of the Internet since the Gopher went south. As far as I know, there are only two types of graphics on the Web: content graphics and presentational graphics.

  • Content graphics comprise the content of the page or serve as illustration for text content. For example, a news story on nuclear research breakthrough may feature a photo of a glowing (pardon the bad pun) scientist in a hazmat suit. A page containing a gallery of pictures with cut lines could serve as another example of images as content.
  • Presentational graphics serve the decorative purposes of a page. Typically, these are ingredients for what you'd call "page template" – they survive, with some degree of consistency, from page to page on a site. Taking away or changing the presentational graphics does not affect the content of the page. The nice white-space background texture that makes your eyes feel happy, or the heading that expresses the spirit of the site, or rounded corners that give your sidebars the look of a candy bar – all of the above are presentational graphics.

Another, less obvious example of presentational graphics is using images to convey textual information. Very often, Web sites can be found using titling (and sometimes more) that is rendered as images. See, text looks much better when kerned by hand and licked clean with anti-aliasing in Photoshop in a font that's something other than the common serifs and sans-serifs given to us by Web gods. And in the absence of a standard font delivery/rendering mechanism, provided by CSS or (X)HTML, developers use ye olde GIFs to compensate.

However, as I mentioned earlier, these images are context, not content. Why? Well, because from the perspective of content, we could care less about how it looks. We just want information. The "pretty" part is thus presentational, and only the actual textual information that is represented by the image is content. Can't decide who you really are, eh?

Images and structural markup

Obviously, presentational graphics have no place in structural markup. Only content graphics deserve to have their own designated image elements in the markup. The rest will have to take a ride on a CSS bus. Luckily, the color and background family of properties gives you more than enough flexibility in accomplishing that, and A List Apart is a good starting place in getting a taste of common techniques.

What of that MPD-afflicted "text as graphic" case? If we tuck our graphical titling into CSS backgrounds, we hide content in the presentational land, because these graphics contain textual information. If we make them into image elements, we have presentational elements in the content, which is even worse. What shall one do?

Because the initial reason for having text as graphics is due to incomplete rendering paradigm, there is no perfect solution. But there are a few that come pretty darn close. I am talking about the family of image replacement techniques. They all approach the issue from the same angle: textual information is marked up as text, but replaced with images using clever hacking with CSS, client- or server-side rendering. That way, the markup stays structurally correct, and the layout engine of the browser is augmented with new capability to make the text look more appealing. The major limitation of these techniques is that they're hacks, and like any hack, each technique has it Achilles' heel:

  • Static image replacement (FIR being the first, Leahy being my current favorite) still requires you to break out your Photoshop if the text information in the images changes.
  • Client-side dynamic image replacement (sIFR is the best example) has additional expectations on technology support (Flash is required), does not provide enough presentational flexibility (you can't hand-kern something that's generated on-the-fly), and may have accessibility problems (try reading sIFR-enabled page with the latest version of JAWS).
  • Server-side dynamic image replacement (DTR comes to mind) places extra computational burden on the server and has the same flexibility and, to a lesser degree, accessibility issues as its client-side counterpart.

However imperfect, image replacement is an enabling technology. Without it, presentational aspects of the page would have been the sacrificial lamb of structurally-correct markup. I doubt structural markup would've had a chance of making it to the mainstream.

Brand is content?

Very often, it is tempting to regard branding elements on a page as presentational. Branding elements are part of the letterhead, not the letter itself (letterhead being the presentational part of the page, of course). But in reality, the situation is a little trickier. In most cases, brand is as important as content on the page and deserves to be counted as content. Here are a few examples:

  • Point: The university seal is often used on a page to signify that the content comes from official university sources. Removing the seal from content diminishes the authority of the page. Thus, the seal is content.

    Counterpoint: This is the case of mistaken identity. The seal itself is not content. The content is the phrase "This page is part of the official university content", which is implicitly stated by the presence of the seal.

  • Point: The logo of a company on a page was re-colored to match the theme of the page, has been given gradient fill and a drop shadow to make it look "pretty". Anything "pretty" is part of presentation, thus making the logo a presentational graphic.

    Counterpoint: The changes in logo appearance are indeed presentational. However, being the unique mark (title) of the company, the unaltered logo itself is still content. Therefore, the unaltered logo graphic may be part of page content, only to be later replaced by the spruced-up presentational version. Think of it as using image replacement technique for an image.

Hyperlinkin' graphics

Web wouldn't be Web without hyperlinks. Those pesky anchor elements define the essence of surfing, the brand new user experience that was born with the Web. Many times, the item that the Web surfer clicks on is a graphic. Now, quick: is this a presentational graphic or content?

To answer this question, let's examine the nature of a hyperlink. A hyperlink is a way to link from one page to another, which identifies the target of the link on the page that's the link's starting point. Naturally, identification of this link is content.

Yes, but what kind of content? As any of known accessibility guidelines (WCAG, Section 508, etc.) would tell us, this content must be textual in order to be interpretable in absence of the agent that supports visual content. Therefore, from the perspective of user experience, the textual nature of the link is more important than its visual representation.

This means that any graph
ics that are part of hyperlink are probably presentational
. They are there to make the link look "nice" or "pop", not to identify the target of the link.

Comrade, what about my image maps?

Image maps are about as evil as you can get from the perspective of structural markup. Think about it: it's a markup construct that was devised to arrange links (content) on a graphic using 2-dimensional, pixel-oriented system of coordinates, which is as presentational as you can get. Stay away from the image maps, they are the heathen borne from Devil's womb. Especially, since you already have a presentational vehicle such as CSS.

Rules of Thumb

  • The image is definitely content, if
    1. It is referred to in the textual content. For instance, "This diagram depicts the relationship between good and evil (see figure 1)"
    2. If removed from the page, affects the value of content
  • The image is probably content, if
    1. It was created specifically for this page
    2. It is unique for this page
  • The image is probably presentational, if:
    1. It's clickable
    2. It was borrowed from stock library
    3. It is present on multiple pages with a degree of consistency
    4. It lends itself better to a GIF format
  • The image is more than likely presentational, if:
    1. If removed from the page, does not affect the value of content
    2. It contains textual information that would be considered content if it were just text.

Image element Quiz 1

Following the spirit of this article, how many image elements will you need to develop markup for the following composition?

Quiz 1

Image element Quiz 2

Think of what XHTML markup you would write for the composition below. Specifically, what would you use to express the icons (I assume it's obvious that they are clickable)?

Markup Quiz 2

Image element Quiz 3

Visit the following Web sites, view their source and point out images are incorrectly marked up as their own elements:

Note to the user from the utopian future: If you are looking at my page and can't find any examples of bad structural markup, you bring me the happy thought that I finally did find time to redesign my site. If you can't find anything wrong with any of the Web sites listed, you are either overlooking something or the future is looking so bright that I might just have to get me a pair of shades.

With any luck, this article shares your current thinking. Or maybe it gave you something to argue about (that's what the comment form at the bottom is for). In either case, next time you code presentational graphics as image elements, I hope you see it as adding ugly warts to the beautiful face of your Web site.

Party Like it’s 1997: The Curse of the Back Button

Haven’t you heard? DHTML is cool again. Now, before y’all run out scriptin’ your own little cans of Asynchronous JavaScript + XML , let’s pause for a second and consider these observations:

  1. DHTML has inherent usability issues. These issues are still present to various degrees even in all new, slickest applications. As Scott Isaacs states in his post

    The user-interface issues revolve mostly around history and refresh. (For example – In GMail, navigate around your inbox and either refresh the page or use the back button. In Spaces (IE Users), expand and view comments and hit the back button.  I am willing to wager that what happens is not what you really want).

  2. DHTML usability issues are here to stay. Unless some visionary scripting genius strikes again, they will keep DHTML as an application platform in the category of audacious hacks. Of course, the usability undoubtedly will be sacrificed on the altar of coolness: “What? You can’t click back to the album from a picture on Flickr? Well, boo-hoo! What would you rather have, a clunky extra click or the wholesome goodness of Flickr? Fuggetaboutit!”.

So, what is the nature of these issues that Scott was talking about?

DHTML vs. Usability: The Crash Course

In the typical world of Web, clicking on a link makes the browser fetch request to a Web server and deliver a new page.

At the moment of the click, the page you are on is deemed departed and added to the browser history (so that you can click the back button to return to it later, if you’d like)

DHTML provides the capability to intercept a click and, instead of fetching a new page, stay on the same page and do something with it (like open a menu or unhide a section of the page, or make a creepy clown jump out from the bottom).

At this moment, we are faced with an interesting dilemma: even though we clicked on a link, we haven’t departed the page. So, how should the fact of the click be recorded in browser’s history? Is this just a click or  some kind of weird “virtual“ click? And, if the back button is clicked, what should occur? Should DHTML script recognize this fact and adjust the state of the page accordingly? Should the creepy clown retreat back beneath the bottom of the page?

While there are are various ways to answer these questions, the fact that remains is that browsers were not originally designed to account for that kind of state change. There is no definitive way to detect the event of clicking back button. Heck, you can’t even see where we are in browser history from inside of the page!

The issue was further complicated when the XMLHttpRequest capabilities were introduced. With XMLHttpRequest, clicking on a page may result in content being loaded from the server and added to the page without leaving it.

Naturally, this opened doors for the thinking that maybe the user never needs to leave the page. Glory! Glory! We can build entire Web applications that are based on just one page, which changes its entire appearance using nifty server roundtrips behind the scene. “But… what about my back button?“, asked the ordinary user.

Web Page Paradigm

Developers, I am here to remind you of the Web Page Paradigm, put in words so eloquently by Mark Hurst:

On any given Web page, users will either…

– click something that appears to take them closer
to the fulfillment of their goal,

– or click the Back button on their Web browser.

Now, please repeat after me:

The browser back button is an essential part of user experience and every effort must be made to make it operate flawlessly within your application.

There. Whether you develop DHTML applications as part of your job or just as a hobby, it would not hurt to memorize and stick to the statement above. Feel free to print it out and frame it. Or cross-stitch it. Or put it on a t-shirt (Now, there’s an idea!)

Of course, with the back button comes its buddy, the forward button, which must also work in complete accord with your application. In other words, your application must be “clickable” back and forth transparently, as if the user was visiting the old-fashioned, pre-DHTML pages.

As an extra caveat, consider the bookmarks. In the Web browsing experience, any page can be bookmarked. So, not only your application must be “clickable“, it must also be “bookmarkable“ (I don’t think that’s a real word).

As a person who spent a lot of time working in DHTML trenches and looking on the Web, I have to admit that I know of no application or technique that universally makes any DHTML application adhere to these principles in all major browsers. In my experience, you can only go so far with what we have today. From limitations like the absense of an event model that would allow DHTML to react to history buttons to bugs that disable even a possibility of establishing the correct current location, this  is a tough one.

But I can’t know everything. Maybe — just maybe — there is a workaround or a hack hiding somewhere that brings normalcy to DHTML Usability.

Social Content Management

So, you’ve revolutionized the way people access information. Again. Just after the novelty of a search engine wore off, the ingeniously simple magic of content aggregation is taking the world by storm. Now, you don’t look for the information — the information comes to you. More than that, with the advent of casual blogging, everybody and their grandmother — quite literally — can be producers of this information. Spaces, Blogger, the oft-forgotten LiveJournal, and other online services make it almost too easy for you to start your own personal feed, ready to be subscribed to in a matter of seconds. Type away, grandma! The world is listening.

And type they did. Suddenly, everybody has a blog (“online journal” is so two years ago, you know). People are pouring out their emotions, latest tidbits of news, however big or small, linking to each other, expressing their thoughts, ideas, from asinine to wickedly brilliant. The collective chatter is getting louder and more diverse, adding more and more harmonics, fast approaching the complexity of a white noise… And when my desktop aggregator tells me every two hours that there are 500+ new posts found in 100+ feeds, I know something’s gone terribly wrong. The magic spring of information turned into the busted open hydrant of blabber. Now what?

Welcome to the field of Social Content Management. Just a couple of years ago, its older cousin Enterprise Content Management (ECM) was all the buzz. But unlike ECM, Social Content Management is not here to support and enforce business rules, workflows, and an overarching information architecture of content. You can’t enforce workflows on a blogging community. Suddenly, it’s all about what sites you link to, what others think about you, whether and in what context they link to you. Rather than business rules, it’s cliques, networks of friends, and circles of interest. In this new world, content management is a byproduct of social interaction. There is no editor. There is no producer or reviewer. Instead, editing and reviewing activity is woven into the process of blog surfing. Whether it’s commenting on a post, clicking thumbs up or down button, pinging a TrackBack, even adding a link to the post — each of these actions is used to infer more information about organization of content.

Speaking in definitions, Social Content Management is a set of concepts, methodologies, and standards, which enable and facilitate creation, organization, and maintenance of content by means of social interaction of individuals online.

To avoid being egged mercilessly, I must disclaim that I didn’t come up with this term first, and certainly didn’t invent the notion. Slashdot is a shining example of Social Content Management, and this site has been around for a while. All I am trying to do is organize and orient the various thoughts regarding this subject to gain a better perspective on the field.

Of course, just naming the process does not solve the problem. By definition, Social Content Management produces highly compartmentalized and biased content structures. Not having centralized due process makes objective organization impossible, which makes it hard to get out of the boundaries of compartmentalization. However, centralization or accumulation of content organization leads to various issues of ranging from API or even problem domain disparity to identity verification and privacy. In other words, the field is wide-open. Actually, it’s more like a steppe, with rolling tumbleweeds and wild grass hiding treacherous ravines.

All the more exciting, isn’t it?

Feelin’ all AJAXy: How Prince of Salamis Became the Moniker for Stuff Done Before

Developers of the MSDN Library site, I feel your pain. You’ve perfected technology years ago (and I am not talking dog or Internet years!), quietly enjoying its success, only to have all of its coolness taken away by Google. Then, some hotshot comes along, slaps a four-letter moniker on it and bam! — you are so out of the picture, it’s not even funny.

For those who haven’t been paying attention (Watchful Mary Jo and even the Noble Scoble included, methinks), Microsoft had used AJAX in production sites for many, many years. How many? Well, let’s just say that there wasn’t an XmlHttpRequest spec properly implemented in Mozilla. And certainly before the term AJAX was coined. Observe Exhibit A, the tree menu of the MSDN library site: asynchronously loaded using JavaScript and XML, beta in 2001, live in early 2002.

What can you do, Microsoft dudes? You just don’t know how to coin cool four-letter acronyms. Although I have a feeling you could think of a few four-letter words right now…