Personalized Gadget UI

When attempting to present information that depends on personal preferences, market segments or past behavior one of the major problems the platform has to solve is to be able to gather the data and assemble the page in a reasonable time.

It would be easy for example to build a client based UI that pulls different pieces of content as needed and assembles a page dynamically but the problem with this approach is that as the number of items to be retrieved grows, performance suffers due to network latency.

Another option is to preassemble the result on the server.  The problem is that now the server needs to be able to aggregate and execute different code paths on a per request basis.

Egooge supports both models and achieves high performance by combining these two models. A prototype of a gadget based page that demonstrates these concepts is here.  The prototype requires SilverLight 2.x and although we haven’t provided a HTML version of the gadgets it is possible to create different formats (HTML, Flash, etc.) and all could be supported at the same time.

 These are the requirements we set for this specific gadget based UI:

There should be searchable catalog of gadgets. People can search for a gadget for a specific problem and then added them to their page.

The main page should be assembled at the server on the first request.  This page should not require of secondary roundtrips to present the first view.

The client should be able to download on demand code or layout that is used to extend functionality. Care should be taken not to use this path to create the first view. This is simply a mechanism to asynchronously download features after the page is created.

The client should be able to store settings that alter how the page is created. That is the gadgets selected, the gadgets position and properties that affect how/what the gadget outputs, for example a weather location or a list of stock symbols.

A storage area for complex gadget based data should be available. For example a schedule attached to a calendar.

Step By Step

First a request is made by the client to the front end server. The server determines the shell and starts assembling the page. Making requests to either the content cluster(s) or user clusters for page fragments depending on the type of data. The software load balancers help connect to the correct endpoint.

In this implementation we have two clusters one for site content (standard web pages, weather data, stock, etc.) and another separate cluster, running exactly the same code that is use for user data.

In egooge each user account is managed as a small web site, these allows the load balancers to partition and manage per user load in the same way per site load is managed. It could also gives a user access to the same tools and pipelines used for generating regular content.

After all of the fragments are fetched by the front end server, this might require several roundtrips to the UI clusters, the final page is sent to the client.

To view the Gadget Store use this link:  http://editor.egooge.com/?site=my.egooge.com and then open the pageparts folder.

To view the anonymous user’s site use this link:  http://editor.egooge.com/?site=anonymous.ugc.egooge.com . The document “applications” stores the list of gadgets and related properties.

This link: http://editor.egooge.com/?site=feed.egooge.com point to a site that stores data feeds. In this example, the weather gadget uses the weather data stored under weather folder.