Summary: Information Architecture Overhaul of An Existing Elgg Site

 

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!

 

  • Shyam,

    This is an awesome overview of building a fully customized and themed Elgg site.  Thank you for sharing it with us!  Many people come to Elgg's community expecting to download Elgg, put it on a shared host, and then be the next Facebook.  Your overview is a great demonstration that building a site takes hard work.

    We know there are major limitations in 1.7 and below's CSS and canvas support.  We're hoping to change this in 1.8.  It looks like you've already been looking around, so if you have any suggestions please don't hesitate to bring them up!

    Congrats on going live, and good luck to you and your client!

  • Thats an awesome work Shyam and great summary and overview :)

    HaPPy NeW YeaR Brother :)

     

    HaPPy ElGGinG :)

    Do GooD :)

  • Shyam

     

    Excellent work! It takes a lot of work amking a fully customized Elgg Site. We've been working several weeks on a custom Elgg site and it was a lot of work to design it as the customer wanted. I like how is that going, but we still have more work to do.

     

    Kudos!! GREAT WORK!!!

  • Brett, thanks for the kind words. Most of what we have managed to do would not have been possible without the excellent core of Elgg. I don't think people appreciate enough how good it is.

    In most of my work with Elgg what I have found is that people have wrong expectations from it and don't understand the difference between a framework and a product. By the time the vendor is involved in the picture, it is almost always too late.

    More than the canvas support, it is the manner in which that plugins leverage it that causes the issue. If you combine all three panels into $area1, it limits the ability for a developer to change it in a theme. The documentation need to stress on this. In fact, the documentation effort needs to be much better, let me see what I can contribute more to this.

    1.8 looks really good. I have taken the plugin layout from that a reference while designing the new site. I am so glad to see the /pages/xyz.php or /world.php gone in a lot of plugins.

    rjcalifornia, jaxcatz,

    Thanks :)

  • Very nice! I was thinking of something like this on my site too. This denitely could be a great inspiration for me.

  • Wow!! sleek and awesome!

    looks like you put a lot of thinking into it.

    We'll wait till some plugins of yours will leak out ;-)

    Thanx for sharing the process

  • Shouvik,

    Thanks, I have been following your riverdashboard project closely and have taken a lot of cues from there.

    El, thanks :)