A blog looking at business communication, knowledge management, scripting tools, OS technology news and other things of interest to mobile tech workers. As I find interesting news this will also contain pointers to thoughts related to configuration managment, change management and general software development.
This Post sparked some interesting comments about "problems" with the implementation of Wikis. Here is one I hear all the time:
The total lack of structure annoys me to no end. Maybe the people who build and evangelize wikis prefer that; they seem to find it a strength. I think they've just ended up building a tool that's great for people who think the way they do but not for others. I _want_ structure. Communicating and working out ideas is difficult enough that I have no use for a tool that simply flops everything down on the ground in a big tangle.
From my point of view, a well established wiki is not unstructured at all. Rather, the structure is community developed and owned. The point is not structure vs. no structure, but ownership. In a healthy wiki the structure emerges out of the culture of the wiki's community.
I understand that Kara Swisher has a great article at the WSJ ... is there a full text somewhere for those of us without a subscription?
Kara Swisher, in this morning's Wall Street Journal, writes about how 'Wiki' May Alter How Employees Work Together : Enter the wiki, which has aims to revive the idea of the "writable Web," which was how the medium itself was originally conceived by many of its earliest proponents. Using simple software, it allows anyone with Web access to post a page of information that is accessible to anyone else in the same group or organization. Others in the group can then...
UPDATE
Still haven't found the article on-line anwhere but here is a good review of the WSJ article.
The idea is to navigate by 'facets'. So in the first step users can select a facet out of the set of all facets. In the next step, the users can select another facet out of the remaining facets. Which facets users will see as available navigation choices is dependent on the path they take.
The Flamenco Project is a platform that supports this kinds of navigation.
I wonder if this is what Iwe are doing every day by using the More Like This features of Furl or the similar features of del.icio.us. The furl service generates a list of furled pages that are related via their various category classifications. I've developed a set of Furl bookmarklets that let me look at pages that furl users have categorized as similar to the page I am looking at. These bookmarklets then turn the whole web (at least the bits that are in furl anyway) into a facet navigable web. Furl seems then to be a way to capture facets dynamically by a large group of people rather than having to build them in intentionally as an author. It seems to be a better way to develop higher quality facets for content.
A quick follow up to my prior post. I have found it interesting that making a wiki offline seems to change how I use as well ... it feels less like interaction with the community for some reason. I think it is an important capability to have for frequent travellers who are off the net, but it will interesting to see if it changes the wiki usage pattern or community development.
Offline access to a wiki is something that I've wrestled quite a bit. Its the part of being a RoadWarrior that makes wiki use difficult. To solve it, I have made use of a mirror of the wiki (that basically creates a static copy of the wiki web) but then I don't get the opportunity to contribute to the wiki when I have the most free time. Like when I am on a plane or sitting in an airport without Wifi ...
Have you ever had the problem of "where do I put this?". At many places there are a few systems: Wiki: Attach a doc to the Wiki. It is great in that it can be linked to in a nice way, you can grab it from wherever you are etc... Company File Repository: You can put the doc in some remote file repository (folders on a shared samba system, etc). This is shared, but there is no revision control, and if you are offline you can't get to it Sync'd repository: (E.g. CVS/SVN bastardized to do this). This is nice in that your docs are local, and you can see what is updated etc etc... but folders aren't the best way to organize things, and there isn't much metadata I have tried other work arounds, like having a WikiAttachments directory where I keep everything so I have a local copy. But you don't know when someone has added things, and it is a pain to keep in sync. What is there was a way in which I could use cvs/SubVersion to talk to Confluence, and it would all me to sync up and have local copies. In fact, it would be cool to have a sync'd up copy of the entire Wiki so I could run it locally if I was offline! I guess with tech such as Near-Time Flow and BEA's vapourware Alchemy, we could get there too...
My second cut at solving this is to write an offline tool for TWiki that basically extends my Twiki External Editor tool with a publish and subscribe capability which allows you to sync topics locally. Theoretically, it should be able to handle attachments as well. Additionally, if you change a topic offline in parallel with online changes, you can merge more recent changes into your offline copy before you publish it back up to the wiki ... very cvs'ish or subversion'ish. It is still very rough but I am already finding it useful. Keep an eye on this space for announcements of its availability.
This is a a very powerful observation, namely, that organizations are structured to actively work against knowledge management and empowered peer interaction which is so critical to KM success.
Becoming a true knowledge management organization, in which information is shared seamlessly among employees and departments, has always been an acknowledged challenge. But when I read Jeff Nielsen's book The Myth of Leadership a few weeks ago, he convinced me just how much the deck is stacked against KM.
I am really into wiki. I have installed a wiki for our developers at work with great success. Nothing is easier and faster to propogate information and ideas.
The company I work for wants to start using a SharePoint site. It thinks that this will be the cure for information sharing. I am skeptical, but I don't have any experience with SharePoint so I don't really know. It looks like it has a ton of cool features, but how practical is it?
So, if you had to put SharePoint head to head with a good Wiki implementation, who would win?
My experience with Sharpoint is that it ends up being a fancy shared drive or file dumping ground with not nearly so much extra value as you would get on a Wiki. Most of the implementation I've seen end up having a nicely organized directory structure but are still only glorified file dumping grounds. If the wiki takes off, it turns into a more collaborative space or community white board and I have not seen that emerge on the SharePoint.
My preference would be for the wiki if you want to do more than just store files. I know that SharePoint can do a lot more ... that is just how I've seen it used most frequently. Just my two cents.
David Gelerntner, a computer scientist at Yale, perhaps put it best when he said, "Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity."
Peter Caputa is wondering about Furl or web archiving tools.
Del.icio.usrocks. It is my main bookmarking tool. Users can share their bookmarks publiclyon the web; use a javascript bookmarklet tool to bookmark a page in one click, categorize bookmarks under multiple categories and type their own short description for the bookmark. All these features make backfliplook like DOS.
Spurlvs Furl: Not sure what came first, but there are not a lot of differences between these two. There are some differences in implementation: Furl has a toolbar and spurl uses a browser button for MS IE users. After a quick trial, I would say furl gets a better rating on usability. But, I have talked with the founder of Spurl, and he is definitely on the right track. And both of these tools allow people to archive single pages of content. So, instead of just storing the link to it, you can store the page. Like I said, I don`t use these tools. Does anyone? For what purpose?
As an active furl user, I would say that furl functions as a Social Bookmarking++ service. I use it the same way as most people use Del.icio.us with the added advantage that pages I bookmark are also saved. That includes the ability to share entries out in a complete feed or by category. Very handy. Additionally, the page categorization allows furl to "recommend" pages to me with startling accurancy. As far as what you can do with furl, checkout my Furl Bookmarklets for ways to traverse all the furled pages you are interested in. Also checkout 10 Cool Things To Do With Furl.
I have found these two bookmarklets to be incredibly useful and offer them here without warranty ... I have tested these on IE and hopefully soon on Firefox.
The first one is FurlInfo. It looks up the current url in your browser and displays the number of times it has been furled, and a quick summary of similar items that were furled by the users that furled that page. Whew. Sorry about the long sentance.
The second one is similar. FurlMoreLikeThis displays the complete set of related furled documents based on the category of the furled page... provided it is furled. The underlying furl service appears to use the categories that group furled pages to search across related items. Its pretty neat because it usually means someone has actually put eyes on the document and made relevancy decisions. I have found this to be a higher quality way to search than using google's similar features.
To use them, simply drag and drop them into your bookmarks in either Mozilla/Firefox or IE. If you are interested in furl, you can sign up for it here. Use in good health and please email me at etaekema-at-earthlink-dot-net if you have trouble with them.
I'm still not entirely sold on PowerPoint the Good But here are some places to looking at to help make it better. This is probably the longest PowerPoint resource list I've seen. From Working Smart - My Favorite PowerPoint Resources:
Use it to update your customers with news of interest in your field ... spontaneous communication channels that self maintain.
Use it as a way to support group information sharing for people who don't run their own blogs...
Use it to decorate your website... as you bookmark they show up in the side bar of your website.
I agree that using furl for group work is something that is begging for more direct support in the furl toolset. What I've been doing to help this out is exploring ways of creating a group furl aggragate RSS feed ... and then we each select a category to share and the aggregated feed picks up that category. A little cumbersome, but it preserves individual entries from deletion by other group members.
Knowledge happens via connections & relationships, deep dialog and emergence, not via the collection, arrangement, organization of information objects or access to personal tools.
Knowledge flourishes in an ecology, needs diversity exchanges and creative abrasion to be articulated and verified.
Makes you wonder how you might capture knowledge ... That seems to be something I hear too frequently as the rationale for knowledge management, either personal or corporate. Knowledge occurs in the gaps between facts and artifacts ...
There is always a struggle with initial wiki use by corporations. This is particularly so in environments that are enamoured with taxonomies and categorization. It is so tempting to try to preconcieve how a wiki will be used and to force it to work a certain way ... and it turns out that this is precisely the approach that makes it less a wiki and more likely to fail. Frank Carver puts it well:
Trust me, if you want people to contribute on a Wiki, give them a real blank page and actively encourage posting by making it as simple, obvious and unambiguous as possible. Look at c2.com. Look at my demo installation of my own Wiki software. Wiki is about freedom and simplicity. With the the possible exception of the formatting markup, Wiki technology nestles in a "sweet spot" of approachability, usability and power. Move away from that sweet spot in any direction, however well-intentioned, and you begin to lose or dilute the things that make it work.
As you work to establish a wiki in your organization, you are more likely to succeed if you make adding / editing dead easy.
Ng Pheng Siong at render-blog muses about how external editors can be more seamlessly integrated into a Wiki browsing experience. His solution is to have the wiki server download the page as a separate mime type which gets passed off to a helper app that loads the editor after parsing the page.
I have been thinking about doing something similar for TWiki but am trying to find a way to do this without having to make any backend changes to the TWiki skins. If this is possible, it would have the benefit of allowing a wider range of users to edit TWiki this way.
One approach that I have played with would be to turn editTwiki or editMoin into a small webserver and then use a bookmarklet to redirect the current page's url to that local webserver, which would then launch the editor. Its more overhead, but would then work with a larger set of installed wikis.
I wonder if there is any mime magic that could be done from within the javascript in a bookmarklet to send the current page's url to a handler without the webserver being aware of it ... Sounds like a security hole if you could do it.
Edit This Page Bookmarklet is as close as I have found to accomplishing that and it still requires a cgi script somewhere ...
Syndication
Contact me
