Members: Join   Log In
Conv J Mike Munsil
Rank_participant
re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
Icon-thread a reply to The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
by J Mike Munsil on Jun 17, 2008 - 10:28 AM read 69 times
 

I don't agree that wiki markup language is a real barrier. I think that the discomfort with it is more of a symptom of a larger barrier, one that we all face from time to time; encountering the unknown.

How does it make sense to evangelize wiki use if at the first sign of resistance you  respond by providing work-arounds to get people back into their comfort zones  ?

That's advertising, not evangelizing.


IndustryHome_xsm
  • Conv Brittain
    Rank_docent
    re: re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
    Icon-thread a reply to re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
     Icon-thread in a conversation thread started here

    by Brittain on Jun 17, 2008 - 12:15 PM read 60 times
     

    Mike, in many cases I'd agree with you; however, with respect to wiki markup I'll differ.  Unlike some features where evangelizing is appropriate, I don't find it appropriate for wiki markup because:

    • There's a better alternative (for most users) ... the wysiwig editor, and
    • It's not a fundamental wiki function.  In other words, if you eliminated wiki markup you'd still have a recognizable wiki.  Contrast this with multi-user concurrent editing or page versioning, without which a wiki transforms into something else.

    I'd suggest saving the evangelism for the fundamental wiki functions.


    No current tags

  • Conv Steve Elmore - Demoing Twitter
    Rank_mentor
    re: re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
    Icon-thread a reply to re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
     Icon-thread in a conversation thread started here

    by Steve Elmore on Jun 17, 2008 - 01:32 PM read 63 times
     

    I think it is important to recognize our audience and that user adoption runs the full spectrum: early adopters to those who have to be dragged kicking and screaming. Wiki mark-up is not consistent across platforms, and this can create a level of user frustration that occurs when the final product does not look the way the user intended. Let's keep in mind that most people still can't tell you what a wiki is, and of those who can only 1% are willing to contribute.

    Developing Cisco Support Wiki, my position was closer to yours (especially since MediaWiki doesn't have a functional WYSIWYG editor). I felt that if someone with a computer science degree working for the world's leading network development company could not figure out wiki mark-up, then they should be stripped of their diploma and sent to work driving a delivery truck for Sysco. However, enterprise software has a different common denominator and most non-technical users do not want to take the time to learn something new, they just want a tool that makes their job easier and with less overall effort.

    Evangelizing wiki use should center on improving work flows and creating collaborative behaviors. Consequently, we have to overcome any technological barriers that get in the way of that. We are asking people to change their behaviors, so let's enable them through a better user interface and user experience.

    • Conv J Mike Munsil
      Rank_participant
      re: re: re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
      Icon-thread a reply to re: re: The Many Uses of Enterprise Wikis - CIO.com - Business Technology Leadership
       Icon-thread in a conversation thread started here

      by J Mike Munsil on Jun 17, 2008 - 02:43 PM read 76 times
       

      Thanks, guys, for the replies; good info.

      I guess my real point, poorly expressed above, is that you cannot get real change in an organization if you implement change that reinforces current poor practice. 

      Let's take the simple example of taking a group of MS Word users and trying to get them to work collaboratively in a wiki to create a document (this is exactly what I am doing now). I could have implemented a wiki that was totally WYSIWYG and menu based. I did not.  Why? Because I am looking past this project towards the next one with the same group. By the time we work on the next task I want to be comfortable that those who cannot learn (that is, who refuse to use the wiki) are weeded out and that those who can learn have identified themselves by trying to use the wiki.

      Current (and poor) practice for a group is to independently create sections of a document as separate Word documents and exchange them via email.  You all know what kind of a nightmare and waste of time and money that results.  Even worse is that the users are also wasting time formatting (often incorrectly) the documents.  

      Replacing the cherished poor-quality word processing interface with a limited but similar interface is sending the wrong message to the users. We are, in effect, saying "This it not really something different, it's just kinda different." The message we are sending is that the users they do not have to take  the change seriously; they do not have to apply themselves and learn.

      "However, enterprise software has a different common denominator and most non-technical users do not want to take the time to learn something new, they just want a tool that makes their job easier and with less overall effort."

      If we cater to the perception that the users cannot learn, they never will. that's human nature.  If, instead, we promote learning by booting the users out of their comfort zones early on, then we can gain tremendous long-term advantage at the expense of short-term peace of mind.

      It is for these reasons that I am averse to making things easy up front.

      Perhaps to a large extent, my point of view is based on my focus on small organizations and small groups. This I know, and I understand that change in large organizations is a different animal. However, large organizations are composed of smaller ones, official or not. Change the small and you can change the large.

       

      In any case, thanks for the article and for making me think. I appreciate having access to this area and to you folks.

       


      IndustryHome_xsm

Featured

Project ITR
Project CBS
Project LIM
Wiki Archive
Concours Archive

Author Profile

J Mike Munsil

Participant Rank_participant

Subscribe

Feed for nGenera Community:
Feed_small Public Secure_feed_16 Secure

Why subscribe? What is RSS?