Back to start Norwegian version of the blog


or more precisely: Rich or Poor klients ?

I have this new project at work. We are going to develop a new application One Workplace Web (OWW), which is going to be a common application to our users where the will find all their applications and data. It's supposed to be a rolebase approach where the data and functions you see is based of your role. So management people will have other view data and function than maybe the worker which require more detailed level of data.

We also need to be able to drill down into more details about the data (or functions). So the OOW wil have a static header and footer, and a menu area on left and the main area will have a lot of applications or view or modules. Maybe there will be some widgets on the rigth side, but that's more a guessing from my side. See picture below.

Some other schetches I have done on web 2.0 approach is here :


Then the discussion starts....

 Our runtime environment is WebSphere AppServer ND 6.1.0.17

There is mainly 3 architechtures to address this:

The alternatives:

  1. Portal
  2. Web 2.0 Rich Clients and REST services and Dojo toolkit
  3. Web 1.0

The Portal is discarded mainly due to cost, so the choice is between Rich Clients (Alt. 2) or ordinary web-applications (Alt. 3) with a sitemesh fashion of assembling the total view in every application on the server. It's called a 1+10 approach. See picture below. It spesifices that every module/view is a whole application, that includes the rounding area as it is it's own.

 
So how difficult is Rich Clients ?
How unfashion is alternative 3 ?
How easy is it to have 10+ modules in Web 2.0 and have these very loosed coupled with the other areas in the Layout Container ?
What is the key to success in Rich Clients ?
Its there any other sites that can be referenced to ?
Why should we not go for Rich Clients ?
Why should we try to go for Rich Clients ?
My colleagues claims it to risky, it's to new, it demand too much javascript knowledge, it's just fancy, it's to hard to debug. What can I say to that ? 

This is a blog entry, but hopefully it will turn into a discussion that migth answer some questions.

1 Comment

  1. Anonymous

    So how difficult is Rich Clients?

    It can be very tricky if you are trying to use all sorts of html / dynamic CSS tricks to do the page layout.  If you

    stick to absolute positioning of all the nodes, and use javascript to calculate layout parameters, it's much easier.

    You should also understand the Observer pattern, so that your widgets communicate in a loosely coupled way:

    http://www.java-tips.org/java-se-tips/java.lang/the-observer-pattern-3.html

    How unfashion is alternative 3?

    If you are going to do a new new kitchen, then put in new cabinets.

    How easy is it to have 10+ modules in Web 2.0 and have these very loosed coupled with the other areas in the Layout Container?

    Just use DWR to communicate directly with you container objects.

    What is the key to success in Rich Clients?

    Simplicity and the same things that are key in fat client user interface design.  Also you should be 

    and expert at CSS, javascript, and html, and the Dojo Objective Harness (Testing).

    Why should we not go for Rich Clients?

    Delivery speed and learning curve.  If you have more experience with JSP / JSF / PHP

    then go the safe route first and try to convert the application to a rich client user interface after. 

    If your javascript and dojo experience is limited, you could find that you've used far to much time

    on understanding it, and now your entire project is behind schedule.  On the flip side, if you do it the

    web 1.0 way, you could convert the application gradually to a web 2.0 app.

    Why should we try to go for Rich Clients?

    You'd have to measure and weigh the responsiveness of the application against your

    use case requirements.  Rich clients are the future though, so why not just get on the bus? 

    You're definitely getting on at some point.

    My colleagues claims it to risky

    It's only risky if you try to do it in a big bang approach with a very limited timeline.  Try to do a simple application

    first.  Pick the simplest use case and implement it using both approaches.  Then ask yourself which

    is easier to support over the long run.  Make sure you document the differences in implementation

    approach, and that you are constantly demonstrating how simple it is.  If your documentation is really good

    and easy to understand and clearly demonstrates your workflow and delivery process

    then you colleagues are going to feel a lot better about it

    it demand too much javascript knowledge, it's just fancy, it's to hard

    to debug. What can I say to that? 

    Create the demo with the simpest use case and show it.  Then extrapolate

    out of the experience the methodology and design process you would use for extending

    it.  Make sure you are using the dojo testing harness to unit test your presentation layer

    so that you can demonstrate that there is a clear and simple way to isolate any presentation

    layer issues you may be having.