Search

Jonas, You say ‘worth demonstrating’, but I dont’ think its about demonstrating, its about extrapolating out to common use-cases, and producing solid production-ready or production-near ensembles to save devs time, and keeping that ensemble supported by committed community members (which may or may not include help from the extension developers that have contributed to the ensemble).

If the audience for this would be inexperienced, non-technical users, then I would agree that it could run the risk of mis-representing Symphony’s characteristics. But as I see it, it would rather be devs that have the ability to learn the system but simply need more confidence in Symphony as an immediate solution then the tabula rasa available now.

The blog workspace available now is kept minimal intentionally; its meant to be didactic. I can’t see the argument against making a more full-featured blog available, intended for actual use as a blog.

That said, there is nothing stopping anyone from doing this. The only real difference between this and how ensembles are born now would be perhaps a more concerted effort by the community to collaborate on it. Last time I checked, Stephen Bau, our Advocacy czar, had one or two ensemble releases. Wonder what he has to say on the issue…

To be sure, I think the ensembles are a great idea all around, and would be a great boon for the experienced community and newcomers alike.

However, there are some significant differences with this approach compared to other systems, and this is important to consider. In Drupal, if you want a forum, you load some modules. Same with images and media management. At any point you can add these capabilities to a preexisting site by loading some plugins, and you’re pretty much done. Now granted, they might only give you 50% of the features you want, and they might be hard to work with, but at least you have something.

In Symphony, extensions will give you additional functionality in the same way, but most extensions tend to be smaller in scope. (e.g. there will probably not be a full-blown Forum extension.) So if I have a Symphony site for my company and I want to add a forum quickly, I may essentially have to merge the architecture from a Forum ensemble into my existing site. This is hardly a quick, plug-and-go situation.

Or, if we have separate ensembles for a Forum, Blog, and Image Gallery, what if I need all of those features in a single site? Is it on me to blend the ensembles together?

Anyway, these are just some sample scenarios to consider and limitations we need to address.

This is hardly a quick, plug-and-go situation

Definitely. But if there was no plug-and-go solution available for the initial core function of the site you may not end up using Symphony at all, and would be up the proverbial creek when it was time to shape it and expand it to you needs. And I’m not saying this would happen to just Symphony neophytes. I like to think I’m familiar with Symphony, and I’ve have been in that situation, and had to choose another system.

I have an upcoming project that I know will go the same way. I’ll do my best, but the time it would take to get Symphony to the point Wordpress is at ‘out-of-the-box’ will probably lead to us using WP, even though the site is not a blog. WP can do blogging and page-based structure. There are tons of other good reasons to use Symphony over WP on this project, not the least of which is just the unknown future need for expanding the site. However, long-term rationality doesn’t always win out over what is the most immediately convenient.

what if I need all of those features in a single site?

Ah, the long-sought Holy Grail of Symphony development: the modular ensemble. I think we discussed this during our largely quesadillaless conversation in Mason a couple weeks ago.

what if I need all of those features in a single site?

You want to wait for Symphony 3 where everything except entry data are stored in XML and can be version controlled, merged and synchronised.

Ah yes, modular ensembles, a lack of quesadillas, it’s all coming back to me now. ;)

Even something seemingly as simple as a Blog ensemble is trickier than one might think: should it work like WordPress? Tumblr? Should it support static pages? Will we provide several themes? What sorts of commenting does it support? What if I want a photo blog instead? Does it have spam prevention? Search? And so on…

That said, personally I would jump on such an ensemble regardless of the particular supported features, because I want to replace my WordPress blog with Symphony for obvious reasons. I could build a blog site with Symphony now, but like you said, I’m not going to bother to spend the time on it because WordPress already works.

You want to wait for Symphony 3 where everything except entry data are stored in XML and can be version controlled, merged and synchronised.

Oh right! Fantastic. So excited about this.

Community Supported Symphony Ensembles

I’m personally very happy that we are having this discussion. Now that we have received some well deserved industry recognition, I believe that ensembles are the next logical step for Symphony advocacy.

Officially supported ensembles are realistically a long way off, although the Symphony book project will give more urgency to the development of ensembles to demonstrate the concepts in the book and showcase the capabilities of the system.

There is enough work for the development team and working groups in developing the core application and maintaining the community site. That should be their sole focus. The task of building ensembles should fall to the community.

@ashooner, your idea of Community Supported Ensembles sounds the most viable to me. My ensembles have been primarily experimental, building pieces for a project that I have been working on for a number of years.

It’s probably safe to say that most small businesses are struggling with process issues and wrestling with how best to transfer offline processes to the web. I chose Symphony about five years ago, when I was freelancing, as an application that had the potential to become the solution for the lack of an integrated set of tools.

Having been working for a web agency for the past four years, the challenges have been the same. Unfortunately, expediency often wins out over craft and urgency obscures the need to strategically select the right tool for the long term benefit of the project.

While working with sometimes less than ideal development situations, I always have in mind some long term goals to build an integrated system that will be able to help with common business process problems.

  • Project Management
  • Digital Asset Management
  • Collaboration Tools
  • Knowledge Sharing
  • Document Production & Printing
  • Standardized Systems for Layout and Production
  • Content Strategy and Content Collection

Each ensemble that I create is an experiment to solve another piece of the puzzle. Obviously, it’s a long term project with lofty goals, but the need is borne out by our experiences with fragmented processes using systems that are not easily integrated.

So far I have created prototypes or ensembles for

  • blog
  • portfolio
  • calendar
  • project listings
  • client listings
  • time tracker
  • financial manager
  • to do list
  • forum
  • cities listings
  • XML importer
  • WordPress importer
  • proposal system
  • HTML/CSS to PDF tool
  • agency site
  • prototyping tools
  • form builder
  • flexible grid systems
  • content modules

Is anything finished? No. Although I have released a lot of it in the form of ensembles. Now that we have an almost feature complete core with version 2.1.1, I am in the process of updating old ensembles in preparation for integration of commonly needed features into more complete ensembles.

Do I need help? You betcha!

It’s enough of a challenge to keep up to date on all the awesome extensions being released as I don’t have the opportunity to work on Symphony projects on a daily basis.

The more we can collaborate as a community, the better we will be at establishing best practices for building sites with XSLT and Symphony, developing reusable solutions for common problems and relieving the burden of work on the development team to help them focus on core development issues.

If anyone is interested in helping out with developing some Community Supported Ensembles, feel free to comment on what I or others have already created. Tell us where we can improve them. If there is enough interest, that could provide the motivation we need to collaborate on a core set of ensembles that have the features you are looking for (and finally finish the Members extension).

If we start now, we’re going to have a lot of the pieces figured out by the time Symphony 3 is released. Then, as Allen alluded to earlier, assembling the pieces is going to be a whole lot easier.

Hmmm. Is there a particular comment length that I should avoid (admittedly, I was unnecessarily wordy)? Or was my comment overtly self-serving? I hope I didn’t inadvertently shut down this interesting thread.

Also, keep in mind that I am speaking only as someone who is interested in building ensembles, and not in any official capacity as a representative of the Symphony Advocacy Working Group.

One of my motivations for using Symphony has been to enable small non-profit organizations to be able to benefit from the flexibility of Symphony by solving some of their common problems in a full featured ensemble. Such an ensemble could include static content pages, a blog, a member forum, a photo gallery, a calendar of events and a contact form.

I needed to quickly put together a site for the speed skating club where my family are members. At the moment, it is just plain old HTML and CSS. But I was thinking it might be a good basis for building a Symphony ensemble, now that they want to be able to update it.

Since I am donating the design, I might as well make it a project that I can donate to the Symphony community and document the process while I’m at it.

This is a real project (less pie in the sky dreaming), with more of a sense of urgency to it, so I’ll be more motivated to actually finish it.

Great Design, Stephen!

Thanks, Michael. :-)

I have been thinking about the default Symphony workspace today and have to admit that I never liked it but understood the idea of having some kind of unfinished learning environment. Adding a blog workspace could easily make Symphony “just another blogging platform” in the eyes of newcomers - which Symphony is definitely not.

But something feels strange about this concept: Symphony is all about perfection. Having a simple, clean interface. Giving the developer freedom to setup his own information architecture and offering him a way to fully control his HTML source code. The default workspace doesn’t fit into this at all: it is about - well - imperfection?

In my opinion there is an easy way to solve this problem by highlighting Symphony’s capabilities simultaneously:

  • We should offer a clean Symphony package that does not contain any workspace folder. This is the professional mode that every serious Symphony developer is already using (at least I am always deleting the workspace folder to create a clean workspace on install). This way you can setup your system from the ground up.
  • We should then add a few separate ensemble packages like a blog, a gallery, a member system. These are the showcase packages for beginners or those who just need a blog but don’t want to use Wordpress as they like the Symphony concept and look and feel. They offer a fully setup ensemble that you either have to life with or that you need to adjust depending on your needs.

Stephen, no worries about hijacking the thread, you are the ensemble master and your input is great!

Nils, I like that idea. Given Symphony 3’s filesystem-everything approach, I wonder if we can come up with something creative that would allow one to easily plug an ensemble’s architecture into an installation. It would be like Export Ensemble, but lighter — extracting only the relevant parts of the ensemble instead of the whole installation. (I guess this is Andrew’s modular ensembles idea.)

The major issue is how you handle conflicts — for example, if the installation and ensemble both have require a section called Articles, you’re kind of stuck.

@bauhouse

That sounds like a great start of a community supported ensemble package.

I just hope when the devs finish pushing out Symphony 3 the official ensembles will materialize… or any other arrangement that guarantees similar levels of support.

@nils

We should then add a few separate ensemble packages like a blog, a gallery, a member system.

Or it could even be a separate project/branding that runs alongside with Symphony, if there’s really a strong need to want to keep them apart.

Heck maybe that’ll mean it will get dedicated devs and communities; anything that can lead to ensembles that’s well maintained and supported is great.

I kind of like your approach Nils, but at the same time there exists a middle ground. Experienced developers certainly don’t “need” a blog ensemble or whatever as a demo workspace, even for their first go at Symphony. But there’s still a lot of “best practices” and other code snippets currently living in the default workspace that is useful to have as a “beginner to Symphony”.

I get your sentiment in the sense that, even in my first ever fiddling with Symphony I got “annoyed” by all the cruft in the default workspace. Still, it introduced me to the default XSLT parameters for one thing. But I think it would be frustating as well as a developer to download Symphony without a workspace folder. It’s helpful to be given an example, but as a developer you don’t need it in detail (“how to build a blog in 5 seconds”).

(Some rambling thoughts in the middle of the night.)

@Frode: Following this concept it should be no problem to offer a learning ensemble as well.

@Jonas: Concerning ensembles — I’d love to have a modular ensemble system. It would offer an easy way to add new functionality to a site, when you could simply add the calendar ensemble to the blog ensemble. It would need some kind of namespacing — alternatively it would be an idea to allow more then one workspace folder per installation, e. g. renaming workspace to ensembles, adding multiple ensemble workspaces inside that folder.

Hi All,

I’ve spun off the modular ensembles topic onto a new thread.

I go away on a three-day writing retreat, and wow, what an explosion of really helpful, thoughtful discussion. Maybe I should go away more often…

Just a few days ago I was in the shower and an image flashed into my head (no, it wasn’t Allen wearing a fake mustache and a cowboy hat, although that’s pretty funny). It had to do with this very topic, and I quickly wireframed it and sent it around to the team: downloads

The idea was for a small selection of fairly basic starter ensembles. These aren’t full-fledged ensembles necessarily, and wouldn’t replace the need for a growing collection of really polished community ensembles. But they’d sort of bootstrap certain kinds of scenarios—whether for production or just for learning and experimentation.

This was just a random thought on my part, and I’m not sure I like it any more or less than anything that’s been discussed here, but I thought I’d add it to the mix.

Craig, I like the look of that. How would it be maintained though? Every Symphony core and extension release would have to get integrated to keep each ensemble up to date. That’s not too bad, but certainly more effort for maintainers. Maybe we need something like Drupal’s Patterns module, so the end user could run some installation profiles instead to get the desired feature set.

Or, one other thought…the thing that’s quite incredible about WordPress is the ease of adding plugins; you can search for and install them straight away from the administration interface. Maybe it would make sense to centralize/automate the installation of extensions, XSLT utilities, and (if it ever happens) modular ensemble features such that you could do it from within the Symphony backend? If we were really smart about it, one could simply choose a “Blog” feature group and it would just push out whatever you need for that.

Maybe it would make sense to centralize/automate the installation of extensions, XSLT utilities, and (if it ever happens) modular ensemble features such that you could do it from within the Symphony backend?

We’ve been thinking about this for S3. Lots of hurdles though…

I like your sketch, Craig.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details