My customer is asking me if they should use UCM console as end user UI or should make new UI running on wls by leveraging UCM api(RIDC, for example), we researched some topic on this, following is conclusion:
1. UCM console can be customized with HCST/P/F, but need skilled expertise on it, big change might make it very difficult if not impossible.
2. Customize components is another way to do it, but still need deep expertise.
3. Using RIDC/WS is suitable for java programmer in a "open" architecture.
What else should be considered on this? what is the other customers choice?
First of all, this choice is not either/or.
In the end, it will be your customer (with your assistance) who should decide which way to go.
What you should consider are your use cases and the enterprise architecture. I also advice to follow the principle "change as little as possible" (once I heard that the most successful ECM solutions are those where a user does not even know that she is working with one) - if your customer already has a way how to manage documents, this way suits end users and serves the purpose, you should try to use it (e.g. people might be used to store documents in hierarchical folders on a file system; there might be a central application or a portal, etc.). Of course, sometimes it is impossible, and sometimes your customer might want to compromise in order to minimize the costs.
Jiri has laid out the options and considerations quite nicely and accurately (as usual, has provided solid advice). I'd just throw in the WebParts for Sharepoint as another option.
In looking at the customer's points of consideration, I can't help but to wonder why this product was considered for purchase if there is so much angst over custom components and dynamic server pages. Every product has its proprietary angles. Content Server (UCM/WCC/ whatever you want to call it today) is actually quite flexible in how it can be manipulated, but you do need a working knowledge of IDOC if you want to change it via the provided interface. This would be true of any other way that you choose to manipulate it - does the customer actually have Java developers in-house? .Net? PHP? CGI/Perl? (If you don't like the interface, then it's relatively simple to write your own, and just call the services from Content Server. Somebody still has to do the work in your chosen language, and have an understanding of how services work.)
Using a strict RIDC/WS path does not guarantee that you will not need other custom services written (back to those pesky components again, since the existing service may not be sufficient, or you just need something else.) The biggest mistake I see newbies attempt with Content Server is trying to immediately jump into writing Java without knowing what already exists in the core system. It makes the job much harder than it needs to be, because most of the stuff typically being contemplated already exists in the system.
If the customer has spent x hundreds of thousands of dollars on the product, but decides that skimping on training the staff or the occasional consulting engagement is a way to recoup the cost, then they will likely be just as unhappy with the end result as they were with the previous solution that initially prompted the purchase of new software.