TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: YC S10 startup wants your opinions about wikis

26 pointsby ithayerabout 15 years ago
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

13 comments

moeabout 15 years ago
I'm skeptical that a wiki is still a sensible angle in this day and age.<p>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.<p>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).<p>I would rather claim that there is simply a fundamental impedance mismatch between the wiki concept and the common workflow in most companies.<p>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.<p>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.<p>Anyways, to make a long story short; instead of beating a dead horse yet again, why not look at the ideas that <i>have</i> caught on in the meantime?<p>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.<p>So, my humble opinion would be that there's still <i>tons</i> 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. ;-)
评论 #1346960 未加载
评论 #1346763 未加载
评论 #1346750 未加载
nreeceabout 15 years ago
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.<p>My feedback below derives from experience within medium-large Financial Services organizations AND a small Web-based startup.<p>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.<p>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 &#38; easy access to documents. They also want to compare or recover previous versions of a document.<p>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.<p>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.
megaduckabout 15 years ago
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.<p>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.<p>For a great example of how <i>not</i> 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.<p>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.<p>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.<p>That's my two bits. Good luck to you, and congratulations on getting into YC!
评论 #1347206 未加载
Maroabout 15 years ago
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.<p>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...?<p>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.<p>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.<p>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), <i>email prevails!</i> Hence my suggestion to integrate with email.
评论 #1346888 未加载
philwelchabout 15 years ago
There's Wikipedia, and then there's wikis.<p>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.<p>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.
shorbajiabout 15 years ago
Good luck with this. There certainly is room for something light &#38; inspiring.<p>I would like to see a tool that would, first, allow real-time editing of structured documents. Think Etherpad meets Wufoo.<p>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 &#38; 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.<p>For this to work, as a minimum we would need:-<p>1. real-time communication 2. the ability to design templates with the right balance between strictness &#38; flexibility<p>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.<p>Not sure how this would work, but perhaps the following:-<p>1. Access control 2. A way to transforming one document with a certain structure to another.
stuntgoatabout 15 years ago
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.<p>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.<p>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.<p>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.
ErrantXabout 15 years ago
There are currently (in my mind) two commercially viable options in the "wiki" style arena.<p>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.<p>Secondly (and there is a <i>big</i> 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.
评论 #1346941 未加载
albahkabout 15 years ago
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.<p>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.
qhoxieabout 15 years ago
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).<p>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.
sandGorgonabout 15 years ago
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.<p>Currently, we are using Dropbox as a replacement for our wiki
评论 #1347211 未加载
Tichyabout 15 years ago
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.<p>There must be offline Wikis by now? Offline as in HTML5 Offline?
p01nd3xt3rabout 15 years ago
Pivotal Tracker - pivotaltracker.com