Sunday, August 18, 2002

liveTopics license

So I'm ready at last to release liveTopics 1.0, the last remaining task is to find the license to use.   I want a license that allows me to release it free for personal use whilst still retaining my ability to charge businesses for it.  I want a license that allows me to publish the source (with Radio is there any other choice?) and encourage others to contribute, yet doesn't allow my work to be unfairly exploited.

Can anyone recommend what license I should be using?

18/08/2002 16:13 by Matt Mower | Permalink | comments:
More about:

Addressing accessability: font sizes

Why I'm Not Reading Your Blog and Why Others May Not Be Also.

Why I'm Not Reading Your Blog and Why Others May Not Be Also

  • *&*### Font Size is Locked Down!!!!  Depending on how you setup your CSS sheet, people with certain browsers, say IE 5 - 6 on a PC, can't raise the font size of the main text.  I run 1600x1200 on a 19" monitor and that means that 10 point type is, well, just plain freaking teeny tiny.  Here's a blog I'd like to read regularly but I don't really since it's just too small (but it's good):
    [The FuzzyBlog!]

» The reason I changed my weblog template was to make it more accessible.  I had been feeling that the template I was using so cluttered that it was getting in the way of the content.  Comments I received from others before and since would confirm that.  I believe the new template is much better in this regard.  All the bells-and-whistles have gone.  If you want to do a Google search about some topic I'm talking about, get the Google Toolbar and do it yourself!

However Scott's posting reminded me that this isn't enough.  So I've hopefully addressed the first of his complaints.  Mark Pilgrim has kindly organized his accessability guide for easy reference and today I've done Day 26: Relative font sizes.

18/08/2002 17:20 by Matt Mower | Permalink | comments:
More about:

Fixing intranets with klogs

Fixing intranets. It's interesting how the same issues seem to come up in bunches. Over the last month, I have now talked... [Column Two]

» James has written an interesting post about some of the common problems with intranets that he encounters with his clients.  As someone interested in how klogging (I'll use the term for now!) could affect the role of intranets and content management his issues seem particularly relevant to me.  In preface to my remarks I should point out that I am choosing to address static content rather than the possible dynamic web applications you might find on a typical intranet.

The issues, re-ordered slightly to suit my responses, are:

  1. The intranet has grown over time.
  2. Manual processes (using Frontpage or Dreamweaver) are used to publish pages.
  3. A lot of information has been published, but the site isn't being used.
  4. There is little high-level structure, and users are not able to find information.

1. If you want a logical hierarchical structure then organic growth is a problem.  It's like running water, it flows down along the path of least resistance and doesn't care about the direction.  Same with people, they'll squirrel stuff anywhere that makes sense today (have you taken a good look at your my "My Documents" directory lately?).   Of course if you're klogging then this organic growth is part of the package.  Whether that bothers you is probably a factor of points (2), (3), and (4). 

2. This is most obviously solved by klogging software.  It's one of the fundamentals.

3. Hard to say but I guess much of the information published may be of low quality.  In my experience no matter how hard publishing to an intranet can be, creating information is harder still.  This leads to variable quality in that information.  Variable quality leads to low usage.  Low usage provides little incentive for new information to be created and so on.

Klogging address this in two ways I think:

  • When you have something to publish it's dead easy: click, type, click.
  • You can publish in bite-size chunks.  This means that if you have a small but useful piece of information you can just klog it.  You don't have to pad it into a long document to make it worthwhile.  You also don't have to find "just the right place" for it to go, it just gets klogged.  That chunk can exist in it's own right, waiting for the day someone needs it.

Which brings us rather neatly to (4)

4. As it stands klogging is a decentralizing technology that doesn't encourage a formal hierarchical structure.  You klog and, if all goes according to plan, people will subscribe to you and they will link to you.  Will they be the right people?  Does it make information any easier to locate?  Not automatically no.  But then hierarchical structures don't necessarily make life any easier.  Once a hierarchy is more than about 2 levels deep it can cause it's own navigation issues.

Some people might argue that a healthy klogging culture coupled with a Google search appliance (or any search engine that has a pageranking algorithm I guess) could well make it easier to find what you're looking for.  I think theres something to be said for that.

My own approach is to allow for easy metadata-enabling of klogs.  My hope is that combining klogs with topic maps will allow new structures to be grown from them automagically.  This can complement the pagerank based search and provide new ways of finding and traversing group knowledge.

So should you scrap the intranet and replace it with klogs?

I don't think so.  But perhaps you should think carefully about what you want your intranet to achieve and whether some of your goals for information publishing and dissemination couldn't be better achieved with a klogging strategy.

18/08/2002 22:31 by Matt Mower | Permalink | comments:

Klogging issues

I had a very useful and productive meeting on Friday.  I gave my first klogging pitch and, despite the roughness of the material, it didn't go too badly wrong.  I was pitching to friends which has it's plusses and minuses but overall it's the right place for your first pitch.

Here are some of the important issues that were raised:

  • Having klogs can easily overlap with existing formal systems.  For example when klogging a difficult interaction with a student (these guys are at a University) does this mean that you don't put the information into the CRM system?  Or when klogging about a problem with the printer should you not fill out a helpdesk ticket?   It's not enough to answer that these kind of formal systems are often under-utilized, the people aren't trained, etc. since it's hard to argue this with a client who has invested in these systems.  Indeed you may be pitching to one of their sponsors who might not take kindly to such assertions.
  • Klogging as presented so far is a decentralizing technology.  However the natural tendency of most organizations (at least in my experience within the UK) is to want to centralize.  The idea of employee's having greater autonomy is not desirable.  Of course they won't say that up front, however...
  • Many people will fear that klogging could be used as a control tool that lets unscrupulous managers see exactly what they are doing and maybe even document their job so that they can be replaced by someone cheaper.   It's a sad reflection on todays workplace, but it is a reflection.
  • Security.  This is closely related to the de-centralization point above.  At the moment klogging systems (because they are basically blogging systems where security isn't an issue) have little or no inherent security.  This will limit their value as people will feel unable to klog anything sensitive.
  • Big-KM vendors will embrace klogging.  This is really only of interest to people espousing klogging solutions based on products like Radio or MoveableType (is there anyone?).  My own belief is that the Big-KM vendors will do their usual job of missing the boat, missing the point then coming to the party with a hotchpotch solution.

These issues are not new but are, to my knowledge, unresolved.  I'll be looking for answers in the days and weeks ahead.  Anyone got a headstart on me (please!)?

18/08/2002 23:22 by Matt Mower | Permalink | comments:
More about:

Klogging up the intranet

Just thinking about intranets and klogs.

I think klogs bring the role of a web or intranet editor sharply into focus.

Much as the users of a Wiki should occasionally re-factor pages that are becoming "busy" I think that a good intranet editor should be grooming the klogs in their organization and drawing together useful strangs to form part (or all) of the static intranet.

I wonder what kind of tools would make this easier?

18/08/2002 23:26 by Matt Mower | Permalink | comments:
More about: