RE: [exoplatform] The new eXo in the market

["Matthias Klein" <matthias@xxxxxxxxxx>]

Thanks, Benjamin, for your super quick and super helpful reply. After this,
I will take a closer look at the new eXo (have done some stuff with eXo 1
but was not too impressed as everything seemed low level techi oriented back
then)
I think eXo has the potential to be really "big" in business but I think,
eXo SARL may want to think about encouraging one more department: the tool
department providing extremely powerful wizards/templates/tools for
developers.
Take a look at Intrexx. Even my mother could write a portlet for entering
data: just pull the widgets onto a pane, label them and click on "create
portlet". In the easiest case, it will then make a DB-table associated with
the widgets and you can enter data, browse the data, manipulate it...
Takes only minutes but covers many trivial applications. And if you need
more functionality, just extend the code this portlet tool created. I think
something like that would be really good for eXo. 
Or take a look at Synyx GmbH. They have a system based on OpenCms where you
can draw a form in OpenOffice, feed that into their system and it
automatically creates the GUI, a normalized DB schema (not just 1 table!), a
management view and so on based on that.

At the same time, a plugin for easily creating portlets visually (create new
portlet project, draw the structure (how many panes, how interlinked....)
and then visually pull JSF-Widgets (including those from other JSF widget
projects) into the pane where the IDE plugin automatically generates some
part of the backend (backing beans, data connectors, classes...)

As far as I see, this seems to be missing. But I will definitely take a very
close look at your new eXo and its existing components. But I never found
any list of portlets that work with eXo that you mentioned. Where is it?
I am not talking about portlets written by eXo SARL but a showcase of
portlets by 3PD that run in eXo (With screnshot and demo and so on)
Also, an eXo site showcase would be helpful (with screenshots, demos and so
on again) where your customers can present the projects they have done with
eXo. Then people who don't know much about eXo can browse through that
catalogue and just SEE what the RESULTS look like when using eXo (what
others have done with it). If they want something like that, they will ask
for eXo assuming that it can be done again.

Thanks again for your speedy and very encouraging and helpful reply.

Matt


 

-----Original Message-----
From: Benjamin Mestrallet [mailto:benjamin.mestrallet@xxxxxxxxxxxxxxx] 
Sent: Sonntag, 24. Juni 2007 11:27
To: Matthias Klein
Cc: exoplatform@xxxxxxxxxxxxx
Subject: Re: [exoplatform] The new eXo in the market

Hi Mathias ,

Interesting questions, will try to answer them one by one


> The first one is: Don't I lose all platform independence (one of the 
> motives for things like jsr-168) if a 3PD produces a portlet for eXo 
> which seems to require a whole lot of Ajax and exo specific stuff?

You don't need to use AJAX nor eXo specific stuffs to make your JSR
16 run in the WebOS mode, the state of opened windows is now preserved so it
will simply work like SpagoBI portlets in the desktop mode
(http://wiki.exoplatform.org/xwiki/bin/view/Main/SpagoBI). Now note that
there is still a normal page layout mode as before that you could use also.

Nevertheless our model is very powerful and we add some specifications
extensions, up to you to use them or not but it can work without them.

We drive innovation on top of standards!


> The second one: what can I do "out of the box" with eXo? I mean:  
> really DO
> (as in "work")? Some of the built in portlets seem like technology 
> focused proofs of concept or "basic" techi-portlets to me when I 
> compare them to what I am used to from other portals.

The ECM portlets are usable out of the box and compete with the most
advanced solutions of the market like FileNet or Documentum, have a seconf
look it is not techi oriented but really business oriented.  
This is a real hit in our sales.

> If eXo SARL wants to be a platform provider, the valid answer to my 
> 2nd question would be "not too much" - but that's okay for a platform.
> But a
> platform lives only through its content (e.g. Portlets). Is there or 
> will there be a list of available portlets or eXo based applications 
> (both free and commercial ones) of eXo and 3PD?

We are a platform provider but we more and more provide out of the box
portlets that targets generic needs and allow 3PD to build their own
application on top of eXo targeting dedicated markets. That is the case of
SpagoBI and mainly the goal of most JSR 168 portlets providers, the list of
JSR 168 applications is already quite big.

The next horizontal product will be the Collaboration Suite (check  
the RoadMap:   http://wiki.exoplatform.org/xwiki/bin/view/Main/Roadmap)

> My third question was: When I think of our customers (Mainly the 
> management of automotive and logistics companies for which we provide 
> business intelligence solutions) I notice that some of them really 
> want to use portals. But they don't care about technology - so they 
> don't see the beauty portals like eXo may posess internally. All they 
> want to do is get their work done in an integrated way. And I am 
> wondering: why would they want eXo instead of Sharepoint or an IBM 
> portal? And I must say: I don't know. Can you tell me?

If you don't know why are you posting a mail here :)

More seriously, eXo is the only truly integrated Portal and ECM solution in
the Java EE world and it also now provides the most ergonomics portal ever
created. Show it to users and you will see that they won't leave you until
you install it.

Since the announcement of WebOS we have made several demos to large
customers and all of them wants it install even if we will release in
september, so our pipe is really impressive.

Furthermore it is OpenSource and also less expensive than other Java
Portals.

Now comparing to Sharepoint, I have to say I like Microsoft integrated view;
it is basically the same as us including office plugins integration (but we
also support OpenOffice). Hopefully our user interface is now much cleaner
than sharepoint's one. But the mos important reason of not going to a
microsoft world is the use of standards and vendor lockins. You may get the
job done quickly but you are doomed to always use Microsoft products when
you will extend the platform, integration will also bve a  nightmare.


> Let me give you a standard scenario:
> Some management department wishes to concentrate the BI activities and 
> related document management and communicational needs into a portal. 
> They want 2-3 transactional applications (managing some data stored in 
> different databases and data warehouses), document management, user 
> management with profiles and means to communicate, they want 20 
> parametrized reports (it depends on their role which report they are 
> allowed to see and what parameters can be used) with export to Excel 
> and PDF and a print function and they want 12 100-page Powerpoint 
> reports automatically created in different intervals with different 
> parameter sets and have them sent to over 1000 people by email and as 
> well stored for later reference and made accessible based on the user 
> role through the document management.
> They want
> all of this to happen in a portal so they can later plug new 
> applications into it that accesses the same data and fully integrates 
> with existing stuff. And all of this pronto.
>
> Okay, if I choose Sharepoint for this, I get the portal, user 
> management, role based user mgmt (which integrates with the existing 
> corporate directory), several communicational means, the document 
> management (with versioning and such), the mailing list and contact 
> list management, outlook synchronization of contacts and calendars and 
> this type of stuff out of the box. Takes me a few days to install and 
> configure but then we are good to go.
> Now the developers open their Visual Studio and create a new WebPart - 
> assisted by a wizard which does lots of the heavy lifting for them.
> A few
> mouse clicks later they have created several datasets connecting to 
> the different data sources they need. Then they write the 
> transactional application (usually simply by creating new dialogues, 
> pulling widgets into the pane of which many are databound - so there 
> is no need to write any additional source code to make dialogues that 
> allow data entry and data retrieval. Shortly such an application is 
> done (Example: our last application with 50 data management dialogues, 
> validators, role based access... Took 2 developers 2 months to write - 
> including the specification, test, deployment and documentation). 
> Okay. Now we have the 2-3 transactional applications.
> Now let's tackle the 20 parametrized reports. For that I open my 
> Visual Studio, create a new reporting services report, define the 
> dataset and get the wizard to create the required mix of tables, 
> graphics or pivot tables (with or without grouping, drill-down or 
> parameter based handling of widgets). To have such a report up and 
> running usually takes 1-3 days - depending on its complexity. Export 
> into several formats such as Excel and PDF comes out of the box. Print 
> function as well. And depending on which way I write this report, the 
> parameter page is automatically created for me (I usually write my own 
> because then I can control it better - but that doesn't take long) Now 
> about the last part: the automatically created multi-page PPT reports.
> Using a PPT library in Visual Studio that's easy. Just create the 
> dataset for each slide, use templates for standard diagrams or write 
> own diagrams (consultants can be VERY creative when it comes to 
> inventing new diagram
> types!) by configuring standard slide items or by writing C# code 
> using the API of the PPT library. In average, per slide you need 1-3 
> days as well.
> Simple ones containing lists or tables or standard diagrams can be 
> finished within very few hours or even less.
> The document management handles the storing of created slides, the 
> report factory handles the schedule-driven creation of these reports 
> and the list management sends the reports to all subscribers.
> After only few months this entire application with all reports and 
> transactional application (in other words: large portions of the 
> business processes of this management department) is up and running.
> We have done all these things mentioned with Sharepoint so far and we 
> appreciated the many out of the box functions and the huge amount of 
> IDE integration (Visual Studio has really powerful wizards and 
> templates for about everything) so developing new functions is really 
> easy and quick (which is the most important thing).
>
> Now I am wondering if and how I could have done the same (or more) 
> with eXo in shorter time?

The result would be more impressive in eXo P2 and ECM2 and using SpagoBi
(embeded Jasper for the reporting) for the BI part. And a few months for
that looks long to me :)

and when eXo CS will be ready I don't see what is missing from what you
describe :)

HTH

Benjamin

>
> Thanks
>
> Matt
>
>
>
> --
> You receive this message as a subscriber of the 
> exoplatform@xxxxxxxxxxxxx mailing list.
> To unsubscribe: mailto:exoplatform-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws