This is a non technical description of a possible future version of Elggm or at least the installation of that future verison. This is my ideal system, perhaps, pulling together much of what I have explored.

I am a great believer that if you want to create or alter something you have to have a picture in your mind of the place where you want to end up. This should not be a technical image, or include any lines of code, but should be a good old "artists impression" of your destination. Architects have used this system for many years - even thought the final building will be stuffed with engineering marvel, it is the image, the promise that is shown in the picture that will sell the idea. So, this is my artists impression.

Obviously, Elgg currently does not work this way, but it could!

Download

Elgg would be available in two versions:

Server wide Core System

A core only system that would be adapted for server wide deployment. This would be a version that could be used across many domains and would require a server wide administrator. This is beyond what the multi version of Wordpress is and possibly more closely resembles WHM from Cpanel.

In this version, “instances” of elgg could be created and associated to a specific domain name and even a specific IP address. Core plugins would be administered centrally and the superadmin would be able to determine which plugins would or would not be allowed for use by the admins for the individual instances. This version would be particularly suitable for large corporations that require multiple versions managed centrally.

However, this document is not really about this version - I just threw that in to the mix for fun!

The Elgg Community system

This would be the main version of Elgg, installed and run, as now, as a stand alone version. Download would be as now as a complete version, or as a lightweight install script version that downloads most of the files direct from the web site. This second version may be particularly suitable for highly customised versions where the admin only want specific functionality.

Installation

Installation would be very similar to now, however having finished the initial installation complete with database population and a username and password generated for the super admin, the new Super Administrator would be taken to a new configuration system.

Choose a Community Type

This section offers administration or configuration templates that define what sort of site this will be. None of these are set in stone, they are just configurations to get the system going and this should be explained on the page. One version should be a "if you don't know, choose this one" version. Proffered versions could include:

• Closed Company Intranet - A basic set up with basic profiles (name, description, department, location, no blog, no message board, personal document manager), Groups and sub groups allowing basic project pages that can be linked into a management system, front end news and employee information, employee list etc. This system is closed completely to the outside world except for a login if it is on a publicly accessible server.
• Closed Club Community - Again, closed to the outside world with the "public" option removed, but other than that a pretty full basic system
• Open Community - a system where anyone can join and the contents of the community can be read by every one and picked up by search engines.

Others could include versions where only admins can create groups, or where blogs are not available, but more emphasis is placed on forums and so on. These configuration templates can include third party plugins which would be downloaded and installed as part of the installation. There would be an option to browse community configuration templates in remote repositories as well as uploading commercial ones. Obviously, we would need someway of downloading these templates from an Elgg installation to create them in the first place!

Site Themes

The next screen would offer the chance to choose from a range of themes. Again, it is made clear that these are all customisable and the admin is encouraged to choose one to get them started - if in doubt, choose a nice simple one. There should be a range of slick corporate ones in there as well as the more colourful community ones. As with the previous configuration templates, there is the option to browse repositories or even upload a theme.

Site Details

The last of these screens asks for some basic site details:

• Title
• Meta Keywords
• Meta Description
• Offline Message
• Super Admin full name and details

These are mandatory with the exception of the meta data.

At the end of the screen a button invites the admin to Launch Site. All the settings are saved and final installation takes place including automatic downloading and installation of additional plugins. At the end of that process the admin is taken to the administration screen where he/she will need to logon.

At this point the front end of the site is OFF LINE and the offline message would be displayed to anyone viewing the site.

First Chores

Although the site is offline, the admin has access to the front end. They are encouraged to browse through the system to ensure everything is working as intended. If not, er ... not sure at this point!

Once they are fairly certain they know what they are up to, they are given a quick tour to fine tune settings.

Administrators and Roles

The first stop is to add any additional administrators and assign them roles. These would be the standard roles associated with moderation, editorial and so on, also any additional site wide administrators. They are also given the ability to create custom roles, giving these new roles specific permissions on a plugin-to-plugin basis and to edit the existing roles (with the exception of the Super Admin).

Front End Group

This is the group that controls the landing page of the site. It is automatically created on installation (even if groups are not made available to other users as part of the site configuration) and the group admin is by default the Super Admin (the super admin can appoint a separate group administrator for this group who does not need other high permissions). It is by customising this group that the landing page is created including additional pages like terms and conditions and so on using the Page system. In all intents and purposes, this is a normal group, it just has slightly different permissions and a different default layout. Like other groups everything is highly customisable, but it sits within the chosen overall site template.

User and Registration

Here the admin can customise how user profiles should look, what plugins they should include, what fields are included (and which are part of registration) and how registration works. Most of this will have been created by the Configuration Template, but the admin is free to add additional customisation or change any settings. The admin also has the opportunity to arrange the default profile widgets - though these can be changed later. Note: Default profile widgets only effect users that register after any changes have been made, so encouraging admins to sort this out at this stage is a good idea.

Design Studio

Although the admin may well have picked a theme for the site, further customisation may be needed or the admin may be starting from scratch. Each part of the site (user administration, for instance) has its own link to customise the look of its tools and widgets and page, but these are also contained centrally in the Design Studio section of the site. Repeating these areas allows easy customisation without having to continually jump from one area to another - adjustments can be made to profile look while in the user area, or they can be done from the Design Studio.

In the design studio, the admin is able to upload new themes, customise CCS with an editor, create default widget layouts for any plugins installed and even design complete templates, if they can happily work with HTML and the templating system. They can assign this part of a site to a dedicated role, if they wish, so that they can bring on board an external designer who can create templates without having access to other functionality. Part of the design studio should be a testing area where templates and looks can be tried on all parts of the site without committing to the main site. This test area can be viewed by all admins and can even be released for viewing by general users. This sort of functionality can be very popular when battling against highly opinionated communities (trust me on this one!)

Plugins

It is inevitable that the super admin will want to check and configure various plugins and may have a wish list to download and install. The plugin console divides the plugins into groups - core plugins, tools, template plugins. Only the super admin has automatic access to all three areas.

A useful tool for the Super Admin at this point would be an initial plugin report. This would list all the plugins, their status (active or not), whether newer version are available and their dependencies. At this point, it is always worth running the updater as one or two may have a newer version available.

Once this is done, the administrator can start to configure the plugins. Most of the configuration will be for the tools as these are the visible plugins that are used by the users on the site. Configuration is over a series of tabbed screens - Plugin default name (you can rename Forums to Boards if you wish), active or not, description, these are found on the first general tab and are common to all plugins.

The second tab would have permissions - which role can access the plugin and to what level. Although much of this can also be configured on an individual basis, the super admin may want to set up defaults and possibly lock some permissions so they cannot be changed. For instance, a forum plugin associated with a group may be viewable by a logged in user, but the cannot write to the forum unless they are a group member. Group members may not be allowed to upload attachments, but moderators can, and so on. Again, this permissions tab would be common to ALL tools.

The third tab would be very specific settings associated with the plugin. On very simple plugins, there may be nothing on this screen at all, highly complex plugins such as forums may have many settings to do with things like nesting, categories, links, levels of moderation and so on.

The fourth tab would contain a list of any additional functionality supplied by mods - plugins that are designed to offer additional functionality to plugins. These can be opened in windows for configuration without leaving the parent plugin.

Of course, as part of choosing a Configuration Template, the super admin may not feel the need to touch the initial configuration of the plugins and simply get on with launching the site.

Testing Mode

Having done all the initial house keeping, the admin can put the site into testing mode, if they wish, and invite users on board to test. The site is live but completely behind a walled garden. The offline message remains, but a link to a login box is added for the testers. Tester accounts are created by the admin - there is no external registration procedure. In this mode, testers are given a Report to Admin link on their menu bar so they can report any problems. These reports are flagged in a special area of the back office available to all admins.

Going Live

At any point the site can be made live - all these first chores are optional, though recommended, and the admin may prefer to just get the site going.