<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: What you get with Teamwork and what you don&#8217;t</title>
	<atom:link href="http://blog.twproject.com/2009/07/16/what-you-get-with-teamwork-and-what-you-dont/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.twproject.com/2009/07/16/what-you-get-with-teamwork-and-what-you-dont/</link>
	<description>work management software</description>
	<lastBuildDate>Mon, 28 Nov 2011 10:39:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Pietro Polsinelli</title>
		<link>http://blog.twproject.com/2009/07/16/what-you-get-with-teamwork-and-what-you-dont/#comment-219</link>
		<dc:creator><![CDATA[Pietro Polsinelli]]></dc:creator>
		<pubDate>Fri, 17 Jul 2009 17:23:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.twproject.com/?p=773#comment-219</guid>
		<description><![CDATA[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 &quot;just todo list&quot; application, of course). Keep in touch, regards.]]></description>
		<content:encoded><![CDATA[<p>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 &#8220;just todo list&#8221; application, of course). Keep in touch, regards.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Warren</title>
		<link>http://blog.twproject.com/2009/07/16/what-you-get-with-teamwork-and-what-you-dont/#comment-218</link>
		<dc:creator><![CDATA[Warren]]></dc:creator>
		<pubDate>Fri, 17 Jul 2009 17:10:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.twproject.com/?p=773#comment-218</guid>
		<description><![CDATA[For a start, Teamwork needs it&#039;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&#039;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&#039;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.]]></description>
		<content:encoded><![CDATA[<p>For a start, Teamwork needs it&#8217;s own API (preferably REST &#8211; this is the way to go), available in JSON and XML output formats (like all good APIs).</p>
<p>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&#8217;s Online office tolls is essential. Integration with services like Box.net should come only once these major players have been catered for.</p>
<p>Also, the Teamwork code and user interface are messy and inflexible &#8211; I&#8217;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).</p>
<p>If there was cleaner and better structured code companies would be able to customize the interface to meet their needs.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

