[daisy] Better desktop integration

[Karel Vervaeke]

On Sun, 2008-05-04 at 13:35 +0200, Marc Portier wrote:
> 
> Karel Vervaeke wrote:
> > We are planning to make things much better by creating a desktop
> > component that will even make it unnecesary to go to the HTML document
> > editor.
> > 
> > [0] http://cocoondev.org/wiki/g5/607-cd.html
> > 
> > Please post your remarks to the list, I will gather your input and merge
> > it with the document later.
> 
> A lot of thoughts I had when reading the document, in no particular order:
> 
> 
> * Main observation: daisy works with *documents*, but these external 
> editors will all work on *files* that fit into single parts of daisy. 
>  From that observation I more and more got the feeling that this tool 
> should focus on files/parts first and only for the interested and for 
> background daisy communication know (and show) detailed info about the 
> actual daisy-documents.
> 
> The most obvious effect of this would be that the gui proposal would 
> change to  not list daisy-documents, but rather files (or daisy-parts). 
> And probably thus by 'filename' rather then by document-name (or id) + 
> partname.
> 
> For most 'simple' documents the relation is 1-1 so doesn't make a big 
> difference?

+1, Part/file oriented will feel more natural.  However, the wiki and
the desktop component should provide functionality to "Download all
parts of this document" and "Upload all parts of this document".

Perhaps visually grouping the parts could help here (e.g. in the table,
instead of using an alternating the background per row, use an
alternating background color per document.  Unfortunately, when the list
is not sorted on document name this idea falls apart).

> * Leading to my name/abbreviation(extension) proposal: dpm for daisy (or 
> desktop) part manager

+1, although I'm sure we could easily come up with many more TLAs which
would be equally good ;-)

> 
> * Leading to my menu-integration proposal
>    - it's getting crowded already but I think this deserves a separate 
> menu entry:
>      - Desktop Part Manager (or something shorter)
>          - Install (link to docs or jws directly)
>          ------------
>          - Manage All Parts (unlikely IMHO)
>          ------------
>          - AttachmentPart
>          - ImageDataPart
> 

Again, good idea.  It would be nice if we could detect if DPM is already
installed, but I don't think the webapp nature allows this elegantly)

> 
> * Additionally some (all?) part-editors (in html) could easily provide 
> an obvious button to "manage this part through a desktop editor tool"
>    - this probably calls for an extra property of part's (or 
> part-document-associations) that indicates of external editor management 
> should be offered or not (something the xsl will eventually pick up 
> probably)
> 

True

> * If possible the desktop component should have the possibility to 
> notify the user via the systray. + We should list the kind of 
> notifications that could be of interest. (If not via the systray, at 
> least via the component itself)

Yes, notification would be an very useful idea - should be investigated:
what can we do with notifications and how we can do it in such a way
that it will not become obnoxious (or that it can be sufficiently
configured -- note: more work)

> * In the list of "Desktop component fucntionality" I was missing two 
> actions:
> 
>    - "Overwrite" which would allow to just copy over a local file over 
> the one that is in the local dpm-cache
> 
>    - "Revert" which should allow to discard all local changes and go 
> back to the version at last checkout-time (by keeping a .svn like 
> original copy so it is available off-line?)

+1, very useful indeed.

> 
> * and if I've read the discussion between Jorg and Lou correctly, a 
> third additional operation could be:
>    - "Link To File" which would allow telling the system that the 
> part-file itself is not internally in the "local cache" but rather 
> pointing to another file-path
> 
> * Note that drag-drop might trigger similar effects:
>    - drag-drop-in could be 'overwrite'
(as discussed IRL) Drag/drop should always mean 'link to', not
overwrite.

>    - drag-drop-out could be 'link to'
(also as IRL)We probably can't handle drag-drop-out, since the drop is
handled by the receiving application.

(Note: even though drag-an-drop linking seems practical you will still
have the effect experienced in the current part editor upload widget:
when linking, you are 'blind', (i.e. you don't have visual confirmation
that you are dragging the right file to the right document).  However in
a desktop environment, it is easier to verify (no download/upload
delays, less clumsy GUI)

> * And in the same area: double-click should equal the mentioned 'edit'
+1, a simple but useful addition

> 
> * When the user chooses (in his browser) to manage a part from the 
> desktop a so called dpm launcher file should be sent in the reply
>    - extension and mime-type should be associated to launch the desktop 
> component
noted

>    - file should probably not hold the contents (binary octet stream) 
> but only all required metadata (xml or json format) to support all 
> required management operations
That was the idea

> 
> * The wiki-document should be extended with a more detailed description of
>    - the contents and layout of the
> 	- dpm launcher file
>    	- dpm local cache directory
As above.  I will document the dpm file format clearer.

>    - the extra cocoon supported uri's that will handle the pass-through 
> part operations on the repository (cause I think we should not just call 
> the repo directly)
Indeed, dpm would communicate with the wiki only.  I don't know if a
transparent pass-through is wat we need, we can just as efficiently
process the incoming dpm calls and use the available object model:
    document = repo.getDocument(dpmInput.getDocumentId());
    document.setPart(dpmInput.getPartType(), 
	dpmInput.getMimeType(), dpmInput.getData())
    ...

> 
> * gui should display appropriate file-preview icons, if possible those 
> associated to the part's mime-type/extension as per the host's OS settings?
To investigate if it is possible.  (Mmmm, gnome's icons with
content-based previews).

Also, if the part has been linked (see drag-n-drop) use an overlay icon
(a la windows' shortcuts).

> 
> * With respect to the support for multiple daisy instances:
>    - I'm not sure, but I think we can have one installation of the 
> dpm-desktop component per daisy instance connected to?
Should be doable.  We surely should keep the part lists separated so we
never display information from two separate wiki's in one application)
and maintain separate "local cache directories" for each wiki.  (or
"local stores", as we should call them - I'll leave the obvious League
of Gentlemen quote to Paul))

(Note: Had the idea of 'how to identify a wiki', I think the best idea
is still to use the base URL (everything up to the mountpoint - but this
could be problematic in cases where a site is mounted as the root from a
site (?))

>    - Main argumentation for that: having one jws installation per 
> daisy-installation/server means they can independently follow up on the 
> version upgrades in the future (jws update)
>    - There is probably a very limited set of users that get to work with 
> more the one daisy instance in this way?
>    - The JWS installation can easily (and clearly) hold the name of the 
> daisy installment one works with...
> 
Yes, I don't think many people have more than one Daisy instance, but 
we should still handle those cases.
The browser will just open .dpm links so it will be up to the DPM 
application to distinguish between wiki instances (and spawn separate
windows or even separate processes (better in case of crashes?) when detecting
 multiple wiki sources).

> * More on the support for "configuration" in the gui of the desktop 
> component: Specially stuff like user/password can probably be 
> managed/stored in the background? I would hope we can keep this 
> component as lightweight as possible.
Yes, the less configuration the user is presented with, the better, but
it is also clear that there will be conflicts of interests.  Seeing as
DPM in its current form is already quite complex, this should be lower
priority.  

In any case, storing username/passwords combinations also raises
security questions which are currently not addressed.  Could be linked
to the "persistent login" feature, for which multiple 'autologin keys'
would be stored.  Having a separate login key for the application would
allow us not to store actual passwords, but equivalent passwords which
can not be used for changing user information, ... (see the persistent
login documentation for more info).

> 
> * In contrast with that: I like the idea of the facet-assisted searching 
> in large document-sets. We should however clearly list on which facets 
> this browsing would occur (mimetype, extension, date, document type, 
> document owner, ...) In the end sortable and configurable columns might 
> be good enough.
I will list them in the documentation page.  With a decent table GUI
library, an intelligently chosen fixed set of columns should be almost
as easy to implement as user configurable columns.

>   Big question is what size of local cached documents do 
> people expect to be managing at any given time in this way? (personal 
> guess would be around 20-25)
Size does matter ;-)
  * 20-25: seems reasonable, still relatively easy to handle in a single
list
  * 100 or more: seems reasonable in large batch-update scenario's.  In
this case, there will be less searching.

> 
> * I like the idea of reusing the current logged in session from the 
> browser. We'll have to be weary of session hijacking though. (Even if 
> this is not in the 'criminal area' e.g. dpm launcher files being 
> forwarded by email to some colleague)
> 
> *As for the listed URI's
>    - I would keep the jws URI's strictly for GETting the web-start file 
> to trigger the local installation.
+1, easiest to implement, no development/design/investigation overhead
and easy enough for users to understand (perhaps even easier than
understanding complex jws magic)

>    - Same for the dpm-launcher file
Unsure what you mean with dpm launcher file? Are you referring to
the .dpm file downloaded from the wiki?  (I also don't understand what
you would mean with 'Same for the .dpm file')

>    - Next to that there should be a set of pass-through REST-like part 
> mangenemet URI's to actually get/update the part contents.
As noted before, I think there is no need for transparent passthrough,
but of course a decent REST design is not optional.

> 
> * The wiki-document can use a glossary since it introduces some new 
> nomenclature in daisy land.  Local Document Cache, Desktop Component, 
> DPM Launcher File,...
Will do.

> 
> all for now,
> regards,

Thanks a bunch!
Karel

> 
> -marc=
> _______________________________________________
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
> mail to: daisy at lists.cocoondev.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy