This sounds like a classical techies/non-techies problem. The techies are trying to implement something, in this case a wiki, that is an unknown concept to everyone else. And since the techies "get it" they expect everyone else to get it too. The thing is that to the rest of the organisation there are probably the following problems: - they don't know what a wiki is, and they don't much care. Even though they use wik…
I agree that you should force them into making the change. You won't make the most friends doing it, but it'll be less of a hassle. You need to take the 'facebook approach.' A lot of people HATED the new facebook design when it originally launched. I'm sure you remember, there were groups with millions of members saying "bring back the old facebook" and complaining about everything. Months later everything has calmed…
Ask HN: Why do non-techies simply not "get" the idea of a wiki?
31–40 of 57 posts
Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#32For example: well them they can't go on holiday unless they book their holiday days into the wiki.
Also, overtime. Do people at your work get paid overtime? If so, make the system so that they don't get paid it unless they put their overtime hours on the wiki.
Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#33Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#34Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#35Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#36This sounds like a classical techies/non-techies problem. The techies are trying to implement something, in this case a wiki, that is an unknown concept to everyone else. And since the techies "get it" they expect everyone else to get it too. The thing is that to the rest of the organisation there are probably the following problems: - they don't know what a wiki is, and they don't much care. Even though they use wik…
Where I work, I've noticed several trends: - Duplicate work; as long as the wiki doesn't replace existing processes, placing things there is simply additional work. Moreover, because it's additional, there's no guarantee that any desired piece of information will exist in the wiki. - People don't like not having an "owner" to a document, especially regarding private edits and such. - Wiki's make you search for a topi…
Wikis are for text that people want to read and change, regardless of its source. This makes them ideal for Wikipedia but inherently out of tune with the big-corporate environment, a large crowd in which people prioritize based on who is talking to them. A boilerplate memo from the generic HR-department address can be skimmed very quickly; an email from HR addressed solely to you might need to be read; an email from the HR rep who has been assigned to your team might need a more careful reading and perhaps an acknowledgement; even a boilerplate email from HR might need careful attention if the author is someone you befriended at the company Christmas party.
You don't want an automated alert every time your boss's assistant reorders the columns on the weekly report. Ideally, your boss will only call your attention to the report when it is important for you to read it. That's part of the boss's job -- to protect your attention so that you can spend your time being useful instead of rooting through irrelevant wiki documents! And how is the boss going to direct your attention? Email. And while she's sending email, what's wrong with just pasting the information itself right into the message and saving the recipient some additional clicking?
Put all that stuff on the wiki and file off the TOs and FROMs and datestamps and you might as well just label it BOILERPLATE, because nobody's going to have the time to sort through it all. Even a genius super-librarian can only help so much, because the social context of email (its timing; the number and identity of the CCs, the history embedded in all the quoted emails that extend far down the page, etc.) is hard for a librarian to capture, let alone convey in wiki form. And, no, the version history does not help much. (Deriving people's motivations by reading their diffs is a techie art, not a liberal art. And emails carry a semi-reliable record of who has read the message as well as who has helped to write it.)
(A minor note: You left out Powerpoint in your description of the "enterprise wiki". It's pretty important, and for more than just stupid effects-laden bullet points. I worked in an engineering firm. All of us were capable of understanding wikis. I never tried to set up a wiki, though, because people communicated in charts and graphs, and at the time I couldn't find a wiki whose chart-and-graph workflow was anything short of "excruciating". The state of the art was to mail out arguments that consisted of stacks of graphs with commentary, rendered as Powerpoint docs.)
Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#37Why on earth are you trying to use a Wiki as a calendaring app whn there are so many good calendaring apps out there. I'm fairly techie - but if someone told me to edit a Wiki to put my holidays in, I would not be amused. You'll be getting them to use vi to enter expenses claims next.
Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#38Period.
Re: Ask HN: Why do non-techies simply not "get" the idea of a wiki?
#39What information is the non-IT user really having to disseminate to others? What value is it truly providing? How have you made adding the information to a wiki not be additional work? Is it improving productivity or reducing it?
And finally, who has ownership of the project? If you do not have a non-IT owner it'll 'gather dust' if the value of the application is not easily perceived.