>> this hasn't been 100% successful. Many of the people in my company >> don't like trac's UI and started putting stuff all over the place >> which seriously reduced trac's utility (we have data in shares, wedav >> repositories, google docs and google sites). And this has created a >> host of problems. I'm not sure if the problem is due to trac actually >> being difficult to use or us not being willing to commit resources for >> improving the user experience. > > This was enough to spark me to finally file > http://trac.edgewall.org/ticket/10012, > also been on the TODO list for too long.
Well... for the most part the over all UI of trac hasn't been the issue. At the end of the day I don't see a huge difference between Trac's UI and say something like JIRA. And it's a lot better than something like 37signal's basecamp which I'm using with another project. Sure there might be more dynamic status type information on the front page (usually keyed to the user), but you can accomplish similar things in trac through judicious use of its existing capabilities. Between TicketQuery and the #div processor I've been able to create some excellent reporting/indexing interfaces in trac. The big place where we run into issues is with search... finding stuff in the wiki can be hard. Another part of the problem here is related to usage and I believe this is true with pretty much any type of information organization platform, if you aren't careful you end up with a giant mess. There are basically 3 ways to combat these types of problem: be very careful with what you put in the wiki and how you name (and tag) it (limiting content), provide multiple pathways to facilitate finding information (hierarchical organization, tagging, linking, indexing), and a robust search capability. The major issue with all 3 of these is that if you put junk into the wiki... how are you supposed to find the good bits. My personal solution (which didn't scale once we had more than 15 people using the wiki) was to go through every new piece of data added to the wiki and try to categorize it. But as I said... this didn't scale since I had other duties for the company and this was a house keeping issue. But I think this house keeping thing is basically a critical function with a wiki. Look at the work that Steffen has been doing updating the TracUsers page, and the continual efforts of the other members of the trac team to keep the wiki content updated and spam free. It's a lot of work and takes a certain amount of effort which must be invested. You can't just throw the data in there and expecting it to organize itself. And I suspect this is one of the major issues my colleagues have... they think it works that way for some reason. :-/ Another issue was with editing of content. While I love the Trac wiki syntax (I write most of my documentation using it and then post it to some trac instance) most people don't seem to like it and preferred some sort of WYSIWYG interface. We installed the Trac WYSIWYG plug-in (now integrated... started using Trac with 0.9) and that helped a little bit, but dealing with things like attaching images and such still isn't the easiest thing in the world. Then there's the issue of what happens when your browser crashes while editing or you accidentally close the window and lose your work. We developed an in house plug-in to help with this, but it's still annoying. On top of all of that people are very comfortable in Word... and this just ends up having much of the material in trac as attachments in doc, pdf, and ppt (or sometime stuff them into a svn repository connected to the wiki). These are essentially unindexed... so you've just got all of these extra files scattered about and outside of the search system. There has been an ongoing (almost 2 years now) plan to replace trac with something else... but so far nothing good has been found. (I guess that says that Trac doesn't suck that bad. ;-) And while many started using Google Docs... this makes me crazy because even in the corporate edition there's no way to see all the other documents everyone else has created... they all must be explicitly shared... the totally opposite of how a wiki works. Ideally you want an organization to have a single source for all of the relevant information about its activities and the information necessary to make progress on its tasks and projects. Trac could be providing this, but it requires some work by the deploying organization. You have to spend time pruning and sorting your data. When it gets big enough you start needed to managing indexing of the related pages for projects and start instituting some hierarchical organization (with a personal project I've been trying to do this from the start since if it gets going re-organizing the data will be a major pain. And this is even harder to do when your colleagues don't buy in to what you're trying to do and reject the tool. Ben -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
