The CMS Expert

Recently there have been an increasing number of posts on the community site related to donations and paid support / solutions on the community site. I have made a couple posts addressing this, but it’s still occurring with increasing frequency.

First, this is the community site for Elgg as an open source project. This is not your personal site; this is not an Elgg demo site; this is not an advertising service. This site is a place for users, contributors, and those curious about Elgg to interact with each other, share ideas, share troubleshooting, and to share plugins and themes. The contributions to this site are made without want, requirement, or expectation of donations. If you are uncomfortable with these stipulations, please leave the community site. If you cannot abide by these stipulations, you will be banned.

Secondly, as a developer who happens to like having food to eat, a place to sleep, and heat in the winter, I understand the need to be reimbursed for time spent developing. As an open source developer, I understand the need to keep the project’s community active and I believe in the principles and philosophies of Open Source. These two concepts are not mutually exclusive, but are beginning to be in this community. When every discussion board and group is littered with donation requests it greatly distracts from the value of having a community based around a project.

On the other side of this are the users who take all for free without contributing back. This also hurts Elgg. I’ve outlined before how to contribute back to Elgg if you can’t code, and for the most part people do. There are some “help vampires” that demand free help right now or they demand immediate updates to plugins. This isn’t the way to interact in an open source community either and is just as damaging as commercial spam.

No one is against using Elgg as a means of income. In fact, part of the decision to dual license GPL/MIT on Core was because MIT offers developers who want to resell greater flexibility than the GPL. However, having the community site polluted with “Donate!” messages is distasteful and subtracts from the worth of the community as a whole. More than one person has commented on the fact that seeing all the donation requests in the community makes Elgg less appealing. This must stop.

So what would you, the community, like to see on the this site regarding commercial services and donation requests? 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. In group discussion, if the only reason for a reply on a discussion topic is to gather donations or to offer unsolicited paid services, it will be deleted and the offending user will be banned. Posts prefixed with “Looking for a developer.” are, of course, fair game to announce your services to the author. Post that say “How do you…” are not appropriate threads in which to ask for donations.

On a personal note, I hate that this post needed to be made. What has been happening on the community site is so far from the philosophies of open source that it’s very discouraging. Open source software is something I feel strongly about and that I will fight for. If you don’t like interacting with an open source community, please leave–you will be frustrated and you will frustrate those around you. If, however you simply don’t know how to interact with us or are uncomfortable about it, please send me a direct message or an email and we’ll talk. The point of open source is community, and that’s something I will protect in Elgg.

Please comment at the Community Action group on the community site.

Greetings all!

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.

Greetings all!

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.

Greetings all!

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!

Greetings all!

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!

 Elgg 1.6.1 has been released!

This release fixes a few problems users reported having in 1.6 including:

• Errors on registration with Default Widgets enabled
• Broken tag search
• Broken “Tools Administration” page when simplecache is disabled
• Bookmark links missing
• “View friends resources” links not working

1.6.1 should be a very solid release, but as always, please report any bugs to Elgg’s Trac.

Greetings all!

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!