[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Task control/Document control in kplato
From:       Dag Andersen <danders () get2net ! dk>
Date:       2007-09-26 11:30:47
Message-ID: 200709261330.47655.danders () get2net ! dk
[Download RAW message or body]

Onsdag 26 september 2007 11:44 skrev Thomas Zander:
> On Wednesday 26 September 2007 11:15:28 Dag Andersen wrote:
> > > I have just one observation; your proposal looks a LOT like what
> > > several solutions have done in a web-based form. Which I dislike due to
> > > the poor usability those apps tend to provide. Competing with such apps
> > > may not be
> >
> > Do you have any more specifics on usability probs? (Don't want to make
> > the same mistakes.)
> > By "such apps", do you mean project management in general or document
> > control specifically?
>
> I was specifically talking about so called "Enterprise content management"
> frameworks.
> For example
> http://www.alfresco.com/products/ecm/screenshots/2.0/check_in.png
> or in general;
> http://www.alfresco.com/products/ecm/screenshots/
>
> The usability problems are due to the fact that they are always webbrowser
> based, which has its own set of problems.
> The other major one is integration; they separate file-management from the
> application interface. Meaning that you are required to save a file
> somewhere in your homedir and find it from your webbrowser again to upload
> it. 
Yeahh, that's a lot of manual document control...
> My suggestion was to integrate it with the app so the user doesn't even 
> know the doc is saved on his HD, he for sure doesn't need to provide a
> directory.
Yes, what I had in mind with my solution also :)
Example of workflow would be:
1. PM emails project members mails with workpackage attached.
2. Member opens the workpackage with the new app (wph).
The work package is (automatically) saved by wph to a projects dir in 
$KDEHOME/...
The wph looks a bit like the todo dialogue in kdepim with clickable entries 
for all the documents in the workpackage.
3. When the user opens a document he wants to edit, it is extracted (by wph) 
from the store to a temp file and given to apropriate app for processing.
4. When the user closes the app, wph retreives the temp file and stores it in 
the work package.
5. When closing wph, the status/progress dialog pops up. If changed, info is 
mailed back to PM.
--------
For integration with pim (on the member side), 2 options:
1. Make a kresource (or is it service now?) in kdepim that can read info from 
the projects dir.
2. Have wph (automatically or manually) mail a VTODO to the member.
-------
Use of pim would be optional as wph could open a file dialog on the projects 
dir if started wo a file.
>
> > > the best long term strategy. Working better with them by actually
> > > implementing support in the apps (much like my initial suggestion doc
> > > outlines) may be a better long term solution.
> >
> > For kplato in general I need more than document control.
> > As I see it, the "report status/progress" dialog would be the same (or
> > very similar) wether it's called from a koffice app or from my "work
> > package" app, and I'd think the solutions can coexist. Providing both
> > would mean some extra legwork in kplato, though.
>
> Right,
> one of the ideas I heard was to work with big players in the enterprise
> content management market.  These ECM packages tend to provide document
> workflow with things like routing a document to different people.  Much
> like I suggested in my PDF.
> Based on that already existing functionality you may be able to talk to the
> ECM vendors and get a web-service api to which you can upload the document
> after you show your dialog inside the application.
> Not sure how best to provide the dialog inside apps, though. As there
> certainly is work required in the application to do so. Which we can do in
> KOffice, but I have troubles seeing that done in your "work package" app
> (I'd love to be proved wrong there, naturally)
Hmm, I have the feeling we misunderstand each other, or more likely I 
misundertand you...
My "work package" app is a new app that needs to be writen, so I don't see why 
it can't provide a dialog?
The distribution of documents would work almost exactly as you describe in 
your PDF, except that instead of eg a kword document file, a work package 
file (a zipped file that includes the kword doc file among other things) is 
distributed. (Or have I missed a trick?)
-- 
Mvh
Dag Andersen
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]