The quote he pulls is
The quote he pulls is
Of course it isn't Wednesday yet, but I'll be a day early.
One of the things I've been tracking over at Arborwiki with our analytics install is the fraction of pages that people hit that don't exist yet. These are marked on screen so that if you know what you are looking for you'll recognize it, but often people don't, so they click through and get a blank edit screen.
Every so often people do edit this page - but often they don't.
A reasonable goal is to try to minimize the number of times people get frustrated, so one way to track that is to look at the fraction of pages over time where people hit a blank page and try to minimize that. Looking at it over the last 3 months it appears that 3.2% of page views go to a page that doesn't exist yet - if you do a "Top Content" report, and then filter for the string "redlink", you'll get what you want.
One way to do continuous improvement, then, is to run a simple report for the pages on any given day, and look through them for ones where people clicked and didn't find anything. Go to those wanted pages and search until you can put in something at least minimal for them.
Today's crop of such pages includes the Ann Arbor Wine Club, Edward Burger, Michael R. Reid, Miles Street, Native Plant Nursery, and Oakland Cruisers. With any small amount of diligence you can whittle away at the edges and reduce the failure rate over time.
Every once in a while you find a smallish wiki that looks like it's healthy and has interesting material. These wikis are bigger than the single person brain-dump, and smaller than Wikipedia, and less abandoned than most temporary bouts of enthusiasm that bring people into wiki-land.
For Wiki Wednesday, I'm starting a new series where I pull a random (or at least semi-random) page from Arborwiki and look for ways to improve it.
The Ann Arbor group was started in 1914. It hosts two annual events, a Greens Market in December and a Garden Walk in June.
Some things that could be improved on this - and there's a long list - might be
Thanks to ebonhawke, the guild wars 2 wiki for this idea.
Part of a Wiki Wednesday series; this post is NOT FINISHED but I needed to post it anyway.
Using a wiki to help develop and edit text for your project is appealing because when it all works you can, when everything works right, get a lot more done with less document management overhead. However, there is a large group of professionals who regularly work with complex documents who are intimately familiar with Microsoft Word, are experts in understanding how it can be used to build complex and attractive deliverables, and for whom a wiki environment is novel - not just because the mechanics of editing, change tracking, and formatting for presentation are different, but because the model for how people work together in this world is not the same.
Here is an outline of how to explain wiki to Word users. It is broken into three parts: the mechanics of moving documents from Word into wiki, the process of working together on a document, and formatting the resulting work for delivery to a client. The first part, document import, is going to vary depending on which wiki platform you are using; I'll illustrate here with Socialtext, which does this task in response to very specific demands from early customers. The second piece on collaboration within wiki is fundamental to the change that people will need to internalize on how work gets done inside a wiki, and it's the hardest to experience without going hands on. Finally, the process of moving completed works from wiki to some other presentation format is worth going through, and again the devil is in the details.
What is a wiki page, and how does it differ from a Word document?
A wiki page can be thought of as a single document inside a collection of related documents. It is typically designed to have multiple authors, and it may or may not have a final published version that is delivered on paper or other static form. In most cases, people editing the wiki page will be online while they are doing it, and their changes will be instantly reflected in the page text.
In contrast, a Word document can be thought of as a single document unconnected to any related documents. At any time it has a single author, and there is very typically a final published version which is designed and formatted for distirbution. In most cases, people editing a Word document will do it independent of Internet access. Changes from multiple people are typically done sequentially, with subsequent authors able to accept or reject annotated changes in Track Changes.
Word is overwhelmingly presentation focused, and generally provides tools for people to build documents that look great. Most wikis have much more limited user control over the aesthetics of the page, and are often designed around collaboration first and only secondarily on presentation for print.
I have an existing draft of a document that I want to upload to a wiki to edit. How do I do that?
In most cases, you can cut and paste from any document on the Internet or any Word document directly into a wiki page. Some formatting will be lost, and some features of the original source document (footnotes, side bars, page layout, and more) will not be preserved.
Sociatext ... document import ... ???
How do I track the changes in a way that I'm used to within a wiki?
Edit ... change ... reconcile versions. Parallel development, merge.
Edit, edit, comment on versions. Serial development, no merge.
Change log, history, who edited which when, what were the differences. Diff based, not red line.
Who gets to edit this document, and how do I know that we're done?
Wiki permissions, edit vs view. Social control, expectations, soft security within an enterprise.
The three people I'm cooperating with have differences of opinion. How do we reconcile these differences within a wiki?
Three way document review inside Word is a huge pain to make sure you get all of the changes merged in in parallel. You can serialize the process by having the document go round-robin but sometimes that introduces unacceptable delays.
I need to take this document that we have made and make it beautiful for print (or PDF) and make it final so that the client can't make changes. How do I do that?
... is just a start; we haven't even hit footnotes, tables, immutable boilerplate, annotations in the change log, accept or reject changes, and ... The ... is ..., and ...
I wonder sometimes which portion of the population has the wiki circuitry in their brains that allow them to light it up and make sense of that environment, and which part does not and will never "get it".
PALO ALTO, CA - November 5, 2008 - Socialtext, the Enterprise Social Software leader, today announced it will host Widget Wednesday on November 12, a distributed hackathon for widgets and mashups. Socialtext partners Box.net, Denodo, Newsgator, Meebo, Six Apart, Slideshare and others will participate in the hackathon to develop OpenSocial standard-based widgets and mashups on the Socialtext platform. Socialtext also announced that it will release all of the widgets it develops under an Open Source license -- to help partners, customers and developer community members create mashups leveraging Socialtext's best-in-class REST API.
OpenSocial is the standard propogated by Google for creating widgets: There is an OpenSocial Foundation, and they are celebrating a 1st anniversary in (where else) San Francisco on November 13. A highlight of the event is the Global Container Crawl where you test your install on as many systems as you can do in one afternoon.
There are hundreds of millions of people using social networking sites that support OpenSocial apps. To take advantage of the distribution that OpenSocial provides, you'll want your app to run on more than just one site. There are a few things to consider when writing or maintaining an app that works across containers. This page will give you an overview of these issues, and you can find tips for reaching users on specific containers by following the links in the Containers section.
The OpenSocial community wiki has way more details.
Stewart Mader and I had a good conversation, and from it came references to these posts; I'm noting them now here so that I can find them again (!) and so that I can remember the context of the conversation.
Five effective wiki uses - a piece in Website Magazine. In short: project management, customer/client collaboration, documentation, online community, FAQs and policies.
Onboarding: getting your new employees cleared for takeoff - some wiki patterns associated with using wiki to answer new hire questions and otherwise get new people to be part of an organization
When to wiki and when not to - wiki as complementary, not replacement technology; wiki to do work in progress, but PDF for final publications; using a public wiki next to a traditional static published site; and using wiki as a content management system.
Does your organization have these boundaries to communication? On using enterprise wide wiki systems to let people from different parts of the organization discover each other so that they can collaborate.
Thanks to Sunir for the connection! And, note to self, start with Skype next time instead of telephone.
Google's AdSense program is designed to provide relevant targeted advertising content to web pages. It works, sometimes intermittently, on weblogs - but there's often enough other non-relevant things on the design of those pages to work only indifferently. What you do find however is that the appropriately targeted wiki design - especially one where the subject matter expertise of a professional association is involved, and where the words in use a specific to a field of specialty - yields extremely targeted results.
Caution is worthwhile, however, because for every well-targeted advertising stripe you get the occasional horrible, unprofessional blunder. Some cases in point.
Quimica from the American Chemical Society is running this ad on page one, hosted on Wikispaces:
Now ask yourself, what is to blame here? There are three ways that you can fix a problem like this of having inappropriate advertising running in your wiki.
1. Don't run advertising at all. Host your wiki yourself, or host it somewhere with an option to turn off advertising. Remove the risk of the accidental inappropriate Adwords ad by not using Adwords as an ad network.
2. Sell advertising in-house as sponsorships, or run house ads in the stripe of the page normally designed for external advertising. This might very reasonably be ads for things like upcoming association events, membership benefits, or other details that look like advertising targeted straight at your members.
3. Use the Google AdSense ad quality as a measure of the relevance of the pages you have, and edit the wiki until the junk ads don't show up. Block advertisers that are inappropriate, remove page text that triggers inappropriate ads, and otherwise optimize for relevance, professionalism, and revenue. This works best when you are hosting a wiki on a platform and get the revenues for the advertising - some "free" wiki hosting really is paid for by click-throughs on ads that you are running, and if your association members are using Google Adwords to promote themselves they may well be running ads that would be very relevant on your site.
4. Use Google AdSense quality as a quality check on the professionalism of the AdWords advertising that your association members are running. From time to time, advertising copy writers at agencies will write ads that are completely inappropriate because of regulation or professional standards that they are blissfully unaware of, and by having a spot which attracts these ads you can build in feedback for professional ethics.
Last night was Wiki Wednesday in Ann Arbor. We met at Rendezvous on South U.
In attendance: @matth @homelessdave @edwardvielmetti griff
Regrets: @bkerr @vaguery @samrose @tedernst
The main topic was Arborwiki, it's continuing care and feeding.
I gave some results of initial local search log analysis from the new features in Google Analytics, as a way to systematically surface pages that people are looking for that aren't there or that need love.
We talked about ways to source more photos for Arborwiki, with a call to the local Flickr community. Many pages don't have pictures on them that could. The Ann Arbor District Library has an image archive, but copyrights are murky and thus most of the photos are unusable. Most Flickr people are happy to grant rights to their photos for Arborwiki use if asked.
Griff talked about ideas for putting together a local community newspaper out of Ann Arbor Alive. We worked through some of the mechanics and logistics of this including trying to figure out a hosting platform - consensus was that Arborwiki has some of the data, but that this might be an ideal student Drupal design project.
There was some brainstorming about bicycle-mounted, bicycle-powered low power FM. Dave has bike power and a trailer suitable for towing a mobile station. FCC regs (unclear on exactly which) allow some amount of low power broadcasts as long as they are non-interfering; with an Internet head-end and a network of neighborhood retransmitters you could reasonably build community radio on the cheap.
Dave suggested an area of focus around expanding the number of biographies on the site. It would be reasonable, for instance, to have a bio page for every elected official, for every person that a street was named after, and for other people with some notability or notoriety. Less clear was the relationship between people's "user" pages and people's "bio" pages for folks who are contributors.
Matt talked about maps and mapping and plugins that manage that, which appear to be evolving well. Some ideal future neogeowiki world has an infrastructure that generates KML as a byproduct of user behavior for mapping and search.
NEEDS LINKS - DO THAT NEXT - POST NOW
Marshall Poe is speaking in Ypsilanti tonight (oct 25 2007). Here's his interview in The Atlantic: Common Knowledge: Marshall Poe on the marvels and pitfalls of Wikipedia, the fastest-growing encyclopedia in human history.
EMU is hosting a year-long lecture series on "Wikipedia and Academia." The first lecture/discussion (by yours truly) will be tomorrow night (Thursday, October 25) at 7 pm, in 201 Pray-Harrold Hall on the EMU campus. The subject will be "Wikipedia: Academia's Friend or Foe?"
Next semester there will be three more lecture/discussions:
-Larry Sanger (co-founder of Wikipedia; founder of Citizendium), "Wikipedia, Citizendium and the Future of Online Collaboration"
Thursday, February 7, 7pm, EMU Student Center Auditorium
-Andrew Keen (author of Cult of the Amateur), "The Dangers of Wikipedia"
Thursday, March 6, 7pm, EMU Student Center Auditorium
-Katherine Walsh (member of the WikiMedia Foundation Board of Trustees)—Title TBA
Thursday, April 10 7pm, EMU Student Center Auditorium
If you have questions, please contact me.