Tag Archives: Tools

The Tools

We started looking for suitable collaborative tools by looking at Gartners Magic Quadrant for Social Software in the Workplace – a lovely chart that plots all the movers and shakers in the social media space. We could quickly rule out tools that seemed too CRMy, had a pricing model that ruled them out (i.e per user) or too business focussed. After a few rounds of testing we were left looking at….

The Candidate Tools

SocialText – a commercial enterprise wiki with a social layer


One of the most interesting things about SocialText are what it calls Signals, which are a bit like Twitter for the organisation, except Signals include tweet-like messages AND document changes. Very nice. We found the blogging tools very poor though – with blog posts essentially being wiki pages.

Like most wikis you can embed tags to give pages more functionality (such as showing a list of Recent Changes, or items from a Delicious feed etc). This means that you can cobble the functionality you need together very quickly. One example we played with was for the IT Support Office to individually use Delicious to bookmark and tag fixes they found out in the rest of the web and have them “collected” back on their wiki pages.


One of the “killer” features of SocialText is it’s Desktop application which, like email, tells you when something new has happened. This is an essentially component of any new collaborative tool because it “pulls you back” rather than becoming “another place to check”.

Jive – a commercial forum-based tool with wikis and blogs etc


Jive has a lot of polish with regards to the interface. It is easy to create content.

LifeRay Portal and LifeRay Social Office – a java-based, open source portal tool


LifeRay is an astounding product. When you initially log in, you just drag the components you need into your community site ( pages, wikis, blogs, calendars ) and then invite people in. This is staggeringly easy to do, like having a Ning-builder (but better). The LifeRay Social Office suite is sort of a “pre-built” version of the portal.

If you have ANY java abilities at all this is worth a look. I was slightly scared by having to compile CSS into jar files to change the look and feel and work with a gazillion XML files but some people can eat that geekery for breakfast.

Elgg – a php-based “community in the box”


Elgg is immediately likeable. You create Groups that have blogs, discussions, files, wiki pages etc. The problem with Elgg (for us at least) was to do with the permissions model, or who can see what. It’s funny but with almost ALL these tools, the permissions model is where the pain is… And often, it’s not that it’s difficult, it’s just that it’s poorly communicated. You can’t see who can see what…

Other Tools Worth Considering?

Half way through the trials we kind of re-discovered Confluence, a commercial enterprise wiki with an impressive list of plugins (including Sharepoint connectors which may come in handy at some point).

And later I stumbled across Mike2.0 which is interesting in two ways. Firstly, it is attempting to share the knowledge about collaboration… and secondly, it attempts a shot at combining some best of breed open source tools into one suite. You can download omCollab which is WordPress, MediaWiki, phpBB and other tools all rolled into one seamless environment. It’s a great idea… it almost works… but there are seams (and it’s fun to install).

Some of the others we tinkered with are listed in my Delicious tag for collaboration .

The Difficulties of Evaluation Community Software

Because collaboration is almost impossible to simulate… the plan is/was to get as many teams actually using these tools on short length actual projects so that we could get reliable feedback about what works and what doesn’t. So, through a process of “walking about a lot” I met as many different teams at the university and badgered them into helping test the tools. We now have teams sharing content daily … and others tinkering at the edges. It’s a good mix and so far has been a damn sight more productive than attempting to evaluate what the organisation needs without people in the mix.

The next post will be about some of the features and bugs that we found along the way.

p.s This post would have been a lot longer, in fact it was, but somehow WordPress lost it and I’m still a bit grumpy about it… As it turned out, it’s probably a better blog post for being shorter…. still… grr!

Wonderful ZuiPrezi presentation

Recently, a GeekUp message rekindled my long-standing appreciation of all things zoomable. One of the problems with many zooming demos is just that, they’re only demos.

Like many visualisation examples, zooming works best when you it’s a tool rather than a media-type. You need to get your hands dirty, to fly around and play with your data rather than consuming someone else’s zooming media.

In the same way that reading a great book inspires you to write or seeing a fab painting makes you want to sketch or hearing a moving song starts you singing… In same way that writing bad poetry makes you appreciate the good stuff or painting an awful picture makes you visit galleries…

ZuiPrezi is wonderful! And not only is it interesting from a media consumption point of view, it’s a tool with which you can create your very own zoomable presentation or environment. I’m absolutely blown away by the potential of this….

For those without embedding, go here.

Your Space isn’t My Space

I love the idea of collaboration. I love drawing. Collaborative drawing is a rare thing…  it hardly ever works…. for me at least… and one of the main reasons is because of the lack of ownership within the collaboration. Collaboration shouldn’t be about letting some random idiot ruin your stuff (or the other way around).
Doodle-board is ok but you very quickly want your own board. Having anything collaborative where there is more of a motive for vandalism will always fail.
I wonder why the drawing tools themselves are so laggy. Drawing isn’t drawing when there’s a lag, it’s a bit like when a phone has a delay and you find yourself stultified, unable to speak…or chat rooms when the delay makes nonsense of the conversations…
This BBC One Twitter board reminds me of PlasticBag Tom’s social telly watching mock-up, an idea that I still think has legs. The BBC site should let me create a space on top of their Twitter space so that as well as babbling on in real time in-tune to the programs, I and my friends could too. It’d be like been able to heckle the shows with your friends as audience/fellow hecklers.

The Wallright project actually takes another collaborative painting tool and makes it appear on a real wall. I like this idea… and this one rations your paint, presumably to limit vandalisation… but it instantly feels like you are working under a miserly teacher not handing out the red and pink because of what they might draw. The colour palette is too limited… and again, the drawing experience is horrible.

It seems that as someone else paints, my strokes are taken off… which is interesting, like there’s a finite amount of paint that keeps getting recycled.

The lack of ability to keep a bit of the canvas for yourself is a shame… if this was a real wall I could at least use my elbows to keep you from messing my bit up.
I’d forgotten about this drawing-based image search engine (retrievr). You paint what you want… and it fetches similar images. I painted an Apple and got this. This would be really interesting for porn… perhaps generating a whole new collection of primitive art works that would describe our collective sexuality. At worst you’d have an hilarious comic to which people could suggest captions.
I’d love this site to…

  1. work with Flickr or Google images, more is always better.
  2. Be able to take text input such as tags, more modalities is often better
  3. Work with a collaborative site such as the ones above, more people can be better if done well.
  4. Show a list of recent searches/drawings

5 tips to help you choose a CMS based on the editing interface alone

One man’s WYSIWYG……is another’s botch job.

WYSIWYG (What You See Is What You Get) editors are starting to replace textareas in web forms. The openwysiyg initiative makes it easy and cheap for all developer to use these tool.This in itself seems a good thing, many people find it easier using simple tools rather than having to remember, or refer to, funny {{IMG}} codes. I know I do, I’m using the Blog editor built into the Flock browser (see image) , it’s lovely and interfaces to WordPress. But WordPress has its own WYSIWYG editor too… as does Blogger… and despite them all working a little differently I tend to only use two or three buttons, bold, italic etc so the differences don’t matter.

Better tools help make better content. Because I have a nice editor, this article has a picture that helps explain what I’m talking about. If I had have been using a web form, if I’m honest, I wouldn’t have bothered. I added the the link above because it was quick and easy, if I’d have been using HTML you would have had to go and google for that yourself. Tools make us what we are, define the ways we think and communicate.

As part of the monkey code-a-thon we had to choose a CMS that had a certain list of features. The one we chose has a WYSIWYG editor, or at least, it looked like one. I discovered during its use that in fact it wasn’t one, it was a short-cut inserter for wiki-like syntax… ouch! Lesson learned… so, when looking at a CMS’s features you need to use the editor and ask of it these questions…

  • 1. Media. Can you add a picture to your content that you haven’t uploaded yet? In Use Case terms this is one of the most common need when you are creating content… you write some stuff and think, I need a picture here and then most CMSs let you down. You can’t add a picture you haven’t added yet… and worse you then have to save the thing you are working on (you are probably half way through) and go and upload your picture and then add it where you want it. If you haven’t lost the will to live or at least the thread by then, you are super-human anyway. Case in point… as I was writing this I did a quick screen grab, dragged the picture onto my Flickr topbar and then into my post…
  • 2. Media. Can you see the pictures you are working with?… a reference doesn’t cut it. If I was writing a CMS today I think I’d make sure it supported the Blogger XMLRPC API before I started making any content editing forms…. And I’d make sure I stored user-generated data in my own format so the html could always be parsed and verified…
  • 3. Creation going forward. Can you link to something that you haven’t made yet? Again… this feature is intrinsic to wikis and yet normally missing in CMS… because they start from the wrong assumption. Content. Most CMSs think of content as a thing, an enitity on its own rather than as a piece of a larger whole. It’s sort of a western way of thinking really as opposed to a more eastern mindset. Content is wrongly seen as a collection of individuals rather than a community of interdependent items.
  • 4.Context. Does the editor know anything? If you have created an article recently called “How to Train Your Duck”… then when adding a link are you reduced to knowing the URL or does the editor know what other content is in the system, what other content you are working on, what other content is nearby or relevent?
  • 5. Linking going backward. Are you creating a dynamic static site? I’m always amazed by sites that have articles that link to other articles. In time, newer articles get created on the same subject and the earlier articles know nothing about them. Why is that? I guess this one is more about the back-end than the editor itself, but there is an interesting overflow between authored links and discovered links that I won’t go into here.

You’d be surprised how many fail on the criteria above. So… remember, when you are looking for a really usable CMS and it has what looks like a WYSIWYG editor, don’t be fooled. A bold and italic button do not a usable tool make. Get in there and actually use it, put it through the 5 steps above and see how it really performs, because, when it comes to interfaces, nice buttons really don’t matter, what you see is not as important as what you can do with it.

Wikis vs The Usability of Online Document Editors

I have just had a quick play with site builder WetPaint, and made this… everythingability page. I was impressed with the tools but it really got me thinking about the future of wikis. Do wikis have a future at all given certain developments in online document editing? Factors such as…

  • Wiki syntax is meant to be simple but always ends up not so. Online WYSYIWYG Web2.0 tools are getting better/easier to use than any wiki syntax ever could be
  • People always need layout… eventually. Of course you can start an raw text but as soon as you have more than 20 pages you start to want to be able to navigate both your site and the length information contained.
  • Most wikis need moderation, the idea of “anyone can edit this page” doesn’t work in the real world… unless you are Wikipedia I guess… and even then….
  • Tools are starting to appear that take into account that fact that people want to create networks of information not pages. That’s traditionally where wikis have always been strongest (over online document editing tools) but they are now losing that ground.

As WYSIWYG editors are getting better and better, they are stealing wiki concepts along the way. If they steal enough what IS a wiki (versioning, collaboration etc.) then what IS an online editor/CMS and what IS a wiki will become difficult to call.

All online document editors, including Writely, FCKEditor, TinyMCE or WetPaint or any of the many others have failed to steal the wiki’s crown jewels, namely, the WikiWord.

The WikiWord is there to be stolen. It’s not big but it is clever… very clever indeed.

A WikiWord is a beautiful and magical thing that means you don’t need to copy URLs (as well as the link text) when creating links…this lets you link to things on-the-fly… quickly… and a lot of the time it is not the information that is most important, it’s the links between items that is important….

A WikiWord let’s you create-going-forward (rather than having to leave a page to create the page you want to link to then go back to the original page and create a link to the page that you just created).

A WikiWord lets you add links (or place-holders saying “we need to create this later”) in the text, not using a tool, you don’t have to change “mode” from keyboard to mouse… the place-holder factor needs playing-up, it is hugely important…
The first online editor to assimilate the WikiWord ( and therefore a network-information editor rather than a document-centric editor) will be hugely successful.  All the editor would need is…

  • a hook so that WikiWords can be recognised as you type (so the editor needs to know it’s own information context, in other words, no document is an island… )
  • a hook that handles what to do when clicked (create a new resource or go to the named resource)

… once you have that… this editor could be dropped into WordPress, Blogger or GMail or any custom CMS. It would change the way we blog, how we communicate or create online information. It would mean that more information was “better linked”


I recently asked a question on the Django list and discovered a flame war about Ajax toolkits with such gems as …

Frankly, you should just learn it because it will benefit you. It€™s not rocket science. That you refuse means you are just lazy or stupid.

Django has a great community (and to be fair this happened on someone’s blog) but it does surprise me that people talk to each other (about Ajax toolkits for god’s sake) like this…

Anyway… I found this interesting little tool… looks nice….

What is Tabblo? Your photos.
Your words. Put them together
with Tabblo and tell your story.



Another attempt at a temporally-ordered LifeStreams interface (I think) in Onlife. The last one I tried, called browseback (I think again) didn’t quite do it. The screenshot of this looks interesting.


For a day or so, I have used MicroWiki, but found that after 4 days nobody has replied to my support questions which for me are all show stoppers.

What I really liked about microwiki was how well it could integrate with WordPress… but every time I edit a page it extra-escapes the quote marks… hell even the microwiki pages has the same problem…. “Click the \\\”log in now\\\” l”


I’ve been using VoodooPad for day now and it’s bloody brilliant. I have managed to get an AppleScript and a Python plugin working that takes the content of a wiki and publishes it on Blogger which I think has lots of potential.

It needs some work… ahem.. for example, I am going to have to do some work making sure that when splatted to Blogger that the site still has relevant naviagtion, that the wiki isn’t blogged to death and presented linearly (if you get what I mean).

I may need to use WordPress instead of Blogger because the API is richer, but I like the idea of using Blogger as a data-storage… don’t ask…

I was so taken with this product, I bought a copy… and then started rummaging around on eBay for a graphics tablet. I want to doodle!

Wikis and the evolution and development of ideas

As I write, I realise the writing tool I am using is not what I should be writing in.

Most documents I write start with a Sticky and quickly migrate to BBEdit, which keeps up with the speed I sometimes type at. Often I use Mail, because I happen to be there which has an “as you go” spell-checker. I bought TextMate but it still seems a bit goofy somehow.

As a document gets longer and more complex I then have to switch to Word because it has Styles, although I can never quite control them properly, but mainly because it has a “Document Map”. If you’ve never tried using the Document Map and work on long documents with nested headers in, you should give it a try, it means you can jump between sections and is an invaluable feature to me.

Often, once Word’s formatting has driven me insane, I import the file into Apple’s Pages which has a much simpler interface but no Document Map. Pages can handle lots of images though whereas Word stumbles as soon as a few screenshots get added.

Many times, before I jump from text editing (with BBEdit or Mail) into DTP (with Word or Pages) I consider using a Wiki in some form. The reason for doing this is that my words and ideas don’t need formatting with fonts and sizes, they need organising. At this point the flow and structure of the document are still up for grabs and ideally I’d like to be able to write… quickly… and link relevant resources and then re-order certain chunks. Copying and Pasting in Word is not reorganising, it’s hacking the text.

At times, when in the WikiWhirl, I have tried PHPWiki and WikkaWiki and the MacOS X Desktop version of MoinMoin called MoinX. These are all OK and standard Wiki tools but at this stage of the game, I don’t want a browser based Wiki because they are too cumbersome, I need a desktop GUI-based Wiki, with spell-checking and the ability to keep up with the speed of thought.

On the desktop side of things I have tried, PersonalWiki. PersonalWiki was great except for a few bugs that lose the formatting (ouch!). The real promise of it was that can export to HTML. Although it says I can use my own templates it doesn’t tell me how. PersonalWiki was a great project that ran out of steam/money/time. Tantalisingly it also looked like it may be able to import/export from standard online wiki tools (such as MoinMoin) but the lack of documentation (and the difficulty installing MoinMoin on MacOS X) meant that I never got that “killer” feature running.

WikiNotes looks very promising, but exports very ugly old HTML. It would be better if it exported ugly old HTML but used DIV tags for a header, content, footer etc and left me to edit a CSS file to make it a little less ugly.

Yesterday I trially a number of PHP and python based wiki tools, desperate for one that would sing for me. None did. Java-based SnipSnap and Confluence look worth a look but they are either TomCat dependant (so won’t run on my host) or very expensive.

The best wikis I have seen so far are commercial services or privately owned, like SWIK, Peanut Butter, StikiPad and OpenText. From a usability and syntax point of view, there are no good open source wikis. Of course, if the content in an open source gets compelling enough then the quality of the tool becomes less important, people will struggle with form-based editing and geeky syntax because, well, it’s just the way it is.

All of this leads to a point of complete disbelief really. I can’t believe that I’m the only person who would kill for a GUI wiki tool that had an exit-route towards online tools. I can’t believe how there are no tools that support the creation of networks of information (hypertexts if you will). The tools of today still are biased towards editing text, not relating text. We are still in the dark ages. The web is all about networks, connections, clouds and clusters of information and yet we author using notepad, poor CMSs and document editors. It’s not about the document, it’s about the nodes IN the document, it’s about the connections between the nodes in the document. It’s a wiki.

As I write this I wonder if I have a disability that goes, whenever I do anything, I wonder if I could do it better or quicker or with more elegance so that I never actually finish what I started out to acheive. Right now, I should be writing, but I’m writing about the way I was writing and wondering if I could write better if I took a few days off to build a tool that helped me write the way I want to, one that started in text, added structure (but not formatting) and then allowed multimedia and layout, and finally was in a format that allowed online access, comments and collaboration.

Documents (or ideas) are not static things, not document types… their format should evolve over time as they get improved and shaped. They may start as quick notes and end as richly linked and organised tomes but the way in which you work with them should be appropriate to their needs, not the application or tool you are working with.