New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When Picking Compositions for a Document Type, show the folder groupings #3740

Closed
skttl opened this Issue Nov 22, 2018 · 20 comments

Comments

Projects
None yet
4 participants
@skttl
Copy link
Contributor

skttl commented Nov 22, 2018

If you have hundreds of compositions, and you have organised them into meaningful folders, it would be good when you are picking those compositions on a document type, to be able to see those folders... (currently using colours!)

Originally from @marcemarc https://issues.umbraco.org/issue/U4-11274

Would love to see this.

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 22, 2018

This is a really good idea. But given the complexity of compositions (i.e. avoid circular references, can't choose existing compositions etc.), it's not a particular good fit with the existing tree components.

Maybe a means to mend this would be to add a path below the doctype name - along the lines of this?

image

I'm sure I could be persuaded to fix that up 😄

@skttl

This comment has been minimized.

Copy link
Contributor

skttl commented Nov 22, 2018

Maybe have them divided into sections by folder, then :)

Right now, they are sorted alphabetically, which makes compositions (and other foldered types) scattered all over the list, depending on their names.

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 22, 2018

I understand what you're getting at. But I'm pretty sure that for the vast majority of the installs out there, it'd be much easier to find the applicable doctypes when they're sorted alphabetically instead of grouped by some folder structure. On a global scale I assume having so many doctypes is an edge case .

@marcemarc

This comment has been minimized.

Copy link
Contributor

marcemarc commented Nov 22, 2018

@kjac The idea follows from taking a more atomic approach to document type design, in the move away from inherited document types, towards compositions. To get the real benefits of compositions you break them down into smaller atoms and molecules to compose your document type organisms - but the backoffice 'curating' experience of compositions is very simplistic. (I use pink, and the fragment icon for compositions to make them easier to locate in this huge list). Because the Document Types now have a tree, that allow for the creating of folders, to organise the different types of document types, it sort of makes sense when you go to pick from these items, to have the same experience as when viewing this tree, take advantage of your organising folders (not nested doc types - just folders)

So original issue is just related to try and make the experience of using compositions a favorable one, it is the recommended approach, but there are lots of little ways we could make using compositions better...

image

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 22, 2018

@marcemarc I totally get both the approach and the idea and I'm not at all opposed either.

Just remember that there's also a UX downside to having a tree: When editing the compositions, how can I see which ones are currently selected, if they're hidden inside closed folders... Do we need a list of "currently selected compositions" on top of the tree?

If so, are we really making things simpler in the first place?

But if we keep the current list, shouldn't we be adding that list of "currently selected compositions" anyway, to aid the overview of those who have a gazillion "molecule" doctypes?

And so on, and so on 🤔

Again - I'm definitively not against having a tree for selection. It's a very appealing thought. I simply wonder if we can do something equally effective with less effort - specially when we also have a search field available in the dialog.

@marcemarc

This comment has been minimized.

Copy link
Contributor

marcemarc commented Nov 22, 2018

@kjac yes, tree may not be the best solution, as devs we often express a solution rather than the problem.

So problem is really:
a) distinguishing compositions from document types, when picking them to compose a document type
b) easily seeing which compositions have been selected for a document type, to enable you to remove
and it feels like the problem kicks in when you have to scroll the existing dialog...

the existing folders might feel best/obvious for a) but lousy for b) - perhaps it's more analogous to a 'content picker experience', where you can pick items, but you don't have to open the picker again to see which items have been picked

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 22, 2018

@marcemarc yes and yes. Provided we:

  1. Somehow find a way to communicate the complications with existing compositions, circular dependencies and inheritance in the content type picker (i.e. why some content types are unselectable).

  2. Find some place to display the currently active compositions. Unless we show them in the first dialog, and then spawn a second dialog to pick the additional compositions. Which is a bit... ergh?

Maybe I just have a problem killing my darlings on this one 😲 but as a fix of lesser magnitude than where this seems to be headed, this might work?

image

Obviously the dialog would scroll to near infinity in your case with the items growing in height. But again, there is a search bar right there.

@marcemarc

This comment has been minimized.

Copy link
Contributor

marcemarc commented Nov 23, 2018

@kjac yes, picking and adding are similar but different journeys - a similar interaction within the document type design area is when you add/edit a property - at first you are shown the 'property settings' tab which shows you the selected property editor, (or presents an 'add editor' option). then clicking the editor or clicking add editor, opens the second 'Select Editor' tab... which then has much more space for organising things to pick from eg 'Available editors' and 'Reuse'....

possibly with compositions then, you have your initial 'what is picked' similar to your 'active composition document types' above (+1 for path) - and then there is an option to launch another tab, that lists further compositions to pick from, but as you say the big underlying problem is difficulty to show which items are 'pickable compositions' and which items are 'document types already composed' etc, not easy to tell without lots of n+1 querying, but i think having that second slide out panel, with a nice search and scrolling list, would be a step in the right direction, be an improvement to both journeys, you could imagine the second slide out panel allow you to 'filter' by folder possibly?

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 23, 2018

@marcemarc let me see if I understand you correctly. You're thinking:

  1. List the currently picked compositions in the first dialog (slide-out-panel, call it what you want 😄) with a "Remove" option for each and an "Add" button to add more compositions.
  2. The "Add" button triggers a new dialog with the list of applicable compositions and a filter option to narrow down the list of compositions.
  3. Bonus points for making the filter option span the folder names as well.
@skttl

This comment has been minimized.

Copy link
Contributor

skttl commented Nov 23, 2018

Something like this would make me happy.
image

You would still have the complete overview of available doctypes, and which ones are selected. But the sort order and grouping would mimic the doctype tree.

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 23, 2018

@skttl that's totally doable. I have a working PoC which could easily be turned into that.

Is the "Compositions" folder an actual folder in your doctypes tree? Or is it supposed to be a view of the currently applied ones?

@skttl

This comment has been minimized.

Copy link
Contributor

skttl commented Nov 23, 2018

Yes, compositions is a folder. In this have a structure like

  • Document Types (the tree)
    • Compositions
    • Grid editor items
      • Forside

Where I have my compositions in the Compositions folder, grid editors in Grid editor items, specific frontpage grid editor items in Forside, and then all the rest in the root of Document Types.

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 23, 2018

@marcemarc what's your take on @skttl's suggestion?

@marcemarc

This comment has been minimized.

Copy link
Contributor

marcemarc commented Nov 23, 2018

@kjac it's definitely an improvement!

If we consider the two journeys and the problems...
a) we can find easily any 'compositions' folder that contains the compositions that someone might have to pick, if no folders exist the fallback is the same as what we have
b) At first it doesn't necessarily seem like an improvement on easily seeing which compositions are picked... however if someone is using folders for 'compositions/molecules' then they'll all be in the same place, so yes it will be an improvement :-)

if I type in the search filter the name of my foldername... will it filter to that folder's contents?

Only niche, thought is if someone goes 3 or 4 folders deep... it will kind of scale still, but also 'edge case'

Second thought is if HQ feel like the interaction isn't in keeping with the rest of the backoffice - and therefore the two step slidey out panel approach is more consistent UX - but it could be argued, for now, replacing what we have with this, is a good step forwards, and the original method of picking them 'isn't' necessarily an example of a consistent UX experience either?...

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Nov 25, 2018

It's definitively doable:

compositions-grouping-demo-1

Before I start ironing out all the kinks, maybe @nul800sebastiaan should have a look at the proposed solution?

@nul800sebastiaan

This comment has been minimized.

Copy link
Member

nul800sebastiaan commented Nov 27, 2018

Thanks, good discussion so far! I'll need to gather some feedback from HQ before you move on indeed. We'll get back to you!

@nul800sebastiaan

This comment has been minimized.

Copy link
Member

nul800sebastiaan commented Dec 17, 2018

@kjac Reviewed, the proposed solution is good! 👍

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Dec 17, 2018

@nul800sebastiaan awesome! I'll dig out my PoC branch and finish it ... that's one more PR for the Christmas calendar secured 😁

@skttl

This comment has been minimized.

Copy link
Contributor

skttl commented Dec 17, 2018

alt text

@kjac

This comment has been minimized.

Copy link
Contributor

kjac commented Dec 18, 2018

PR in #3900

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment