nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Future plans for Alfresco Explorer?

targa2000

I heard somewhere that it will be unsupported in the future. Is this true?

Find more posts tagged with

Comments

mrogers

Well, on one level of course the statement is "true". In the year 5.5/Apple/26 [Dr Who - End of the World] It is unlikely that Alfresco will still exist :roll:

Perhaps a more useful answer is that Alfresco Explorer is supported now and in all planned releases and will be until it is obsolete and no-one is using it.

targa2000

Okay, good to know. So, I guess what I heard were just rumors.

mikeh

Okay, good to know. So, I guess what I heard were just rumors.

Where did you hear them? It would be a good idea to correct the source.

Mike

targa2000

some people I am working with on a project. It might become an issue in the following weeks.

targa2000

They are arguing using Share rather than Explorer because Explorer is no longer supported. But I'm finding that while it is possible to develop with Share and it may be the future of Alfresco, there are a lot more capabilities with Explorer at the moment. For what our client needs and wants in their timeframe and budget, Explorer seems to make the most sense. Another project using Share ran into a number of problems.

mrogers

The statement "because Explorer is no longer supported" is not true.

esource

In the book "Professional Alfresco: Practical Solutions for Enterprise Content Management" by David Caruana, John Newton, Mike Farman, Michael Uzquiano, and Kevin Roast, on page 8 it says

"It (Alfresco Explorer) is currently being phased out in favor of Alfresco Share."

mikeh

Yes - no new features are planned to be added to Explorer.

However:

The statement "because Explorer is no longer supported" is not true.

The focus for the future is more on APIs rather than clients. We'll still develop Share (and support Explorer), as it often drives the API development and direction, but people often prefer to roll their own UI using our APIs rather than customising our clients to fit their needs.

Thanks,
Mike

invictus9

Yes - no new features are planned to be added to Explorer.

Hmmm. Well, that's too bad. Share is at least one generation in basic functionality behind Explorer, and it also does not scale as well as Explorer does.

mrogers

Well just to complicate things :twisted: although no new Explorer features are planned at the moment … That does not mean that there won't be any. For example the group admin console in Explorer was overhauled fairly recently. And there's ongoing improvement and bug fixing happening all the time. And as you point out Share does not yet have all of Explorer's functionality.

mikeh

Hmmm. Well, that's too bad. Share is at least one generation in basic functionality behind Explorer, and it also does not scale as well as Explorer does.

Isn't that more of a reason to concentrate on Share development and make sure all of Explorer's functions are available via remoteable APIs; rather than force people to use Explorer?

I'm not sure what you mean with the scalability comment - Share can be deployed on (one or more) separate Tomcat servers and distributes more processing to the client's browser rather than the Repository. Did you have a particular use case in mind?

Thanks,
Mike

invictus9

I'm not sure what you mean with the scalability comment - Share can be deployed on (one or more) separate Tomcat servers and distributes more processing to the client's browser rather than the Repository. Did you have a particular use case in mind?

I didn't mean performance scaling. I meant enterprise scaling with the number of people, functional areas and sub-organizations. I work at a small university with a number of colleges and business units. Many functions span the colleges (admissions, administration) and many are particular to a business unit.

Administrative scaling: You are currently an administrator or you aren't. If you are, you can do everything; if not, then you can only manage documents and spaces. There is no mechanism for delegation, scoping, or range. This is an issue with Alfresco in general.

1) All administrators have access to all category tags. You can't carve out a subset and allow only some sub-trees to be administered by a sub-group, except by gentleman's agreement.

2) All administrators have access to all users.

3) All administrators have access to all …

Site scaling:

1) Share does not have sub-sites. Strongly related sites, such as all of those run by the Financial Services Division, are tied together by some artificial, unenforceable, funky naming scheme, such as a name prefix – fsd_students, fsd_bookstore, fsd_whathaveyou. Considering that those sites should also be further partitioned in larger areas, and the funkiness just gets worse.

2) The Share interface does not out-of-the-box support delegated rights for creating or naming of sites. Consequently, anybody can name a site anything, perhaps colliding with the use of a different business unit. Namespace management then also requires that you get the name right the first time.

3) A typical use for a Share site is a working committee, such as College of Law Student Retention Committee. We have, perhaps a thousand such working committees. So, our naming convention would be that col_studretention is the site name. Over in the College of Education, someone creates coe_studentretention. The Department of Anatomy has its committee for retention, because of recent retirement of a well-loved professor (fictional), so it would be com_doa_studretention. And on and on and on, for thousands of committees, task forces, projects, working groups, etc.

How well does Alfresco fare with thousands and thousands of top level spaces? Not very well, performance starts sucking after a bit. That is why file hierarchies get introduced. Namespace management is only one of the reasons.

Multi-tenant is not an answer either. It partitions the problem but in the wrong way.

mikeh

There's some interesting stuff here. Could you raise this in JIRA please (tends to get lost on the forums otherwise), so I can make sure our Product Manager has visibility of these issues.

Thanks,
Mike

invictus9

I have added two tickets:

https://issues.alfresco.com/jira/browse/ALF-3582
https://issues.alfresco.com/jira/browse/ALF-3583

esource

I received an e-mail with the following comment supposedly from someone who works at Alfresco:

The book is right, but Alfresco Explorer won't go away for a long time yet.
It is getting no further development, just bug fixes.

We are not sure yet how many development cycles it will take to completely
replace Explorer with Share, probably another 2 product release cycles, so
3.4 and then 3.5. At that point everything should be set to deprecated
Explorer.

mrogers

Well someone probably needs to be more careful about what they are saying.

Up to the last sentence agrees with what has already been said on this thread.

But

At that point everything should be set to deprecated
Explorer.

In my opinion there's no way Explorer will be deprecated or "unsupported" in two releases' time. In order to deprecate Explorer, first Share would need to reach feature parity with Explorer and then all the paying customers need to migrate to Share. I don't imagine either of these happening any time soon.

esource

Well someone probably needs to be more careful about what they are saying.

Up to the last sentence agrees with what has already been said on this thread.

But
At that point everything should be set to deprecated
Explorer.
In my opinion there's no way Explorer will be deprecated or "unsupported" in two releases' time. In order to deprecate Explorer, first Share would need to reach feature parity with Explorer and then all the paying customers need to migrate to Share. I don't imagine either of these happening any time soon.

Thank you for the information and for correcting what this other person says. But I'm wondering, is there some type of official statement or 'roadmap' from Alfresco that defines Alfresco's plans for its software?

mrogers

The roadmap is here : http://wiki.alfresco.com/wiki/Roadmap

Project SWIFT is reasonably understood now. And more details will probably be added in the next couple of weeks.

The next project, CUMULUS, is far more vague although one or two bits of it are in progress.

Any further out than the next couple of releases is in people's (Alfresco's and the communities) heads. Yes there are lots of ideas, proposals and possibly prototypes but it is little more than "wish list" that far out.

alexr

Ok but what about this entry on the 2010 Roadmap?:

Enhancements for 2010
Improved usability via new Document Management Client for the Alfresco Repository

It clearly addresses a "new" Document Management client (Alfresco Explorer alternative?). Or is Alfresco Share
already being addressed as the "new"" Document Management client at this point?

Guess what it boils down to is if and when will there be a completely Surf (and perhaps even partly CMIS?) based Alfresco Document Management client that can be used as
a real alternative to Alfresco Explorer (jsp based)? That means containing all or almost all functionality of the jsp based Explorer.

mwildam

Anyway, I did not find a really good Client from usability point of view.
They either offer just the very basics and miss a lot of features or there are usability issues. I mean for example the editing of details in the Alfresco Explorer is soooo annoying (jump back on top after each click, long way until a few items are selected for categories etc, ….).

I wrote a pre-profiling client for our customers that simplifies imports (and then the details are basically never edited again because only PDFs archived).

Share looks a little simpler but there are also plenty of issues - even although at least offering a preview (commercial ECM systems have that since many years - although I admit that finding viewer components for all the different formats is not easy).

Is there anyone in the real world putting those clients into the wild for being used by an end-user?
All people I talk to who somehow have heard of Alfresco or have to do with it, tell me, that Alfresco only used in the background…