Ask HN: YC S10 startup wants your opinions about wikis

26 points by ithayer ↗ HN
We're a incoming YC team exploring online collaboration tools and workflows. We're working on something completely different, but are running into the same annoyances managing shared information that we've experienced before in other teams. We already know about basecamp, sharepoint, etherpad, unfuddle, jotspot, pbwiki, google sites/wave, chatter, solutions mentioned in previous HN posts(1) and wikimatrix.org... But amazingly, nothing seems to fit quite right.

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 ] thread
Pivotal Tracker - pivotaltracker.com
We always (eventually) run into problems with Wikis, since we always end up with huge PDF or XLS files that we want to add to wikis.

Currently, we are using Dropbox as a replacement for our wiki

Dropbox is also getting some traction in our company. It's a great way to have a central repository for documents.
Great timing - I just abandoned an idea because I could not find a wiki-type product for what I wanted. Basically, I want to create a wiki to keep track of many different properties and the associated images, lease documents, information etc on each lease in a portfolio. A wiki would be fine, but I also want to run some analysis on a small subset of structured data such as Lease start dates, amount of rent, future rent, dates of lease expiries etc.

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.

For me there is always an "overlap" problem with "infotools" like todo lists, issue trackers, wikis, google notebook etc. And in my case, they're always competing with email, which is hard to beat.

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.

I think Wave's lack of success is due to a lacking user experience.

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.

In my opinion, the key to online collaboration is product design for the right audience. It can't be a swiss-knife solution. Collaboration means different things to different people. Targeting large organizations or targeting SMB's will require different strategies, since both perceive and use collaboration differently.

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'm skeptical that a wiki is still a sensible angle in this day and age.

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. ;-)

Thanks for the insightful comment. You hit the nail on the head - we're not interested in building another wiki (as you mentioned, we haven't seen one we've liked). We're just trying to think about whether it's possible to solve the problem in a simpler way.
Agreed. Providing structure around an existing workflow for a target group is exactly what the doctor ordered... but even that's a tough nut to crack. One of our hopes in exploring existing workflows is to identify both winners and losers around specific use cases. Thanks for the thoughtful response.
The problem with this approach is that there are as many workflows as there are organizations/people?
There are, yes.

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.

I'm curious about the issues you have with pivotal tracker. After years of frustration with tools I've found pivotal to be a breath of fresh air. The killer feature is using historical velocity in conjunction with estimates to guestimate when work will be done. This forces managers to see the tradeoffs they are asking for when they ask to squeeze something in. Mainly because of that we found that simply adopting the tool actually improved our agile process. With regards to using it in place of a wiki it depends what information you're looking to track. Pivotal's nature is very feature/time orientated and so may not be suitable for consolidating information. The tags/search functionality might be useful here though. Assuming you maintained the tags this would allow you to aggregate related information retrospectively rather than having to continually consolidate as you do with a wiki.
Well, I've summed up my gripes in other comments previously, it mostly boils down to that I consider the UI an utter abomination.

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.

I was surprised to hear your objections to the user interface so I took a look at mantisbt. I found it interesting that I hated the interface for probably the reasons that you hate pivotal.

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.

Well, with regard to ordering, as said, I have no idea how people bear with pivotal's complete lack of any way to express dependencies. Those are at the heart of any project I've been involved with, as stuff naturally gets delayed and shuffled around all the time. I have yet to find a sensible way to get a comprehensive status-view of a given Goal (consisting of multiple stories) in pivotal.

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 ;-)

There's Wikipedia, and then there's wikis.

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.

Wikis are designed to share information. Collaborating with others in your case seems to be about solving problems and accomplishing tasks. I would use tools that are best for each purpose in the collaborative process, rather than lean towards sacrificing functionality for 'all-in-one'-ness.

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.

There is certainly room for better wiki options. I found JotSpot to be the most interesting and innovative, but it basically died when it was acquired. The current offerings are so heavily weighted toward power users wider adoption simple will not happen (in terms of editors).

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.

Good luck with this. There certainly is room for something light & inspiring.

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.

As moe has pointed out, you're not going to instantly displace entrenched software, especially in businesses. So, you need a migration path. People already have bucketloads of documents, and many of them are locked up in bizarre proprietary systems (I'm looking at you, Blackboard!). Some kind of bridge is critical, and email is the prime candidate.

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!

Here's an example of a workflow we have almost daily. Someone makes some wireframes or designs. Then emails a bunch of people: "attached (and also uploaded on basecamp) is the latest version of X with the following changes. Can I have some feedback/thoughts, particularly on Y and Z? Thanks!". The feedback comes in through 1 or more email threads. It's a little clumsy.
I think you should give Central Desktop (www.centraldesktop.com) a try. Disclaimer: I'm an employee.

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.

There are currently (in my mind) two commercially viable options in the "wiki" style arena.

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.

So you can browse the wiki as normal - but when it comes to editing you get an Etherpad style interface to allow collaborative editing.

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. ;-)

Fair point. Although I have found many aspects of Etherpad to be incredibly useful (and we use and installation of it internally at work now for speccing work) - with some work it could be the "next big thing"
Once thing that hinders my adaption of such tools is performance. I think having a kind of offline wiki that syncs in the background would be mandatory. Even having to wait just a couple of seconds after pressing "submit" hurts my brain. Maybe Etherpad is better here, I don't know - I can't quite cope with the interface of Google Wave.

There must be offline Wikis by now? Offline as in HTML5 Offline?