Software & IT

Blog 3.5.0 Set for Release

After a few months delay, the Blog team is set to release the 3.5.0 version of the DNN Blog module.

I won’t go into the details of the reasons behind the holdup.  Our team leader has done a good job of that here, if you’re interested.  Suffice to say, sometimes, there are circumstances beyond one’s control.

I am not sure at this point if there will still be a 3.6 interim, or if we’ll proceed directly to version 4.  I’m sure everyone knows my opinion!  At any rate, it’s good to be back on track.

ZuiPrezi: Yup Yup

Daniel Miller turned me on to ZuiPrezi, a nonlinear presentation environment built using Adobe Flex.

It’s really cool, but not just because it knocks PowerPoint back on its butt.  It’s cool because of what it suggests about the future of content presentation.

A lot of marketing types have abused Flash by building incomprehensible yet very nifty-looking sites with it.  Like Rapp.  They’ve improved their site, believe it or not.  Now it’s two pieces – a blog, which is nice but uninformative, and a list of a couple dozen phone numbers on a rather overdone map interface.  It’s up to you to know in advance that they are the world’s largest Internet marketing content provider, otherwise, you wouldn’t even know what business they’re in.  And forget about watching a demo reel, seeing a list of current clients, or getting any actual business related information.  It just isn’t there.  But this is an improvement – a few months ago I stumbled across their web site and couldn’t even figure out how to work it.  As in, literally couldn’t figure out what it did.

ZuiPrezi is so simple.  You use it to produce a landscape of information, then fly around that space according to predefined markers, or navigate the space ad hoc.  That’s it.  The information you place in this landscape is the same stuff you can put in a PowerPoint – text, graphics, photos, video, etc..  The only difference is that ZuiPrezi breaks out of the “pages” paradigm by placing the information onto a surface over which you fly, instead of paginate.

Where ZuiPrezi gets it right – at least in the demo presentations produced by Kitchen Budapest – is through the use of visual cues like boxes, text, and images to provide a meaningful landscape when you zoom completely out.  In other words, you can see the content of the entire presentation and immediately grasp a lot of context.

This is the future of content sites.

More to come…

Blog Team Announces Interim 3.6 Release

The DNN Blog team has announced plans to release an interim 3.6 release to provide some final changes before undertaking the effort to rewrite the code for the version 4.x release.

The 3.6 feature set has not been made official, but current plans are to add support for BlogML, tagging, 301 redirects, and custom RSS URLs.

All effort will be made to minimize scopecreep, since it is a high priority to move forward with 4.x, but we felt that these critical changes needed to happen sooner than could be provided by 4.x.

Please Wait While We Fumble Around in the Registry

I really like Windows Live Writer.  But what’s up with the installer?

Why should it take long to determine which Windows Live applications are installed?  Hey, Microsoft developers, I’ve got a new word for you: manifest.  Would it be too hard to just have a file that contains the Windows Live applications and their versions?  I’m sure it would take a lot less time to “Search”.

Oh, yeah.  A loooong time.  Just under 15 minutes.

Seriously, folks.  If you can’t write better apps than that, I have grave concerns for the future of your company.

More on Tagging

I stumbled across a bit of text that clarified an earlier discussion on tagging:

Hierarchical: indicates a parent-child (vertical) relationship like cat and dog are children of mammals)

Association: indicates a “similar to” (horizontal) relationship like mammals is similar to animals.

Bingo!  This is what people think of when they create categories and tags.  Categories are hierarchical, and tags are associative.  The problem is – they’re both right and wrong.

They’re right, because this is in fact what categories and tags provide.  But they’re wrong in the sense that all knowledge is hierarchical, because all human comprehension is based on sets, and sets are inherently hierarchical.

This proves an earlier point.  It isn’t the case that some knowledge is hierarchical and some isn’t.  It’s just that some topics are members of hierarchies that haven’t been defined yet.  “Mammals” isn’t similar to “animals”.  Mammals are animals.

“No problem,” you rejoin.  “That’s just a bad example.”  To which I reply: prove it.  Show me an example of an association that relates two topics yet isn’t part of a definable hierarchy.  By definition, you can’t, because the presence of an association automatically implies some set within which both topics belong.

Now, when it comes to pouring this into software, an obvious fact springs to mind: we can’t possibly be expected to have a perfectly complete taxonomy available for use within our publishing platform.  Instead, we need a system that is flexible enough to let us build as much or as little hierarchical structure as we need, and then to apply “associative” tags for topics that don’t fit into our structure.  Furthermore, it would be ideal if there was a way to “round up” topics that aren’t part of the structure, and fit them in ex post facto.

6 More Words to Avoid on your Resume

TechRepublic has a cute article listing 19 words that you should avoid using in your resume.  If you need this sort of advice, then it’s a good read.

However, I think they missed a few:

Microwaveable: your skills in reheating leftovers are probably not going to get you the job, unless you are, in fact, applying for a job as a microwave oven operator.

Lesion: nobody wants to see your scab, and, regardless of the macho factor, your wounds will not earn you enough pity to get the job.

Spandex: I’m sure you look great in your Speedo.  Don’t bring it to the office.

Nubby: nobody even knows what this means, so why bother?

Lotus Notes: two words that guarantee you will be summarily passed over for any job, probably including Lotus Notes Developer and Lotus Notes Administrator.  It doesn’t matter if you used Lotus Notes to cure cancer, the world has determined that it sucks, and has moved on.  Let go.

Did I Mention that Vista Sucks?

I needed to do a quick screen-sharing session with a couple of folks today.

In the past, I’ve always reached for MSN Messenger.  At my last client, Messenger was the default chat client, and since it has built-in application sharing, we used it daily for all kinds of tasks from troubleshooting code to figuring out where to eat.

For some reason, however, I got stuck in an infinite loop when I tried to use Messenger to share a web page.  Selecting “Application Sharing” from the “Start an Activity” menu, I was presented with this disturbing message:

Your invitation was not sent because you need the latest version of Messenger to use the Application Sharing feature. Please go to the Windows Live Messenger update site to install the latest version.

That was a strange message, because I’m running the latest version available, 8.5.x.  But, being a sucker, I clicked the provided link, which started up the Windows Live Installer, which promptly informed me that I was, in fact, running the latest version.

I tried to get help on the Windows Live site, but there is no help at all on the “Application Sharing” feature.  In fact, the closest item in the Help Table of Contents was this useless page.

Frustrated, I turned to one of the last remaining software companies that still seems to have a clue (Google) for an answer to my problem.  Google quickly provided this thoroughly helpful link, which, as you can see, explains that Application Sharing (as well as Whiteboard) are no longer available in Vista.  Instead, we have Windows Live Meeting, which is a Vista-only application (and is much more clumsy to use than Messenger).

Yet another place where I’ve bumped my head on Vista.  It’s not that it’s different.  It’s that it doesn’t work as well.

Or, in this case, AT ALL.

Exciting New Enhancements to the Blog Module Comments Section

Identification icons are quickly becoming a popular way for bloggers to encourage responsible use of blog comments.  A variety of solutions are available, all of which aim to provide useful benefits to the blog reader.

Identification Icons

Identification icons are quickly becoming a popular way for bloggers to encourage responsible use of blog comments.  A variety of solutions are available, all of which aim to provide useful benefits to the blog reader.

Identification icons allow blog readers to personalize their posts just like a forum avatar.  The additional personalization may encourage responsible posting as well as increased commenting and discussion.  Identification icons prevent users from impersonating one another, leading to more responsible posting.  They also may prevent flaming, since a user tied to an identification icon will have to take additional steps to obfuscate their identity.

Version 3.4.1 of the Blog module supports all popular identification options available today:

  • Gravatar
  • Identicon
  • Wavicon
  • MonsterID

Gravatar, or Globally Recognized Avatar, provides an easy service that allows users to upload an image avatar that follows them from site to site.  This simple solution ties the image to an email address, providing a very easy way for blog software to retrieve the image.

Identicons, Wavicons, and MonsterIDs are automatically generated images that can be used in place of a Gravatar in the event that the user does not want to create one.  These images are generated by a hash of the user’s email address (or IP address, in the event that the user chooses not to enter an email address).

One feature that may be unique to DotNetNuke is the ability for the user to instantly preview their image in the comments section before submitting their comments.  As soon as the user enters their email address and tabs out of the email field, their Gravatar (or other icon) will automatically display in a preview area.  As far as we know, this preview capability doesn’t exist in any other blogging platform.

Other Comments Changes

We’ve included a few other improvements to the comments area as well:

  • Users can now enter a website address with their comment.  This feature can be enabled or disabled by the blog owner
  • Blog owner can show or suppress unique comment titles
  • Blog owner’s comments have a unique CSS tag, enabling them to stand out from other comments

My Vista Field Report

Vista sucks.


What really amazes me is that, apparently, tens of thousands of people tested this operating system for an extended period of time, and it still made it out the door.

I’m not going into elaborate detail about the problems, which, while numerous, fall into two categories:

  • Performance
  • Usability


Vista performance is terrible. I am running Vista on a 3Ghz Pentium D, 2 GB RAM, 1 GB ReadyBoost, 200 GB main drive, 500 GB data drive, etc. etc. etc.. Not the world’s most modern computer, but still quite powerful. XP runs on it like a champ.

Here’s my benchmark. I run a NAnt compile script repeatedly on an app that I maintain. I’ll compile this thing 20, 30 times at a sitting. I was frustrated with the process because, on Vista, sometimes it would compile in 5-8 seconds, but about 40% of the time it would take 30-60 seconds. Very slow, and far more variable.

On XP? The same process runs in 6.8 seconds, with approximately .3 seconds variability. Like clockwork.

The reason for the slowness and variability is easy to guess: the problem is probably any number of the 89 processes or dozens of services running at any time in a minimal Vista install. The thing is so horribly overbloated. If even one or two are rude, then that could be the problem.

What I do know is that my hard drive is constantly spinning. I’ve complained about this many times in support forums. The answer is always the same: the Windows Search indexer will chew on the drives for a few days to weeks while it’s building the initial search index. This is a perfectly reasonable and understandable explanation, and I’m willing to accept it since the idea of Windows Search is possbily worthwhile.

However, six months and one red-hot disk drive later, nothing’s changed. I don’t know what Vista is up to, but it’s really working hard. Way too hard to just be idling. And that ReadyBoost memory key just stays lit up.

I figured I might have a bad install, so I switched back to XP for a few months, then, stupidly, reverted back to Vista. SSDD.

I don’t have time to test, fix, troubleshoot, or benchmark. I use the computer too much. But my near-constant use provides me with outstanding subjective measures. The user experience of Vista is very, very slow.

Conclusion: Vista performance is terrible.


Aero is beautiful. My video adapter is quite powerful, so Areo renders nicely with no performance hit. Lovely. But no improvement in usability.

The rearrangements in Vista are a setback. Did the “Add/Remove Programs” control panel really need to be changed to “Programs and Settings”? It was a lot easier to find near the top of the list. But the rearrangements are, overall, trivial annoyances that I would eventually overcome.

The UAC is a nightmare. Supposedly, after a while, you don’t have to deal much with the UAC. Clearly, these people don’t ever clean up the shortcuts on their desktop. Every deleted shortcut is first met with “Destination Folder Access Denied – Continue, Skip, Cancel” which, when Continued, requires a UAC authorization.

Yes, that’s right, I need Administrator privileges to delete a shortcut from the desktop.

I’m sure there’s some reason that is perfectly compelling to some propellerhead somewhere. But it’s stupid. I can delete an EXE from my desktop with no interruption at all. So why do I need Administrator permission to delete a shortcut to the same EXE?

This is just one usability example. There are others. The worst offender is not Vista itself but its user-spiteful sidekick, MIcrosoft Office 2007.

Let me get this straight. They decided to change the toolbar and the hotkeys in one fell swoop?

So I’m a hotkey user. Right off the bat, I’m grounded, because so many have changed in Office 2007. So I go hunting for the right button.

However, some genius decided that what I really need, what would be really great, is context-sensitive buttons, completely and utterly missing the beauty and purpose of the button bar.

How so?

If I already knew the context of the command I wanted, then I could just as easily have picked it off a drop-down menu as I could a context-sensitive button bar. The beauty of a button bar is precisely that it isn’t context sensitive. It’s immutable. The same things are always in the same place no matter what I’m doing in the application, unless I specifically modify the bar to suit me.

Which wouldn’t be so horrible if the hotkeys (which are also immutable) hadn’t changed at the exact same time. But they did, grinding my ability to edit Word docs to a complete halt.

Indenting, numbering, and other simple, critical word processing functions have, however, remained broken. No time to fix them, what with all the oh-so-important toolbar redesigning going on.

It would be laughable, if it wasn’t so damned painful.

So, it’s back to Windows XP and Office 2003 for me. At least until it’s time to upgrade.

To a Mac.

Blog Module Musings

A lot needs to happen to make the DotNetNuke Blog module truly competitive.  Part of the problem is that there are competing needs for the module:

  • Use as a “personal” weblog
  • Use as a publishing platform

Joe Blogger

Of course, the Blog module was originally meant to serve the needs of… bloggers, that is to say, people writing journal-style weblogs.  Like this one.  That’s why it’s called a BLOG module, stupid.  OK, but suffice to say, there are particular needs of a personal weblog application:

  • Easy to use, simple
  • No need for workflow tools
  • Most will be single-author
  • Great looking, easily skinned
  • All the coolest social networking yada yada
  • etc..

In other words, a personal weblog needs to compete effectively with WordPress, Blogger, TypePad, and other popular blogging tools by offering an app that works at least as well (which will be hard, considering that several of these are free, including the hosting).  To that end, some of the features that the Blog module needs to consider are:

  • Built-in skinning (perhaps a set of 5-10 built-in template skins)
  • Email-to-blog capability
  • Metaweblog support (already on its way)
  • Social networking support (already on its way)
  • Categorization & tagging

It might also be nice if there was a way to do a DNN “blog” install, in other words, a single installer that performed the basic DNN install as well as getting the basic Blog module installed and configured.  Of course, a DNN install is still not as simple as it ought to be, and until it is, there really is no point in refining the install process of the Blog module.  DNN itself is already a sufficiently high hurdle that most casual users will shy away from using it just for blogging.

Which raises an interesting question:  are DNN bloggers every really going to be casual users?

Casual DNN Users?

After all, how many people really run DNN just to operate a personal weblog?  Doesn’t the implicit power – and complexity – of DNN in and of itself filter out almost all casual bloggers?  I mean, if I just wanted to start blogging, there’s no way I’d use DNN.  I operate this blog on DNN because I’m already running several DNN sites.  And I still question my logic in setting this up as a DNN blog instead of using WordPress or Blogger.

Seems to me that for most Blog module users, what they have is a website, part of which is a blog.  Think about this.  If they’re running DNN, it’s very likely that they’re doing “other stuff” with it other than just running a blog.

Which raises some interesting points:

  • The blog may be much more likely to be multi-user
  • The blog may be a kind of substitute for the Announcements module or FAQ, providing company information
  • The blog may be a publishing platform more than a weblog

DNN Publisher

Which brings me to the other competing need for the Blog module – the publishing platform.  If you need to manage content – by which I mean significant amounts of printed material – in DNN, then the Blog module quickly becomes your only choice, short of purchasing a publishing tool.  Nothing else in the DNN module base comes close to meeting this need, with the possible exception of the Announcements module.

As a DNN consultant, I always advise against purchsing modules if it is at all possible to conform a preexisting base module to the need.  I see the base modules as part of the open-source draw of DNN, and while they may evolve more slowly than commerical modules, they’re likely to have good quality and ultimately stand the test of time better than commercial modules.  I want to stay on open-source code as long as possible.

That’s why I chose the Blog module for, instead of buying a module or building one of my own from scratch.  The fact is, it meets about 65% of my need.  Really, just barely enough to limp along.  I don’t really want it to look like a weblog, with the calendar and month list being the primary navigation tool.  But I’m willing to make do, because I get so much for free.  Free is good.

The needs of people using the Blog module as a publishing platform (like me) include almost all the needs of the casual bloggers, but add a few twists:

  • Increased need for workflow
  • Different (non-traditional) navigation
  • Better multi-author / multi-department support
  • Different “main page” support

This is by no means comprehensive, but hits the high points.  With only a few improvements, the Blog module becomes “DNN Publisher” – a flexible publishing platform.  Suddenly, this tool can support lots of publishing operations, specifically, content sites (like newspapers and magazines) and multi-department corporate sites.

Push and Pull

All this flexibility will come at the price of complexity.  I believe that with some elegant design, we can minimize the complexity and maximize the flexibility, but increased complexity is probably a given.  So there will be inevitable battles between the people who want to use the module as a simple blog platform, and others who want to use it as a more powerful publishing platform.

Which takes me back to that earlier question: how many people really run DNN just to operate a personal weblog?  Doesn’t the implicit power – and complexity – of DNN in and of itself filter out almost all casual bloggers?  Is it really reasonable to expect DNN to compete with a free WordPress account for the market of people seeking to journal about their trip to Spain?

If there are significant disagreements about the direction of the Blog module, I think there will need to be some sort of informed answer to these questions.  Perhaps a survey or some kind of market research will be in order.  At any rate, I intend to push the Blog module in the direction of “DNN Publisher”, because I think that’s it’s unique value and a better fit with likely DNN users, and if I take a few bullets, well, they’ll be neither the first nor the worst.

The Great Child Blog Opportunity

Currently, the Blog module implements a concept called “child blogs”.  These are sub-blogs of a parent blog, which are broken out in the user interface as separate sections, each with its own administrative rules.

Since the Blog module doesn’t currently support the idea of categories or tagging, a lot of people use the child blog functionality as a means of providing a categorization function.  In fact this is often the recommended use of child blogs.  IT Crossing’s lovely metaPost product takes this one step further, by integrating the categorization function in LiveWriter to the child blog capability in the Blog module.  Unfortunately, this misuse of the existing functionality is going to have to change, and the sooner, the better.

Currently, the Blog module implements a concept called “child blogs”.  These are sub-blogs of a parent blog, which are broken out in the user interface as separate sections, each with its own administrative rules.

Since the Blog module doesn’t currently support the idea of categories or tagging, a lot of people use the child blog functionality as a means of providing a categorization function.  In fact this is often the recommended use of child blogs.  IT Crossing’s lovely metaPost product takes this one step further, by integrating the categorization function in LiveWriter to the child blog capability in the Blog module.  Unfortunately, this misuse of the existing functionality is going to have to change, and the sooner, the better.

What the Hell is a Child Blog Anyway?

I can’t read the minds of the original designers.  However, a peek at the database helps to shed some light on the issue, and it reveals an altogether different (and better) purpose for child blogs than categorization.

Child blogs are implemented as complete blogs in their own right, the only difference being that they have a “ParentID” that points to an uber-blog.  This parent-child relationship allows child blogs to “roll up” into a parent blog in a very useful way.

Why is the child blog structure a poor place into which to pour the concept of a category?

1. Blog entries can belong to more than one category / topic
2. Categories, as a concept, do not possess all the other managerial attributes of a blog (e.g. “allow anonymous comments” is not an attribute of a “category”)
3. Categories do not have “owners”
4. There can be more than one category hierarchy (for example, an auto-review publication might have an index of cars by manufacturer, and another index of cars by car type)

It seems apparent to me that a category scheme for blog entries ought look a lot different from that of a child blog.  In summary, there ought to be an organized list of category “topics”, with a many-to-many relationship between blog entries and topics.

What, then, are child blogs?  And how should we steer their use going forward?

To me, it’s clear that child blogs represent “sub-publications”.  In a large publishing organization, say, a newspaper, different sections of the paper are managed by different organizations.  They all roll up into a single publication, but by and large each publication is an almost stand-alone entity.

Consider the sports section of a major newspaper.  It has its own editorial staff, its own submission policies, maybe even its own index.  There really isn’t any reason that it couldn’t be sold separately as a sports-only specialty newspaper (and some are), except for the fact that it’s bundled together with the rest of the content.

Or consider the test-drive section of a car magazine.  There is a dedicated team of reviewers who do nothing but drive and rate cars.  They have their own procedures for this.  They’re answerable to a Practices editor who manages the review practices for fairness.  They have their own team of people who manage the pipeline of new cars that need to be tested and evaluated.  Really, there could be a publication that is nothing but car reviews, except that the auto magazine has decided to include it with all of the other sections in a bundle.

I think it’s clear that child blogs ought to represent “sections” – pieces of the publication that are broken out for arbitrary business reasons, and not necessarily because they relate to common topics.  Now, a given publication might very well like to split out its publication according to some major topical divisions, and child blogs could be the right way to handle this task.  But in this case it’s simply a coincidence that child blogs are split out according to major topical divisions.

The other thing that a child blog shouldn’t necessarily be is a set of entries by a given author.  Of course, it may be useful in a given publication (a moblog, for example) to give each author his own child blog and let each one be individually managed.  But it shouldn’t be necessary.

Child blogs really map to the idea of organizational structure.  Some companies are organized by product.  Others by function.  Some are organized geographically, others by technology.  Some are split in order to serve government customers separately from private industry.  In every case it’s a mistake to confuse the org structure (e.g. “product organization”) from the thing itself (e.g. “actual products”).  Likewise, child blogs ought to be used to solve the arbitrary managerial or organizational needs of a publication – which may map to high-level topics or authors / author groups, but only by coincidence.

Get to the Point Already

Where am I leading this?  Let’s get to the punch line.  I want to separate the semantics from the presenation.

Categories and tags – which I am increasingly beginning to think about collectively as “topics” – represent ways to chunk the content by its meaning, organizing it hierarchically (as with a category) or flat (as with a tag).  There are different user interface widgets we can employ to get at the content by topic, including widgets that display “index views”, widgets that display “tag clouds”, and widgets that display “related entries”.  Ultimately, however, we’re just talking about different ways of doing the same thing – grouping entries by topic.

Child blogs – which I am increasingly beginning to think about as “sections” – represent ways to chunk the content according to arbitrary managerial need.  Child blogs should allow a large publishing team to segment the ownership of pieces of the publication and roll up the content into a coherent whole.  In fact the current design of the Blog module comes surprisingly close to this goal.  If any workflow capability is attached to the Blog module, it’s clear that child blogs represent the set of structures needed to pull it off, each offering its own set of editors and authors, approval workflows, roll-ups to parent teams, etc..  As with “topics”, there are different user interfaces we can employ to get at the content of “sections”, including widgets that allow individual child blogs to live on different DNN pages (each with its own look and feel) while rolling up to a “summary” page elsewhere, widgets that roll up the child blogs together by section (rather than grouping all the content together chronologically), or widgets that provide category “indexes” within a given section (like a sports section index).  Ultimately, however, we’re just talking about different ways of organizing content according to an arbitrary managerial need.

Authorship – which needs to be thought about independently from “blog ownership” and “sections” in a multi-author publication system.  Authorship is an attribute of an “entry”, while “editorship” is an attribute of a “section”.  While a given publication might create a different “section” for each “author” (e.g. a moblog) I think that ought to be the exception instead of the rule.  A given author might create content in various “sections”.  Yet there remains a need to be able to find content by author.  Ideally, we should provide widgets that can display content by author – even allowing a publication to create “author pages” – without necessarily creating a child blog for eah author.  So, for example, a moblog like CuzWeSaidSo would probably create one section per author – because that’s the idea behind the publication – whereas a product-review magazine like ProRec would have sections like “From the Editor”, “Product Reviews”, and “Industry News”, with a given author publishing content in any or all sections.

The Pain of Change

One reason I mentioned metaPost earlier in the article is because I believe that improvements in the blog module, as well as its support tools like metaPost, will lead more people to choose the DNN Blog module for their publication needs.  Let me be blunt: what we have now is a sort of bastardized system that solves none of the above problems well at all.  The longer we go on without making these critical structural changes, the more we doom the Blog module to a second-class existence.  Conversely, the sooner we tackle these problems, and the sooner we address the pain associated with making these changes, the easier it will be.  Delaying these changes only means more pain later on.

Tags, Categories… What’s the Difference?

I’m cooking up a categorization / tagging module for the DotNetNuke blog module, and really would like to get it right the first time.

I want to balance ease-of-use, practicality, and power.  Right away, the issue of managing a “true” hierarchical tag structure with multiple selection capability rears its ugly head.  Building a tree-style hierarchy manager is tricky, and can be confusing to users.  And then, assigning categories from a tree structure can be very clumsy, especially if the tree is very tall.  I’ve seen this done with side-by-side listboxes & tree controls, and it’s always really clumsy.

If we set aside the idea of hierarchy for a second, and just look at good ways to apply tags, I like the way Amazon handles it by using a simple Ajax-enabled auto-suggestion textbox.  You can easily type a few characters of an appropriate tag, and the app will suggest the rest of the word.  More tags can be added with a comma delimiter.  If you want to add a brand new tag, you just type it.  This eliminates the need of a long list with checkboxes or a UI for creating and managing tags.  A significant advantage is that it works for short lists yet scales up very well for long lists.   I strongly prefer this UI for applying tags to blog posts.

Trying to implement this with true hierarchies is trickier.  My idea is the use of a hierarchy delimiter.  The user can create hierarchies as deep as they like, and the auto-suggestion box helps them out.  So a blog post might be tagged up as follows:

Tags: [PlacesDallas; PlacesNew York; PlacesParis; FoodsSteak; FoodsFish; FoodsPizza; Time of DayMorning; Time of DayEvening]

The data-entry UI would automagically suggest each portion of the hierarchy at a time, so when the user types “Pl” the textbox responds “Places”, and the user hits the delimiter key “” to accept and begin entering the next hierarchy component:

Tags: (type) Pl
Tags: (UI responds) Places
Tags: (type) Places (user enters delimiter key)
Tags: (UI presents) Places[drop-down list of places in the places list, if list is < 10 entries]
Tags: (type) PlacesDal
Tags: (UI presents) Places[drop-down list: Dalhart Dallas Dalton]
Tags: (user selects Dalhart)
Tags: (UI presents) PlacesDalhart; (adds delimiter so user can begin entering next tag)

The data can be stored in the database using a traditional n-level-hierarchy (parent-child) structure.

A hierarchical list can then be presented:

..New York

Not Alone

In my latest post, I mentioned that I really view tags and categories as two facets of the same thing.  Turns out I’m not alone.

This interesting post explains how WordPress implements tags and categories.  Like me, it’s apparent that they view both tags and categories ultimately as the same entity type: “terms”.  They then overlay a set of structures that enable various use of “terms” in the WP UI.

I think a similar – if not identical – approach should form the basis of tagging and categorization in the DNN blog module.

Tags, Categories, and Knowledge Management

I’m inclined to view “tags” and “categories” as just two facets of the same thing: knowledge hooks we apply to content to help us find it.  My gut tells me that these things tend to be viewed as two different beasts because of the way they’ve historically been implemented.

While I’d love to get the concept of tags and categories right the first time, and do it in a way that’s cohesive and elegant, in the end, compatibility with other approaches is probably the right solution.  So we may just need both tags and categories regardless of personal beliefs on my part.

Of course, one way to kludge both into a common solution – that isn’t terribly kludgy – is to have a predefined “category” called “tags” (or “Keywords”) that contain all the “tags” and which are wired through API to the correct fields in LiveWriter.  They could be presented in the DNN module as a separate field that works just like “categories” only without hierarchy separators.  It would still reside in the same data structures and produce the same lists and “related entries” capabilities.

I have a lot of experience with knowledge management solutions (I’ve been doing KM since 1993), and think that “best of both worlds” is really the best approach, because it offers the flexibility of tags with the structure of categories – in other words, it’s a lot more like the way the mind manages these knowledge structures.  My experience is that “structured categories” always start out as “flexible keywords”.   At some point, there is sufficient comprehension to establish the structure that was previously invisible, and then your “keywords” become “categories”.

Let’s take a cue from Amazon.  They sell items in categories.  And items can have multiple categories.  They also assign author (artist) and other common attributes.  However, they only offer one “category” structure – a “genre” list.

They also offer tagging.  If you look at what sort of tags get created, it becomes plain that there are three sorts of tags:

1. Spurious tags – tags that duplicate existing attributes and shouldn’t be there in the first place, e.g. “Monty Python” tag associated with the movie “Monty Python and the Holy Grail” which has an artist of “Monty Python”, or tags which just don’t add practical value, like “Movies that Include the word ‘swallow'”.

2. Tags that ought to be part of a data structure that just doesn’t exist – e.g. “Graham Chapman” tag on “Holy Grail”, which really ought to be part of a structure called “Actors” but isn’t provided by Amazon.  Or “British Comedy” which really should have been a subset of the “Comedy” genre, but Amazon didn’t provide this option.  Or “Arthurian Legends” – a tag that could easily have been a category in the “Subject Matter” hierarchy.  Or “Party” – a tag that could well belong in a “Mood” category.

3. Tags that don’t seem like they should be part of a data structure, YET, because not enough material has been tagged on this dimension to understand the dimension.  For example, your hypothetical post that you wanted to tag “suggestions”, could easily have been a node in the “Article Type” category, along with “Ratings”, “Reviews”, “Comparisons”, and “Recipes”

Back in the olden days of doing KM in Lotus Notes, there was often great confusion about the difference between “Categories” and “Keywords” and the reality is that they’re both the same thing, with differing amounts of structure.

IMHO the problem that “tags” have shown up to address is the same one that “keywords” showed up to address – the problem of only offering one category dimension.  People get stuck in the paradigm and can’t get out.  Consider this article covering the subject – it’s clear that the author views “tags” and “categories” not as KM abstractions in and of themselves, but as artifacts of the particular implementation in WordPress.  WordPress has a particular implementation of Categories that lends itself to a limited use – e.g. you can’t have too many, because the sidebar list will be too long.  Well, that’s an artifact of putting the whole thing on a sidebar all at once, and not a consideration of the KM implications at all.

Consider that most books just have an “index”, which is a “subject category” structure.  But some reference books have indices for many different dimensions.  Likewise, most blogs just give you the capability to build the single “subject category” structure.  But if we built just one iota of flexibility into the “category view” module, then you could (for example) have one category hierarchy that is short and highly topical and shown on the sidebar (like WordPress) as well as other hierarchies that are deep and multi-layered, but viewed through a larger display on a different page, and other views like the “Related Entries” views that mine the hierarchies and just return the most relevant entries.

Not only does this offer a lot of UI flexibility for sites with a lot of structured content, but also, given the way the topics, keywords, and URLs are all associated, it’s a real SEO boon.  You can build a very strong semantic map into the linked content.

Having said all that, I will return to the position that I suppose we’ll have to support both tags and categories, but perhaps we can do it in a more powerful, elegant way than just duplicating a bunch of middle-of-the-road functionality.

The Valid Lure of The Next Big Thing

Jeff Atwood writes about the “The Years of Experience Myth” in his usual, dead-on style:

Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match– exactly and to the letter– some highly specific laundry list of skills.

Somehow, they’ve forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.

Jeff goes on to make the point that you can use job requirements like “3-5 years of experience in such-and-such” as a baseline for determining the quality of the hiring company.  If they hire based on irrelevant (or counterproductive) measures of skill, chances are good that “the rest of the team will be stooges picked for the wrong reasons.”

Let’s take this a few steps further.

Consider the impact of this situation on emergent technologies, and I think a case can be made for why new, “special” technologies have the lifecycle they do.

I’ve often wondered why new technologies get the hoopla that they do.  Is C# really such a huge improvement over C++?  Is Ruby on Rails really such an extraordinary step up from PHP?  Sure, these technologies usually represent improvements – sometimes significant ones.  But by now we all should know that the real cost – and opportunity – of technologies lies in the human capital involved.  I for one will take an A+ PHP developer over a B- Ruby developer any day.

So why do new technologies get the buzz?

If the best programmers are learners, then it stands to reason that when a new technology is introduced, it will be the curious learners – the best programmers, in other words – who early-adopt it.  It therefore follows that the first wave of solutions based on the new technologies are often the outstanding solutions – not because the technologies are so great, but because by virtue of their newness, only the very best programmers are using them.

Once the technology has matured somewhat (and the requisite training curricula, certifications, and dead-meat programmers take their places in the market), productivity understandably falls off.  The quality and novelty of the solutions drop.  The buzz and hype fade.  And the best programmers, having been a part of this technology shift for several years at this point, start looking for something new to learn, and move on.

This offers some interesting lessons to learn.

  • If you’re a software badass, then it really pays to stay on the leading edge of new technologies, even ones that don’t seem to offer a real benefit.  By doing so, you not only differentiate yourself from your peers, but you also will probably end up in the company of other badasses doing badass work.
  • If you’re a company looking to start some new development, consider implementing using new technology as a way of discerning and attracting talent.  Your risk – that of implementing an untried technology – may be lower than the risk of implementing an established technology with tired, unproductive, uncreative developers.
  • If you’re a software toolset provider, your marketing strategy should be based on finding the software badasses and convincing them to early-adopt your technology.  This may even dictate that you do not offer training or certification, and keep your documentation sketchy and terse – just the way badasses like it.

The Sheer Magic of

If you aren’t yet familiar with, you should be.

For several years now, DynDNS has offered a free (yes, ma, free) DNS service for people with dynamic IP addresses.  This allowed people with a highspeed always-on internet connection to get a domain name.

See, if you have cable modem or DSL, you really have enough bandwidth to run a light-volume internet host from your home.  The problem is, you can’t register a domain name, because your IP address changes from time to time.  Enter DynDNS.  They have software that detects when your IP changes, and it updates their routing table.

Unfortunately, the only domain names you can use are extensions to their preset names (names like  For many uses this is enough.  I’ve been using for years as a domain name for my company’s backoffice server.  It really works, and it’s free.

Free. The word seductively rolls from my tongue.  MMMmmmmm freeeeeee.

But now, DynDNS offers another service that may change everything for me.

For about $25 per year, they’ll run a dynamic DNS service for any domain name.  You register the name with the registrar of your choice (say, GoDaddy) and point the domain to DynDNS’ nameservers.  That’s it.

What you’ll find is that if you have a reasonably reliable high speed internet service, you can easily run a web site on your personal machine (or, if you’re like me, on your own server at home).  In case you’re wondering, Dell sells servers perfect for this sort of light-duty use starting around $350.

If this works well enough, I may even decide to host at home.