Symphony.

With the release of Symphony 2.4, a question that I've heard a lot over the course of the last couple of years came up again: Will Subsection Manager be updated to the latest Symphony version?

The answer is twofold. No, Subsection Manager as you know it will not be updated. The underlying concept is too complex, not focussed on the right things and does not scale well. Still, the basic ideas behind the UI – the search, the inline editor – are very useful when handling associations and lacking in Symphony so far.

With this post, we'll offer you a concept how to replace Subsection Manager with something new, more versatile and interchangeable based on the latest Symphony features: the Association Interface. To bring this idea to life, we're offering our time and expertise in turn for funding by you, the community.

Starting Point

The core functions for relationship management are offered by Symphony itself. Thanks to the commitment of John Porter, we have a solid base for managing associations which Symphony exposes in a simple interface in the right drawer since version 2.3.

Besides Subsection Manager, there are two major extensions dealing with associations:

• Select Box Link and
• Select Box Link Plus

While the first is quite robust, it's lacking a real UI. The second one is similar to Subsection Manager in terms of complexity: although it shares name with the official SBL extension, it's a separate field with a very complex set of features (I'd say, it's even more complex than SSM).

The main problem with all existing solutions available: they can't replace each other without you editing the database and your entries by hand. All extensions focus on their own field instances and don't look at the broader concept of associations, that is also used by default select boxes and tag lists (the usage of "dynamic values" creates associations that can be shown in the entry indexes).

Step 1: Combining Subsection Manager, Duplicators and Selectize

As of version 2.4, Symphony includes Selectize, a hybrid text and select box. Combining its features with core interface components like Symphony Duplicators and our know-how of building Subsection Manager allows the development of a fast, feature-rich UI for finding and attaching entries. This UI can enhance select boxes, tags list and Select Box Link fields alike. Using JavaScript and CSS only, the interface can be plugged into existing installs without having to change the field or section structure. It can be switched on and off without affecting data storage. So the kind of Assocition UI we'd like to build will be a real add-on you can use to enhance and streamline the user experience.

It will be compatible with Symphony 2.4 and above.

Step 2: Inline Editing

Subsection Manager proved that displaying and editing associated entries inline reduces cognitive complexity of association management. The main problem was the implementation that relied on a small, space-limited iframe inside the Duplicator interface. But inline editing is not about previewing content, it's about creating content. It needs space.

Our idea is to create a new inline editor that builds on the existing layout structure of the backend. Symphony's main content area looks like a sheet of paper, so let's do what we do with real paper when we read and write: stack it. Think of one sheet for one Symphony entry: we can pop up the child entry we'd like to edit on top of its parent and return to the parent entry when we're done. The inline editor will overlay the current content area, still showing the header of the parent in order to make the context and hierachy clear.

Basecamp has been doing something similar for a few years.

Step 3: Nested and Sortable Data Source output

Two features have been very prominent in Subsection Manager: nested and sortable Data Source output.

Nested or inline output of associated entries has been a time saver when you create your Data Sources. It also simplified logic in your templates because you didn't have to match data across node sets. The idea is to provide these features as a separate extension so they can be used independently of the UI. In order to improve performance compared to Subsection Manager, the extension should create virtual Data Sources that replicate the logic internally that you'd normally have to setup by hand: the virtual Data Sources should fetch IDs from the existing XML tree (like using output parameters), load the child data using the Symphony Data Source class (like adding a secondary Data Source filtered by these parameters) and add the result to your associated entries (this is what you normally do in your XML by matching different nodes based on entry IDs). The Data Source editor can be enhanced to offer a selection of fields to be returned in the XML.

Sort order can be determined by storage order in the database. So the Association UI just needs to offer an additional sorting feature to set the order.

Funding Goals

Creating an association interface for Symphony is a complex task. We are aware of this as we have been supporting the Symphony community with Subsection Manager over the last four years. It takes time to build and test the components and it also takes time to maintain and update them over time. That's why we'd kindly like to ask you to support this project to lift association management to a new level.

These are our funding goals:

1. 500€: Work on the Association UI will begin in a private repository only donators will have access to.
2. 1000€: Work on the inline editor will begin and the Association UI will be made available to everyone.
3. 1500€: Work on nested and sortable Data Source output will begin.

Donations: 1740,70€

By Bernardo Dias da Cruz, Ben Babcock, Juraj Kapsz, Daniel Golbig, Vojtech Grec, Andrea Buran, Brendan Abbot, Roman Klein, Korelogic, Ngai Kam Wing, David Oliver, Patrick Probst, Mario Butera, John Puddephatt, Goldwiege, Andrew Minton, munki-boy, Martijn Kremers, Ian Young, Leo Nikkilä, Jonathan Mifsud and others.

Thanks for your support!

Nils and Johanna
hana+nils, http://hananils.de

FAQ

What happens if you don't reach the first funding goal?

We'll refund donations in this case.

I'd like to donate anonymously. Can you please exclude me from the list of donors?

Just drop us a line at buero@hananils.de.

This sounds really interesting and I definitively would love too see a solid solution for association interfaces happen.

I didn't use Subsection Manager more than once or twice, but I heavily relied on the alternate interfaces (mostly autocomplete & multiple checkboxes) Select Box Link Plus and Reference Link used to offer. I say used to, because as of S2.3.3 and the switch to jQuery2+ things became quite buggy with both of them.

As I'm currently working on a few projects based on S2.3.6 and couldn't do it without these alternate interface views I thought about what the best solution to get them running again would be. As fields aren't interchangeable I never really liked the technical concept behind Reference Link and SBL+ - they were somehow based on SBL, but still seperate extensions that needed to be supported and compatible when updating Symphony. But the way SBL+ offers different views for one field is absolutely great and exactly the way it should be done in my eyes. Only not by an additional extension, but by the "core" field that manages associations. Thinking a little further that core field better wouldn't even be based on a certain kind of view but simply offer a basic package of "association functionality" that then could be presented (and maybe extended) by different views.

So instead of waiting for updates for Reference Link and SBL+ I thought I'd better give it myself a try and came up with a solution that roughly sounds like this:

1. Select Box Link Field should be named Association Field
2. It should not be coupled to one view, but like SBL+ be able to handle many views
3. Unlike SBL+ not all of these views should be part of the extension
4. The extension itself might offer 2-3 rather simple "core views"
5. I thought "Selectbox", "Autoselect" and "Checkboxes/Radiobuttons" would be a good start for that
6. Other Views should be pulled from other extensions, but listed in the settings-panel of the Association Field
7. The database structure of "Association Field" should directly offer the possibility to store a sorting-order of associated entries
8. Actual Usage of that sorting feature should be provided by the view

Apart form the sorting order feature I already got this up and running, though my autocomplete-view (based on selectize) is pretty rough yet and still needs a lot of refinement.
I mostly built this for my own needs and didn't mean to publish it as yet another association-extension. SBL+ caused enough trouble back then ;)

But when finished I would have somehow published it as a of proof of concept and tried to start a discussion about handling association views and what of these thoughts might made sense to the community. I know that my proposal completely ignores the aspect of inline editing, but I never really had demand for it and thought this might be better off as a separate solution.

Still might finish this field for my current projects, but now as Nils seems to strive for a even broader and more challenging solution I thought I just might post my thoughts now as they not only share the same topic, but also help to explain where the following questions come from :)

So I'd really like to know if your solution...

1. ...would allow to select a specific view per single field (i.e. have different views for SBL in one section)?
2. ...would offer the opportunity to develop/include my own views (like simple multiple checkboxes)?
3. ...would offer the possibility to make associations sortable?

Compared to your complex proposal these are rather small tasks, but that's what I actually need in most of my projects.

I'd be happy to support your solution if all of this would be the case, but I'd be even happier if some of my thoughts regarding changing the basic SBL Field to become a more flexible and solid foundation for all kind of association-interfaces might be considered to be combined with your ideas. I think they might fit in pretty well :)

I will answer more detailed later, but just a few notes on your questions:

1. ...would allow to select a specific view per single field (i.e. have different views for SBL in one section)?

Yes, the idea is to add an UI select box to the section editor which lets you choose the desired view on a per field basis (for select boxes, tags lists and SBL fields).

2. ...would offer the opportunity to develop/include my own views (like simple multiple checkboxes)?

In my eyes, it's a good idea to have a unified concept to select UIs but the different UI should not be bundled in one big extensions. It's easier to maintain small extensions, so I'd create one extension per UI (e. g. one based on Selectize, one providing image grids etc.).

The Association UI extension can be used as a prototype for other UI extensions (clone it, adapt it to your needs, publish it). Additionally, Symphony could be updated to offer a way to register UIs for associative fields (SBL, select boxes, tags lists). But I actually think this is not necessary if extensions follow the same concept how to attach interfaces – setting the needed standards is part of this project.

3. ...would offer the possibility to make associations sortable?

That's the idea, yes. Symphony Duplicators and Selectize both offer sorting features, so this should not be hard to implement.

That's why we'd kindly like to ask you to support this project to lift association management to a new level.

Why not just make it a commercial extension?

Why not just make it a commercial extension?

I feel having this would greatly benefit the whole Symphony community, and in return the community will come and improve this extension, like it usually does. Even the whole 1500€ will most likely not cover all the time/expenses Johanna and Nils will be putting into this. But if it can serve as a kickstart for a powerful, extensible new tool I’m all for it.

I feel having this would greatly benefit the whole Symphony community

Sure, but I don't think the crowdfunding approach is sustainable in the long term for that kind of thing.

People who fund it don't know in advance if it will be any good or useful to them, Nils on the other hand won't get any money for supporting and maintaining the extension in the future.

Also, would the community also fund another extension and another extension? What about core development?

Commercial extensions would be a better way in my opinion. Or maybe make the extension free (if the community can't be trusted to pay for using it in production), but only provide commercial support instead.

Sorry, I guess this is off-topic and Nils already decided to go with the crowdfunding approach. We could discuss this in another thread if someone else is interested in this kind of thing.

Sorry, I guess this is off-topic and Nils already decided to go with the crowdfunding approach. We could discuss this in another thread if someone else is interested in this kind of thing.

No, that's an important discussion. Personally, I think a combination might be interesting: use funding to kick off things and add a small per site licence fee for production use when development is finished (giving the funders a unlimited free licence of course). I like the way Kirby handles this as it gives you the code free for evaluation but applies a fee in the end.

Nevertheless, I noticed that while people demand features a lot, they are not necessarily willing to pay for it.

Sure, but I don't think the crowdfunding approach is sustainable in the long term for that kind of thing.

I see your point. It sure is a bit of a philosophical dilemma. Like the future of symphony itself, which a lot of people are willing to discuss in great detail, but very few people are able to contribute to actively.

If there are parties interested in having this developed: Why not pay for it, if it wouldn’t be developed at all otherwise?

If there are parties interested in having this developed: Why not pay for it, if it wouldn’t be developed at all otherwise?

Sure.

No, that's an important discussion.

Thanks.

Is there the Symphony community large enough to support the idea of commercial extensions?.

My guess is that there's no market at all. So Nils' funding approach is probably a good way to get this started.

Awesome initiative Nils, once again :)

You probably can make use of both ways, crowdfunding to launch and commercial support in long term.

I'm one who really want to see this idea came to life, the Inline Editing idea is fabulous, also behaving like an add-on upon the SBL field is even better.

Donated! (I wish I could donate more, but EUR to BRL + Taxes is not much fair :P)

Good luck, and please let me know how can I help with!

Cheers

Thanks a lot Bernardo for your support! You are our first donor.
I added the sum of donations to the initial post and started a list of donors. If you don't want to be listed there, drop us a line at buero@hananils.de.

Regarding commercial extensions, I agree with Thomas that our community base is to small to refinance the development of an extension by just charging a small amount of money for it. You'd have to deliver up front without knowing if you get at least a appreciable sum in the end. That's why I think kick-starting a project like ours with fundraising is a good idea.

Of course, you'll buy a pig in a poke but we have been contributing to the core and the extension eco system for years so that people get a picture of our work and should be able to evaluate its quality.

We are entering new territory because this has not been done before in our community and I have thought about your comments above. It would be great, if we could agree on some kind of "Symphony Commercial Extension Licence". A licence similar to MIT but with one restriction: if you'd like to use the extension in production you'll have to pay a small, per install licence fee (like 15 EUR). If the extension was funded by donations, donors will be given a free licence without restriction.

This should of course not be the default licence for extensions, a free open source MIT licence is fine in most cases, but it would be great to have a standardized commercial option as well.

I have to say, I'm not very happy reading this at all.

Symphony is an open source and free product, and over the years, I would have loved to have charged for my time that I ploughed into the product and community, but didn't because of that single point; Free.

The new design was paid for, and look what happened there.

I for one would certainly never be happy paying someone to use an extension, it goes against everything Symphony stands for. We make the tools for people to make their money, we do not charge people for useful bits of interface.

No.

I agree with John regarding an extension installation fee. I’d rather see them free like symphony itself.

Kickstarting an extension that can be developed further by the community is a different kind of animal.

Symphony extensions have always been sponsored. Either by clients that requested a feature or by agencies that developed their own toolkit. Symphony is open source, yes, but why does that mean that all the work has to be done for free?

I've received a lot of requests to add this or that to extensions like Subsection Manager, an extension that has grown far beyond its initial purpose. It was an imense task to maintain it over the last years and my point of view is quite clear: if no one is willing to support the work in someway, it's not really needed and there is no need for me to work on it.

The new design was paid for, and look what happened there.

This is a different story and not related to our work which is available on Github as appointed. The problem here was that suddenly all members maintaining community sites – especially Allen – left for different reasons.

Alex, I know that licence fees would be new to the Symphony community but initial funding doesn't provide a base for longterm support. This is why I think it's an interesting idea to consider, especially because there are a lot of members in our community that rely on other people to create extensions for them. We've once experimented with voluntary donations via Gitip and this didn't work out at all.

Regarding this project, we said "Association UI will be made available to everyone" which means MIT licence in this case.

Still I think it's important to discuss commercial options here.

@Nils I see your point. I’m still not sure if a fee would be solving this particular problem. But I agree it should be discussed.

Are there any commercial extensions out there somewhere?

Are there any commercial extensions out there somewhere?

Not in the Symphony community but think of themes or plugins for other systems like Drupal or Wordpress.

The reason why we are all not sure about the future of Symphony is not because of the quality of the system but because of the missing foundation. Symphony 1 was created and maintained by Twentyone Degrees, Symphony 2 was first supported by Airlock then by Soario. There has always been a commercial fundament until one and a half years ago.

Symphony is an open source and free product, and over the years, I would have loved to have charged for my time that I ploughed into the product and community, but didn't because of that single point; Free.

The way I see it, Symphony being free and designers and developers being paid for special features is not contradictory at all. I remember working on the website for our student film festival back in the days using version 1.6 or 1.7, and we desperately needed a gallery option. We paid Twentyone Degrees to develop the "frontend editing" and "photo gallery" extensions for us (which I think were cross-financed by Stephen as well, or something along that line). They were then released for everone to use.

With this proposal, Nils and I are offering an idea and "work time" to develop something interesting here, just like we did with the design and release of Symphony Factory. It is indeed sad to see that nothing has sprung from the funded framework, that it hasn't really been put to use. I sure hope (and am pretty certain) this would be very different with the Assocation Interface, as it hopefully makes things easier within using Symphony - instead of it being another big project to take care of (like using Factory to rebuild a Symphony website).