UI presentation control across many discrete web apps

Question

Our company currently has 7 separate large Internet facing web applications.
They all have the following

• have different look and feels that represent the branding style of the time when they were built
• have different UI and backend frameworks based on when they were built
• separate teams supporting and developing each
• built over different timelines - some up to 10+ years old

This presents the following problems

• New brand changes need to be applied separately - This is very costly and does not usually happen
• Accessibility issues or other broad bugs have the same problem
• New Style and Interaction guides need to be applied separately - again same problem

I'm looking for techniques others have employed in a similar environment so that new applications can be separately built and maintained with the client UI still centrally managed without being a bottleneck. I was thinking about taking the same approach as white labeling where master HTML/CSS/Javascript templates are produced and versioned. It would then be up to each team to take an updated version when it becomes available and incorporate during build. The risk of it never being updated is still there. I'm guessing this is not an unusual situation for large corporations (we're in finance). Can you share with me your techniques and technical frameworks you've used?

Also interested in any literature (books or websites/blogs) on the topic.

Answer 1

You thought right, master Javascript/CSS resources are the way to go. They can be easily updated, and you don't have to retype common functions, etc. If you have a sort of library such as script.aculo.us or jQuery, functions that are frequently used can stay up to date while saving bandwidth.

For example, view-based applications (e.g. games, complex programs) load and display different "views" that may contain interactive HTML, images, and more. The actions of transitioning, showing, and transferring between views are pretty much universal and only have to be declared once. This also makes it easier to develop and focus more on the content rather than basic coding that is repetitive. Another handy technique is incorporating a common "structure" throughout the apps; things like icons, sounds, and views can have a predetermined "place" in the package/directory that are simple drag-n-drops. In my experience, bottlenecks aren't really a problem when dealing with simple javascript files < 300kb.

The only trouble exists when server-side operations get involved. They are absolutely necessary, especially for finance, as well as games (logins, accounts, high scores). However, trying to create convenient universal server-side scripts are not a good idea. When a server has to filter several thousand scores (or accounts) and has other functions as well (that are also simultaneously requested), they get slow and cause bottlenecks which in turn slow everything down. The trick here is to have many low-function scripts that perform tasks efficiently, that can still be multi-purpose.

Basically, creating and maintaining lots of applications demands lots of organization - but only at first. Once you've got something to build on, you're on a roll.

Answer 2

I think Sitemesh will be a good tool for you to look at. This allows white labelling of multiple sites which you can control from a single Sitemesh web app.

See the Visual Example diagram on this link http://www.opensymphony.com/sitemesh/