Bricolage 2.0 was released today. This is a pretty big deal, and a long time coming. The most important changes, from my point of view, are:

• Revamped UI. As a 2006 Google Summer of Code project, Marshall Roch added a slew of Ajaxy goodness to the Bricolage UI. It used to be that, to dig down into a document, you needed to click through reloads for every level. Now the entire structure of a document is available on a single screen, and digging down takes place in situ. This means faster, easier document editing.

  There are other niceties too, thanks to Marshall, like as-you-type autocompletion of category URIs and keywords, popups for associating related documents, dynamic field generation for document keywords and user contacts, and animated workflow actions for moving, deleting, and publishing documents.

  These changes mark a truly impressive improvement in usability for the people who use Bricolage every day, and will by far be the most welcome change for our users.

• Finer content control. Thanks to another 2006 Google Summer of Code project, Christian Muise implemented what we call “element occurrence specification.” Bricolage document structure is controlled by administrators creating document types with hierarchies of elements. Elements may contain fields—the types and value of which may also be specified (text, textarea, select list, etc.)—and other elements.

  In previous versions of Bricolage, if an element was a subelement of a document, one could add any number of that element to a document. Fields were a bit more controlled: you could only say whether one or many instances of a field were allowed in a given element.

  Element occurrence specification allows administrators to have much finer control over document elements by specifying the minimum and maximum number of instances of an element or field may occur. For example, one can say that a document may have only one instance of a field, or must have three, or may have between 3 and 5, or may have at least 3, or may have any number, including none.

  Bret Dawson put it really well in the Bricolage 2.0 Changes:

  Want every book review you publish to contain at least three but no more than 10 ISBN numbers? Want exactly four pull-quotes in every article? You can do that in Bricolage 2.

• MySQL support. This, too, was a 2006 Google Summer of Code project, by Andrei Arsu. Yes, you can run Bricolage 2.0 on MySQL 5.0 if you want. This was a pretty big project, and I’m surprisingly pleased at how well it works now that all the kinks have been worked out (special thanks to Waldo Jaquith for being brave (foolish?) enough to start a Bricolage project on MySQL and thus to shake out some bugs).

• Apache 2 support. This was started quite some time ago by Chris Heiland, hacked on later by Scott Lanning, and finally finished by yours truly. I look forward to dumping Apache 1 in the future.

There’s other stuff, too, lots of little things and not-so-little things. Altogether they go a long way toward making Bricolage better.

It’s been quite a day, and I’m glad to have it out the door. Four years is a long time to wait for a major release, and it happened not because of me, but thanks to the work of others who have picked up the gauntlet. Huge thanks especially to:

• The Google Summer of Code, especially the 2006 projects (yes, we finally shipped them!).
• Phillip Smith, who spearheaded the terrific new bricolagecms.org design, updated the Bricolage 2.0 context-sensitive help, and generally pushed forward the Bricolage marketing and social media agenda (follow @bricolagecms!).
• Bret Dawson, who has been writing release announcements and put together the awesomely human version of the Bricolage 2.0 change log, as well as the public announcement.
• Matt Rolf, who wrote the Bricolage 2.0 press release and provided a huge load of various HTML and CSS fixes to Bricolage 2.0.
• Marshall Roch, who started hacking on Bricolage in high school, worked through two summers of code, and made the UI what it is today.
• Alex Krohn, who provides hosting for the Bricolage site via his Bricolage hosting product at Gossamer Threads, helped to diagnose and fix a number of important bugs, and has just been an all around great technical resource.

Many others provided feedback, patches, and bug reports, and I appreciate all the help. I hope to see you all for Bricolage 2.2!

Looking for the comments? Try the old layout.

I’m very pleased to report that the Google Summer of Code Bricolage projects have all been successfully completed. The contributions of the three Summer of Coders, Marshall Roch, Christian Muise, and Andrei Arsu, will be included in the next major release of Bricolage. On behalf of the Bricolage community, like to extend my gratitude to Google for sponsoring these three excellent students to dramatically improve the interface, capabilities, and compatibility of Bricolage.

So what got done? Here’s a rundown:

• Marshall Roch added many slick Ajax features to Bricolage. The story profile now manages the editing of all elements and subelements in a single screen, with no loading of a separate screen for subelements. You can navigate to subelements by clicking on a tree structure right in the story profile. Subelements more than three levels down will be loaded dynamically when you get to them. You can also drag and drop fields and elements to reorder them.

  Other stuff that Marshall Ajaxified:

  • Document and category keyword editing
  • Document category association
  • Document output channel associations
  • Organizations in the source profile
  • The “Add More” sections of the user, contributor, media type, and alert type profiles
  • Roles in the contributor profile
  • Assets on desks and My Workspace

  Marshall worked hard to integrate more interactive features into this 2000-era application, and I, for one, appreciate his hard work. Great job, Marshall!

• Christian Muise added support for an occurrence specification to element types and field types. That means that when you make an element type a subelement of another element type, you can specify the minimum and/or maximum number of times that it can be a subelement. So when an element of the parent type is created, it will automatically add the minimum number of instances of a subelement specified for that parent type. This will allow an entire element tree to be pre-populated as soon as you create a new story or media document. Leaving the min and max occurrence set to 0 (zero) maintains the old behavior (no required subelements and an unlimited number can be added).

  Christian did the same for field types, too. The old “Required” and “Repeatable” attributes are gone; now you just specify a minimum number to require that number of instances of a field, and a maximum number to limit the number of instances. Together with the element type occurrence specification, this functionality allows Bricolage administrators to have a lot more control over the structure of the documents created by editors.

  Christian worked hard to complete this project, despite other huge demands on his time this summer (including a full-time job!). But thanks to his active participation on the developer mail list and his willingness to ask questions of his mentor, Scott Lanning, and myself, he overcame all obstacles to implement these features. He even wrote a number of new tests to ensure that it works properly and will continue to do so for the foreseeable future.

  Excellent work, Christian, and thank you so much for your contribution!

• Andrei Arsu ported Bricolage to MySQL 5. Bricolage has always run on PostgreSQL and used a number of PostgreSQL-specific features to ensure that it ran properly and well. Andrei took these on, converting the existing PostgreSQL DDL files to work on MySQL, figuring out how to convince MySQL to work with some of their idiosyncrasies, and writing compatibility functions in the MySQL driver and upgrade module so that things should largely “just work.” As a result, for the first time ever, you can now build and run Bricolage on MySQL. Can compatibility with other databases be far behind?

  Andrei picked up Perl very quickly during this project, and was able to understand how such horrible code as the Bricolage installer worked without running screaming from the project. His code was well-written and his approaches to compatibility flexible and scalable. Well done, Andrei!

Future Plans

The next tasks toward getting this code integrated and released are as follows:

• Andrei will merge his MySQL port into subversion trunk. This should actually be fairly straight-forward.

• Marshall will merge his Ajaxification work into trunk. I don’t expect that there will be any conflicts with Andrei’s work, as the two projects were orthogonal.

• Christian will merge his occurrence specification work into trunk. This will require that he work some with Andrei to ensure that his changes to the PostgreSQL DDLs are propagated to the new MySQL DDLS. He will also then need to work with Marshall to make sure that the occurrence specification works properly with the Ajaxified UI.

Once these tasks have been completed, we’ll be ready to release a development version of Bricolage with all three of these major improvements. The development release will allow members of the Bricolage community to start to play with the new features, report bugs, and make further suggestions for improvement. Expect the release sometime in the next six weeks or so.

Again, my thanks to Marshall, Christian, and Andrei for their hard work this summer, and for all that they have contributed to the Bricolage community and project. I hope that each will remain involved in the community, not only to support the features they’ve added, but to work with other members of the community to add new features, help newbies, and generally to spread the word.

Looking for the comments? Try the old layout.

As you may have read, we got quite a number of applications from students wishing to contribute to Bricolage as part of Google’s Summer of Code initiative. Quite a few of them were very good. There were eight projects I wanted to accept, but, Bricolage was allocated only four projects. Of course, this is four more than we would have had otherwise, and I’m really excited to be working with them this summer.

The four winning projects are:

• Add Input Channels, by Marshall Roch
• New Sample Document types and templates, by Scott Loyd
• Port Bricolage to Apache 2/mod_perl 2 and Windows, by Sam Strasser
• Port Bricolage to MySQL, by Tamas Mezei

The other projects I wanted to get but could not were:

• Add Bulk Edit, Bulk Media Upload, and Site Tags, by Andreas Hofmeister
• Element Occurrence Specification, by Christian James Muise
• Add JSP Templating, by Adrian Fernandez
• Update and Modernize the Installer, by Yiannis Valassakis

I am hoping that some of these students might want to work on their projects, anyway. I’ve even found other developers to help with the mentoring of JSP templating (Patrick LeBoutillier with Perl/Java voodo) and the installer modernization (Sam Tregar of Matchstick fame). Unfortunately, I’ve not heard back from any of them after sending them an invite to participate in the project. C’est la vie, I guess

The hardest part of the proposal evaluation process was selecting from the 20 proposals to port Bricolage to MySQL. Ultimate, there were four excellent proposals for this project. Reading the proposals over and over, I couldn’t decide between them. Ultimately, I sent an email to the four top contenders with the following items for them to reply to:

1. Please describe in a line or two your Perl knowledge or experience (if any).
2. Please describe in a line or two your MySQL and PostgreSQL knowledge or experience (if any).
3. Please describe any previous Bricolage usage experience.
4. Please describe any previous Bricolage development experience.
5. Please describe any previous Open Source development experience.
6. What school do you attend?
7. What is your specialty at the school?
8. How many years have you attended there?
9. How much time do you expect to have for this project?
10. Have you applied for any other Summer of Code projects? If so, which ones?
11. Your personal or professional web page URL (if any).
12. Would you be willing to collaborate with another developer who might be working on a SQLite port to ensure that your changes can fully inter-operate?
13. Please outline your project plan for porting Bricolage to MySQL, including a description of what parts of the Bricolage API, DDLs, installer, and upgrader would need to be modified to complete the project.

For better or for worse, all four applicants responded with detailed answers to my questions. They were all great, and that made it even harder to select just one of them. At this point, there were only a few hours left to rank applicants in Google’s SoC Admin Web app, so I figured I had to get more objective—or at least fool myself into thinking I was.

So I decided to rank each applicant from one to five for each question, and then add up all of the results and see who came out on top. So now I was comparing answers to a single question between applicants, and filling in scores for them in a spreadsheet. As it was, things were still really close; yes, all of the students where that good! Tamas came out on top with a score of 30, two others were tied at 28, and the fourth applicant scored 26. They were close enough that I wanted to review them all one more time, this time paying specific attention to the last item in my questionnaire, the project plan.

Each of the four applicants had taken the time to read the mail lists and had looked at the existing Bricolage code. But there were varying levels of detail and demonstration of knowledge for how to implement the MySQL port, but Tamas did come out slightly ahead on this item, so I gave his proposal the green light.

But in truth, I would have been happy with any one of those four applicants. I was only sorry I had to choose only one! If Google does this again, I think I’ll list many more project ideas on the Bricolage Web site, and try to steer people to the mail lists to discuss their ideas before sending them in. Then I might end up with 11 great applications!

Looking for the comments? Try the old layout.

The Bricolage project is pleased to have been selected to be a partner in the Google Summer of Code. This Initiative is designed to introduce students to the world of Open Source Software Development and provide them with a $4500 award for completing an Open Source project before the end of Summer.

As a partner, we are currently looking for student volunteers to propose Bricolage development projects. We have created a list of suggested project ideas. If you’re interested in hacking on Bricolage for fame and fortune, join the Bricolage Developers mail list or sign on to #bricolage on irc.develooper.org (MagNet) to outline your proposal and get feedback as you prepare to submit it to Google. You can also join the Google Summer-Discuss group or sign on to #google-summer on irc.freenode.net for more general discussion of the Summer of Code.

But hurry, the deadline for proposal submissions is June 14! Students who get Bricolage projects accepted will be mentored by me and other members of the Bricolage community.

We look forward to your proposals!

Looking for the comments? Try the old layout.