[taskjuggler-devel] A view ideas for a reorganized GUI for taskjuggler

From: msuess (michaelsuess_at_gmx.de)
Date: Mon Aug 29 2005 - 23:22:11 CEST


From: msuess <michaelsuess@gmx.de>
Message-Id: <20050829212211.D085163D9@einstein.suse.de>
Date: Mon, 29 Aug 2005 23:22:11 +0200 (CEST)
Subject: [taskjuggler-devel] A view ideas for a reorganized GUI for taskjuggler


So it turns out that I do not like both available Gui's for taskjuggler too much. This might not be the best start for a post like this, and it might just be me, but things always seem to work differently from what I think they should. So I decided to think a bit about how I think a GUI for a project manager should work. Oh, and before I go too deep into this: I am not a GUI-designer of any kind, so if you think my ideas are crappy, just step forward and tell me :).

I think we have two main categories of stuff to consider: we have all kinds of project data (infos, tasks, resources, accounts - note that I do not include reports here!), and on the other hand we have views on these data. These views include the file editor view (for example in Kate), as well as the various kinds of reports (graphical gantt view, html reports, PS-reports, XML-reports, iCalender). It could also include a tabular view (similar to the one already present in TaskJuggler / Reports tab).

So, how can we organize these two orthogonal concepts? The answer I would prefer is already in TaskJuggler and ktjview2 (although not in a single solution :) ) : I would keep the icon bar on the left of ktjview2, but only put icons for the actual data in there (I already mentioned them: infos, tasks, resources, accounts). Clicking on the icons opens the different views on the right. And it opens them in tabs. I am not a graphics artist and I do not have the energy right now to produce a mockup, so I will have to describe it a little more here. Imagine clicking on the tasks button. You are then taken to the editor view in a tab. Clicking on another tab shows you a nice gantt-chart of the very same data. Want to see a html-report about it? Its just one click away in another tab (we have kparts, don't we?). View it as a postscript file? Just click on the tab. Want to have some information about developers and what they are doing? Click on the developers button on the left, and y
 ou are taken there to the default view (probably the editor view). One more click gets you any view on these data you want.

But where do these views come from? Right now, you have to put them into your project file yourself for each and every project (they are called reports right now). Or you just use the provided template. The question that came to my mind is: are these reports really so different for each and every project? I know I just used the ones provided in the template. And I could imagine others doing the same. Is there maybe a default set of reports that apply to every project? And if yes, maybe these can be automatically created by the GUI and put at the end of the project file (with a big warning up front to not modify them, or even code in the GUI to not show these reports in the editor view)? If these default reports are really there, then thats where the views I talked about above come from.

And what about the people that need more reports? Well, maybe for them we need a new kind of data button called custom reports. I am going into details already here, and its to early for that, so I will leave that point open.

But there is one more point I want to emphasize: The user should have the ability to select, which views he wants (for example to specify he wants HTML, gantt and iCalender) in a config dialog. Since he can select his preferences this way, it makes sense now to create and update all selected reports in one go as soon as the user tells the system to schedule (F9). The views must be all there and up to date after scheduling, no more clicking on the nice menus at the top of the pages in the HTML-reports only to be told that this page does not exist! This has bothered me more than once, and the idea sketched above would make it obsolete.

So, thats about it from me. Does this idea sound interesting and doable? Or is there anything I missed? I have not used taskjuggler extensively, and I do not have very much experience with other project management tools, so I expect to have missed things. I want to get into KDE and QT-programming a bit, so I might even be able to start turning these ideas into code, but on the other hand I do not really know how much time I will have tomorrow, nevertheless over the next few month. And I sure do not want to start coding something, only to be told later that it is never going to be accepted ;).

--
"What we do in life, echos in eternity..."
-- 
To unsubscribe, email: taskjuggler-devel-unsubscribe@suse.com
For additional commands, email: taskjuggler-devel-help@suse.com


This archive was generated by hypermail 2.1.7 : Mon Aug 29 2005 - 23:22:17 CEST