Ask HN: YC S10 startup wants your opinions about wikis
We're wondering if there's room for something light & inspiring, like github and posterous are for their respective tasks. We've found one key driver to a successful collaboration experience is how effectively it integrates into your workflow, which for us means email. Few tools seem to do this well without being heavyweight.
Most people we've talked to are passionate one way or another, and we've enjoyed the discussion. Some of the questions we've asked are:
1. What type of projects have you used wikis/shared documents for? How many readers and writers were involved?
2. Think of a specific project where a wiki or <insert your tool(s)> was invaluable. What made it work?
3. What didn't work? Was it an issue with the collaboration process, tool or ... ??
4. What was the typical workflow like for you? What were the pain points? How would you have done it differently?
5. What is the minimum set of features that would be required to be useful?
Tell us your thoughts. We would be happy to clean up & publish the results if it would be helpful for others (we'll do this if there are sufficient responses to warrant this, say, 50)
(1) Previous HN posts about wikis:
http://news.ycombinator.com/item?id=49440 http://news.ycombinator.com/item?id=1257106 http://apps.ycombinator.com/item?id=371133 http://news.ycombinator.com/item?id=569189
27 comments
[ 2.6 ms ] story [ 58.7 ms ] threadCurrently, we are using Dropbox as a replacement for our wiki
If I went to the trouble of inputting all this information, I would want to have the ability to script some of the data I input, kind of like a wiki page but with some structured tags etc. Things like Google maps, photo galleries, PDF previews would be icing on the cake.
Suppose I have an idea for a neat new feature for my product. What do I do? Write an email to the others, or put it on my todo list, or on a shared todo list, or create a feature request on the issue tracker, or write it in a wiki, or write it in google notebook, or just write it in todo.txt...?
In the end, I use email for most things and google notebook for personal notes. I also carry Moleskine for when I'm not in front of the computer.
Since you asked about collaboration, I think an ideal tool would somehow integrate with email (gmail), because clearly email is not going away for another x years.
Also, I think the quick descent of Wave into also-ran status shows that "fancy" collaboration sounds good, but even if the initial reactions are super-favorable (I used GW for weeks and even wrote a blog post about it), email prevails! Hence my suggestion to integrate with email.
Google integration hurt wave because it forced your friends also into that model. Etherpad had a much lower 'buy-in' that made it great for experimenting. The lack of folding messages hurt the returning-user experience - I've read the same msgs at the top of the wave since we started it. Outgoing email also seemed to really like to quote the first message on the wave, and never give anything more useful than 'the wave was updated', so I'd put the effort to login only to find the only activity was a non-committal 'uh huh'. Facebook at least tells me who messaged me.
I believe in Wave's innovation to realize I'll email out a rough draft of 'things to bring on the trip' and the other people on the thread can both respond as a new message (hey, whats the plan for food?), and also to add/remove/comment on my list of things to bring.
My feedback below derives from experience within medium-large Financial Services organizations AND a small Web-based startup.
We use shared documents and workflows on a daily basis. Currently we use SharePoint internally. But we also use Google Docs between smaller groups of people. We migrated our main Wiki to Sharepoint, and have also been developing on SharePoint to extend it a bit.
I think more than the mere charm of devising a cool collaboration tool, what really works with "document management" is it's centralized version-controlled nature. More than anything, people want quick & easy access to documents. They also want to compare or recover previous versions of a document.
Collaboration (as we geeks think of it) is different from collaboration in the real-world. Some may disagree, but in real-world businesses documents are rarely edited by more than one person at the same time. In medium-large organizations, collaboration and meetings are often synonymous. From what I've witnessed, document-based collaboration in most medium-large organizations means 5 people sitting in a room going through a document and taking notes. Having said that, it's also a fine opportunity to promote a change and make it truly collaborative in the 21st century sense.
SMB's (and startups) are more savvy, flexible and open to experimentation. I think the best way to look at online collaboration is, first and foremost, by taking collaboration out of email.
I've used plenty of them (and like them for tech centric documentation) but let's be honest; they never quite caught on in a business context.
This is most certainly not due to a shortage of implementations (wikimatrix lists 124, no less) nor due to a lack of user-friendlyness (markup-free WYSIWYG ui's are dime a dozen now, from pbwiki to google pages).
I would rather claim that there is simply a fundamental impedance mismatch between the wiki concept and the common workflow in most companies.
Like it or not (disclaimer: I certainly don't), most workflows are still dominated by Word and Excel documents. Those don't mix well with a wiki, in fact they don't mix at all.
Moreover once you enter this battle you'll find yourself not only competing with the friendly closet fileserver ("Just drop it on drive Z:, Sue") and E-Mail ("I'll mail you the new version in a minute") but also with the ilk of MS Sharepoint, Mindtouch and a truckload of other workflow solutions that more or less "work", but most importantly usually allow the users to stick with their beloved MS Office suite.
Anyways, to make a long story short; instead of beating a dead horse yet again, why not look at the ideas that have caught on in the meantime?
Those would be the whole 37signals stuff (basecamp), dropbox, and I guess you also have to count pivotal tracker into that bucket (as much as I despise it personally). What most of these seem to have in common is the "do only one thing and do it well" approach, as opposed to the old "one tool to rule them all" meme.
So, my humble opinion would be that there's still tons of low hanging fruit in the latter market. A wiki on the other hand... Well, perhaps impl #125 will finally part the users from their Excel. But tbh, I wouldn't bet on it. YMMV. ;-)
But there are lots of common patterns (i.e. email to discuss details with colleagues after a new updated document is published). Supporting each individually would never work but observing and supporting the most common workflows within a group or diverse groups is a great way to create a compelling product imho.
The shortlist (from top of head): text fields are way too small, I can't edit my own comments after posting, stuff jumps around randomly all the time (due to ajax and because stories move panes when changing status), the whole workflow abstraction is extremely leaky as story-interdependencies cannot be expressed, etc. etc.
For me PT is a toy at best ("Oh look, it updates in realtime when someone makes a change") but nowhere near a serious tool for keeping track of a project.
If you haven't yet then I can only suggest to take a close look at mantisbt. It's not flawless either, but it has 7+ years evolution under its belt and makes an awful lot of sense once you got over the arguably ugly (yet extremely efficient) UI.
IMO one of the great strengths of pivotal is that there is a single view of the project. While tools such as mantisbt allow you to track lots of information (such as severity and interdependency) I'm not actually interested in this information beyond using it to decide what order work should be done. Pivotal forces you to resolve these factors into an ordering and in doing so provides a much simpler/clearer view of a project.
You could argue that not having this extra information makes reprioritisation harder. In practice I've found that this extra information is often subjective or temporary e.g. how severe an issue is/we really need this feature! I've always found that tracking these opinions is pointless as they change with such frequency that the tool is out of date anyway (ever hear arguments starting with "but you said it was severe two weeks ago"). In the end my experience is that people always know what the important issues are when prioritising, they don't need to keep them in a tool. They also appreciate a simple view of a project which I think pivotal does very well.
Take for example this mantis ticket, esp. the "Relationships": http://www.mantisbt.org/bugs/view.php?id=11330
At a glance I can see what state this Goal is in, what the progress is, what it depends on, what it is blocked on (if anything) and who is involved.
With a few plugins mantis will also add fancy progressbars and time estimates. I think there's even a plugin to compute a velocity similar to pivotal, even though I've found that feature amazingly useless in pivotal so far. Perhaps it works better when your tasks are very uniform and your teammates are robots instead of humans. ;-)
As for the higher level ordering (enforcing an ordering on Goals), for that Mantis uses the Roadmap, which can ofcourse also be modified at any time as needed; http://www.mantisbt.org/bugs/roadmap_page.php
Note also that all those extra-fields that are enabled in that mantis installation (Platform, OS etc.) are optional and customizable. In my setups there's usually only one or two, which reduces the UI clutter.
Note also the concise "Issue history" at the bottom which I much prefer over the cumbersome, ajaxified, collapsing/jumping mess in pivotal.
Anyways, to each their own. Different people, different priorities ;-)
Wikipedia is an awesome resource because hundreds if not thousands of people every day actually collaborate on it. There are a few big public wikis that are like this, too, but Wikipedia's the main one. Of course, Wikipedia has a toxic and idiotic culture, but they wrote a not-bad encyclopedia. That's fine.
Wikis, on the other hand, are usually just a repository for single-author documents which are, at best, sparsely updated by that single author when he is bored. They don't spin up to full collaborative potential if they're just a documentation repository for a group that has real work to do. They're just another bin of poorly updated documentation.
I would recommend a shared blog so each person can share current notes/ideas/links- for ideas and brainstorming. This is the place for peer comments and discussions. I can edit a blog post easier than a sent email.
A wiki would be great for separating known and unknown answers to the questions that arise during the project. This is the place to show what has been done and what needs to be done. Discuss these topics on the blog, not on the wiki 'discussion' page; post the _results_ on the wiki.
org-mode or something that simulated it would be great for prioritizing tasks. For those that are not familiar, it is an emacs mode that, among other things, allows you to create and move nested lists ( lists of lists ). This is the place to micro-manage the order of steps so that they are done most efficiently and keep people on track.
I've had the chance to work at a large scale website based completely around a wiki, and the successes and failures therein became quite evident. There is definitely room to innovate, especially on the editing side of the experience. I have some interesting friends in the wiki community, so feel free to ping me if you want to chat about it some more and I can probably put you in touch with them.
I would like to see a tool that would, first, allow real-time editing of structured documents. Think Etherpad meets Wufoo.
Take the example of a team writing an RFP to buy IT equipment. Team members from purchasing, the business unit and IT would need to collaborate on a document with likely a pre-defined structure (technical specs, functional specs, terms & conditions, deadlines, etc). This is different from the lack of structure in Google Wave or Etherpad. I imagine that the majority of knowledge work in today's enterprise is about filling in templates rather than free-flowing text.
For this to work, as a minimum we would need:-
1. real-time communication 2. the ability to design templates with the right balance between strictness & flexibility
Second, it should support a workflow. Sticking with this example, the purchasing manager should be able to publish the RFP and invite vendors to respond. The bid manager at the vendors should then be able to turn (transform) an RFP into a bid template, invite his/her sales team to collaborate on a bid and so on.
Not sure how this would work, but perhaps the following:-
1. Access control 2. A way to transforming one document with a certain structure to another.
I would also figure out some precise user scenarios and workflows, then build a tool tailored for those. If you have clearly defined targets, it should become clear where you can insert a new product.
For a great example of how not to do it, look at Google Wave. Wave is fantastic, magically engineered, and has all sorts of way-cool properties. Search, tagging, collaborative editing, document uploading, you name it. I've used it on a three person project, and it was the best documentation/communication tool I've ever used. I love Wave.
However, I never use it anymore because it's got some deep problems: Wave depends on everybody using Wave. There's no good way to hook into other services. You're confined to the web client, which is a big turn off for some people. Finally, people don't really understand it. What is it good for? Google's answer is "everything", but that's not really an answer.
Using Wave is like being trapped on some technological Galapagos, where everything is cool and exotic but totally detached from the rest of the world. That's the kiss of death, especially when you're a startup looking for traction.
That's my two bits. Good luck to you, and congratulations on getting into YC!
Upload a file to Central Desktop, check the people you want to notify, and they'll get an email. Any replies to the email get attached to the file in Central Desktop, and CC'ed to everybody involved.
Firstly a mashup of a wiki and Etherpad. So you can browse the wiki as normal - but when it comes to editing you get an Etherpad style interface to allow collaborative editing.
Secondly (and there is a big business here if you get it right) is document management storage. Everything has to be versioned and audited now to meet ISO standard. A server that would accept uploaded word, excel etc. documents, let you edit them and create new ones would be killer, you could track versions automatically and place it prominently in the document as well as maintain an audit of edits. Another wiki aspect would come in in terms of discussing the documents (like a talk page) which is massively useful.
Just my 2 cents but I strongly disagree with that. "Realtime" collaborative editing is a very, very small niche. Think about it, how often do you need or want that?
Secondly (and there is a big business here if you get it right) is document management storage.
With this one I agree. Equally strongly. ;-)
There must be offline Wikis by now? Offline as in HTML5 Offline?