Symphony.

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.

Alpacaaa during the London Symposium this year surprised us with a Symphony installation packaging system called Builder. It pulls references from the symphony website and also from Github to create a selection of extensions and symphony release versions. I’ve yet to find the time to play with it and see how it can be used to offer a package builder for the Symphony website.

Nice wireframe, @czheng. I do like the idea of having more starter/reference ensembles. The pressure to have something perfect before I release it means I may never release it, but if we treat ensembles as sketches, there’s more possibility for contributions and collaboration.

It might even be good to have ensembles offered as either complete solutions or rough prototypes so people looking for downloads know the difference between the different grades of available ensembles.

@Allen, that’s kinda what I had in mind.

With the ensemble and extension issue, why not make the system automatically download updated extensions? The developer releases a update, people with that extension would get a notice about an extension update. If the user accepts, the extension would be automatically uploaded and installed. I think Wordpress and a few other CMS’s do this already, that is, they download updates for themselves through FTP and install it. Can’t this be done with extensions?

This is part of what we’re looking into. There are lots of issues here:

• some users install via FTP and some via Git + submodules
• we have to think through what compatibility issues we might run into
• we have to really solidify the extension system on this site if it’s going to be the basis for all this
• we have to figure out whether/how much to rely on Github, or assume extensions will be on Github

That’s just a few of the many. It’s definitely a priority for Symphony 3 though. May not be done by 3.0 but we’d like to have at least laid the groundwork for more elegant extension handling by then.

I like your sketch, Craig.

Me too.

@czheng These ensembles would be built only for Symphony 3? It will be “bread and butter” to maintain it on GitHub, and even to accept contributions. Also pushing developers to look forward to use and make S3 more solid.

Didn’t read the entire thread just yet, so I’m sorry if something has already been said.

I think the point of why to use symphony over other solutions should be what’s unique to symphony.

Lots of easy to install extensions won’t sell symphony to anyone, because it’s quite common and expected anyways.

We should go out and speak at barcamps, web mondays and other events alike to educate web workers on the advantages of XSLT, symphony’s non-page-based approach and its core philosophy instead.

Makes sense?

edit
Ok, so Nick already mentioned that. Anyway, go for it..! ;-)

@jensscherbl, I think that makes a lot of sense.

I see ensembles as a means to an end, that end being to show how flexible XSLT can be to develop really useful, well-crafted sites and applications.

If I show up at an event with a clean install or the default workspace, I’m not sure that it will be as compelling as a complete, fully-featured ensemble.

@bauhouse

Sounds like we’re on the same wavelength here.

As already mentioned in other comments, my guess would be that starting a symphony presentation with pre-packed ensembles leads to wrong assumptions about what symphony is and how it works.

But it’s a great way to show the possibilities of symphony once it’s clear to the audience how these ensembles are actually built and how easy it will be to build their very own that fits their project’s specific needs (once they got into it).

@jensscherbl

I think the point of why to use symphony over other solutions should be what’s unique to symphony.

Agreed.

Lots of easy to install extensions won’t sell symphony to anyone, because it’s quite common and expected anyways.

You just completely contradicted yourself in a single sentence. If it is quite common and people expect it, what do you think if they can’t find it? Yes, they will be turned off. It might not make a sale, it will darn well break one.

…leads to wrong assumptions about what symphony is and how it works

Withholding feature in fear of overshadowing Symphony’s advantage in flexibility is utterly ridiculous.

If that’s the method to influence the way people think about Symphony, then it will be the method that keeps people from thinking about Symphony.

But it’s a great way to show the possibilities of symphony once it’s clear to the audience how these ensembles are actually built and how easy it will be to build their very own that fits their project’s specific needs (once they got into it).

Does developers, or that professional (agency) developers have needs so diverse, that there is no noticeable common ground in terms of site component that they need to build?

Is offering nothing truly better than offering something that’s maybe 80~90% suitable in order not to “force people think a certain way”?

I beg to differ. You’re not forced to do anything, you’re CHOOSING to utilize this blogging ensemble, you’re CHOOSING to download that forum ensemble knowing fully well what you’re getting, and are fully prepared make the trade-off between time and coding structure/method.

Even yourself has stated that an extension(ensemble) ecosystem is common and something people expected. Why do people need a healthy ensemble/module/extension ecosystem? Because it saves time and money.

This is not a preference, this is a real need and a real factor in determining which system to use by devs; especially professional, agency devs that Symphony devs are so focused on.

You can have all the right W3C buzzword in the world but it won’t help the devs when they’re against a tight deadline and need stuff done fast.

The old systems have strong out-of-box features but lacks flexibility; if Symphony remains strong at flexibility but lacking out-of-box features it’ll be yet another cripple, just limping with the other foot instead.

@Shaw

You just completely contradicted yourself in a single sentence. If it is quite common and people expect it, what do you think if they can’t find it? Yes, they will be turned off. It might not make a sale, it will darn well break one.

I think you got me wrong.

Symphony should indeed have a healthy ecosystem.

But since that’s not what sets symphony apart from other systems, it’s not what we should concentrate on for promoting symphony to others.

@Shaw

do professional (agency) developers have needs so diverse, that there is no noticeable common ground in terms of site component that they need to build?

Exactly, of course there are common needs.

you’re CHOOSING to download that forum ensemble knowing fully well what you’re getting, and are fully prepared make the trade-off between time and coding structure/method.

This is the key to this idea: If done correctly, these ensembles could not only start you off a few steps ahead on a project, but also provide a common context to ask for help and provide feedback to improve the ensemble.

It seems like we are bouncing around two target audiences:

1) Professional web developers — I consider myself to be in this category (at least they pay me to do it.) My personal view is that I need flexibility in how I build something, because I have specific requirements I have to meet for my clients’ projects. In addition to flexibility, I want my tools to help me get hard things done as rapidly as possible. One good example is that Symphony’s XML treatment allows me to import lots of external content with almost no work.

2) Casual users / hobbyists — these folks are likely looking for a boxed solution to a specific problem (“I want a blog.”) They need common features that are easy to integrate, or already integrated. It needs to be easy to use. They may also want to tinker with Symphony’s functionality, templates, etc.

I think for the first group, Symphony’s flexibility is by far the biggest selling point. Not to say that these people don’t need to integrate common features — of course they do — but common features are not Symphony’s best strength right now. Given that, we should certainly work on ways to make it easier for developers to integrate the features they need with less effort. (I still think sample Ensembles are at best a partial solution to this problem.)

For the second group, sample ensembles will help them a lot, potentially representing the entirety of their needs.

I should add that at the moment, I choose Symphony when I need to build something custom, but I generally choose another CMS when I need common features like static pages, image galleries, etc. So what @Shaw is saying is right: if we fix this, I would have no reason to ever choose something else.

It seems like we are bouncing around two target audiences:

I’d urge anyone interested to read the findings of the Drupal 7 UX findings, where they have done a lot of research into their audience:

• Who is D7UX for?
• Drupal 7 UX: What about the developers?
• Designing for the wrong target audience (or why Drupal should be a developer tool and not a consumer product)

@nickdunn

From: Designing for the wrong target audience (or why Drupal should be a developer tool and not a consumer product)

There is one big problem with this approach, particularly if it touches the very core of Drupal. The changes that are required to the interface to really achieve the goal that we were tasked with – to really make Drupal understandable to Verity & Jeremy has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff.

I agree with this, if we’re talking about Drupal.

First reply to the article:

There’s nothing about being a first-rate framework that precludes building a first-rate application on top of it… in a secondary layer. That secondary layer can do all kinds of stuff, if the framework underneath it has been built properly, as a framework. If the framework underneath was built as just a support for the application, then it’s going to be a half-assed framework which leads to a half-assed application.

Which is precisely where Symphony is positioned.

Drupal

Layer 2: Plugins, Hacks, Themes…. etc. etc.

Layer 1: Core Engine + Features + Workflow

Symphony

Layer 2: Ensembles, Utilities, Plugins… etc. etc.

~~~~~~~~~ Giant Firewall Protecting Developer’s Precious Virginity (Edit: This is for humor only! I’m sorry if anyone’s offended, I mean I’m a developer myself, at least I’d like to think so) ~~~~~~~~~~~~

Layer 1: Core Engine

So if you think a particular ensemble is bothering you, just stop using it.

Symphony is not Drupal, there’s no reason that both audience can’t be served.

Shaw, you’re going to have to take it down a notch if this conversation is going to remain productive.

Remember that, just like the rest of us, you’re simply expressing one opinion among many. Your assessment of what Symphony is or should be isn’t necessarily one that everyone here agrees with. A little humility in that regard would go a long way toward helping us address the legitimate concerns raised in this thread.

@czheng

I apologize if anyone is offended by the “firewall” bit, I just tried to insert some humor in to the discussion (Come one, it’s hilarious, right?). And if using the various bold/italics for better emphasis come across as shouting, I apologize as well.

Other than that, I’m just making a counter argument to the points made in the article presented.

Now I figure I should just lurk around for a while so I’m not preventing other people from having an opinion wink wink.

No worries… we just have to be careful, that’s all. In this medium it can be easy to misconstrue someone’s tone or intention, and we’re all very committed to keeping the forum a comfortable, friendly, constructive environment. It’s awesome that so many people are so passionate about Symphony, but I just wanted to make sure we kept the discussion amicable.