topic Re: Having Share know the location of checked out files? in Alfresco Archive

Having Share know the location of checked out files?

alexandra — Sat, 15 Oct 2011 13:10:19 GMT

I am using Alfresco and EMC Documentum at the same time. One thing I am missing is that Documentum WebTop and Digital Asset Manager always downloads checked out files to a specific folder Called Documentum/Checkout which means that when I am done editing in Word I hit save - return to the Web GUI an

Re: Having Share know the location of checked out files?

afaust — Sat, 15 Oct 2011 14:28:11 GMT

Hello,

Alfresco follows a principle of zero-install for clients being able to use the product. The way it currently is designed to work allows it to work with almost any web browser without having to grant any elevated privileges to Share (including Java Applets, which could be one way to deal with this use case without installing something that should not already be there).
For Office documents, this use case is already dealt with by the SharePoint protocol support in Alfresco.

In terms of gauging the complexity of the current usage: I sure hope that users are not mindless drones and have used a computer for something else apart from work for the last decades. Ever since the dawn of the Internet, users had to remember where they downloaded files to in order to be able to use them - this should be ingrained into our being by now, just like another complex function known as "breathing". I personally think that IT (actually everyone, but IT is what I may be able to influence) should not take part in dumbing down society and any use case where click-stream efficency is required due to a massive amount of work would surely use a different interface than Share (like OpenWorkDesk).

Now that I have that off of my chest: One of our customers is also using Alfresco and Documentum in parallel and we have provided a proof-of-concept implementation based on Java Applets with elevated security privileges that can achieve what you require - check out / download to a (specific / user selected) folder, remember the download location, check for changes (regularly / on page load / on focus) and provide a simple "Upload changes" type action. Apart from the security privileges required for access to the clients hard drive, this is the least invasive approach in order to follow the "zero-install" principle as best as possible.

Regards

Re: Having Share know the location of checked out files?

alexandra — Sat, 15 Oct 2011 19:52:12 GMT

Thank you for you answer but…Wow! it was not my intention to offend you in any way. I just reflected on things based on 5 years of experience of using EMC Documentum. No platform is perfect. Things can be borrowed. Thanks for reminding me of the zero client install policy…I just wondered if there was a way even without that.

I am not all suggesting that I see users as mindless drones, I have trouble seeing how you came to that conclusion. However, using the word "complicated" was maybe a bit strong. I was merely trying to see if there were any ways of further simplifying usage of Alfresco not because users are stupid in any way but to make things as intuitive as possible. The concept of check-in/check-out is a novelty for users with experience from file servers only. That means that the usual concept of:
- open file (in application) - make edits - save file (thats it)
is not the same. Especially on a Mac where inline browser view of Office-documents is not possible. I also believe that one of the main strong points of ECM is to make the platform the main place for storing information which in a perfect world only makes your local harddrive some sort of temporary cache for things being edited.

So if you are not to offended I would like to know a little more about your solution with Java applets. That would be an interesting options for computers that our organisation owns and configures.

Re: Having Share know the location of checked out files?

afaust — Sun, 16 Oct 2011 12:49:28 GMT

Hello Alexandra,

maybe I should have added a disclaimer or emoticon to indicate I am not that serious about that topic or have taken it as personal as it may have seemed - or that I do not assume you personally see end-users as drones. The trigger was indeed the claim of "complexity", which I have heard to abundance from customers in combination with trivial aspects like
* remembering where users download files to
* users knowing common key combinations like Ctrl + Click, Ctrl + X or C or V …
* users knowing how to access SharePoint functions within Office applications when attempting to utilize SharePoint for online editing

The argument is always the same: it is not intuitive, desk workers "usually" do not know these features etc. ("usually" often explained to mean "all but the marginalized 2 % of tech savvy employees")
As an individual who lives in the same era as customers or their desk workers, I can not accept the general claims and most of these arguments as they imply that end users are still stuck in the early '90s and generally incompetent when it comes to working with a device they had to work with for more than a decade and can't generally avoid working with at home… I expect at least some effort on part of organisations wanting to improve processes with ECM in terms of educating their employees in the most basic functions required to work within these processes - or improve hiring standards.

Coming back to the main topic…

In order to simplify the checkin/checkout procedure using the web interface, the web application needs some type of access to the clients filesystem. This can be achieved by either generally elevating the privileges of the entire application to allow JavaScript to access it, or having some kind of limited scope sub-application which can be individually elevated. Java Applets offer companies a way to both electronically sign an application and elevate privileges based on the certificate used to sign it.
Using applet technology we:
* added an applet based action in documentlist and -details view for checkout and download of documents
* allowed to open either the document or download location on the client
* tracked download locations per Alfresco document (based on NodeRef)
* used modification dates and hashing to detect changes in tracked documents (when the related document is accessed in documentlist / -details)
* added a second applet based action to upload / checkin any changes

This only requires that:
* organisations distribute a general purpose JRE to clients
* organisations distribute certificates for verifying signed applets (only for security concerns, may be waived)

Regards