Tip:
Highlight text to annotate it
X
MALE SPEAKER: I'd like to introduce Suw Charman who's an
expert on social software and does lots of consulting with
large companies-- helping them implement it and bringing
blogs and wikis and the kind of tools that we take for
granted into ordinary companies.
She's going to tell us the problems that people have
there and lots of other interesting things, I'm sure.
SUW CHARMAN: Lovely, thank you.
I've been a social software consultant
for about three years.
I started off calling myself a blog consultant and when I
said that I was going to do this for a living, people kind
of laughed and went, No one really needs to
be told how to blog.
This isn't going to work.
But it turns out that it's a bit trickier than it seems
when you're using blogs in business.
So I'm going to talk primarily about using blogs internally--
because blogs and wikis internally.
I think the external stuff-- the marketing stuff's been
fairly well covered, but what I focus on is helping
companies understand how they can use blogs and wikis and
what happens--
what you can do when things go a bit wrong.
What I tend to find is that companies will install the
software because it's very easy to install.
A few people will start using it, but then they won't
actually be able to get the wider community, internally,
to use the software.
So much of what I'm saying is from experience of working
with clients and the problems that we've actually seen in
and the way that we've dealt with them.
Just out of curiosity, how many of you are using blogs
and wikis internally?
How many of you would if you thought they were any use?
Right.
I think the main difference between blogs and wikis and
the way that they're used internally rather than
externally, is, basically, wikis for collaboration, blogs
for publishing.
And it's fairly clear if you're into this whole high
tech stuff, how the technology works.
But it's not always clear why some people don't
adopt social software.
So even if you have people who understand wikis--
even if they're active on something like Wikipedia, they
didn't necessarily like using this software
internally for work.
And there's a whole number of reasons why this is that we've
come across.
Firstly, is this kind of slightly odd, very low level
fear of social humiliation.
That people get really quite concerned sometimes about how
they're going to come across to their peers and,
particularly, their bosses.
They're scared of saying the wrong saying, of making
mistakes, and looking like an idiot.
And quite often-- this is kind of a very low level fear that
they didn't even realize themselves.
They just feel kind of uncomfortable with the idea of
talking publicly to their colleagues.
People feel quite comfortable with email because email is
essentially a one-to-one communication, or
many-to-many, but it feels private.
So even though your emails are going to be stored on servers,
even that they can be forwarded and printed out and
all the rest of it, it feels like a present medium, like
you're not exposing yourself.
So people will send email.
They're happy to CC others in and BCC and all of this stuff.
But when you're actually giving people what it a very
demonstrably public place to work, then this kind of
shyness sets in.
There's also a lot of people who actually aren't very
comfortable with the idea of writing.
It seems slightly weird to say that in a highly literate
society, but people have different comfort levels with
the way they express themselves.
Some people are much better talking to others and actually
having conversations.
Other people feel very comfortable writing rather
than using the phone.
But there is always a subset of people who just feel
uncomfortable using the written word in what seems to
them like a semi-formal environment.
And again, you see, with email, you get a lot of very
informal writing.
So no one really minds if your spelling's rubbish, no one
really mind if your grammar is a bit off.
If you're writing very brief emails, very to-the-point
emails, that's kind of all acceptable
within the email culture.
But the perception of blogs and wikis is that it's much
more formal, that it requires a much higher level of skill
with writing.
Again, this is something that people will never admit.
They'll never come out and actually say, Oh I feel
uncomfortable writing in public.
But there's a lot of this that's kind of just bubbling
underneath the surface.
Other issues--
this varies from organization to organization.
If you have a very open organization where you can
kind of do whatever you like, then this
isn't so much an issue.
But within hierarchical organizations, unless
permission is explicitly given to use specific tools, that
can really get in the way.
People feel like, Well, maybe I'm not supposed to be doing
this, and if my boss sees, maybe this will be a problem
and I really don't want to have that confrontation.
So unless there's explicit permission
to use social tools--
because, I think, they have the word social in them and
blogs are seen very much as diaries and
they're kind of personal.
So there's a sort of psychological mismatch between
what people think the blogs and wikis should be used for,
and what they're actually used for in business.
There's also a level of trust within the tool.
Do you trust the tool to do what you want it to?
We see this particularly with wikis.
When I've been in organizations showing people
wikis for the first time--
and you go through that enlightenment process of, This
is a wiki, it's is a web page to everyone can edit.
And the first thing they say is, So you mean other people
can change my stuff?
Yes, other people can change your stuff.
Can I stop them?
And there's this sort of idea of not feeling quite
comfortable that they can trust the content that's put
on a wiki, or the contact that's on a blog and that they
don't necessarily trust the tools, either, because what if
it loses everything?
And I think--
this is something--
I doubt very much that you have that issue here because
of the culture that you have here, but I see it a lot in
other organizations.
And finally--
well, not finally-- trusting the tool to still be there in
a year or two years' time.
I mean, this has been a big issue--
I worked with one investment bank and they already had a
small wiki that was being used by IT, and they installed a
company-wide wiki.
And a lot of people were like, Well if we put all of our data
in this, is it still going to be here in a year's time?
Are there any guarantees from management that this is a
secure place for us to put stuff?
That it's not just going--
I'm going to wake up one day, get into work, and everything
that I've written is going to be gone?
The biggest barrier for many people is actually they just
don't see the point.
They look at that social software and they see as an
overhead, something they have to do in addition to all of
the work that they're already doing.
So they look at it-- it's a bit like knowledge management
software that was promoted as being a wonderful way to
gather your company's knowledge and manage it.
And no one ever figured out what the hell that meant.
How do you manage knowledge?
But what happened was, lots of companies spent lots of money
on these big, huge systems. And then said to their staff,
Right, we want you to put all of your documents in this.
And their staff just kind of went, Why?
They couldn't see any benefit to them.
There was a definite-- you could see the benefit to the
business if all the documents and everything's all in some
big work flow and categorized.
But the overhead for the individuals was
just way too high.
They didn't get any personal benefit out of this at all.
And the biggest challenge that I have when I'm explaining
this stuff such people is how it can help them and why it's
actually useful.
So let's say that you've got-- you decided that you can use,
say, a wiki for product documentation or product specs
or for logging constantly changing information.
Or you're going to use a blog to publish stuff that maybe
you've been sending out by email on a regular basis or to
communicate with your team or to keep your
own notes or whatever.
And you actually want to start getting other people involved
in what you're doing and using this
software at the same time.
There are two basic roots for doing this.
It's kind of like, top down and bottom up.
And the traditional way of getting people to use software
is to go, This is software, you will now use it.
This is sort of top down, command and control approach.
That kind of works all right-- firstly, if you have that kind
of hierarchical organization where you have managers who
have control over what you do.
And secondly it works if the managers persist in forever
saying, "You must do this, otherwise you're in trouble."
As soon as managers stop saying, "You must use this,
otherwise you're in trouble," people will just kind of
like-- if they're not convinced it's useful, they'll
just stop using it.
It's amazing how quickly people will abandon software
that they don't find useful.
The bottom up approach is kind of like your grassroots,
organic approach where people just start using stuff because
they think that it's interesting, it's useful, it
helps them.
I've seen a number of companies--
it's kind of like Trojan Mouse projects--
where somebody somewhere's got a little server that they can
just shove a blog on, shove a wiki on.
Never really tell IT, they just kind of get on with it,
and it kind of spreads through the organization.
And eventually someone goes, hang on a minute.
Didn't realize we had blogs, didn't realize we had a wiki.
Where did that come from?
And that kind of grassroots effect can be very powerful in
getting people to use this kind of software, because the
only people using it are people that
see that it's useful.
But it does risk--
firstly, having multiple centers, multiple
installations-- so maybe someone's using MediaWiki and
someone else is using TiddlyWiki or whatever.
And you end up with these silos where you've got one
group using one wiki and one group using another and they
really need to be talking to each other.
But they're stuck in different software.
The other issue with this is that, sometimes, when
management finds out that you've been quietly using a
wiki or a blog somewhere without telling them that they
come along and say, We're not having that,
we're shutting it down.
So ultimately, what you really need is kind of
like a middle way.
So you have the support from above that says, Yes, you can
use this, this is good software, we encourage you to
get involved in this.
But you also have buy in and support from below.
That the people who are actually using the software
find it useful and decide that this is something they will
help each other to use.
When you're looking at the bottom up way
of fostering adoption--
I wrote an adoption strategy a while back based on some of
the work I've been doing.
And I just kind of want to run through it, because if you're
in a situation where you want to use wikis and you have
colleagues who aren't really so sure about it, this is a
good set of steps to go through to get them involved
in what you're doing.
The first thing you need to do is figure out
who your users are.
It's very easy to think about users en masse and kind of
say, Well, they're people who are working on
such and such project.
But within that you have small, discreet user groups of
people who have shared needs and shared actions.
So this is all about what people are doing on a
day-to-day basis.
So if you have project manages that are kind of working on
different bits of the same project, or if you happen--
in a lot of organizations, actually, secretaries and PAs
are really good people to focus on.
Because they all do roughly the same thing in
roughly the same way.
And you can get them talking to each other, get them kind
of adopting the software and then they kind
of spread it out.
But you have to understand what they
actually do every day.
A good place to start with this is, look at how people
are using email.
Email is one of the most abused bits of software that
we have in business.
we suffer from occupational spam.
Stuff that you're CCed on that comes from
somebody in the business.
It's kind of official, but there's no real relevance to
your day to day action.
People just letting you know stuff, just CCing you because
they think you ought to know what's going on.
Stuff from departments that have accidentally sent it to
the wrong mailing list. We get huge amounts of email that we
kind of don't really need.
But we also use email very badly for things like
conversation.
So the CC list--
it's very easy for you to just get started on a conversation
with your colleagues.
Then someone gets missed off the CC list or someone just
replies to you and not to the whole group.
And the conversation starts to fragment
across different inboxes.
And you can't access other people's inboxes and just
start reading their mail.
So you don't necessarily-- you're not aware of all the
little sub-conversation that are happening once that
fragmentation's occurred.
The other thing is that people, particularly when
writing documents--
product specs, meeting agendas, this sort of thing.
They will send out attachments to half dozen people, get half
a dozen sets of responses back, and then you have to sit
and hand merge.
So these are kind of specific behaviors that you can look at
people using email for.
You can say, Actually, there are better places to do this,
there are better ways we can do this--
easier, less overhead, and much quicker.
So once you've kind of identified these groups,
identified what they do, identified who's influential
within your area.
Because we have the organization chart--
I don't even know.
Does Google have an org chart?
Probably somewhere.
But you always have an informal organization within
any business of the people who know each other, and the
people who-- maybe they're not even working together, but
they talk a lot, they exchange ideas.
So identifying people who are these little super nodes, who
kind of bridge different communities--
different parts of the company--
and who can actually help you to spread adoption of any
particular tool is quite important.
These are people that can really push a tool from being
something that's used locally to something that's used
business-wide.
And then think about what is it that you're
actually doing for them?
How is this going to make part of their lives easier?
I worked with an investment banking in London called
Dresdner Kleinwort Wasserstein.
And one of the things that we did was looked at how people
were using email--
what they were doing--
and then figured out how they could do it better on--
in this case, the wiki.
And some of the use cases were really, really
small, simple use cases.
It was nothing particularly impressive.
It was things like, doing presentations collaboratively.
So one of the managers needed to--
suddenly was told, You have give a presentation in four
hours on your project.
Had come up with his PowerPoint slides.
I mean--
I personally don't believe in PowerPoint, as you can tell.
But they basically had to come up with this whole
presentation, and they did it on the wiki.
They broke it down into sections.
They kind of brainstormed it on the wiki, and then, once
they had enough ideas, they kind of separated out-- gave
each person responsibility for a given chunk of the
presentation.
They worked on it to simultaneously, brought it
back together in the wiki, and then, final edit.
And at that point, it was put into PowerPoint for the
presentation.
Doing that by email just would never have worked, not in a
four-hour time period.
It just would have been really painful.
The other thing that was really, really--
caught on-- and again, it's incredibly mundane, some of
this stuff--
was meeting agendas and meeting notes.
So instead of sending an agenda out-- and people were
sending agendas around in PowerPoint,
in Excel, in Word--
all sorts of different ways.
And sending these multiple attachments out, getting
multiple ones in, then having to hand merge it all.
And then someone somewhere would have
their bit missed off.
It would be kind of like, Well, you know, my thing
wasn't on the agenda.
And then the meeting minutes, again, would be sent round in
a Word document or something.
Changes would be sent back individually.
And it's these kind of patterns--
it's sort of like, looking for where conversations and where
behaviors are fragmented, and then bringing them together in
something like a wiki.
With blogs, a lot of this stuff is kind of--
anybody that's publishing something on a regular basis--
newsletters once a week or whatever.
And that they were very small, tiny little use cases, but
when you sat down with people and said, This is how you can
change what you're doing now and make it easier, they would
then take that, get their heads around that, adopt it,
and then they start to generalize out to other areas
of their work.
One of the things that I learned was that people are
actually quite bad at generalizing from a very high
level view.
So when you say, Wikis are about collaboration, blogs are
about publishing, it's all about conversation, you can
work with your colleagues and discuss things--
they kind of go, well, why would I want to do that?
When you say you can take the pain out of doing meeting
minutes, they kind of go, OK, that makes more sense.
So it's being quite specific.
The other thing that we found was that you really don't need
to huge amounts of training or anything on these tools.
Most people pick them up real quickly.
It really is about giving them context and understanding
about how this helps them.
And we got a bit old school with some of that the stuff
that we did.
We obviously had pages on the wiki and that, saying, this is
how you use this tool.
But if they weren't comfortable with the wiki
anyway, it's kind of not the right place to put the
material to make them comfortable with the wiki.
So we just printed out sheets of paper-- little trifold
sheets that said, This is how you do it, this is how it
works, how you do bold, and all the rest of it.
And that was really effective.
Because it was something that was very easy for them-- they
didn't have to go and find the page.
Ironically, I think one of the big strengths of wikis is
they're a flat architecture.
They didn't have a hierarchy.
But again, people are so used to hierarchies within
websites, it's kind of like, ingrained in everyone now that
you start at the home page, then you click a link, and
then you see some more links and you click that one.
And we found, actually, people--
within the wiki-- instead of leaving it flat and using
search, they created their own hierarchies, regardless of
what you did.
So we had the front page, it had a list of, departments
within the departments it had a list of teams, within the
teams, a list of projects, within the
projects a list of pages.
And so you end up with this kind of five click hierarchy
of navigation that they've created because that's what
they feel comfortable with.
So again, it was kind of like, if this is a behavior that
they feel comfortable with, then we'll enable this.
And we came up with naming schemes for each page so that
people understood--
if you've got a half a dozen projects and they all want the
page "FAQ," then you can only have one page on a wiki that's
called "FAQ." So it was like, OK, we'll have the team name,
project name, page name in the title so that it
differentiates.
You could immediately see all of the pages--
how they were grouped together.
And it gave people the kind of structure that
they're used to.
It made them feel more comfortable with the tool.
The other thing that we did, as well, was actually be very
open to letting people use these tools how they want to.
So there's quite a lot of kind of social stuff that went on.
People would be introduced to the wiki or the blogs via,
say, the coffee [UNINTELLIGIBLE]
page, where it was like, who wants what coffee this morning
and whoever's turn it was to get and get the coffee.
Sports pages, this sort of thing-- so that people had a
fairly gentle route into using these tools.
And then what we also found was that, as we were
introducing this to more and more people and sitting down
with them and figuring out what they need and giving them
that kind of really personalized help, we started
to see a real drop off--
basically, support requests kind of went, rows and rows
and rows-- there's adoption rows-- and then just kind of
went, fuff and fell off a cliff.
And suddenly, literally, over a period of about two weeks,
no more for support requests at all.
And it was like, this is quite interesting.
What was happening was that, there were enough people
within the business who were using the tools and
understood, Well, this is useful for this, and this is
useful for that, and this is how you do all this stuff--
that they were actually acting as little localized trainers,
themselves.
So there was no need for them to actually ask us for help
because they were doing it within their own groups.
And at that point, we've reached critical mass and at
that point I basically got fired.
Job done, essentially.
In terms of top down stuff, I'm much more in favor of the
kind of bottom up approach, but sometimes you need to kind
of marry it with the top down stuff, as well.
The important thing was having managers that
accepted the tools.
And within a really big organization--
DRKW's 6,000 staff spread in half a dozen time zones--
and it was quite a hierarchical business.
And so if you had one middle manager that basically went,
No, I'm sorry.
This is a waste time.
None of my staff are using this.
It kind of blacked out a whole pyramid of the company.
And we did have this-- we did have people actually saying,
over my dead body is anyone in my team going to be caught
using wiki.
And this was a bit of a problem because they were all
these things political.
As a consultant, it's very difficult for me to actually
look at the politics of the company--
I can look at them and I can go, you're trouble, you going
to be really good, you're going to be a pain in the ***.
I can figure out from-- certainly it's kind of laid
bare if you're an external consultant.
Internally, of course, it's a different kind of fish.
You're so caught up in what's going on and who knows who and
who's difficult and who you've got to keep happy that these
people that can be blocks can really get in the way of one
of these sorts of projects.
The way I kind of deal with it was, wherever you can, just
re-ran them.
You can't convert everybody.
Some people are always going to turn around day and go,
Social software-- we don't have social in our business.
So when you do get the managers that have the
foresight to have that buy-in first and say, Yes, we'll
encourage all our teams to use this.
The ones that were most successful were the ones that
were very active.
So active, themselves, using the tools.
So they were blogging, they were using the wiki, leading
by example.
Actively encouraging their staff to user these tools.
There was one guy who, every time someone asked him a
question, replied with a one-liner that
just said, See this--
link to the wiki.
He refused to enter into any discussion other than on his
blog or on his wiki.
It was like he was stepping away from the emailing game--
just not interested.
And that had a massive, massive effect, because
suddenly, people who wanted information out of him--
whereas previously, he would have gone, OK, you want this
document, here it is, here's an attachment.
He put all of his documents up on the wiki, and it was like,
it's there.
You don't need to ask me for this anymore.
You can just go and download it.
So if you keep losing your documentation, then it's
always there for you.
I started blogging as a personal
blogger five years ago.
My blog is called Chocolate and ***, if anyone's
interested.
And the first sort of three or four months were really gappy.
So I would blog furiously for three or four weeks and then
kind of like--
busy.
And then nothing for a month.
And then I'd kind of go, I haven't gone
away, haven't died.
And I'd blog again and then there'd be another gap.
And exactly the same thing happens in business, that
people will start doing something and then they'll
give up for a bit, and then you can encourage them and
keep going.
It's this whole kind of like, never give up we restarting
doing what you're doing.
It's very difficult to change habits and it's very easy to
kind of slip back into the old way of doing stuff.
And that actually doesn't matter.
If that happens, fine.
Just keep encouraging people to keep going.
But at the end of the day, one of the most important things
to remember-- and this was something, again with the
management--
some people have difficulty understanding--
is that, adoption and usage is not the goal.
You can say, we've got X number of staff and 70%
percent of them are reading the wiki and 30% of them are
using it, and then that's nice.
But adoption isn't the goal.
Getting your job done is the goal.
Preferably, getting you job done easier and quicker and
less painfully.
So I think that's sort of an important one to remember
because when you get really focused on the wrong thing and
the wrong goal, then it kind of diverts you from what
you're actually trying to achieve.
Which is an easier life, as far as I'm concerned.
A job that you enjoy, and doing it as best as you can,
as efficiently as you can.
So that was basically what I wanted to talk about.
I hope some that was useful.
I'm quite happy to answer questions, if
anyone's got any.
Or, equally, if all of this is stuff you already know, I'd
like to know that, too.
I wrote this social software adoption strategy-- it's on my
blog and it basically outlines most of this stuff.
And I was at a conference last week and had several people
come up to me--
That post is fabulous!
We've been doing this in our business and now everyone's
using the wiki.
And I did think to myself, You know what?
I'm really doing myself out of a job here.
But there are just more companies
out there that will--
they will read this and go, It makes sense, but we really
don't know how to actually do it.
The way that I look at it is, I like to go in, help people,
leave, and let them sort themselves out.
I don't want to perpetuate the--
I hate the word consultant because it has all these
connotations of people who perpetrate their own
employment by creating problems, whereas I like to
shorten my employment by making people happy.
Just means I get to do more different things.
AUDIENCE: One thing I didn't really hear you talk about was
like, the broader social net of the whole world, versus
within the company-- a kind of firewall around the wiki.
So I would imagine in financial types of services,
you've got a lot of secrecy and a lot of stuff like that.
So they'll say, This is a wall and only people inside--
can companies-- or do you work for organizations that
actually find these kinds of tools useful for interacting
with partners, interacting with help, like and so on and
so forth as well?
SUW CHARMAN: So there's different models.
You have your internal, within the firewall social software.
And in the financial services, you have these Chinese rules,
these regulatory rules that say, These people cannot talk
to these people until this event horizon has passed, And
with wikis, it's actually quite easy to create little
walled gardens that only certain people have access to.
You can actually kind of seal things off.
You can also create areas that cross--
that bridge the firewall, so that you have access from your
people internally and access from your clients and you can
control who gets that access.
And one of the things I found quite interesting was that the
regulatory side of things--
the compliance offices-- love wikis in particular because
there's a pure edit history.
Every edit that's made is logged, and
who made it and when.
So they actually prefer wikis than something like email.
if you have to do compliance on some email conversation,
it's a nightmare.
Do it in a wiki?
It's pretty easy.
Blogs are kind of like, slightly halfway house because
you can go back and edit blog entries, but there's not
necessarily any record of that.
But blogs tends to be a lot more static, but once you've
published them, they kind of stay published.
But certainly, for compliance, they loved the wikis.
They thought it was great.
AUDIENCE: A bunch of users in an engineering organization
and without going into too much detail-- and maybe you
covered this-- they said that it was difficult to find
materials and some of that's because of a more collegial
and informal way of posting in the wiki and yet, there's a
need for a canonical reference, for particular
engineering [UNINTELLIGIBLE]
How do you deal with that kind of thing?
People saying, This is either out of date or it's
confusing-- or I'd have to actually email someone to ask
them where to find it.
SUW CHARMAN: So the organization of information
within the wiki is interesting.
I've seen a lot of people who actually
create their own hierarchy.
So they're faced with a flat space and they create a
hierarchy of links and traditional style navigation.
A lot of this is actually about how good the search
tools are within the wiki.
And some of that than others.
If you have really good wiki search, it makes it a lot
easier to find what you want.
AUDIENCE: But do you think that solves the problem of
repetition of information?
Because a particular long topic may have repetition from
other topics and you may get contradictions, especially in
engineering documents and sections.
SUW CHARMAN: This is about the culture and how well people
engage with the wiki.
So when people view a wiki as a publishing platform, they
slap up there up and they never look at it again, then
you get these issues around
duplication, out-of-date material.
And that's exactly the same as an intranet.
So you get these like, dead intranets that have been
around for years and no one's actually bothered to look at
the data and cull it.
And part of that is because just the overhead on actually
finding the page and going to whoever looks after the
intranet and saying, Can you change this?
And then by the time they've got round to changing it, what
you wanted to change it to has actually changed again.
With the wiki, yes, you can end up with dead pages, but is
far easier to go in and deprecate things and go, This
is out of date.
And one of the things that we did was take the idea from
Wikipedia of having stubs an notices.
So you could put a little stub page up and say, We need
information on this.
And that acts as a kind of prompt to the people who have
the information who, perhaps, previously didn't feel
confident enough to put that information up there because
maybe they didn't think it was that important.
But it gives them the kind of cultural impetus to do that.
In terms of the mythical wiki gardener--
this is the idea that some people publish stuff and some
people go around tidying up afterwards.
You know, go gardening.
We actually did have these people who were obsessive--
really obsessive-- about making sure that everything
was up to date.
And the ratio of people putting stuff up and people
being obsessive about it can be-- you don't need very many
gardeners to have a healthy wiki.
But it's encouraging people--
and again, one of the hurdles that we had was, people would
just kind of go, Oh, that's not my page, so
I can't edit it.
The whole point of the wiki is that you can edit any page.
It's collectively owned.
This isn't about you having responsibility for this
section but being unallowed to touch this FAQ section.
And that was a cultural issue.
And most of these things-- it's not really about the
technology, it's not about--
a WYSIWYG editor helps, massively.
But it's not really about that.
It's how people react to the environment and the comparison
between the social environment and the hierarchical
permission-based environment that people are used to.
AUDIENCE: [UNINTELLIGIBLE]
--maybe if you have tools, recommendations, as well as
wiki preferences, that's interesting, as well.
SUW CHARMAN: I think the wiki site's probably odd in a way,
when you compare wiki tools and blogging tools.
Blogging tools are generally much more well developed even
though they haven't been around as long.
Wiki's been around over 10 years it's only recently--
in the last two to three years that they've actually started
becoming appropriate for business use.
In terms of tool recommendations--
it very much depends on who's going to use it.
So things like media wikis are really nicely developed, safe
in source, really lovely.
You put that in front of a business user and they just
run screaming from the room.
Because it's like there's all this weird wiki markup stuff.
It's complicated.
It doesn't look like Word.
So then if you give them something
like Social Text or--
there's a new one called ThoughtFarmer which is like a
structured wiki.
And these are much, much, more familiar paradigms. It's very
much like WYSIWYG editor, I click on the bold
and it looks bold.
I don't have to deal with this whole, Is it an asterisk?
Or whether links are done with brackets--
of several brackets--
negotiating different types of wiki markup.
Because people have a comfort zone and that comfort zone is
generally MS Office.
And this what they know, this is the paradigm they're used
to, and the tools that replicate that most closely
are the ones they feel most comfortable it.
But when you're dealing with the techies--
the IT department--
they'll do whatever they like.
We have this big row about transclusion because we were
using Social Text in DRKW and there was a whole bunch of
people who wanted to use MediaWiki instead.
Social Text doesn't do transclusion.
I can't have this template thing here and then use it on
all these other pages.
And it was like, edge case--
majority of people probably not going to do that.
And within blogs, as well as like, different levels of--
it depends on how you want to run your blogs.
So I did a case study of a pharmaceutical company in
Europe who was using blogs for competitive intelligence.
And they had six blogs and they were all--
Chinese walls between all of them.
But certain people had multiple blog privileges.
So if they had one item, they would have to post it on
multiple blogs where it was relevant.
And they were using Traction TeamPage, which allowed them
to have, basically, a blog version of transclusion.
They had one entry and they labeled it with the different
blog names and it showed up in four different places.
Other people use WordPress because it's free and it's
quite nice.
It all very much depends on what level of
granularity do you need?
Do you need LDAP sign on?
What kind of integration do you need?
Can this actually just stand alone on its own little server
with your own little login?
Is it that important that you have integration?
Because a lot of the tools just don't play well with
enterprise level systems. So it's really about figuring--
from that point of view--
who are your users, what are they going to find comforting,
and how does this fit in with your IT
infrasctructure that exists?
And I've had one company point blank refuse to install a
Linux server because they did everything on .NET.
Like, Nope, this is it, we're not having Linux.
Over our dead bodies.
And it was like, OK, that narrows down your options, but
that's your decision.
So IT in that company were less than flexible.
But they made that decision, so--
they want everything to fit together and I
can understand that.
AUDIENCE: [UNINTELLIGIBLE]
organizations.
I've found that one thing that makes wikis successful is
whether people actually post on it and write something on
it and participate.
And to me it seems, often, to be a connection between how
the wiki looks, and how easy it is for
people to post to it.
And the uglier, the better, basically.
So the most successful wiki I've used even had like, there
was no it had a broken image on every page that we just
kept broken because every page looked like a draft.
So people would feel free to post to it, even though they
haven't quite finished their text.
They just dump it up because always, everything there
looked like a draft.
But it was a really useful wiki because that was the one
place that [UNINTELLIGIBLE]
information [UNINTELLIGIBLE].
SUW CHARMAN: It's about your constituency.
If people feel happy with a semi-broken, ugly wiki, then
give them what they're happy with.
I think that there is a--
there does seem to be a separation between the more
technically minded people, who are happy with that kind of a
scenario, and business-focused people, people who are
basically used to Word.
And they really like stuff to look kind of shiny.
So when you present to them a TiddlyWiki or something like,
and they're just like, ahhh and run away.
You present them something that looks a bit like the
corporate intranet--
the same branding and logos and stuff, then they
immediately just kind of--
you're lowering a calmative barrier for them.
You're kind of taking away something that makes it seem
other and making it seem same.
And they're comfortable with same.
So if you're in an environment where people are used to very
bare, ugly tools, and that, then that for them is same.
So, yeah, I think it entirely depends on who
you are dealing with.
AUDIENCE: in social software.
If you were speaking to an audience of a lot of bright
engineers who might be able to get together and fix things,
then what would be the main things you want?
SUW CHARMAN: With wikis, they need to deal
with contention better.
That's one of the biggest pains in the neck-- is when
you get a nice big edit and some other ***'s come along
and changed a full stop and you lose your edit.
Granularity, in terms of being able-- particularly in
enterprises is important--
being able to actually parsel off areas of wiki without
actually having to do multiple installations.
And stuff like Social Text does that fine, but a lot of
the wiki's don't.
One thing I would just love to see would be SubEthaEdit style
simultaneous editing.
So that you could actually see, in real time, the other
person typing.
SubEthaEdit is a tool that--
actually, Steph and I have used at conferences to take
conference notes.
And it's fabulous when you've got everyone on the same
network and you've got three or four people in SubEthaEdit
and we're all taking notes.
And someone's coming along behind and adding in URLs and
correcting typos.
And at the end of the talk, you've got this fabulous, near
perfect transcript of what was said with additional points
and URLs and the whole thing.
And when that works, it works fabulously.
One of the issues with wikis--
even the ones that show you when--
with Google Documents, you can kind of--
vaguely has this whole kind of-- when you hit refresh or
save it, it kind of shows you the other person's edits.
But you can't see what they're doing at the time that
they're doing it.
So if you are editing together, you still end up
with the same contention-like issues of, Well, I just
deleted this bit, and you just edited it, so I've just
deleted the thing that you edited, and blahhh.
Better versioning--
edit history's are too clunky.
If you have an edit history--
I want to be able to say, this whole user session of this
person making these edits--
and these are exactly the words that they
added and took out.
And a better display-- at the moment, a lot of it is just
kind of like, per paragraph.
This paragraph changed, but that doesn't help me skim
through the paragraph and see what was changed.
And multiple comparisons, so that I can say, I want version
12, version 24, and version 60 side by side--
and see, between all of them, which ones changed and who did
what, so you could actually tag the changes with the
person that changed them.
As well as have the version tagged with the person who
changed it.
You could actually look at multiple differences.
I think wikis need the most development.
Blogs-- when you look at stuff like WordPress, it's really
nicely thought through.
I'm looking forward to playing with--
I say look forward but I actually haven't yet-- it
sounds like they've addressed a lot of the issues.
But within the enterprise, again, granularity and
permission--
really, really important.
Being able to say, this group of people has access and this
group of people doesn't.
And I think, scalability is also huge.
Both wikis and blogs have issues with scaling.
Once a wiki gets past a certain size, it can start to
get incredibly hard to find stuff.
Wiki search, mainly sucks.
And wiki search from outside of the tool?
I don't even know if that actually even works.
At most, wikis that have searches, it's all internal.
So you're stuck with--
if that wiki sucks, it sucks.
Blog search varies from--
AUDIENCE: [UNINTELLIGIBLE] --about searching--
SUW CHARMAN: Oddly enough.
AUDIENCE: [UNINTELLIGIBLE]
SUW CHARMAN: Basically, with wikis, it's flat data.
It's just all big bot, all big mush.
And people automatically add in a hierarchy because that's
what they feel comfortable with, because the search
doesn't provide them with--
they don't think Google when they see wiki search.
So when people come to Google search and they know how it
all works and there's a paradigm they understand.
But they don't map that paradigm across to something
like a wiki or a blog.
It's not an instinctive thing.
So moving people from hierarchy to search is really,
really difficult because they just they
have this mental block.
Because I don't think they really--
I don't know.
Do people see Google search as search, or is it just
location, finding things?
It sounds slightly--
stupid thing to say.
When people want to find stuff in a wiki, they just click
through links.
Even if it's a half dozen links, they'll just kind of
go, click, click, click, click click, click because they
expect hierarchy.
So, better ways to move people from the hierarchy to search.
What else?
That's just off the top of my head.
I'm sure come a lot more if I thought about it harder.
AUDIENCE: [UNINTELLIGIBLE]
SUW CHARMAN: So one of the weird things about blogs is
that blogs suffer from the social
part of social software.
People firstly think that blogs are diaries.
And it's only recently in the British media that they have
stopped banging on about blogs as diaries.
Because as soon as you get into this personal expression
stuff, people in business immediately
go, Oh, this is scary.
I actually don't want to have a diary in my business and I
don't want other people doing it, either.
So the interesting news cases on blogs, some of them are
very mundane.
Disney used blogs for event logging in that broadcast
department.
And basically they took out custom built database apps
that really was a bit rubbish and they replaced it with
Movable Type.
And every time something happened, it was blogged.
And you had search, which they didn't have before, you had
archives, which they didn't have before, you ability to
comment, which they didn't have before.
So even though previous database was custom built, it
sounds like it was a bit rubbish.
The adoption issue for that was just nonexistent because
they basically went, Throw that away, bring this, this is
all part of your job, just get on with it.
Quite a few people I know have used blogs for personal
knowledge management, if you like.
So keeping track of calling vendors, talking to clients,
just general information that's important.
So they can find stuff more easily.
One guy I know, actually--
he was working on a project where he had to report every
month, that he didn't really have any colleagues.
So every month he would have to go through all of his email
and write this report for his boss and say, This is what
I've been doing.
When he started blogging, he just stopped doing that.
And if his boss said, How are you doing?
He just said, Read the blog.
Everything's on the blog.
The whole thing is catalogued.
That kind of became reporting tool for him-- a sort of
tracking and reporting tool.
On the competitive intelligence one, we see lots
of knowledge sharing around that area.
How's the market developing, what ideas have we got, what's
happening out there, what's happening in here.
And just random--
some companies actually do random social blogs where
people just go, Oh, this interesting.
And this might be something on YouTube or whatever.
And, interestingly, that seems really counterintuitive, to
let people blog about social things and non work-related
things internally.
But it turns out to be a very good way for people to get to
know each other.
And in very large organizations you end up with
lots of small communities based around your colleagues
and the four people that they know.
You might be working on something that someone else is
working on, but you may never actually find out about it.
And what blogs I've seen do is actually
bring people together.
People started going, Oh, I saw this article about such
and such and doing this-- and they'd start to talk and then
figure out they're working on similar sorts of things.
In one case, one guy in London, one guy in Tokyo--
they would never ever meet.
Turned out they were doing basically the same thing.
And then that opens a door to
collaboration and smarter working.
So there is actually value to having that
kind of social stuff.
One guy at DRKW didn't know his boss, had never met his
boss, for like six months after he started.
And they were talking on the wiki and on the blogs, and
when they did to meet, they just kind of
hit the ground running.
There was none of this awkward, Oh, I'm your boss.
They already knew each other and they already knew what was
happening and all the rest of it.
We underestimate the importance of social
relationships in business.
Businesses are made of people, people have social
relationships.
Without those, it's very
difficult to function properly.
So allowing small talk is beneficial, allowing these
social relationships to form and to be
strengthened is also important.
Anyone?
Anything else?
I think we're actually done, anyway.
It's 12:00.
Wow.
Thank you very much.