Symphony.

I would love to do away with linking field altogether and have a separate area of the admin to handle associations, but that is a pipe dream I fear.

Thought the same thing yesterday.

I tried the new associations stuff for the first time today, and I find it quite confusing that it seems to just bypass the core associations workflow and reintroduces a newer version of subsection manager instead, while keeping the core associations UI unused and intact.

I didn't want to word it like that, but that is exactly what I thought.

Anyway, here are excerpts from what I emailed Nils recently as what needs to be achieved.

With having time to actually think this through more, I realise that I have taken the easy approach with core associations by implementing the Drawer, yet leaving the actual associations to the Fields. In all honesty, this alone is where the real flaw is, and it's understandable why yourself and other community members want to maintain this all at a Field level. The intention from my end was to always go away from Fields, but it looks like doing this incrementally has caused disagreements, and I may not have explained that properly, if at all.

Associations are intrinsically Section based, and the old Section Link Field understood this to some degree, although had a poor UI and was based around the 'Field' concept as Symphony was limited to this, being one of it's core tenets. While the team originally perfectly understood how associations work on a logic level, they never got the UX/UI right from a user level, and it's this reason that the 'Field' idea has propagated for so long. The Field concept is a database level idea, and with Sections trying to mimic databases to some degree, its understandable that a team lacking UX/UI experience would do it the way it was done.

For it to work properly in a CMS context though, it shouldn't be Field based. I'm doing my usual here, and not thinking about a pragmatic approach ;)

I had the idea in all my research to change, fundamentally, how Symphony handles associations. Fields like the Select Box would still be around, but Fields like the Select Box Link wouldn't. I know what to do in theory to achieve this, but didn't tackle it then, as I thought it would just be me working on it, and there was no chance in hell I would have completed it ;)

So in outline, a developer would create all of their Sections. If they wanted to link a simple list, whether it be from a Section, or hardcoded, then the Select Box would be used. No other 'Section' based associations are done yet though.

Once all the Sections are completed, the developer stays in the Sections index, and opens an Associations Drawer. Now, this Drawer is a little bigger and more functional than the other ones, and houses details on Section based associations. This may be better having a separate area of the CMS for this though, I have ideas ;)

The dev would choose the parent section, and the child section. They would also be able to write a reflection style xPath for each one, so that the link isn't simply one single field, but is the entire Entry to Entry. Doing things this way means that constraints can be added to these associations, like one to one, one to many. When it comes to many to many, there would just be another association entry. Other constraints could be applied, like jpeg only images for example.

We have section_associations and we would need entry_associations all core managed. Fields are not the right place for this kind of information as it's not Fields that are associating, but Sections and Entries. We all know how limiting it is, and how many hoops we have to jump through to make Field to Field associations work properly, and that's because the core is a half baked idea in progress that never got finished properly. I don't think it would be a parallel universe to finally put the right control in place for this information. It's not content (data as you put it), but relational logic.

I am strting to think after writing all this, that the Drawer may already be an outmoded concept here, and your modal style UI sits better with me for managing associations at an Entry creation/edit level...

So to recap quickly:

1. A new area of the CMS, Associations, to handle the relevant association management. I can see (in my crystal ball) a drag and drop interface for creating new associations, and a row based list of existing ones. Maybe having a modal style like your new interface for new associations. This needs some brain time.
2. A new core component, AssociationManager which takes away all control from Sections and Fields, and even the publish page code for Drawer creation.
3. Use of functionality that was updated by Remie recently for exporting values as string etc.
4. Use of Reflection technology to create the associating strings, or even image output.

For the future:

1. Think about datasource style approaches to associations. Filterable datasources that associations can harness to pre-filter lists of entries to associate.

@designermonkey It's taken Nils recent extensions, two site migrations and then your words in this thread for me to really understand this concept.

It's like I've been repeatedly bumping into a glass door and you've just pointed out there's a door. Cheers for that.

I am starting to think after writing all this, that the Drawer may already be an outmoded concept here

The drawer is brilliant for documentation and help. It never felt intuitive as an interface for associations for me. Purely subjective though.

As an author, a journalist, someone who is adding new events to a website, someone who's editing menu items, someone who is monitoring orders, it is not going to be natural to create their content first, and then go do the linking in some other area of the site.

Some things to think of:

• Would you be able to see the original content?
• What if you get the order wrong? (ie. create the event before the artist or venue?)
• This entry to entry relationship, does that mean if you're creating 10 pieces of content that there are 20 screens to go through? One for the content, one for the relationship?
• Can you copy the relationship from a previous entry? Or does it get recreated each time?
• What happens on the frontend? How do you do this via Events
• Can you do this programatically (importing)?
• What impact does it have on our current quick actions (Publish Index => set all entries to be 'x' value?

Why does it have to be one or the other? Most of the problems have been discussed from a purist perspective or because we don't deal with complex relationships well. There's a silent voice here that are happy with the existing relationships. For a simple Article -> Comments set up an additional screen to set up relationships seems overkill. But for a complex example of assigning Stock per Store to a Product, that's probably more worthy of a new screen.

Can both live together?

@brendo I'm that person a lot of the time, but even I just had a problem with this. It is as John explained, you don't realise the difference between the relationships as presented in the backend. Seemed to not matter when SSM was king, now we can't re-create the full SSM behaviour so quickly.

I think both can live together but can the UI not be smart and fetch what you need into one page or modal? I don't mind if they're really two or three pages, I could see them as one and select what I need.

Can both live together?

Absolutely!

Brendan, I think you've misunderstood a little. Let me explain more.

When it comes to linking, as a content author, not much changes, other than the drawer would be used to make associations instead of using a field. Instead of really worrying about the parent child relationship (which would only add the one to many constraints) entries can be associated, and created (as Nils has proven) from both ends.

Would you be able to see the original content?

I'm not sure what you mean here.

What if you get the order wrong? (ie. create the event before the artist or venue?)

Then you could create the parent entry from the child you're currently creating.

This entry to entry relationship, does that mean if you're creating 10 pieces of content that there are 20 screens to go through? One for the content, one for the relationship?

Well, no, as the associations are added in the entry that was just created.

What happens on the frontend? How do you do this via Events

I haven't put that much thought into it yet ;) But I imagine that it would be much the same as it currently is. It would only be the event internal logic that would create the associations in the right places.

Can you do this programatically (importing)?

Can we do it currently? No. The XML Importer allows us to kind of do it with a couple of passes, but the key is having the association IDs to hand. It would be exactly the same IMO.

What impact does it have on our current quick actions (Publish Index => set all entries to be 'x' value?

This would indeed have to change a little.

Remember that this is still ID to ID relationships, just removing the reliance on an actual field to do the linking. Fields are for items of data, be it complex data, like the Address Field for example, or simple data, like a Text Input. Associations are inherently different, and that's what I'm trying to point out.

The solution I'm proposing wouldn't be able to live side by side with field based ID to ID associations, as the core table that handles them would need to change, and we'd have a hard time managing which one was which.

Remember, the change is when setting up the sections, not making the association, well, apart from using the drawer to make the actual association between the entries.

When it comes to linking, as a content author, not much changes, other than the drawer would be used to make associations instead of using a field.

In my eyes this would be quite a big change - and not a good one.

I understand how "outsourcing" associations to the drawer is be a valid concept for obvious parent-child-like relations (Article > Comment), where the associated data conceptually doesn't make sense as a field in the entry-form, but there are other cases, where the association shouldn't be something that is "attached" to an already "finished" entry, but is simply a part of the entry data - as is any other field of the section.

And for these cases the following question arises:

Why should a content author care about whether some of his is input data technically is an association or not?

A content author should always be able to fill in data in a fluent and comprehensible way and in lots of the sections I build with Symphony mixing up "normal" fields and "associative" fields in a single form, without strict visual/conceptional separation, not only makes perfect sense to me, but to my clients too.

To make myself a little more clear I will illustrate this with two real-life examples:

---

1) A simple case - Artist Events

An Artist I built a page for has to fill in 6 fields to create an event:

• Date
• Time
• Location
• Program
• Ticket URL
• Category

Location and Program are associations to other sections using the good old reference link field in autocomplete-view.

But in my eyes I wouldn't call this a section that consists of 4 values and 2 associations. It's a section that consists of 6 values of which 2 happen to be associations.

All this - the position of the fields, the sequence of input, the autocomplete-view and last but not least the ability to duplicate a complete event via the "duplicate entry"-extensions is the way I expect a form like this to work - and so does my client.

I really wouldn't want to sell him an update where he has to open a drawer to fill in 2 of this 6 values (that for him are one like the other, just some data...)

---

2) A complex case - A database with lots of categories

For another client I built a database for audio-logos.
There are 18 different types of associations for each audio-logo-entry and each of these associations uses a SBL+-field with a view that best matches the purpose.
So between normal input fields, checkboxes and alike the client builds associations via selectboxes, autocomplete-fields and multiple checkboxes/radiobuttons.

Most of theses associations are simple categorizations that give the client a bunch of options to choose from. Like which "instruments" are used in the audio logo.

The reason why I use seperate sections for a lot of the category values is that the client needs to edit, translate and manage them - e.g. tick a "publish"-checkbox to select categories that he wants to be included in a frontend-search.

I can not use a Taglist-field or a simple Select Box Field to achieve this.

Fields like the Select Box would still be around, but Fields like the Select Box Link wouldn't.

This would imply that just because my categories derive from other sections I couldn't include them in my forms as I could do with hardcoded categories. I'd have to put them in the drawer, just because of their technical origin, not because I want them there.

Not only would this be a big mess with such an amount of associations, it also wouldn't make any sense conceptually.
Even more than in my first example the associated values are part of the entry data and do not feel like separate entries that I'd want to link to my entry afterwards.

---

Removing the ability of building associations on a per-field-level inside the entry form in favor of a section-based association-solution that UI-wise is solely focused on the drawer (or any other place outside of the entry form) would be all but "Don't make assumptions" in my eyes.

Instead I'd like to see the Association Field be evolved into a direction where

Association Field...

• ...will replace SBL completely and be the "one and only" field for associations
• ...does make as less assumptions as possible about how or where it visually gets represented (no more built in selectbox-styling)
• ...can be used in an "invisible mode" (> hide then prepoulated)
• ...can be used in a "passive mode" as a list of items inside the drawer (styled with "drawer" views)
• ...can be used in an "active mode" as a selectable choice of items inside the entry form (styled with "field" views)

I don't think we are far away from that and I'd hate to see Nils efforts in finding a unified approach for the UI of associations beeing discarded in favor of an approach that seems rather "technical" than "pracical" to me.

At least if I'm getting everything right that was written in this thread... which I'm not too sure about ;)

I don't think we are far away from that and I'd hate to see Nils efforts in finding a unified approach for the UI of associations beeing discarded in favor of an approach that seems rather "technical" than "pracical" to me.

Thing is, it's not unified, it's exactly the opposite at the moment. There are two competing interfaces for the same thing at the same time right now.

If the core ui (drawer) is not good enough to be used or extended for these purposes as originally intended, it should be changed or removed, not simply ignored.

Thing is, it's not unified, it's exactly the opposite at the moment. There are two competing interfaces for the same thing at the same time right now.

Well, I don't see them as competing.

There are use-cases for both, the field-approach and the drawer-approach, so why shouldn't they coexist under a unified approach of showing/styling associations inside of these two areas.

If I for a example edit a blogpost the drawer could host links to associated entries (comments, images, downloads, etc.), while I could include the selection of blogpost-categories (that might derive from another section and therefore would be associations too) directly in the entry form.

Would make sense to me and would use both approaches.

The thing is - when setting up a section one should have complete control over where an association appears, how it is styled and if/how it is editable. What makes sense for me in the drawer might be better placed inside the entry form for another user.

I do like the drawer as an additional UI for certain kinds of associations, but definitively not as the only place to house them.

So from my point of view I'd answer @brendo's question "Can both live together?" with "Yes".

I never professed to have this all figured out, and I am by no means a UI expert, but, I will re-iterate, Fields are not associations.

If we need to change the code in Symphony a little more to allow us to represent Associations within the flow of the Publish page, then so be it, but continuing to make a Field do the work is not the right answer.

Plus, I've already said that modal style as Nils has it is a better option than the drawer, I only see the drawer as a place to collect the information for Associations.

Symphony 2's UI is very limited, and it is where Symphony 3 started to alleviate the issues, by allowing better layouts. We should re-address that, and try to retrofit some of that work if we go down this route.

Thanks Roman for those screenshots and description, your example is exactly the scenario I had in mind where the 'associations' are an essential part of the entry it'd be difficult for an author to comprehend the entry if half the information was tucked away in an 'X'.

I never professed to have this all figured out, and I am by no means a UI expert, but, I will re-iterate, Fields are not associations.

The statement is correct, but it's a little besides the point. A field is the current UI of an association. Technically whatever happens under the hood happens, but to an author, an association is just another field and allows for entry creation to be seamless. I really don't want to get to a position where the author has to 'think' while editing; is this content or is this an association. That's a step back and just because it's technically correct, or theoretically accurate doesn't mean we should do it.

We need to sketch/wireframe/model how any new workflow would work for both a developer and an author at this point I think. The concept is fine, but it's not tangible and to be honest, I'm obviously missing something very key.

@Roman I can think of a use-case that I would describe as very simple but it is now slower. Nesting more than one section.

The output of current association field is limited to one level of nested subsection. The UI is not. Looks and feels great but slightly wrong to have one thing an association and the other a DS chain.

@brendo

to be honest, I'm obviously missing something very key.

I currently don't get to choose between field or section based associations, although I believe Symphony is capable of doing that.

What is the UI discussion? Can't it just look like a field, and wouldn't the author just be choosing what he/she saw there? I don't know what those boxes are in the example above, I know I want to choose Guitar. That could be an association, would I need to know?

What is the UI discussion? Can't it just look like a field, and wouldn't the author just be choosing what he/she saw there? I don't know what those boxes are in the example above, I know I want to choose Guitar. That could be an association, would I need to know?

That's the point I'm trying to make, an author shouldn't care if a piece of content or an association. It's all content to them. Publishing needs to be seamless regardless.

Well I'd agree with that @brendo, but I guess you are saying that it might not be possible to have the nice UI and the proposed association scheme?

Is it taboo to ask if there's anything already out there that does this stuff well or at all?

<whining>

This discussion is a lot about "the right UI", so I can't refrain from iterating what I have said many times before.

The main problem with associations is the UI, just because there is no "one size fits all" solution, and it's so hard to change Symphony's backend to suit your needs. You have to get your hands really dirty with PHP and things like XMLElements etc. You have to build large extensions or change the Symphony codebase dramatically even for small modifications of the backend.

But why? Symphony's biggest shortcoming is the fact that publishing forms are built using PHP. I don't talk about developer-stuff like the datasource editor etc., I really don't mind how these parts of the backend are generated. But it should be simple for a developer to tailor the content publishing forms/pages. And while we promote a very clean and logical approach for the frontend of websites (XSLT, datasources, events), we still don't have it in the backend.

Imagine that the publishing part of the backend would be built around this idea — wouldn't it be rather simple then to change any UI or even the whole workflow? As long as Symphony builds backend publishing forms in pure PHP, we actually don't listen to what we praise.

I know that this would be a very very big undertaking. But every now and then, I see developers like @Nils and @designermonkey taking enormous efforts to solve relations/associations UI stuff. If all these efforts had gone into an XSLT/datasources/events publishing solution, we might be closer. And once we get there, we wouldn't need to discuss "the perfect UI", because every Symphony developer could build the perfect solution for a use case. Even building applications in the frontend would be much simpler, because you could use a lot of the (backend) code that would be shipped with Symphony.

Combine this with a modular architecture for collections of XSLT/datasources/events to be plugged into the backend, and you have s.th. like Symphony 7.0, codename "killer".

This would make Symphony stand out from the crowd.

I would like to say thank you to everybody who has put work into associations in the Symphony backend. But in all honesty: I have given up to use the backend for complex websites or applications. Some time ago I have decided to manage nearly all content from the frontend, using basic fields and logic from Symphony wherever possible (and a lot of my own templating code). It was the right decision, because I love to have straight technological layers and building blocks — and to me Symphony's backend feels like a big mess. (Not regarding the design, but technically.)

</whining>

I'm just going to slip in the middle of this conversation here and say that for all the pros and cons I am loving the new association stuff. I'm working on my first production 2.5 site now and it would have taken me longer, and had an inferior UX without it. A prototype I've been working on (2.5 RC) for the past couple months would have been practically unusable without it - I'd have rather used WordPress (!).

That's not to take anything away from those debating the finer points - but I just wanted to note that regardless, it's a big step forward in my eyes!

@nathan I absolutely agree!

I'd have rather used WordPress (!).

Wow, that’s harsh!

Wow, that’s harsh!

Haha, drastic times call for drastic measures!

WP has a good plugin for connections - you'll need a dedicated server to run the website, but it has one!