4 ms·

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 h

by moe 17y ago

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

ithayer 17y ago
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.
innovate 17y ago
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.
- Maro 17y ago
  The problem with this approach is that there are as many workflows as there are organizations/people?
  - innovate 17y ago
    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.
ollysb 17y ago
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 17y ago
  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 17y ago
    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.

by moe 17y ago

ithayer 17y ago

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.

innovate 17y ago

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.

Maro 17y ago
The problem with this approach is that there are as many workflows as there are organizations/people?
- innovate 17y ago
  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.

ollysb 17y ago

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 17y ago
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 17y ago
  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.