Alfresco Share is a team-centric collaboration tool. It’s really cool and our clients have been reacting very positively to it. When customers see the AJAXalicious UI, a common reaction is to want to take the next 5 projects on their list and “do them on Share”.
In cases where the functional requirements closely resemble team collaboration, that can be a great choice. In others, it’s an abuse of the tool. Just like a lot of things in software and life, just because you can doesn’t mean you should. (Remind me to tell you the story about building a tennis court reservation system in Lotus Notes some time).
Anyway, let’s assume you’ve got a set of requirements that reasonably resembles team-based collaboration, but some of Share’s tools (wiki, blog, document library, calendar, and recently, bookmarks) don’t work exactly the way you need them to. I’m not talking about adding new, self-contained custom components. This is specifically about customizing the out-of-the-box Share components. With that in mind, here are five areas where even simple Share customization efforts could take longer than you might think.
Custom Metadata
In its current incarnation, if you have custom metadata you want to display when looking at document detail, that’s code you have to write. Alfresco’s Mike Hatfield said, via Twitter, that the 3.2 Forms Service will make this better, so that’s good. If your Share sites contain simple documents that use only out-of-the-box metadata, this won’t be an issue for you.
Custom Workflows
Currently, in Share, there are a couple of places where the jBPM workflow engine is used. First, when you invite someone to a site, that kicks off a workflow. Second, you can “assign” an advanced workflow to a document in the document library.
The first issue is that the workflow submission dialog includes only the two out-of-the-box, document-centric workflows, “Ad hoc” and “Review and Approve”. It won’t show any custom workflows you’ve deployed. The workflow modal is not inspecting the workflow UI configuration like the web client does, so even if you got your workflows to show up in that list, the form wouldn’t have the custom workflow metadata you need to launch your custom workflow properly.
When you log in to Share, you’ll see a “My Tasks” dashlet. This gives you hope that maybe that dashlet could manage tasks for any workflow. Unfortunately, it only works with the “invite user” workflow and the two document-centric, OOTB workflows.
Long story short, Share isn’t set up to work with custom workflows out-of-the-box. If you’ve got custom workflows that need to work in the Share context, you’ll need to write your own dialogs for launching the workflow and your own component for managing workflow tasks.
YUI Bubbling Events
Share makes heavy use of YUI Bubbling Events. This results in a great end-user experience–the Share components communicate with each other and refresh themselves via AJAX without page refreshes. But it does mean there’s a bit of a learning curve when following the same pattern to implement your customizations if your team has never worked with the bubbling library before. It can get kind of thick in places.
Incidentally, all of the YUI stuff is part of Share, not Surf, which is the framework used to build Share. If you’re building your own Surf app you’ll need to grab the YUI libraries (or any other libraries you want to use) yourself. It’s the same for the Flash pieces (multi-document upload, document preview). It keeps Surf light, but if you want to incorporate that kind of functionality into your Surf app, some assembly will be required.
Code Sprawl
In Share, every module has as least one JavaScript file. For example, the Document Library has six different JavaScript files weighing in at about 136KB. Sometimes what should be a simple change (adding a button, creating a new modal) requires changes to every one of those files. This combined with grokking the bubbling events translates into potentially lengthy development cycles for stuff that you wish would be quick.
Theming
The main CSS file for Share is in the themes directory. But changing that will only affect the global dashboard header and the site dashboard header. If you want to change the theme for everything in Share, including individual tools, you have to change each tool’s CSS file. Those CSS files live in the “modules” directory. It would be nice if it were easier to implement site-wide or global themes.
Adding your own Components/Tools
The impact of these issues are lessened somewhat if you are adding your own components or tools instead of customizing what’s already there. It’s easy to write your own dashlets that show up on the global dashboard or the site dashboard. And with a little work, you can write dashlets that talk to each other using YUI Bubbling Events, just like the OOTB dashlets. The area for improvement is in skinning, configuring, and extending the out-of-the-box tools.
Share Your Thoughts on Share
There’s no doubt that Share is a cool application for team-based collaboration. I didn’t expect it to be configurable to the Nth degree right away, and we may be pushing the limits of its intended use. I’m curious to hear from others who have been tweaking the app: Have you worked through these issues? Are there other examples of specific extension points Alfresco could address to make your lives easier?
Great article Jeff! And yes, we have been facing the same issues here. Especially with the workflows, custom metadata and themes, that are the most common request from our clients. To us, one thing missing is a component to manage lists… for every team collaboration project, lists are always a big thing(task list, risk list and etc..). And I would like to have standalone Tasks, not having to tie that with a document. We are starting to research that, if we should customize what they have now, or build something totally different. Any opinions on that?
“Lists” is something that SharePoint has that’s missing from Share so I imagine you’ll see it show up sooner rather than later. Maybe it will be part of the new form service. (I have no idea–I’m just thinking out loud here).
You should be able to add your own tasks/lists component pretty easily. You should follow the same pattern as Alfresco and store your data in a folder named after your custom component in the Sites/Sitename folder. You can get a reference to that folder from the SiteService.
My advice would be to check with Alfresco before you do a heck of a lot of work–you may want to do something quick-and-dirty if Alfresco’s got something similar on the near-term roadmap.
Hi Jeff,
Thanks for you article. It’s a really nice summary of pittfalls that one can encounter when implementing Alfresco Share.
About the workflow part: How do you feel Intalio fits in? Do you see this BPMS suite can be integrated with Share, as integration with the Alfresco Explorer web client is already there?
Regards,
Kees van Bemmel.
I think the easy part of that type of integration would be the UI piece. You’d be writing Surf components that would either call Intalio from the Surf tier or your Surf tier would talk to the Repository tier and it would make the call to Intalio.
The tougher job would be a deeper integration. Like ripping out the jBPM engine and replacing it with Intalio. (Or not necessarily ripping out jBPM but adding Intalio as an additional workflow engine).
So I guess it depends on exactly what you need to do and how you want to integrate. I like the jBPM engine, but I’m willing to bet a fair number of people have done work to integrate Alfresco with alternatives. You might check the forums to see if there’s any discussion of that over there.
Jeff
Hi Jeff
Great summary, I wonder which version you’re using for reference here?
** Custom Workflows
Yes, this is definitely an area for improvement. We were trying to keep the My Tasks dashlet generic as far as possible, but clearly this is an optimistic view. We’ll be looking to improve this dashlet later this year. We’re conscious that the workflow options provided by the Document Library are also very minimal, however we are waiting on some key pieces given to us be the new Forms Service before we can refactor this – and potentially many other – areas.
** YUI Bubbling Events
The Bubbling event library has been a life-saver in places; and many parts of Share would be much more complicated without it. I agree it’s a steep learning curve to unravel some of it’s more esoteric parts (the event handling based on DOM class name code, for example), but overall I’m confident that it’s given us a cleaner implementation than “classic” event handling.
** Code Sprawl
We’ve tried to keep components in Share as separate as possible for future reuse. This has resulted in perhaps more client-side files than we’d have liked, but I do have some ideas to improve this in the future (e.g. through selective build-time merging).
You may also be interested to know that you don’t need to edit any of the client-side JavaScript files, either by extending the existing classes or using the YUI helpers to override them. Have a look at the wiki example “Custom Document Library Action” http://wiki.alfresco.com/wiki/Custom_Document_Library_Action for the former and the “YUI API reference” http://developer.yahoo.com/yui/docs/YAHOO.lang.html for the latter.
*** Theming
The reason I asked about the version earlier is that one of our Engineers has greatly improved the theming for V3.1. Colours and fonts have been pulled out of individual .css files into presentation.css, which should enable basic corporate-style theming. We’ve still to consolidate the images used by components and move them into the theme-able area, but believe only the most determined theme author will replace these.
It’s always good to receive this constructive feedback as it helps us steer the Alfresco ship in the right direction. I’m encouraged to see we share the same thoughts about how Share can be improved for partners and integrators.
Regards,
Mike
Hi Jeff,
we’re experiencing the same difficulties in an Alfresco Share project with extensive customization: adding new functionality (new dashlets) is easy, customizing what’s there can be very tricky.
Some stuff is still sorely missing indeed.
I would love to see Sharepoint’s customizable lists and datagrids in Share too. We’ve been thinking about writing dashlets that offer some of the functionality of the advanced roll-up lists (from Corasworks) that I have used in Sharepoint projects, but we’re waiting until Share has matured a bit more.
Cheers,
Roeland Hofkens.
Mike,
Thanks for the detailed response. This is helpful.
Regarding the version, this feedback is based on 3.0.1. I’ll pass along the 3.1 theming improvements to the client team.
Jeff
Thanks Jeff. Once again, you are right on point. We’ve been prototyping a tool by customizing Share, mainly to leverage its collaboration features. Having struggled with modifying document library, for instance, our current approach is to add new components. However, we want to leverage workflows and integrate things like discussions with our own content model. So thanks for the heads up on these challenges. Climbing the YUI, bubbling and other learning curve has been challenging. However, I agree with Mike, the separation of files is sprawling, but appropriate for extensibility. Tools would help. I hope we all continue to Share our learning experiences.
Hello Jeff. Nice as usual 😉
Do you think that it is possible/easy to customize “Review & Approve” workflow to have one person to perform the “Review” and another one to perform the “Approve” ?
Thanks
JMi
Certainly. You would have to decide how you wanted to make those task assignments. Right now the OOTB Review & Approve workflow lets the workflow initiator make one user/group selection on workflow start. If you are going to split the workflow into additional steps, you will either have to modify the model and web client config to allow the initiator to specify a user/group for both the “review” and “approve” steps, or you could let the performer of the review step pick the approver, or you could just hardcode either (or both) into the process definition.
Jeff
Hi Jeff,
Thanks a lot for providing valuable information on share. This is really useful stuff.
We tried working with blogs and discussions in share. We faced following problem. May be you could give us proper pointers on what we could have missed out.
Following is what we have done.
We created a site by using the admin privileges. Also created couple of users through alfresco web client. We are able to log on to the alfresco share application with those user ids as well. Then we invited couple of users to the site created by admin (with admin login). With admin user id, we also created a blog and a thread.
Then we logged in with these invited user ids and tried to add comments to blog and threads. But, when we click on read of a blog we don’t see the comments text area. In fact there is nothing for the user to add a comment. We tried giving different prvileges (like contributor, collaborator etc) to the invited users, but we are not able to add comments to a blog or create a blog. Same thing with discussions.
Also the create blog and create topic(discussion) links are disabled for these users.
We tried to create the site with these user ids. The user who created the site is having these privileges. But the users that are invited to the site are not able to do the same.
Are we missing anything? It seems that we have missed some basic configuration as these are basic things.
Regards,
Pratap
Hi Jeff
This may not be related to the above discussion but does have to do with customising Alfresco’s content model.
I was wondering whether you may provide further insight into Chapter 3 of your book Alfresco Developer Guide?
Under the section Properties and Property Types in Chapter 3 you mention that the content type Whitepaper will inherit the campaign property from it’s parent type MarketingDoc. I have downloaded the sample code and extended a fresh install of Alfresco 3.2 with your custom content model. Yet when i add new content of the type Whitepaper, the only property inherited is the association.
Admittedly i have not tried this in any earlier version. Do you know if Alfresco 3.2 is backwards compatible with the example you have provided?
Thanks in advance
George
Hi Jeff
I think I found an answer to my previous posting in the comments on this blog https://ecmarchitect.com/archives/2007/06/09/756 – in particular your reply to Tony’s posting.
I am slightly confused however by the inheritance provided by the content model. After reading your reply i wrote a simple script to set the campaign (seeing as it isn’t exposed to the web client) as follows –
document.properties[“sc:campaign”] = “Social Shopping”;
document.save();
I executed the script against a Whitepaper content type. I then previewed the item using the doc_info template and the above property was correctly reflected. However I then executed the same script against a Someco Legal Document type expecting some sort of exception, yet the preview revealed that the document quite happily accepted that property.
This seems to break the inheritance model provided by the content model. Is there nothing to enforce this other than developer discipline?
Thanks
George
George,
Yep. I’m not sure why they don’t check that more strictly. It also works with aspects–you can set a property that belongs to an aspect even if the aspect has not been applied. And in both cases, those properties are indexed and searchable by Lucene which I think is even more bizarre. Of course if you do a search based on the type, an ancestor type, or the aspect, you won’t get a hit, but I still agree with you: Alfresco should throw an exception if you’re trying to set a property that’s not defined as the document’s type or in any of its aspects.
Jeff
Hi Jeff,
I am new to Alfresco Share 3.2. My client requirement is like parent-child site concept.
Example:
Parent site :A
Child sites : B,C,D
Each child sites contains sub sites like,
B contians B1,B2 sites,C contains C1,C2 etc.
Is it possible to create sub sites under site ?
Can you please explain?
Thanks in advance
Varun
I’m pretty sure this would require a customization because out-of-the-box, sites are in a flat hierarchy. Every Share site has a corresponding folder in a root folder called “Sites” in the DM repository. My guess is that the easiest route to implement something like this would be to leave the physical storage of the site folders as-is, and then use associations to keep track of the parent child relationships between sites. You’d then only need to enhance the Share UI to let the Site hierarchy be traversed.
You might want to Google around the wiki and the forums to see if this has ever been mentioned as a roadmap item. Seems like it would be a common feature request.
Jeff
any ones help to me ?
about alfresco uses ?
i need help about alfresco using .
how to use alfresco in my project .
and how i can send and received email from alfresco .
how i can create website in alfresco .
and how to share document .
ravi,
Sounds like you need to spend some time with the official documentation, the wiki, and the forums.
Jeff
How do I edit the metadata of a file after the upload?
Edilson,
Using Alfresco Share, click on the file name then click the pencil icon next to the properties list. This will bring up a form you can use to edit the metadata.
Jeff