Symphony.

While it’s appealing, you should be cautious about telling people too much. If there’s a known vulnerability with a specific Symphony version, this makes it easy for people to spot the version you use. But it’s a good bit of PR to those who discover it :-)

If there’s a known vulnerability with a specific Symphony version, this makes it easy for people to spot the version you use.

In Symphony we trust…

@kanduvisla, I like the idea in principle, but I share Nick’s concerns. At the same time, if we are using the latest version, this shouldn’t be as much of an issue, since known vulnerabilities should have been squashed already and any newly discovered vulnerabilities are quickly attended to.

This does bring up the lack of a formal policy for reporting vulnerabilities.

Maybe a good middle of the road solution would be to state only the major version number.

 <meta name="generator" content="Symphony 2 - www.getsymphony.com" />

I would gladly write an article on why I decided to use Symphony on my personal website after testing out about 20 other systems!

I’m going to push to use it at work too, and depending on the site, suggest it over Wordpress - which most clients seem to want with no apparent reason other than it’s popular!

Anyone interested in contributing articles such as use cases, reviews or the like are welcome to submit to me on CMS Critic for publishing.

How a about building an all singing and dancing ensemble that can do (almost) what cloversites(see advanced demo) can do, and promote that foremost, and only the bare symphony after that? I always get the feeling that newcomers just dont grasp the shear posibilities by looking at a naked install and a list of extensions. You need to see it ‘in action’…

That’s kind of counter to the whole philosophy of Symphony, though. It’s not a swiss army knife CMS that tries to do everything for everyone out of the box. Building that kind of ensemble, in my opinion, would really misrepresent what Symphony is and why it’s great.

That said, we definitely need more impressive, purpose-built ensembles. It’s been on the team’s To Do list forever, but the time is just never there…

I know what you mean czheng, but marketing is about the shiny packaging and the lighting in the shops, even if the product in question is much more zen and doesn’t need all those extra’s…. You can first lure new audiences with a super-ensemble, and then continue to educate them on the modularity of symphony…

Yeah, I understand the sentiment, but I think that the audience you lure with a super-ensemble isn’t necessarily the right audience for Symphony. It’s kind of like using a buffet of brownies and ice cream to lure people to health food store.

I’ve been interested in trying out Symphony for sometimes now and just had to throw in my 2 cents here…

I personally would jump on this thing if it has an official, fully featured ensemble that ships with the core.

I think that being lean and clean should apply to the Core engine only, it shouldn’t mean the lack of functionality out of box; and being flexible should apply to the ease of switching/modifying the officially supported and developed ensemble with something else, it shouldn’t mean forcing people to reinvent the wheel when there are established common functions people needs on the web.

I mean look at ExpressionEngine, this is arguably the most popular recent CMS. And while it provides much of the same functionality out of the box as WordPress, nobody is criticizing it as inflexible or bloated.

Right now the system is catering to experienced developers who are looking to create highly custom, specialized structure/workflows and found current CMS restrictive in that regards.

But those people are not that many, and they don’t have time to lurk in forums all day long to help newbies. The people who really drive a CMS system’s popularity are NOT the most experienced developers or professionals, it’s inexperienced developers and people who do this as a hobby/side-projects.

What do those people need? They need functionality out of box that WORKS and are OFFICIALLY SUPPORTED. They don’t want to spend 10x the time compare to other systems just to get a basic blog/forum/gallery setup going.

If you don’t expose XSLT to them and let them invest some time into it, when they need to go deeper then they already have a stake in the system and they will be much more willing to sit down and learn bit by bit to add/tweak the functions; instead of literally throwing them to the wolves right now.

Is the decision to not provide a fully featured, officially supported ensemble a real benefit to the lean-ness and flexible-ness of the system, or is it just about making a philosophical statement?

If it is the later - which I believe it is - then it is a rather empty statement if you can’t get enough users to adopt.

Edit: if you say newbies/hobbyists are not your target audience, who’s going help you make a mature product? Who’s going to install and actively use new releases/beta versions potentially with critical bugs? Nobody professional will touch that with a 10-foot-pole. These people help you iron out bugs and test new features; and if you throw out the baby - official functionalities, with the bath water - the inflexibility which USED to accompany with all those functionalities in older CMSes (but not anymore since they’re ensembles in Symphony), then I think you’ll be doing yourself a great disservice.

If you download Symphony as a ZIP file from the website it contains a default ensemble which is set up as a blog. If you want an officially-supported blogging system then go for Wordpress, without a doubt. The danger of providing a more complex ensemble is that people will make a quick assumption that Symphony is “yet another” blogging application.

My argument is that if you want or need “out of the box” functionality like blogs, forums, calendars and events and so on, then go for something like Drupal or Joomla that offer these as complete modules.

I don’t think the case for marketing and promotion isn’t to try and attract every single developer who might be wanting a CMS. There’s little point in trying to “steal” those already comfortable with the Wordpress or ExpressionEngines of the world — they’re happy with their tools and workflow. But Symphony is marketed as something different; a remedy to the pain and frustration developers can experience while using these other systems.

I don’t think the intention is to attract newbie developers. Symphony is far too overwhelming in that regard, and it assumes a level of experience on the part of the developer. Every so often we get a forum thread asking how to “edit the CSS” or “change the navigation”. It’s an incredibly ambiguous question when you consider that Symphony doesn’t have default functionality, themes or templates (beyond the “default ensemble”). I don’t think Symphony is aimed at this sort of person.

The partial abandonment (?) of the Drupal UX project was partly down to this very problem: who do you design for? Target the lowest common denominator and you risk dumbing the system down and making the advanced things difficult to achieve. Target the highest denominator and you risk repudiating the less experienced.

http://www.disambiguity.com/designing-for-the-wrong-target-audience/

Symphony has never really been about providing anything out of the box — the default ensemble is intended as a learning tool. It provides you with the tools to build the stuff you and your clients need.

I think the book will go a long way to demonstrating what Symphony is, without the need for out of the box ensembles.

Shaw,

Thanks for this, you make some very good points! I agree that there needs to be a way to get up and running without delving into every little detail of the system, learning XSLT, and having to explore the extension ecosystem too much. I have seen this as a barrier for even professional developers: If they need to spend >6 hours to see the advantages of the software, they take that as a bad sign.

My idea for this would be Communty-Supported Ensembles. These would be conceived to address common needs and uses: Blog, Page-based site, etc. These would be full-featured enough to provide comparable usability to other CMSs, but general enough that not alot of teardown would be needed for developers wanting to customize. Most importantly, they would integrate up-to-date releases of both the core, and necessary extensions. This relieves new users of needing to determine which are the best extensions to use for a task, or how to use them.

These would not ship with the core, but would be featured as more complete solutions for users just starting out. If these were stable enough, orientation tutorials could be written to accompany these ensembles.

These would not just be extension implementation examples, but ready-to-go for users wanting to use the system without breaking their nose when they hit the learning curve.

I will agree with Nick that Wordpress et al. is all some folks need. Symphony probably won’t out-blog Wordress, at least not in any practical timeframe.

I don’t think the intention is to attract newbie developers. Symphony is far too overwhelming in that regard, and it assumes a level of experience on the part of the developer.

Why does Symphony has to be difficult to use? No it doesn’t, even if the user interface and experience is not there yet there’s no reason not to be shooting for it.

Plus, even if there is a steeper learning curve it is most in the setup and building of functions, if you provide a full-featured and supported default ensemble then people can get something functional NOW and then learn while modding what they have piece by piece, instead of giving them nothing and ask them to build Rome.

Target the lowest common denominator and you risk dumbing the system down and making the advanced things difficult to achieve.

There is NO reason for that to be the case if the fully-featured ensemble is kept separate from the core, as it should be.

The point here is adoption, if you provide full featured ensembles to newbies then they will grow along with their understanding of the system. The advantage of a system that is open source as well as extremely flexible is going to affect their decision choosing between different system greatly.

And later on when they go on to develop custom applications, guess which system they will choose? The one that they learned while doing their blogs and which is still perfect for the big job.

Symphony has never really been about providing anything out of the box — the default ensemble is intended as a learning tool. It provides you with the tools to build the stuff you and your clients need.

And yet there’s a thread asking for ideas on how to expand user base.

All I am saying is the problem with past systems are not the feature/functions included, but the way those features/functions are included - too integrated into the core leading to difficulties going about things in other ways.

With all things said and done those included features/functions are useful and are commonly used; why reinvent the wheel just to make a point?

This is basically shouting: “We are flexible! We are so flexible we do not provide something a lot of people commonly uses, you have to make your own! That’s how flexible we are!” While it should be: “We are flexible! We are so flexible it is a breeze to switch with and add onto our provided functionalities and work-flows people commonly use with custom ones you created!”

Thanks for this, you make some very good points! I agree that there needs to be a way to get up and running without delving into every little detail of the system, learning XSLT, and having to explore the extension ecosystem too much. I have seen this as a barrier for even professional developers: If they need to spend >6 hours to see the advantages of the software, they take that as a bad sign.

These would not just be extension implementation examples, but ready-to-go for users wanting to use the system without breaking their nose when they hit the learning curve.

Thanks, exactly the points I’m trying to raise here.

My idea for this would be Communty-Supported Ensembles.

If it means that these would be the de-facto ensembles then I’m all for them.

The reason I proposed those as officially supported and included solution is because in my limited experience when left to the community it inevitably leads to fragmentation (Karl’s Blog Systems, David’s News Blog… etc.), which divides developer’s effort, support effort, knowledge base (a fix for Karl’s system is not compatible with David’s); as well as create a barrier for an ecosystem - it is much more productive and useful to develop an module that integrate with an offcial forum module than to develop an module to Karl’s Forum.

In addition, having a unified official module ecosystem means that the coding style will be kept uniform, and encourage tightly integrated modules that links and enhances multiple other modules - which would be a nightmare if there’s 4 different versions of every module with no official sanction on anyone of them.

This is even more relevant for budding communities with limited man-power in terms of development and support.

I completely agree with Shaw. You hit the nail on the head. There should be more user friendly functions (ensembles, blog, maybe image gallery, etc) that come with the default ensemble for those who are not full time developers. And as they use the system (the default blog, for example), they will naturally want to customize their setup which will lead them to making more things for the system.

The default ensemble is lacking. You can post articles and notes and thats it. The category system is incomplete, there is no tagging. It is difficult to add any other media without the aid of an extension which does not come included. This is one of the reasons I left Symphony in 2008 (only later to come back) because it took a long time just get something trivial like pagination to work. My point is that more functionality should be added to the default ensemble so that new users don’t have such a steep learning curve.

Symphony stands in the middle between an application and a framework. Ensembles are our application. The core is our framework.

Agency developers use a combination of extensions and existing library of XSLT utilities to help speed up development. Non-developer users have a different need; We identify that this is not being satisfied by the system currently.

Right now the team are are concentrating on Symphony 2.2, Symphony 3 and platform features for our community website such as update notification, better extension update system.

The goal is to eventually offer officially supported, well produced quality ensembles. We have vision for Symphony ensembles in our future that would allow the community to create quality ensembles for a market of users who are not developers by trade and hopefully be compensated for their efforts.

The default workspace is purposely lacking in features. This should not be seen as the same as what we have in mind for ensembles. Symphony’s default workspace is a teaching tool; not a feature-rich system. User features add to the noise of the core concepts we want to impart to a new user.

Symphony’s default workspace is a teaching tool; not a feature-rich system. User features add to the noise of the core concepts we want to impart to a new user.

This is a great point. We need two sets of ensembles, one for teaching concepts and one for purposeful application reuse (with moderate customization if necessary.) These may start to overlap — is an Image Gallery ensemble a teaching tool or a starter site you’re going to build with?

You can see that Drupal has taken a step in the application direction with Drupal Gardens. That’s a good example of what we’re missing with Symphony right now — taking a complex framework/platform and offering generic boxed sites built on it. But creating quality ensembles is no small feat, particularly to build them such that they can be easily customized for reuse.

I would vote against the idea of an über-ensemble that demonstrates every last feature you might want — it’s not going to end up very coherent.

Agency developers use a combination of extensions and existing library of XSLT utilities to help speed up development. Non-developer users have a different need; We identify that this is not being satisfied by the system currently.

I’m not so sure their needs are as different as it may appear.

Just because one developer need something very custom doesn’t mean he doesn’t need a blog/forum done real quick as well.

The goal is to eventually offer officially supported, well produced quality ensembles.

Sounds like a great plan, but in the interim shouldn’t there be something that can temporarily fill that role so less-experienced developers and/or designers can also get their hands wet with Symphony?

And… of course as a result gaining more exposure/user-base for Symphony, which is the topic of this thread.

The default workspace is purposely lacking in features. This should not be seen as the same as what we have in mind for ensembles. Symphony’s default workspace is a teaching tool; not a feature-rich system. User features add to the noise of the core concepts we want to impart to a new user.

There’s no reason the official ensembles can’t be provided separately or requiring it to be “activated”.

The main point is to have the common functions to be there and be officially supported and updated as a dependable starting point.

I would vote against the idea of an über-ensemble that demonstrates every last feature you might want — it’s not going to end up very coherent.

Even WordPress doesn’t try to include every last feature; but there needs to be enough feature for it be considered as a proper component, rather than a slightly beefed up coding example.

@Shaw, I don’t disagree with any of your points…but the challenge of developing boxed ensembles is figuring out which features are worth demonstrating, and then which approach is best for architecting those features.

The “killer app” of Symphony is that it can be anything — you could build an image gallery 30 different ways. So which way should we do it in the image gallery ensemble? The answer really depends on what you want it to do.

By building a site off of a pre-made ensemble, you’re stuck with someone else’s idea about how an image gallery would work. Maybe that’s OK in most cases, but does lead you to miss out on some of Symphony’s Awesomeness.

but the challenge of developing boxed ensembles is figuring out which features are worth demonstrating, and then which approach is best for architecting those features.

I think the standard CMS features are pretty established, Blogs, Forum, Gallery; Comments, Comment Moderation, Anti-Spam (Akismet, Defensio etc.), Media Uploading. Hmmm anything else? Really not much.

The “killer app” of Symphony is that it can be anything — you could build an image gallery 30 different ways.

I agree about the “killer app” being flexibility, but I disagree about building image gallery 30 different ways, or a blog, or a forum.

Just because you can doesn’t mean you should; with more than a decade of web experience people have come to expect conventions to be followed, certain things to EXPECT from a blog, a forum and a gallery. Most people don’t build a website for themselves, but for an employer, the visitors, or other users.

Those users have expectations that things work as they expected them to work, and they have every right to expect that.

Therefore I argue unless there are very good reasons to deviate from the norm, a blog should function like a blog should, so do forums and galleries.

And if you need something really different to be build, then you can use the “killer app”; but it makes no sense to go off accepted convention “just because you can”.

By building a site off of a pre-made ensemble, you’re stuck with someone else’s idea about how an image gallery would work. Maybe that’s OK in most cases, but does lead you to miss out on some of Symphony’s Awesomeness.

Again, the one that would end up be the official ensemble will not be someone else’s idea, it would be what most people expect, and it will be the RIGHT choice in most cases because of that.

Symphony’s Awesomeness is that when the time comes that you need to do things a certain way, you can.