Last updated by Joss

Widgets are the most powerful element within any CMS style environment and have been included in Elgg as one would expect.

However, the implementation of widgets is uneven with some of the more standard uses for them being implemented in third party plugins such as the customisable index layout.

Using widgets for customising elements of a site really should be a case or either they are used for everything or they are not used at all - quite obviously I believe in the former, not the latter!

As an example, Widgets are currently used for the layout of the profile page. Strangely, however, the one item that is not a widget is the profile box itself. It would make far more sense if all the elements of that page were widgets - the profile photo, the about me box, the additional profile fields set up by the administrator and even the user menu of links to edit the content.

Widgets and Pages

Widgets could also be linked to page functionality where they can be used to display page content within another page. This would replace the Free HTML widget, in effect. The reason for this is that all custom HTML information belonging to one particular owner ends up in one place; a user should be able to click on a link that says “my page content” and see a list of all html content that they have written across the entire site, including widgets. That gives a huge amount of control and increases flexibility for how to use html content.

(Note: their could be some issues when it comes to including page content within a widget if that page content already contains widgets! Though this may not be an issue at all.)

Page Framework Templates

Both Liferay and Google Sites use page templates where you can decide what you stick where.  They offer options such as three columns across, or little, big, little row and so on. Generally, liferay’s version is more powerful as you can see the content while you rearrange the page. Also, there is a straightforward system for adding additional templates by the administrators.

This kind of approach allows users a large range of options for customising their pages rather than limiting them to one particular approach.  If these are developed as part of the core, then these templates can be associated with any page, whether that is a profile page, a group discussion page, or a gallery page. Adventurous third party developers may wish to change the display side of their plugins  into a series of widgets so that they can take advantage of this flexibility.

Customising the Widget Container

Another function which various widget based systems use is to be able to customise the widget container on an individual basis.  Such customisations are normally limited to borders, backgrounds, transparency and enabling or disabling titles and so on. The default style of the widget would, of course, be determined by the overall site template or group template (if that is different).

Plugin Developers would obviously use the standard widget container and would not be able to overide its look and feel from the plugin.

Another setting that would be default for all widgets would be privacy - roles would be taken care of by which ever plugin is contained within the widget container. This would allow a user to make content private on a particular page, or limit it to a group, where the default state of the content is public or another role more open than the one being chosen. This does not overider other instances of the exact same content witin other widget containers, and nor does it allow for something to become available to a wider audience than the original settings - it the original is confined to a group, you would not be able to make it available to logged in users.

Again, this ramps up the options for the user enormously and gives the site developers very clear core CSS to work with.