1) How are you using Elgg?

We are using ELGG for 2 different sites at the moment:

• The first is a staff collaboration area for coordinating research, communicating about projects, running special interest groups and just generally encouraging collaboration and the sharing of practise across the institution.
• The second is a cross-institution resource which is working to increase articulation paths between ourselves and a few colleges in the Lothians area. It’s being used mainly for communications between the facilitation team, storing meeting/event materials and distributing outcomes. It’s also being used to co-ordinate work shadowing between academic staff.

2) How long have you been using the platform?

I first installed the system to do a bit of research on it around April 2009, and have been using it for live sites since the summer of 2009.

3) How has it been going so far?

We’ve had a really positive response to it so far, but usage is too limited at this point to define whether it has been successful on either of our sites. Hopefully more on this in 6 months time or so!

4) What are your plans moving forward with Elgg?

I want to expand the use of the first site in particular by getting a lot more staff on it. This’ll hopefully generate a lot more content and get the community buzzing!

5) Have you had to overcome any challenges to get up and running?

The main challenges have been technical really – our servers are all ASP based and obviously ELGG is PHP, so I’ve had to go external for hosting which is a pain, and this obviously brings in fears of reliability, security, etc. Also, there is a bit of resistance to yet another system with a new set of logins and passwords. I plan to explore whether we can tie it in with our internal login system using LDAP authentication but I’m not sure if this will be possible between our systems and an externally hosted site from a security point of view.

6) What would you like to see improved in Elgg?

I’d love a few new features to cover requirements which I’m currently handling with slightly inadequate plugins. Of course, I might simply not have come across the right plugin yet so any tips gratefully received:

• Site-wide calendar function, group calendars.
• The ability to authenticate users – far too many spam users coming in at the moment but I really want to keep registration open. More security features to combat this would be really really useful.
• More easy customisation options for the front page. I know there are editable areas, but it would be good to have more power over what appears on the front page without delving in to the code or employing 3rd party plugins that have sometimes brought down my entire test sites.

--------------------------------------

If you would like to share what you are doing with Elgg, please get in touch dave at elgg com. Thanks.

I recently joined Elgg in a business development capacity. Having followed the project for a while, I'm excited by its potential and am looking forward to further developing the open source business opportunities that are available.

Over the past couple of weeks I've spoken to a number of current and prospective Elgg users, from small educational groups right through to large organisations. The feedback has been very positive and is really helping us to refine and shape our services for businesses and organisations. I look forward to updating you further on this over the coming weeks!

If you are interested in using Elgg within your company or would like to talk about our business direction, please get in touch: richard@elgg.com

I wrote a similar post describing how to tastefully advertise your services:

The current plan is to allow those who wish to offer consulting services for Elgg to do so tastefully through their profile and the Professional Services group.

This post has been generally ignored, resulting in the need to revise the community site's policies and terms.

The following changes in terms are effective immediately on the community site:

• Advertising goods or services is forbidden on the community site with exception of the conditions listed below.
• Asking any member for monetary reimbursement for any information, plugins, or code is forbidden.
• User profiles, plugin projects and releases, and group profiles may contain a link to a site offering development or consultation services ONLY in the appropriate section, which is marked with the label "homepage," "website," or "URL."
  
• Users failing to adhere to these terms will be banned and the offending content deleted at our discretion, with or without notification.

Starting with the oldest plugins, community admins will inspect plugins for unsolicited advertising and will mark any offending plugin as "private" to allow the authors to update them. New plugins are expected to follow the posted guidelines.

In addition to these efforts to clean the community site of unwanted advertisements, we have removed all banner ads from all sections of the community site. Further, user profiles will be limited to a brief description, a location, a website, and a contact email address.

Let's all work together to make the community site a collaboration area without the distraction of unwanted marketing and spam.

How is everyone finding the new plugin area on the community site? Since its launch last week there have been generally positive reviews of it. I am pleased with how it functions but know there are a few oddities and hope to continually improve it. The new plugin area features simpler ways for plugin authors to showcase their plugin, recommend releases to their users, request donations, and link to an external project home page.

Because of these improvements and to help clean away some of the clutter, the following new policies will soon go into effect for plugins:

• Projects must contain a functional plugin. Projects with downloads that contain only images, text files, or other non-plugin files will be deleted.
• Use the built-in images feature. Images in the project description or release notes will not be permitted.
• Use the built-in links for donations, home page address, and code repository address. There is no need to duplicate this information in your description or release notes.

As always, plugins uploaded to the community site must be released under an Open Source license. There are many projects that create an open source version of the plugin but also offer a paid or professional version. This is absolutely fine when it is done tastefully, which I'm happy to say is the case with the current authors of such plugins.

Starting January 29th, 2010, plugins that do not adhere to this policy will be given a warning and then deleted if the policies are not followed. This is the first step we're taking to clean up the community site. In the end, we hope to make the community site a place where Elgg users, developers, and newcomers can trade information easily and without distraction. Be watching for more changes next week!

(I need to work on a better salutation...hrm...)

Another good week here with Elgg devel! I have some bits of development info to talk about, but first, some extra-exciting news: starting Monday, my good friend and previous coworker, Nick Whitt (@nogoodnick) will be joining our dev team! Welcome Nick!

One of Nick's first big dev projects will be to wrangle out a real query class in Elgg. Having worked with Nick before, I have a fairly good idea what's coming, and it is exciting. If there are any Active Record fans in the crowd, you'll be pleased. If not, yeah me neither ;) Regardless of if you like Active Record, no one can say the code below isn't fantastic:

	$all_users = new ElggQuery('entities', array('type' => 'user'));

	foreach($all_users as $user) {

		// real ElggUser!

		echo $user->getURL();

	}

Think about how you'd have to do that in the current Elgg. Much nicer above! Again, I'm very excited to have Nick join our team. Now, on to the dev stuff.

There have been two major problems reported with Elgg 1.6(.1): Tags with extended characters don't work, and usernames with certain characters break files and photos. Elgg 1.6.2 is preliminarily scheduled for release the last week of September with fixes for both of these problems.

There has been some great feedback on the Draft Roadmap for 1.7 since Dave posted it a few days ago. A few good ones:

• Add user settings for friendly times (3 days ago) or actual times (September 17th, 2009)
• Alphabetical sorting of groups
• View content by access level
• Size quotas on files
• Hashtag support in The Wire
• Captcha refresh during registration

The 1.7 release is shaping up to be a good one! We'll be coming to a decision on the roadmap toward the end of this week, so keep your eyes open for that once it's been finalised!

I've just returned from an amazing trip to Boston for the jQuery Conference at the Microsoft New England Research and Development Center (aka: "The MS NERD Center"). I saw amazing presentations, met awesome people, ate great, great food, and partook in a fair amount of IE bashing like only JS and CSS developers can.

I attended sessions about Javascript and Ajax best practices, improving JS speed, accessibility using the W3C's ARIA specification, some fun sessions showing how easy and exciting theming in JS can be, and sessions about what's just over the horizon for JS and jQuery. (FYI: jQuery 1.3.3 will be fantastic.) Over the following days and weeks I'll post more specifics about the sessions I attended, but for now I want to talk about some take-aways I hope to use to improve Elgg's Javascript and Ajax.

Create (and use) a JS API in Elgg

Before I joined the Elgg core team, in each plugin I wrote I had to implement Ajax functions to show loading indicators, display success, failure, and other status messages, and to handle the Ajax replies. Blech. Elgg needs a standardised API for requesting AJAX information on both the client and server sides. This encompasses showing a loading notification, fault tolerance, and special ajax views.

Goodbye, lazy loading widgets

Profile widgets in Elgg use a technique known as "lazy loading" in which the initial page loads, then multiple concurrent requests are sent via Ajax to load the rest of the page. Used properly, this can increase the perceived speed of rendering pages in the browser. Used improperly, this can wreck havoc with the user experience...not to mention what happens when Javascript is disabled because of accessibility or system policies. When loading a few widgets per page, this approach works fine. To see it really fail, load 15+ widgets set to display the max number of elements on a single page. Scary stuff! I believe the solution to this problem will be to lazy load only selected elements of widgets--the edit view, the options view, and possibly others......and *deep breath* to refactor the caching system.

Refactoring caching (views, queries, and objects)

If you've been following the the mailing lists, trac, or the community site, you have seen a few discussions about problems with Elgg's caching. Whether it is out of memory errors, or dots in usernames, Elgg's current approach to caching is beginning to fall short. Though caching isn't immediately related to Javascript, it is interconnected in Elgg: we'll have to make sure the refactored caching system can be used with the new JS/Ajax API and widgets system.

Accessibility

This is the beast that few people wanted to talk about--or indeed, hear about--at the conference. One session I attended on accessibility had fewer than 20 participants! While there are upcoming technologies and standards that will make those of us concerned with accessibility better equiped to develop accessible sites, the reality is that this was a neglected area at the conference. The jQuery UI team is taking some good steps to ensure their widgets are accessible and degrade moderately well, but not all of them are functional yet. Of all the projects on the table for Elgg, this will be the most invasive to core and likely the most time-consuming. This is important to us, but I ask for your patience (and help!) on this one.

All in all, I left the jQuery conference with fresh, new ideas of what Elgg needs to push forward with its Javascript and Ajax support. Projects are doing some awesome things with jQuery, and I aim to make Elgg soon be one of them.

As I've mentioned previously, I'm very excited to be going to the jQuery conference in Boston this weekend. Officially, I'll be representing Elgg and learning how we can better implement Javascript and Ajax. Unofficially, I'll be there because jQuery is just plain neat.

The schedule is pretty full, but of particular interest to me (and Elgg) will be discussions about how to implement unobtrusive Javascript, and how to improve Elgg's accessibility. For all the fellow US educators out there, this means improving Section 508 compliance.

Another project I think the conference can provide resources for is the work I'm doing to replace the current sliding Friends Picker with a faster, more versatile User Picker, the (meager) beginnings of which can be found in SVN.

Is anyone else from the Elgg community coming to the conference? If so, find me--I'll be in the Elgg shirt!

It's been another busy week with Elgg. We've pulled in quite a few patches preparing for a 1.6.1 release early next week that will fix some bugs discovered in 1.6. Also, we've established a good base for the Demo site and I've been working on updating the Access Collections for 1.7+.

First, there have been many requests for details about the Demo site. Briefly, the Demo site is running core Elgg from the current SVN that will become 1.6.1. A few users have noticed some cosmetic changes and incorrectly attribute this to the theme--These changes are due to updates to the wire and to the activity stream. The activity stream used on Demo is in SVN and the updated Wire plugin will be put in SVN to be released with 1.7.

As for the plugins, the demo site uses all core plugins, with the exception of the awesome photo plugin Tidy Pics and a language tweak to change "friends" to "following."

As I said, we've pulled in a few bug fixes for problems people have encountered with 1.6 and will be releasing 1.6.1 early next week. In addition to the two bugs I talked about last week, Dave committed a fix for the friends' activities to not displaying properly, and I committed a fix for group discussions to honor the default site access.

For some new and exciting features, I've been working on a replacement for Access Collections. Through feedback we've found that most people don't use--indeed don't even know about--Access Collections and usually try to use groups for collaborative and collective content. To this, I've started developing a collections plugin that serves as an aggregation of all content marked with a certain access level. Developers, you'll be interested in the new get_entities_from_access_collection() and list_entities_from_access_collection() functions. End users, you'll be interested in Elgg 1.7 ;)

That's all here! I hope everyone has a great weekend.

Also, still looking to meet up with some folks at the jQuery conference in Boston next weekend. Give me a shout if you're going!

Just to keep everyone up to date, I'm really pleased with the direction the community is starting to take in Elgg. Trac has been active from the community side with bug reports and confirmations, and active on the core developers side with fixes. A detailed bug report and confirmation or additional details from multiple users goes a long way to help us fix bugs!

Thanks to some of the great bug reports we've received on 1.6, we were able to quickly fix two problematic bugs in 1.6: broken tag search and an error during new user registration when the default widgets plugin. We recognize these are important features that users require, and so will be releasing Elgg 1.6.1 toward the end of next week. If you find any other severe bugs in Elgg 1.6, please submit a detailed bug report to Trac so we can fix them!

Following some requests for a demo site of Elgg and to help keep the community site clean, we've put together demo.elgg.com, a demo site for Elgg 1.6. The purpose of this site is to give users wanting to experiment with Elgg's features a place to play. The site will be reset once a week, so no real content should be entered there. For general discussion about Elgg, troubleshooting, development questions, and socialization, please continue to use community.elgg.org.

Once again, I'm really excited about how the community is coming together around Elgg. Thanks for all the bug reports, discussions, questions, and tips! Open source projects cannot survive without a good community, and I'm happy to discuss with anyone ways we can improve this with Elgg.