Summary: Information Architecture Overhaul of An Existing Elgg Site: Revision

 

I just finished redoing a one-year old Elgg installation. It is a private gated community, which was already running a heavily customized Elgg installation, but I was very unhappy with the basic IA of Elgg, which I still think is its major weakness.

So I decided, with my client, to redo the IA of the core parts of the site and now it is finally live. I am documenting the experience here so that it is of use to anyone who will attempt to do the same in the future.

The end results are something like the following:

image

The rejigged profile page with updates in a tab. All the tabs are fetching data via AJAX.

image

 

 

The main top half of the dashboard. The top nav is persistent, the left is there only on select pages. Pretty much every element on the page is loaded through AJAX.

image

 

Lower part of the dashboard. It supports the endless 'more updates' feature that Twitter and Facebook kicked off.

 

image

 

The default profile view

We started with setting the functional specifications of the new version in Sep-Oct and closed it towards end of November. This is a pretty complicated Elgg build with around 2000 members already in it, so we had to be careful and exact with what we were doing.

The wireframes were done soon after. Mockingbird is awesome for this.

Design was finished by the first week of December, our design agency delivered the HTML/CSS by the 10th of December.

It took 18-days to port the design to Elgg and develop the new functionality required and then a round of testing followed.

The plugins we have used: 

elgg_dev_tools
siteaccess
phpmailer
groupadmin
friend_request
customsearch
groupriver
group_moderate
minify
eager_widgets
sharedly
updown
tidypics
group_mailer
izap_videos
chat

Besides the above and a lot of the core plugins, we have also developed some 13 other plugins to support the functionality they required. They range from a full blown issue tracking framework to a standalone job queue manager (site newsletters and mailers are handled by this). I will try and release as many of them as it would be possible if the client signs off on it.

I did start off using the 'like' and 'rivercomments' plugin, but as we customized things even more I figured it was a better idea to annotate directly against the entities for better control than to spend a lot of time trying to work with the plugins.

To support the AJAX functionality we had to develop another module to work as an internal endpoint. The use of '?view=xml' was made impossible by the fact that there was to be no public data on the site and even with siteaccess it was getting to be a nightmare to lockdown the site. So we had to override every view other than default to prevent data leakage.

We are currently using something to the effect of:

/pg/api_endpoint/get_comments/{id}

/pg/api_endpoint/profile_summary/{id}

All auth is easily handled by gatekeeper().

It took me a while to architect the sub-framework, but it was well worth the effort, even though you could argue that it kind of reimplements the xml/json views.

I had the most amount of trouble actually integrating the various canvas layouts (we were going from a fluid to fixed width layout) and CSS. The way in which plugins currently push data into the canvas kills the whole point of having a great views framework in the first place in Elgg.

If you are a plugin developler, check out the core plugins in Elgg 1.8 branch in SVN. There are a lot of good pointers as to how to seperate data and presentation in the controllers and the views. The current state of affairs is really awful. What is the point in pulling in content of two panels into $area1, forcing other developers to hack the plugin's code to get things done than to extend it.

As it is the case with every framework, some parts of the core API struggles once you hit a certain number of users (try running through anything more than 400 user entities in a single process). This means that you have to either farm out such tasks in batch processes or resort to writing raw SQL. In terms of security at least, it is always better to use the former approach.

Lastly, it would have been impossible to do any of this without some wonderful put in by the core Elgg team and the community that has grown around it. You guys are awesome. Thank you!