Symphony.

Every time XSLT becomes polemic. As much of you guys already concluded, I am with Allen:

That said, while the concepts of XML/XSLT is vitally important, the language itself isn't.

XSLT is a true View of MVC! =]

And still is too much verbose... =[

Ok, moving on. Talking about adoption of Symphony, I was never able to understand completely my php compatriots developers. When I told them about Symphony they in fact understand Synfony (the framework), and I really don't know anyone personally that uses Synfony. The market say the rules most of the time and agencies are hiring (when PHP) CodeIgniters and Wordpressers, that's because the professional offers. So every corner we can find a nephew who can handle Wordpress (almost every blog have wordpress tutorials)... And my buddies are too busy or scared to waste some time in non-mainstream stuffs. I never met one that knew XSLT! =[

That point of view leads me to see a learning barrier for potential users. I mean, I myself when was looking for a IDEAL CMS and reach this Visual Overview I'm enlightened! This is decisive for me to learn XSLT and only then try Symphony (too much theory before practice discourages many). The documentation for learning on this site is good, but a little confusing in it organization. Looking forth for the new Factory Documentation. And maybe some videos tutorials put down this fear of unknown.

The second lack (and last) is the every-time-ground-zero. If build one website with a nice content module, the next website need to copy line by line, click by click, etc... Packages is very much needed. I think it's much more needed than alternatives for templating systems or whatever. I can't imagine how to do this, it's just a feature demand that I don't see discussions (the closest is Symphony Resources).

And still is too much verbose... =[

But that has to be a good thing; if it wasn't as verbose you risk having a template layer which also includes some 'model/control' stuff.

When I told them about Symphony they in fact understand Synfony (the framework)

This happens around here too; especially when a recruiting agency calls... well even direct companies at times even after Spelling it out they tend to get confused. Other then marketing and wider adoption there's not much that could change that I'm afraid.

If build one website with a nice content module, the next website need to copy line by line, click by click, etc...

I think there are ways to possibly go around this; though not properly documented. With the plan of Symphony 2.4 (XML for sections) I think this was one of the things that was going to be tackled properly. Currently I use pre-built ensambles to avoid this problem.

At my primary work the biggest project we have been given was essentially that of Splitting up the Main company's website into separate satellite sites.

I guess it depends on the use case. For something like a software ecosystem, I still prefer having everything tightly integrated and managed by a single entity.

Please have a look at this discussion regarding the domains

Thanks, must have missed that. I also like the subfolders variant best. Is a final decision already made in that regard?

But again, why make it separate installs? Couldn't this be handled by a single install? Different parts of the site could still be developed one after another or changed at different times. This would also simplify the authentication problem.

Other then marketing and wider adoption there's not much that could change that I'm afraid.

Renaming Symphony is still an option. As far as I remember, Allen already considered this, but they didn't find a better name back then. Also, a rebranding was on the table for the original Symphony 3.

With the plan of Symphony 2.4 (XML for sections) I think this was one of the things that was going to be tackled properly.

Exactly.

But again, why make it separate installs? Couldn't this be handled by a single install? Different parts of the site could still be developed one after another or changed at different times. This would also simplify the authentication problem.

If think the complexity of such a single install was the biggest problem of the development of this community site: You cannot update the entire install until you made sure everything works fine using the newer system – what if you need an update for the member handling that break the docs or extensions areas? Also permissions were a problem as far as I know.

As far as I remember, Allen already considered this, but they didn't find a better name back then.

Finding a name that sounds nice and works across languages is really hard – especially because Symphony really works well here.

But again, why make it separate installs? Couldn't this be handled by a single install? Different parts of the site could still be developed one after another or changed at different times. This would also simplify the authentication problem.

I don't mind having subfolders; but I would think separate installs would make it simpler to maintain. You can do updates to parts/sections not all together. You could also have smaller working groups which take responsibility for different sectors without overlapping each-other's work.

Grow Symphony's use by adding the designer's viewpoint to the website:

• Capture the good workflow examples from the forum entries in the main documentation. Don't limit to only documenting the core.
• As @germchaos said that packaging is crucial and I think it has to be up to date... stable package, bleeding edge package. It should be a package of packages including the most important submodules including email and login. Don't most software sites have Latest and Stable? Add designer dependance management.
• Have designers answer designer questions and developers answer developer questions. Symphony has a rich history of designer/developers with incredible backgrounds, but as you move forward I'm pretty sure that developers get sick of answering my stupid questions.

These points seem unaddressed in the present website. I don't have the history like many do on this forum and may have missed something, but have a strong desire to bring out the good points of Symphony to others who don't want to PHP.

I think we're starting to get off topic here. This isn't about the website, or the docs. We have threads for those. This is more about how we grow our community.

We need to aim this discussion as though we already had the website, and the docs, and discuss how we confront others in the wider web community about content management, adaptive content management, adaptive CMSs, COPE strategy, XML data transportation as a standard, tackling Drupal that everyone seems to aim for when they should be looking at us instead.

Like Stephen said, we need to get people looking in this direction, so we need an advocation strategy for the wider web.

It's a great talent of all developers (including myself) to focus on the details we see in front of us, like a website, documentation etc etc, and forget to envisage the wider picture. We can all work all the hours god sends on the site and docs until they're perfect, but if no one pulls people in to read them, we might as well not bother.

There are some big evangelists of standards out there. We all know the names, yet we as a proud community never approach these people and say "Hey, you know those standards you're always wishing a CMS would just do? You know that adaptive CMS your always wishing for? Well that's us!".

I tried contacting one recently after brief twitter conversations about content and COPE, and the response I got was basically "I don't have time to approach another CMS". I couldn't believe it. This person bangs on about all of the things we do being done wrong in Drupal, yet won't stop using Drupal.

We therefore also need to start banging the drum about ourselves, about XML and XSLT, microdata, COPE, etc etc, I could keep going.

Because of this, my blog will be finished soon, and I will regularly start annoying people ;o)

You are right. I made the same here with national (Brasil) web celebs, but they are such douchebags... They only follow trends and make a lot of effort to remain web celebs only talking about trends (in general, following USA trends). They rarely challenge themselves with some new and not mainstream. Also they are soooooo proud of their complete and irrefutable opinion, that if a "nobody" person (like me) point a perfect solution before, this attacks their vanity.

[edit] sorry, this is only my opinion and I know that is a bit aggressive. I cant deal with something like this 51.800 results bullshit mainstream... sorry again.

Thats why I mention break down some learning barriers. I can bet that it would have a strong result in the growth of the community. I'm starting write some articles to send on the wind and directly to popular blogs whith potential interest in this, like Nettuts...

I'm making some noise in national Google+ development communities and trying smooth to get their attention to this. One thing is certain: end-users admins love the Symphony admin because its simple, easy and very good looking. The challenge is convince beetle-head developers to make a simple test drive...

Grow Symphony's use by adding the designer's viewpoint to the website:

You could remove the words "to the website," although it's the only way I interact with Symphony, and insert "to your long-term vision of Symphony."

Are you going to try to get designers to use Symphony? Designer's will have too much difficulty with the documentation and "time to first product" for this to take off. The average person gives "something new" one chance.

Edit I really want to emphasize that whatever long-term choices you make they should have the audience in mind. I'm just not sure the audience is designers.

I'm just not sure the audience is designers.

Let me put it the other way around: I am pretty sure the primary audience isn't designers. Most designers I've worked with do not know nor care about the technology behind a website. They know what looks good, and how to bring a message across, and expect it to just work.

The thing that sold me to Symphony was that it is a CMS built for me (a developer). Designers love it because I can build anything with it, and clients love it because they do not need manuals to understand what they need to do.

Yet none of my clients has ever built their own website with Symphony after using it, neither have my designers. Some developer-type friends, however, are setting up Symphony for test runs after simply showing what I built with it. To them, it sells itself.

The answer is loud and clear. I'm just a little confused by the Symphony Ninja's site even distinguishing between designers and developers if Symphony is built for developers.

EDIT See my comment below.

Sometimes the line between designer and developer isn't all that distinct as it is. Some of us are both to some degree or other. I contract for a small (less than 10 employees) digital agency that mostly does video and motion graphics, but does flash games and web design too. There are two graphic designers there that have some basic flash and web development skills - they can set up and manage a wordpress site, add a theme and plugins and so on, build a simple flash game with cut and paste coding. Anything that needs a more development intensive approach comes to me (or gets outsourced if I'm overloaded with a project). They handle the majority of the design with my input. User experience and interaction design usually falls to me. I also tend to be the server admin and IT generalist.

I don't think Symphony excludes designers who have some development experience or are willing to learn, but as it's a "serious" and "best development practice"-led CMS, some technical ability is definitely required to get the most out of it, and really that's the way it should be. Those designers at my office probably could learn Symphony given the time and inclination, but not without a crash course from someone with development experience. I don't think plug and play design (except maybe with ensembles) is really fitting for Symphony's data-driven methodology anyway.

Perhaps I am in the minority as a designer who codes. I think a designer who is serious about front end development and crafting a site that does what they want it to do without the system getting in the way will love Symphony. But they have to make the proper investment of time to learn XSLT, just as they did to learn CSS. It's not easy, but it's well worth it.

I think beautifully designed ensembles for a variety of use cases would be an excellent way to grow the community. But, frankly, I'm having a hard time keeping up with the development of the Symphony core to be able to keep several ensembles up to date. To be able to maintain ensembles efficiently, it's best not to rely on extensions that are outside of the core, as it's only to possible to update the ensemble when the extension dependencies have also been updated. The more extensions installed, the more complicated an update is.

Perhaps if there was a clearing house of ideas for ensembles that people might like as starting points for various projects, we could use that to build a gallery of ensembles. But, it's not like creating a WordPress theme. Symphony does not have a standard database architecture. One thought I have had is to create a standard Symphony install that simulates a WordPress theme. Then, any WordPress theme could be adapted for use with Symphony.

On the other hand, is there a market for themes for Symphony? Symphony is more than a blog. Plus I know that Allen hates the idea of Symphony becoming a clearinghouse for themes. It might automatically lower the quality of the community.

As a designer, I would like to showcase Symphony as a serious designer's tool, for designers who code and love to have full control over user experience, code, functionality and data structure.

Perhaps I am in the minority as a designer who codes.

We happy few :)

Every designer I've showed Symphony to wants to use it more, but they really struggle getting the investment of time to wrap their head around XSLT. If more templating options were available alongside XSLT; moustache,blade et all. We'd potentially see more interest in adoption.

But in order to support this push to raise Symphonys profile to potential new comers, I'd like to see some video walk throughs like the ones Allen provided very early on in my adoption of Symphony. Nettuts style introductions are a great way of presenting the benefits of Symphony to a wider captive audience. The proof of the pudding is in the eating as they say.. so getting visual and moving visual examples out there of use cases would help sell the benefits of Symphony to a bigger group.

In my opinion.

Perhaps I am in the minority as a designer who codes.

We are coding as well, so you can add another two to the list.

But in order to support this push to raise Symphonys profile to potential new comers, I'd like to see some video walk throughs like the ones Allen provided very early on in my adoption of Symphony. Nettuts style introductions are a great way of presenting the benefits of Symphony to a wider captive audience.

I wholeheartedly agree!

I think what I'm saying about designer/developer relates to Symphony the software as compared to website creation in general. You have the developers who create extensions (using PHP), are experts at .htaccess, use git on a daily basis, regularly discuss the technology behind Symphony. Then you also have the designers who generally use the admin interface, learn XSLT, subscribe to the Ninja techniques, understand sections, and don't really like the command line. So how I responded to @creativedutchmen was not true.

The answer is loud and clear.

It is not clear, and I may be the odd person out.

To restate what Symphony needs to do to grow. I would like to see Symphony solidly prepared to market to the person who predominantly uses the admin interface. I would like to be able to plug-n-play with extensions without using the command line. I would like to take the latest stable core and be able to know how to add the best extension even if it's on the integration branch.

I would like to see Symphony solidly prepared to market to the person who predominantly uses the admin interface.

Agreed. Even though I'm a developer, I shouldn't have to dig into code when working on client projects (as long as the project doesn't need custom extensions).

As a trained designer and highly visual person: How could one not like the command line? :)