

Ask HN: YC S10 startup wants your opinions about wikis - ithayer

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.<p>We're wondering if there's room for something light &#38; 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.<p>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:<p>1. What type of projects have you used wikis/shared documents for? How many readers and writers were involved?<p>2. Think of a specific project where a wiki or &#60;insert your tool(s)&#62; was invaluable. What made it work?<p>3. What didn't work? Was it an issue with the collaboration process, tool or ... ??<p>4. What was the typical workflow like for you? What were the pain points? How would you have done it differently?<p>5. What is the minimum set of features that would be required to be useful?<p>Tell us your thoughts. We would be happy to clean up &#38; publish the results if it would be helpful for others (we'll do this if there are sufficient responses to warrant this, say, 50)<p>(1)  Previous HN posts about wikis:<p>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
======
moe
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.
;-)

~~~
ollysb
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.

~~~
moe
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.

~~~
ollysb
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.

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

------
nreece
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.

------
megaduck
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!

~~~
petervandijck
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.

~~~
clewis
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.

------
Maro
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.

~~~
fragmede
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.

------
philwelch
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.

------
shorbaji
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.

------
stuntgoat
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.

------
ErrantX
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.

~~~
moe
_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. ;-)

~~~
ErrantX
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"

------
albahk
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.

------
qhoxie
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.

------
sandGorgon
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

~~~
petervandijck
Dropbox is also getting some traction in our company. It's a great way to have
a central repository for documents.

------
Tichy
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?

------
p01nd3xt3r
Pivotal Tracker - pivotaltracker.com

