Some recent enterprise social software notes …

Thomas Van der Wal ponders the uses of social software in mergers and acquisitions, referring a recent post by Stewart Mader on the opportunities of getting new employees up to “working speed” quickly (“Onboarding: getting your new employees cleared for takeoff“).

Ken Thompson on the relation between collaboration, teams and business process management:

It’s the human-to-human interactions of teams that count when it comes to innovation and agility. … you and everyone you work with must be able to function in and through internal and multi-company teams, and must also grasp what the latest concept of “team” really means

Matt Moore interviewed James Dellow about the Enterprise RSS Day of Action, here’s the mp3

Armin Karge tells us the story (in german language) of a tangible method of change communication:

Das “Cockpit” muss vor allem zwei Anforderungen gerecht werden: Einerseits soll es Alarmanlage und Kontrollinstrument sein. Andererseits soll es durch Offenheit und Transparenz zu mehr Akzeptanz der Beteiligten führen. Im Idealfall sind die Mitarbeiter beteiligt und identifizieren sich.

Stewart Mader and the team from Atlassian are sharing insights on wiki functionality, use cases and adoption (and they are giving away free copies of Stewarts Wikipatterns book, my review is here) at the Web 2.0 Expo this week, see what’s on the slate and drop by if you’re in San Francisco.

And finally Andrew McAfee reminds us of the importance of all this:

Enterprise 2.0 is not a hype, but it is also not easy, and it will serve to separate the winners from the losers

Andrew will keynote Heliview on May 7th, looks promising, I am thinking of going too – want to meet up?

Upcoming: Barcamp Stuttgart 27./28.09.2008

The date for first ever BarCamp Stuttgart is fixed: Markup the weekend of 27./28. September – as always best experienced in combination with the pre-BarCamp party on the evening of the 26th …

We’ll be at the Literaturhaus Stuttgart in Stuttgart city, thanks to the MFG Innovation Agency for Baden-Württemberg, which is our main sponsor.

German writeup of the second planning meeting here at Carsten Ulbrichts blog, enter yourself into the list of “interested to come” at the wiki (the actual sign-up will follow soon, stand by) and watch out for the cool logo that we’re going to have thanks to Kai.

Enterprise RSS Day of Action

James Dellow prepared a short slide deck for the upcoming Enterprise RSS Day of Action:

James also put up a presentation with a “wish list” for enterprise RSS:

These 10 things are inspired by the RSS services and functionality I’ve seen or experienced on the “consumer Web” that I want to have available inside the firewall too. Hopefully it also goes someway to explaining why Enterprise RSS is a different proposition from simply installing an RSS Reader on your work PC and RSS-ifying your intranet.

Yes, these are traits that are overlooked sometimes. Small wonder too – as enterprise RSS is only beginning to take up, some of these points are just emerging (like mobile access) or are seen primarily as job of the IT department (like security).

Simplicity, adoption and WYSIWYG editors

I was having several conversations at re:publica on wiki adoption (and consulting) topics. Over time, we (that is Andreas Gohr, Christian Kreutz, Tim Bartel, me and sometimes innocent bystanders and fellow twitterati) covered wiki technology, design and a wide array of social software adoption issues. One of the central topics was the question of WYSIWYG editors and their relevance for wiki adoption.

This was triggered by this blog post of Tim Wang (which I found via Tim Schlotfeld), that referred to a short wiki comparison, culminating in this:

Regardless, lack of a WYSIWYG editor continues to scare off most users and therefore wikis lacking one should be eliminated from contention.

This unsettled me, and while I am hearing this argument again and again, I think that this line of reasoning misses some important points. It’s not only about leaving out many able and well-kept wiki engines by restricting evaluation to those with a WYSIWYG editor, and it’s not only about an obvious lack of real research with real users (sure, wiki syntax scares off people and Wikipedia is a miserable failure) – it’s about a fundamental misunderstanding of both efficient knowledge work and user interfaces. While WYSIWYG is supposed to offer clarity, simplicity and easy adoption I hold that this is exactly what wiki markup is good for.

– Wiki markup editing and its restricted user interface makes it easier to focus on content, much like the “dark mode” some people choose for real editing – basically because WYSIWYG editors distract attention.

– We want employees to focus on content, edit it quickly and use the wiki (and the intranet) in an efficient way – we don’t want our employees to fiddle with nice looking but irrelevant eye candy or with overblown full-featured editors like this:

– Antoine de Saint-Exupery, author of The Little Prince, once said, “Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away.” Simplicity doesn’t equal low functionality, and is more important than comprehensiveness (and complexity). Smart web applications need to employ intuitive ways of interaction. Just look at these different user interfaces (by Eric Burke), showcasing common but different approaches to user interface design:

– People with relevant knowledge in the organization (yes, we’re talking about the “empty quarter“, often these are people close to retiring) need simple and clean user interfaces. User interface design ideas like usability, simplicity and clarity suit these people.

– WYSIWYG editors aren’t perfect yet – if  you’re just trying to format text you’ll be OK, but for more advanced stuff like tables etc. you need wiki markup editing anyway. Going the WYSIWYG way is risky too – think of initial user acceptance, that will  suffer when people get disappointed by their efforts at wiki editing. Yes, even when it looks like MS Word it ain’t the same, and becoming frustrated because the wiki obviously scrambles the nice looking word document you just copy-pasted makes for a really bad start. Granted, you can coach and explain this to your users, but then – why not teach them simple markup rules in the first place. Combine this with an explanation why dragging a picture into Word works but won’t (for now) work with a web-based application.

– Advanced users are going to use wiki markup language anyway, beginning wiki users may start with WYSIWYG but will learn soon that the other way is more efficient. When they have grasped a few simple techniques, such as putting ** around a text to make it bold or putting [[ ]] around text to create links, they can create great looking content with minimal fuss, and the look and feel of the wiki pages is consistent throughout the wiki. Providing the choice between both ways, allowing for quick changes between both modes of editing, is one solution. And yes, it’s no big wonder that both Confluence and Socialtext are offering both alternatives in parallel, simple and advanced (yes, that one’s wiki markup mode). Try both modes at the Socialtext WikiWednesdayStuttgart page. So the argument that adoption hinges on the existence of a WYSIWYG editor is flawed – wiki markup can be easily explained and adding some coaching efforts to an implementation project doesn’t hurt, explaining the rationale behind wiki usage etc. I have had decent successes with 15 minute short introductions, followed by “train the (peer) trainer” coachings, after all editing wiki markup editing is neither programming nor rocket science.

– What wiki users really need are standardized wiki markups (like wikicreole). This would make it both easier to export/import content between different wiki engines (and document processors like Word), and to write powerful and easy-to-use WYSIWYG editors. Until then we need to rethink some of our assumptions – especially about what end-users want and need. I see that people want to do their job easily and efficiently and that user interface information overload is a problem. So wiki markup is a solution, not a problem.

If the news is that important, it will find me

Bertrand Duperrin has an interesting post on informational competence, a key competence of knowledge workers. Reminded me of an article in the NYT I found via Marcel Weiß (btw, that’s the mechanism at work) holding that the “If the news is that important, it will find me”-attitude is gaining momentum:

[…] younger [people] tend to be not just consumers of news and current events but conduits as well — sending out e-mailed links and videos to friends and their social networks. And in turn, they rely on friends and online connections for news to come to them. In essence, they are replacing the professional filter — reading The Washington Post, clicking on — with a social one.

Bertrands point of view adds to this a twist on intraorganizational provision of information, the you know “what’s needed, at the right point in time to the right people and so on”, arguing both that finding, extracting, evaluating, and making efficient use of information demands new competencies and that

[…] The problem is not the mass of infomation, it’s the amount of relevant information (what I need to know to do my job now) in relation to the global quantity.

[while] the information I receive through RSS feeds because I wanted to follow it, because it comes from well-targeted search agents, because it’s filtered by my network, is enormous in quantity but provides me with real benefits. It takes time for me to manage it ? It saves many people’s time in my company when I publish things and bookmarks on our intranet, or on the internet when I publish my bookmarks.

re:publica 08 – people make the difference

re:publica ist zumindest für mich (fast) vorbei – viele Vorträge und Workshops (die ich zum Teil ausfallen lassen musste) und Gespräche von wenigen Worten bis zu mehreren Stunden (sic!). Danke an Alex, Alexa, Andi, Andrea, Andreas, Anton, Basti, @Bosch, Christoph, Christian, Connie, Cven, Eric, Frank, Frank, Frederic, Henning, Holm, Jaqueline, Jan, Joe, Jörn, Kosmar, Matias, Mike, Norbert, Nicole, Oliver, Patrick, Peter, Peter, Sascha, Sebastian, Silke, Stefan, Stefan, Stefan, Tea, Tim, Tim, Tino, Tobias, viele viele andere und natürlich Markus und Johnnie fürs Organisieren.

Enterprise 2.0 Keynote @ re:publica

Peter Schütt von IBM gibt nun einen Überblick über Motivationen und Herausforderungen die sich im Kontext von Web 2.0 im Unternehmen ergeben. Schön – das Thema ist offensichtlich auch für die anderen Besuchern der re:publica interessant – der große Saal ist fast so gut gefüllt wie bei der Blogger vs. Journalisten Debatte geradeeben. Im Anschluss wird es einen zweistündigen Workshop zur Vertiefung geben.

Weitere Themen:
– Erfahrungen der IBM mit der Transformation zum Unternehmen 2.0 (u.a. Lernschritte und Akzeptanz der Mitarbeiter)
– Unterschiede zwischen großen und kleinen Unternehmen bei der Herangehensweise an Web 2.0 (klar, sie betreten Neuland, die Frage ist welche Schrittfolge und -größe gewählt wird). Die Daten entstammen einer aktuellen Studie des IBM Institute of Business Value
– Web 2.0 allgemein (Long Tail, …) und die Auswirkungen auf die Produktivität und Motivation von Wissensarbeitern
– Schnelligkeit von digitalem Content (durch Schütt mehr auf die Geschäftsmodelle gemünzt, kann aber auch intern interpretiert werden). Schütt leitet denn auch hin zu “digitaler Reputation” & “social sharing”, das interne Teilen und Arbeiten von Content
– Social Networks im Unternehmen als Plattform für Wissensarbeiter und damit zusammenhängend:
– Crowdsourcing und das Nutzen von externen Ideen im Rahmen von Open Innovation, aber auch der persönlichen Netzwerke der Mitarbeiter (mit kleinen Anklängen an die Potenziale von Social Network Analysis im Unternehmen)
– Flexibilität von Geschäftsmodellen und Informationssystemen durch Enterprise 2.0 erhöhen (u.a. mit Nennung von Mashups, Widgets in personalisierbaren Portalen, …)
– Arenen für Social Software im Unternehmen – passt schon, die Idee “schnelle, kollaborative Innovation zu fördern” ist schon sinnvoll. Problematisch ist mehr, dass die IBM Studie hier offensichtlich massive Defizite bei KMU festgestellt hat.

Insgesamt viel “Richtiges und Wahres” im Vortrag, aber eben auch recht generell und damit leider “nicht viel neues bei IBM (und unter der Sonne)” für mich. Jetzt bin ich auf die Diskussionen im Workshop gespannt, die kleinere Runde ist da sicher vorteilhaft.