Some project management applications provide minimal functionality: just a Gantt drawer. Some, more groupware oriented, provide a vast spectrum, including e-mail and chatting. While developing Teamwork, we made several choices about what to include and what not. The choice for Teamwork has been guided by this simple princliple: include only what will not sharply conflict with acquired user habits, and will have a rich integration with the rest of the system.
Examples of what we did include:
– “boards”
– sticky notes
– to-dos
– a calendar
All these have a natural integration with project management, bringing together personal and team management. So we put them together in a unique, integrated solution; you don’t have to get three separated products from us to get this functionality.
Examples of what we didn’t include:
– e-mail client
– chat services
– file management
The three integrations above are probably used by most in standard ways, and happily too: you are not going to change those user habits with the new project management software; so the work we have and are doing is to integrate with the existing applications, as smoothly as possible.
Notice also that probably most users already have a calendar application, and others that may overlap with what we provided built-in, and for that we are working so hard in extending seamless integrability (most previous posts talk about this in fact).
Current and future developments
This is for the actual situation; but usage of the web is evolving all the time, and more integrations are now needed: in Teamwork we always assumed that the contents and documents related to projects and work which would not be articulated in tasks, issues and to-dos would be handled by other document management software, and then somehow connected to projects (say for example with file storages). But with wiki and blogs, content is more and more inserted directly online, and we should support this also inside Teamwork. One can currently do this by simply creating custom portlets connected to a Wiki service. But as with most of our solutions, we would like something organically integrated with the rest of Teamwork functionality; for example, content editing would naturally blend with exposure of Teamwork objects to REST and similar services, and in-place customizations of pages. So this is one of the (non trivial) directions we are now exploring.
If there is an organic integration that we are missing, just post it on our feedback service!
The quoted products, services and images may be registered trademarks of their producers. Images that require attribution are linked to their source.
Thanks for the feedback, indeed we will provide an API as you suggested. For the rest, we feel that relatively to the size of the code base and functionality, the code is not messy, and actually extremely flexible, which allowed e.g. the issue Ajax multiline development in a very short time. But the idea for the future is to be able to make deeper customization to the interface without going down to the Java recompilation level, which will always be complex, given the richness of the model and application (it is easier to read code of a “just todo list” application, of course). Keep in touch, regards.
For a start, Teamwork needs it’s own API (preferably REST – this is the way to go), available in JSON and XML output formats (like all good APIs).
I feel the lack of good file management functionality is a major disadvantage. If Open Lab are going to insist on excluding good file management functionality like most project management tools, good integration with Microsoft Sharepoint, Google Docs and Microsoft’s Online office tolls is essential. Integration with services like Box.net should come only once these major players have been catered for.
Also, the Teamwork code and user interface are messy and inflexible – I’d like to see cleaner and better structured code which will allow companies to better customize it. I love the use of JavaScript in Teamwork to increase productivity (like auto-suggest for names), but the interface needs cleaning up (hiding and showing information on-demand, only when it is relevant).
If there was cleaner and better structured code companies would be able to customize the interface to meet their needs.