Re: [exoplatform] The new eXo in the market

[Benjamin Mestrallet <benjamin.mestrallet@xxxxxxxxxxxxxxx>]

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