21–28 of 28 posts
There must be offline Wikis by now? Offline as in HTML5 Offline?
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…
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…
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.
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, th…
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
Earlier quoted context omitted.
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…
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-interdependenc…
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.
Earlier quoted context omitted.
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?
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.
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, th…
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.
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.
Earlier quoted context omitted.
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-interdependenc…
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 thi…
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 ;-)