PLIP: I can easily switch back and forth a listing/row of teaser styles (repeater block with selectable source and manually added items)

[djay]

Problem

• I have 12 teasers and I want to see how they look as Search result items instead of cards

Proposed solution

• For the Plone UX person to decide and test but this is what I'd like to test

Repeater Block with auto-fill from query

• replaces both listing block and teaser grids with something similar to wix repeater block
  • ie certain blocks types are marked to be repeatable. the repeater block lets you globally set
  • which block type to repeat
  • what layout for the repeating
  • the style of all the repeated blocks

e.g. Repeater Block Settings

Repeat:         [ Card Teaser    v]
Show:           [ [Title x] [Image x] [Description x] [Date x] ]
Image position: [ Left     v]
Card Colour:    [ Light    v]
Layout:         [ Grid     v]
Items per row:  [ 3         ]
Items per page: [ All       ]
Auto add Items from:       [ From Query    v]
--- Query ---
...
Map Fields [ Title=Title, Tag=Subject, Date=Publication Date ]

but you can switch this to a row of buttons

Repeat:         [ Button    v]
Show:           [ [Title x] ]
Layout:         [ Inline     v]
Items per page: [ All       ]
Auto add Items from:       [ None    v]

or turn it into a related items widget

Repeat:         [ Tags    v]
Show:           [ [Title x] ]
Layout:         [ Inline     v]
Items per page: [ All       ]
Auto add Items from:       [ Related Items    v]

or folder contents

Repeat:         [ Summary    v]
Show:           [ [Title x] [Image x] [Description x] [Date x] ]
Image position: [ Left     v]
Layout:         [ List     v]
Items per page: [ 10       ]
Auto add Items from:       [ Contents    v]

or table

Repeat:         [ Table Row    v]
Show:           [ [Title x] [Image x] [Description x] [Date x] ]
Layout:         [ Table     v]
Header:         [Y]
User Sorting:  [Y]
Items per page: [ 10       ]
Auto add Items from:       [ Query    v]

• A Repeatable Block (sub block) has the following
  • Some kind of registration marking it to be repeatable
  • All block content you enter WYSIWYG (ie not via settings)
    • the link might have to be set using a Quanta style toolbar like [ ⠿ 🔗 🗑 ]
  • the blocks settings are style related only and are now set for all the blocks in the repeater block (ie no customisation per sub block
    • e.g you hide image or description for all. (if show it again later, the data reappears)
  • A set of defaults to map query results to data on the block (optional)
  • Which layout styles it supports. or blacklist of combinations
  • e.g Volto Image block isn't current repeatable since it has caption, link and image source appearing in it's block settings
• There is a line between the manual items and the auto items from query to show they are different.
  • any manual item with the same link is not shown in the auto items section. allows you to prioritise certain items.

[ Card 1 ]
[ Card 2]
--- preview auto added below ---
[ Card 3 ]
[ Card 4 ]
Next 1 2 3 4 Last

• The repeatable block is similar to @tiberiuichim UniversalCard idea
  • except here it only needs to be used in one block, the repeater block (not seperate listing block and teaser grid block)
  • Or it;s an rule/interface where any block can be used to repeat if we know which settings are global and which are edited inline (or can be filled by a query). Currently volto has no way to know the difference between style and data of a block.
  • Not all sub block types would support all layout styles
    • Cards might only be in grids, Buttons only inline, table rows can only be in a table etc. Calendar view might only work with cards? Map view with ??
• add button to add sub block (or DND from auto item preview)
  • if you DND the wrong block from outside it's rejected
• there is still a standalone grid/row block when you want have different blocks side by side but this is a seperate thing
  • also Listing Block, Card Grids, button Block etc are still in the block palette but they would be preleaded repeater blocks
• Pros
  • more intuitive. users think of the links first, then how best to present it
  • users don't often understand listing blocks. this makes it more discoverable.
  • supports queries with manual featured items
  • developers only have to create one sub block type that will work with both listings and grids
• Cons:
  • might be confusing you can't reorder query teasers but can reorder the pinned manual teasers?

@tiberiuichim implemented a version of this in c.cover which lets you combine manual items and query items vokoscreenNG-2023-03-09_09-29-29.webm

wix style repeater block (as suggested by @stevepiercy) is a little different in that it lets you design the exact layout of the card you are repeating. This idea is more about repeating fixed layouts but it might be possible later to create a sub block that lets rearrange its layout and have that repeated to all the other items.

Another partial implementation is in Plone 6 NSW Design System. This doesn't yet combine queries into the same block but does show how easy it is change all the sub items at once.

Other Solutions considered

Notion like convert to action

• e.g. convert Listing Block to Button link Block. or Cards Grid to Vertical summary results list etc
• Maybe in the settings of every block as top option

  | Page | Block
  --------------
  Listing Block
  Convert to    [ Card Grid   v ]
  ...

• Implementation: block authors define converter routines to/from standard blocks or common other plugins. At the min this is just a mapping of field names.
• pros:
  • good idea for more things than just cards and listings. Can turn videos to images, or listings to static tables etc.
  • could still store old data so you can switch back and forth with no loss?
• cons:
  • for solving the problem switching listing variations (manual or auto) seems a bit heavy handed.
  • you'd still need to be careful settings between different block types were similar so not confusing to the user. e.g if both had image visibile option it should be in the same place and be kept when converting
  • where to put it in the UI? in the settings make more sense but then it's an action so does picking switch it right away?

Row Block and separate Teaser Block

• What has currently been implemented.
• pros:
  • Lets you set different variation for any particular teaser
• cons:
  • lots of clicks to switch variations on all the teasers or change orientation

You could enhance this by some kind of generic convert to action and multiple selection but its still more clicks and it's still not clear how you would hide or adjust settings across many blocks at the same time?

Listing block with selectable sources

cons:

• you have to go somewhere else to manually sort or add items to the list. not WYSIWYG.

context

following on from discussion in Teaser Block in Core with @tiberiuichim

Stories (in "assumed" order of how common)

1. I can enter teasers fully manually (ie manual title, description, image)
2. I can reorder teasers after adding
3. I can have a set of teasers side by side or vertically
4. I can have many variants of how rows or grids of teasers appear and switch between them easily
5. I add teasers where title is filled in automatically from the target content
6. I can have a set of teasers determined by single folder contents
7. I can have a set of teasers determined by a query
8. I can have a set of teasers that are inline buttons/tags rather than in a grid
9. I can customise a single title of a teaser in a query set of teasers
10. I can have a manual set of teasers but stored in a field like "related items"
11. I can quickly add a teaser by DND from a finder
12. I can a have a set of teasers determined by a query except a few which I pick to be first
13. I can switch a set to teasers from using a query to be a manual ordering
14. I can reuse a query or "source" between in many teaser sets so as not to type it again?
15. I can have a set of teasers that use different variations in the same set

[djay]

@tiberiuichim @sneridagh @JeffersonBledsoe let me know if I captured the various solutions proposed in https://github.com/plone/volto/pull/3706#issuecomment-1339764918 ok.

I'm not decided on which I personally think it is going be the best for the most users. I think Listing block with pinned teasers could be very nice solution though. but I'd still like to see a generic convert-to action at some stage as well.

[tiberiuichim]

I propose we try to setup a meeting where we're all present and discuss all these, as they're rather complex. If we decide to do something about it, we need to be all onboard this thing.

[sneridagh]

@tiberiuichim +1 for having a meeting focused in this.

[djay]

That would be great if there a UX person who will join? Otherwise it's like mechanics arguing about which potential car design is going to sell more.

[tiberiuichim]

In Climate-Adapt (which is a Plone 4 website implemented with collective.cover) we had the same usecase: we have a listing, but the editors got tired of tagging items just so that they show up in the proper listing, so we've implemented a method to populate the listing by directly dragging the items in the listing.

[fredvd]

That would be great if there a UX person who will join? Otherwise it's like mechanics arguing about which potential car design is going to sell more.

I've just read this issue, but I want to vent my personal annoyance about this this "UX person present' requirement. Apparently the Volto release manager, the senior developer of one of the largets Volto integrator and other good willing very experienced people in the Plone Community that are not good enough for you @djay.

We don't have a 'UX' dictator in the Plone Community, just as we don't have a Release god that decides all the details of what happen when (I know from first hand how Maurits works), or a marketing Pope that instructs all our marketing team minons to abide by his or her wishes. It didn't happen and it is not going to happen.

What is happening is that we all have a lack of time, our own customers/projects AND community tasks and we miss project management hours/people driving the community processes for decision/compromise making towards progress.

There is not a single authority in our community and if you discard people's input upfront because they are not qualified enough according to you (or they might not agree with you on all subjects), that's a not so pleasant communication style.

Maybe I'm picking up all the wrong signals as non native speaker, but please explain to me.

[djay]

I've just read this issue, but I want to vent my personal annoyance about this this "UX person present' requirement. Apparently the Volto release manager, the senior developer of one of the largets Volto integrator and other good willing very experienced people in the Plone Community that are not good enough for you @djay.

I understand where you're coming from in that these are very smart and experienced developers. And these are exactly the people that are needed to answer the questions of how hard is one solution to build vs another, or this solution will cause architectural issues. It's counter intuitive but the best people to answer question of what is best for end users is not the smartest developers. Plenty of others have done a great job at explaining why. This is an excellent read - Why Software Developers Suck at UX, both the article and the comments.

What is happening is that we all have a lack of time, our own customers/projects AND community tasks and we miss project management hours/people driving the community processes for decision/compromise making towards progress.

I couldn't agree more. Which is why it's important to have the right people in the room when making decisions so precious voluneteer time is not wasted.

As example, here is the story of how I wasted my own money already on this project.

We are in the process of implementing the NSW Government design system. Some very common components are Cards, Content Blocks, Linked Lists and List Items. Even though I'm the product owner we were in a rush and so I left my very talented developer to work out how to implement this. He did what seemed obvious and quickest (and recommended by the community) which to create a block for each of those and use the volto grid block. We also created a 2nd implementation of these as variations to the Listing block.

So the very first time I come to use these for something like this I realise the problem

Until I use the blocks I don't really know what they look like. I use cards at first and type in all the text. So now in order to see how it works as content blocks instead I have to start again and cut and paste everything over? I'm time poor, whis is this UI making me work more? Even though I deal with all our support tickets and talk directly to our users they hadn't complained but there was just a 1-2 trialling and they were just learning and I'm sure they were just happy to be rid of plone 5. They also didn't have much of a choice since they already signed up to plone 6. But I knew I would get support requests about this eventually.

So I took the expensive step of ripping it out and getting it reimplemented, which is the "manual listing block" above. So far user feedback is good. It's super nice to enter the content and know you can adjust how it's displayed to get it to look exactly right.

but it still has problems. It only supports variations cards and content blocks because linked list, list items are vertical not on a grid we used volto grid block as a base. Further editing make me realise you sometimes you have links as cards when you want to save space and represent them as Tags which are neither vertical or horizontal but inline. Essentially all of these are different variations on teasers.

Then in doing the documentation afterwards I realise how complicated it is to explain that you can have Cards as either automated listings or manual listings and you need to choose in advance which where the content is coming from before get to try out how it's going to look. Again, can be solved by documentation but since we have an unlimited support policy and are working with smaller agencies with users that edit occasionally, this will result in support requests or silent frustration further down the line. The best kind of training and documentation are those that aren't needed.

This is all just to highlight that a little more thinking by lazy first time editors or UX people might have saved a lot of money. And because we have run out of money for this project it is still frustrating that now we will have to live with editors wasting small bits of effort here and there when for the same price or less, it could have been solved first time in a better way. And of course this problem is just amplified with Plone as open source because volunteer effort is every harder to come by, the implementation is harder as it has to be more robust the inertia to change something once its in core is much that it's almost impossible to convince anyone a bad UI is worth changing.

if you make one tiny thing a little bit nicer, it might make a hundred moments on a thousand days for a thousand people nicer

So this is where we end up here. I have no agenda other than the desire to see everyones valuable time not be wasted by having the end result being best for the end users (not us). Which I'm sure is exactly the same as you @fredvd wants and everyone else involved

[fredvd]

It's counter intuitive but the best people to answer question of what is best for end users is not the smartest developers. Plenty of others have done a great job at explaining why. This is an excellent read - Why Software Developers Suck at UX, both the article and the comments.

Please take in to consideration that you are projecting you personal experiences and frustrations in your own company of who 'smartest developers' are and how they should cooperate in development teams on the situation in other companies using and building Plone/Volto .

Volto development has been primarily customer driven for the last 4 years. That's how the resources were gathered and paid for to get an initial version and the first iterations/improvements on that foundation. KitConcept has taken the lead and open sourced their custom react frontend that built on top of plone.restapi for some of THEIR customers, other companies like RedTurtle, Eau'de Web and smaller integrators like Katja, Nicola, you and many others have chimed in, found customers that wanted this as a solution and built built built. They've tried to communicate and distribute the efforts, but you can see very clearly that each company has so far had to cater for the customer niche they growed around their company first.

And those customer groups demand different complexity/features and have selected different trade offs when looking at usability, editor skills present, required features and flexibility or instead 'locking down' the art direction in those sites.

There are now like 5-10 different directions and evolutions of how to use the blocks system to build Volto websites, but basically we're still halfway stuck in the Plone 2.5-3 era where the developer solution to all your isolation or composition problems in Plone was to create a new Content Type. or set of CT's. But now with blocks.

Totally over generalising: Kitconcept is catering for government / limited freedom / huge editor groups that need to get stuff done, Eau de web is building environmental portal for scientist editors at EEA that can handle any cognitive load and settings as long as they have ultimate freedom to connect everything together, RedTurtle has some large media clients that want the slickest visual presentation possible. And then some more combinations.

You are addressing that the current architecture of 'core Volto' doesn't automatically let your own developers (who were without the luxury of a hands on product owner or a more experienced UX member on the team for such a big project for the NSW Government) to do the right thing and be guided to build the perfect interacting set of blocks that answer the needs of the customer on the current open sources blocks.

That's a pipe dream if you had paid attention to the current state of the blocks system as the product owner. Some really powerful and impressive Volto sites have been built and are in production so far, but they have been paid for by customers willing to spend that amount of many for a custom solution for them because they have the scale/size to pay for that custom development. You can't expect that the lowest common denominator of those efforts at the moment are out of the box ready to use solutions for small development teams without UX resources and experience.

Please Don't assume that Kitconcept, Eau de web and others haven't delivered well integrated and thoughtfull UI's like that for those customers, by looking at core Volto. They had UX people in their teams and they built and delivered custom solutions so far for their Specific Customer Groups.. Follow the Money.

So forward

My personal story so far here is that I joined the Volto team meeting last week and was shocked myself on the current state of the grid block implementation that should flow into core and the discussions around it about Row blocks, grid blocks, etc. etc. I've thought about those issues and chatted twice now with Victor to identify what is missing and how I can help to move this issue forward.

I have enough experience myself with implementing and maintaining collective.cover in government settings for the last 9 years and we're on the same page considering all the issues and possible solutions that you have brought up in this ticket. The same for mosaic with a different large more commercial customer. Cover has some very smart things like the manual listing title, a separation between layout and contents and a content chooser that I miss every time I'm developer for or using Mosaic and now when I started using Volto.

I agree with you on most of the implementation/UI issues you brought up here. I see the same challenges. Just the 'simple' layout of a row of cards with teaser image and text below that wraps correctly in responsive/mobile mode.

This might look like a waste of time, but we need to take a few big steps back and write down a description of primitives, how they interact and define a shared vocabulary / glossary of how the layout model should work. When we have a shared idiom and understanding, we can compare to the solutions / sets of blocks we have now and let developers and product owners propose technical implementations and UI's/workflows, based on the experience so far.

Otherwise I fear that we all individually will continue to reason from our own well known current existing/previous implementations for existing customers and pretend that those client requirements are the only ones we need to cater for. We do in our day to day jobs, but not when trying to come up with the next shared foundation.

Ideally the next iteration should :

• Have a shared agreed upon vocabulary of how we name things and identify primitives and how they interact to improve communication between Volto implementation teams and core developers.
• Have a basic / good enough implementation in core that is not too complicated but shows the flexibility available under the hood
• And allow enough flexibility/abstraction for large project to redefine layout aspects without being hindered by too simple assumptions and implementation in core of what the blocks layout should be capable of.

I've done a mini version of this excercise with Victor last week by blurting out my mental model to him and want to repeat it but then in text form to explain my own mental model, based on using cover and mosaic in the past and dealing with customisation issues.

In a nutshell, YMMV:

For me the whole layout system is a nested container structure with each container containing either 'singular' or 'generator' type blocks. Every container has a set of layout properties, one of those properties is direction. You can change those properties at every container boundary for the contained blocks. Generator blocks are fed by content sources. These are our collection (criteria sets) or sets of individual selected content items (like the listing tile concept in cover). Generator blocks can generate X extra ghost blocks of their own type in the same container. styling properties on the container modify their appareance.

Carrousel /teaser blocks are generator blocks that don't create new blocks but rotate blocks/inked content in their own viewport. Like the carousel tile in cover being a subclass of the listing tile. When you start with an empty blocks layout, it's a container with 2 blocks (title/description) in the down direction. for some languages the default directions are up/left instead of downright, like arabic/hebrew.

Seperate content sources, position in the context layout (or even the site hierarchy if 'portlets'), block implementation and styling properties conceptually.

One thing I discussed with Victor is that 'content sources' should be addressable site wide. When I define a collection/search listing for news items on the homepage, I should be able to create a second generator block on another context and reference the existing criteria-set on the homepage. Heck, theoretically I should be able to extend /combine those and 'stack' content sources. Also we might want to use content sources both for listing inside a singular block (listing tile). Or to generate card groups (generator block) and identify those are 2 different concepts. If and how much of such things we expose in the core Volto distribution is another discussion.

next steps

I propose to start a 'layout-system' topic/channel on Discord, bring in our current designs/conceptual models we've been working off so far together and invite those UX experts that are now spread over multiple Plone integrator/developer companies to contribute their thought and ideas as well.

I'm out of 'community time' today and still dealing with a nasty nose cold/throat ache but will write down my version ASAP and post it here and on Discord.

[djay]

Please take in to consideration that you are projecting you personal experiences and frustrations in your own company of who 'smartest developers' are and how they should cooperate in development teams on the situation in other companies using and building Plone/Volto .

With all due respect @fredvd are making huge assumptions about me and my experience. If anything my experience is based on my very long experience with the plone community but many years in industry also. but there is a good reason why I referenced an excellent article explaining all the reasons why developers suck at UX. So it can be read and so you don't assume it is coming from my experience alone. Pay the very min of respect to read this first and comment on the article, not me. I am not trying to insult people so I ask you to check your egos at the door and be open minded.

Just to absolutely clear: I am not trying to get someone to build something for me to fits my usecase. We have a solution. We won't be able to change this for a long time. I am just trying to share my experience and add our usecases to the mix.

I have also not assumed that there weren't UX people involved in redturtle or kitconcept. I was just suggesting they attend a meeting or get involved here so it's not developers arguing over UX problems with no one trusting anyone else.

Have a shared agreed upon vocabulary of how we name things and identify primitives and how they interact to improve communication between Volto implementation teams and core developers.

You are right. It's extremely hard to understand what you are suggesting or anyone else without defining terms. So I had a stab at this at the top of this card.

• Teaser
  • Block of content pointing to a page (either internal or external) often with title, description, link, image but not always.
• Set of teasers
  • Listing, Row with Teasers, Collection, Search Block etc. But not using that so as not get locked into thinking about what exists now. What it might get called in a final UI, who knows.
• Manual Teaser
  • Where you write the title, description, image etc instead of it coming from the referenced content

I still haven't worked out what you mean by generator. I also haven't worked out yet exactly what content sources are but @tiberiuichim also mentioned this concept previously. I think the idea is that instead of defining manual teasers inside a block you go elsewhere to define that information and then point a set of teasers/listing at that list? sort of like vocabulary? or is the idea of just reusing a query definition in multiple places?

In any case, I've realised from this discussion that I've assumed a bunch of use cases in working out the pros and cons above. And more importantly the differences in approach that have been tried might boil down to different assumptions in how common each of these stories are. In order to speed up this process I've had an initial stab at listing all the stories I can think of and in the order I think is the most common to least. Of course this would be better data driven, (and this is something that a community paid for UX resource could achieve) but if everyone doesn't agree on the order of this list then it makes ever next step much harder.

Github tickets are a wiki so anyone can edit this along with adding more proposed solutions and changing the pros and cons. While github is rubbish for commenting I stlll this medium because the design process is going to live beyond the implementation and every other kind of document will not. Feel free to edit.

I've done a mini version of this excercise with Victor last week by blurting out my mental model to him and want to repeat it but then in text form to explain my own mental model, based on using cover and mosaic in the past and dealing with customisation issues.

Which of the solutions above does this fit into?

In Climate-Adapt (which is a Plone 4 website implemented with collective.cover) we had the same usecase: we have a listing, but the editors got tired of tagging items just so that they show up in the proper listing, so we've implemented a method to populate the listing by directly dragging the items in the listing.

@tiberiuichim so if I understand you correctly, you had a system to achieving pinning special items to the top of a listing via tags. And you replaced that with another system to achieve the same usecase where a query based listing then allowed you to pin or DND items to the top of the list so they always appear first? or do you mean populate in that you had some other listing of content on screen and you are just adding teasers by DND from that hidden list to the final list that would be shown on the page? ie its just a quicker UI to add an manual set of teasers?

[tiberiuichim]

@djay vokoscreenNG-2023-03-09_09-29-29.webm

[djay]

@tiberiuichim cool. so it is almost exactly as I was thinking for "Unified Listing Block with manual teasers at the start". Except can you reorder items found using a query however you want? like move the top item to the bottom? ie it just kind of freezes the list and stores the order internally and resorts based on that order? and if new items match the search do they appear at the end of the list? What happens if items no longer watch the query? do they disappear or remain? The main potential downside of this approach is that none of these rules would be obvious to the user I think. It would have to be made really obvious to the user how it works so as they don't have something unexpected happening like items suddenly appearing or disappearing. Or am I completely misunderstanding things and the query part of that listing settings now does nothing?

[tiberiuichim]

Or am I completely misunderstanding things and the query part of that listing settings now does nothing?

It's very low tech. We've decided that the "dragged items" show up on top of the "listing items" and that's it.

[djay]

It's very low tech. We've decided that the "dragged items" show up on top of the "listing items" and that's it.

@tiberiuichim Did the users have any problems understanding this? did they try to drag it further down the list and asked why it bounced back to the top?

Did you ever have to train anyone new on this system and did it require little explaining?

I keep thinking there would have to some kind of visual markings to make it really clear which part was the manual list and which part was the query list. And have to make it very obvious that if you haven't disabled the query part and there is currently no items it doesn't mean a new item won't appear there in the future.

Did it remove the manually add item from the list of queried items so the same item couldn't be in there twice?

The chooser that lets you dnd directly into drag items directly into the list to speed up that part of the process is a really nice idea. Have to figure out where to put that in the UI.

[fredvd]

With all due respect @fredvd are making huge assumptions about me and my experience. If anything my experience is based on my very long experience with the plone community but many years in industry also.

@djay My apologies, this is where my english & vocabulary is limiting me and I use the wrong language ('ervaring' in Dutch) and on top of that I quoted the wrong paragraph. I was not referring to your knowledge about these subjects in general, either technical, business or UX wise. I respect your experience and know you've been at least as long or longer than me active in the community an in the industry, you are very passionate about these things: just the fact that we are 'arguing' about this with so much text here shows that we are involved and want the best end results.

First: what I wanted to express is that it is not just developers 'in general' as the article you refer to mentions at the beginning, who might have less developped 'empathy' skills to how other people/users try to understand and work with the software applications they build.

I've had meetings where for example a product owner of the CMS kind of complains to me that the 1 hour screencast (6 small screen casts) I created is a bit slow in explaining the basics of the CMS: "can't we condense it a bit". That screencast was based on the end user training I have given over the yeaers, and that was always a full DAY of in house training, where we somtimes didn't finish the 'collections' chapter.

At the same time at that organisation we received support calls that users couldn't copy/paste items, where the 'actions' menu with subitems copy and paste was in plain sight, one menu click away. And other really basic 'how can I do' questions came in as well. That's a big gap or disconnect between what a manager thinks their editors can handle or understand and what editors simultaneous report on what their skill level is. Curse of knowledge in full action: I know how to do this, so why is anybody else having a problem with this. That's universal, not limited to software developers, but also a skill you can learn and train by doing. I love to read Hackernews, but with every article there that reaches the first page I wonder if that is because the contents is factual or because the audience identifies with the sentiments described.

Secondly: with experience I meant to refer to your particular instance/development-project with a development team that builds a solution which turns out to be very difficult to understand/use by end users. That sucks, it costs a lot of money in the end, and you're indeed stuck with a suboptimal configuration that you have to support for years. Been there, done that, guilty myself. And the situation there is that at the moment Volto is out of the box less suitable for 'enterprise' CMS set ups with many actors/edtiors and interestes on the cheap if the budget is small, or even medium sized.

I have had the same experience with Mosaic where 80% worked almost out of the box, but the remaining 20% of required features costs us 80% of maintenance over the years because we didn't fully understand all Mosaic 'concept' when we started using it. And then I'm blaming myself too much, because Mosaic has the same issues as we're talking now about that Volto has, there are 2-3 'implementation' directions and nobody is warning you when you mix them in the wrong way. Looking at you, PersistentTile.

Again, I value your experience in this a lot and that's why we should get this written down, discuss in much more detail and get to a situation where the default set of blocks and layout propertiees in Volto core nudges implementation teams in the right direction, without having them to overthink and rearchitect the whole layout system for every individual customer for every possible future of that customers' future demands on the system. The 'growth' path is something we haven't even touched upon yet. "We only need 2 teasers on a row, never more." 4 months later....

[tiberiuichim]

@tiberiuichim Did the users have any problems understanding this? did they try to drag it further down the list and asked why it bounced back to the top?

No, it's mainly a couple of editors that edit the website. There's a lot of historic context for them, but those listings were migrated from an older version of the website, where they were implemented using "special tagging" so that the items could show up in the proper listing. I got tired of the editors missing the requirements to make their items show up in the proper location, so I just proposed to them that they directly drag/drop the items in the "box". So most of the time the box is used exclusively either as listing or as "teaser list".

Did you ever have to train anyone new on this system and did it require little explaining?

Not for the drag/drop part.

I keep thinking there would have to some kind of visual markings to make it really clear which part was the manual list and which part was the query list. And have to make it very obvious that if you haven't disabled the query part and there is currently no items it doesn't mean a new item won't appear there in the future.

That's thanks to the "modal interface". We don't preview the listing items.

Did it remove the manually add item from the list of queried items so the same item couldn't be in there twice?

That could be done via code.

The chooser that lets you dnd directly into drag items directly into the list to speed up that part of the process is a really nice idea. Have to figure out where to put that in the UI.

That's all collective.cover. Also, we don't apply the query parameters to the "Add content" drag/drop modal listing, it's just a generic Plone control.

[fredvd]

I still haven't worked out what you mean by generator. I also haven't worked out yet exactly what content sources are but @tiberiuichim also mentioned this concept previously. I think the idea is that instead of defining manual teasers inside a block you go elsewhere to define that information and then point a set of teasers/listing at that list? sort of like vocabulary? or is the idea of just reusing a query definition in multiple places?

Yes, a content source is the 'concept' of a source of content items that are somewhere else in the site. The 'manifestation' of a content source in Plone < 5 was the Collection Content type. In Plone 5 it became the collection 'behavior' with the querystring field that you could attach to any content type, but you could even add multiple querystring fields to one content type. But there still was the Collection CT as well. And in Plone 6 it's now the listing tile that you can add X time to any blocks layout on a content item/context.

The challenge with removing the collection as a content item is that you now cannot re-use a querystring (aka content source) in other places. One solution would be to have an index of all blocks in the site (the index is now context/content item based) and the listing tile can either contain a 'local' querystring or refer to another (context/tile/querystring). But that has other implications, like on link integrity. (you are deleting this page, but it has 2 re-used searchcriteria.

'generator blocks' for me use a content source, but can create an x number of cards as copies of themselves, where the cards are in the react component model' on the same level as the block it generates, siblings. They generate in the same 'container' and follow the styling properties set on that container and flow correctly when looking at 'responsive'.

At the same time, a listing block (for example I want on plone.org a compact overview somewhere inside a block of the last 6 Plone releases) with 6 text rows. (aka listing tile c.cover). There no new extra blocks are generated, but all content is inside the block also DOM wise.

There's a gsoc project to upgrade the 'related items' widget in Volto. But you could avoid many use cases of the related items widget with a content chooser where you drop the items visually in the blocks: A generator block adds the item to the manual content list. A listing block add the item to the internal manual list.

---

I find the 'teaser' and 'hero' blocks at the moment personally confusing, because they are more 'communication' directives for what the contents in the block should do to the viewer of a page, than that they are layout system concepts. a card can be a teaser, an employee details card, a software feature / USP you want to highlight. etc. Same for 'hero' block.

---

Something else I've been thinking about is the UI on tables/touch screens with which an editor can group/layout blocks. One of the idea's I have is that you can switch the blocks view to 'layout' mode (button press) then select one ore more blocks (you can only continue selecting blocks in the direction you started by selecting the second block) and then 'group' the blocks. Next you can change the layout direction.

Basically: you add an image block, you add a text block. switch to layout mode, click both blocks, group. Set their direction to down. exit layout mode. Add a new image block next to this container/group. Add another text block. group them, direction down. And then you have 2 'teasers'. That also behave correctly in a responsive way: image1/text1, image2/text2, image3/text3, etc. and not image1/image2/image3, text1, text2,text3 if the editor had created

This does seem like low level where the editor builds the teaser brick by brick. So you don't want to do this as an editor for 12 news item teasers on your homepage. But as a basic layout tool it fits the mindset of many editors.

---

The challenge here for editor 'cogntivie load' is when you start creating multiple ways to implement the same visual apperance: The same could be created with a 'teaser block' that references a news item and fills in the image, description and link to the item automatically. But often 'copy writing' wise the description on the news item is too long or an editor want to have alternative text on the homepage teaser. So then you get by reference but locally overridable, etc. etc.

The 'core' layout system should not limit either of the implementations, but it is customer specific if one, both or even generator blocks should be activated. And when.

---

And it is 'marketing specific' what our demo Volto sites, or core volto install should have enabled as a show case of what Volto is capable of: on a spectrum: should we tell the story of 'inexperienced editor can create cool layouts' with minimal options to get distracted, or 'developer can build any UX on top of our well thought out layout system'.

That's why I'm so hyped about the Plone distributions that are now almost there and we can start using to demo a range of possibilites in the future.

[djay]

That's a big gap or disconnect between what a manager thinks their editors can handle or understand and what editors simultaneous report on what their skill level is. Curse of knowledge in full action: I know how to do this, so why is anybody else having a problem with this. That's universal, not limited to software developers, but also a skill you can learn and train by doing.

Absolutely. It's not that developers find it uniquely hard to imagine what it's like to be dumb or not know something, but the difference is they are often put in charge of making a UI and like anyone don't give themselves the time needed to work out how a real end user would see their intended design.

The challenge with removing the collection as a content item is that you now cannot re-use a querystring (aka content source) in other places

What I don't understand yet is why you need to reuse a query often? Is it because users don't understand how to make queries so you admins make them ahead of time and give them names?

'generator blocks' for me use a content source, but can create an x number of cards as copies of themselves, where the cards are in the react component model' on the same level as the block it generates, siblings. They generate in the same 'container' and follow the styling properties set on that container and flow correctly when looking at 'responsive'.

I'm really not sure I understand what the reasoning behind this idea but Are you talking about the editor creating some kind of template for a listing item but using blocks to do so? if so, how often would a appropriate teaser block not be part of the theme?

There's a gsoc project to upgrade the 'related items' widget in Volto. But you could avoid many use cases of the related items widget with a content chooser where you drop the items visually in the blocks:

You are right. A related items widget is really a set of teasers that you manually sort and add items to. Except that you want it to store that in a field rather than in the block data. I think that could be handled by a universal listing block idea by having a option to store the manual listing part in either the block or pick a field. I'll add that as a usecase into this ticket.

I'm afraid the rest of what you try to explain, I read several times, but I haven't yet worked it out.

[tiberiuichim]

like anyone don't give themselves the time needed to work out how a real end user would see their intended design.

I can attest to this. The multi-block copy/paste feature, for example, was triggered by me having to do some repetitive content editing tasks. If we eat our own dogfood, we may see more clearly the pain points of the editors.

[djay]

At the same time at that organisation we received support calls that users couldn't copy/paste items, where the 'actions' menu with subitems copy and paste was in plain sight, one menu click away.

@fredvd I just realised this morning what a perfect example this is. A UX person would look at that say, every other UI in the world has those under a menu called "Edit". Or anyone with enough time and forethought asks that support call people where they might expect to find it. But You, me and and every other plone developer for 20 years never questioned it being in a menu called "actions" because we knew that more things are meant to sit inside there than would normally be expected to be inside an edit menu. Amazing. This is why developers (often) suck at UX. and why any important UX decision should not have only developers in the room.

And of course I got a support ticket the other day from a new user on volto asking how to delete a page, as there is neither actions or edit or delete now. Knowing you have to use contents and then sometimes go up a level to delete something.... anyway. thats a UX bug for another day

If we eat our own dogfood, we may see more clearly the pain points of the editors.

@tiberiuichim It helps. Developers doing training helps. Developers fielding support calls helps. My guess is the more senior developer you are the less likely you are to do these things. Also it's still not as also having UX person who has the time and experience, doing all these things as well.

I got tired of the editors missing the requirements to make their items show up in the proper location, so I just proposed to them that they directly drag/drop the items in the "box". So most of the time the box is used exclusively either as listing or as "teaser list".

So really its a usecase of "tags" are not a great way to have a manual list and we should just have a manual set of teasers.

But The thing I like about the unified listing block idea is that you can still have block for manual only sets of teasers and you can still have a block of query based teasers since they are just different presents of the same block. and I don't think it would over complicate the UI in either case. In the manual case you would have a check box saying "Automaticly include additional items" unchecked. In the query preset you would have that checked, and items would have a star button which would bring it to the top of the list. There the item wiuld have a drag handle and a delete icon. And there is a divider between the two sections saying that the rest is a preview or the query result. Even if switching an query set of teasers to a manual set of teasers is going to be a rare usecase, it's not really a downside unifing them. And then we can stick to one name for the block, "Listing". I'll see if I can do some mockups of this.

[djay]

@tiberiuichim @fredvd @sneridagh @tisto from the discussion at the volto team meeting I suspect you all think I'm trying to solve the "layout" problem which I'm not. There seems to be an assumption that you solve the "layout" problem in volto and you solve how to have teasers in different layouts. e.g. if we want to allow people to create

or

or

Then we have a layout system and a seperate teaser block (with variations or seperate teaser blocks). This provides separation of concerns and most flexibility.

What I'm trying to say, is hold up on that assumption for a moment. Yes. You can have a teaser block with the 3 variations above and Row block that lets you layout those teasers in both grids and vertical lists... but it's a bit time consuming and manual to work with as an editor.

What if instead we said that the Row block is for the manual layout images with text and other block types, but when it comes to list of teasers, they could semantically define a list of teasers/links they want to display and afterwards work out the best way to present them on the page. In exactly the same way that Listing Blocks have variations and you switch with a single click how the results list appears.

for example, on the home page of this new site we launched, you can't tell which is a Listing Block

and what is manually curated teasers

and each of those the editor can just change the variation of the Listing block to see which is going to present the same information in the best way. as can be seen in this demo.

So far this is much nicer to work with than Grid/Row and individual teaser blocks. but we still use Grid/Row for text and images. And it would allow even more variation styles than we have done. like why can't I switch my Card quicklinks into calendar or into Tag links

I'm saying we take this idea one step further and just have a single Listing block that handles both query based listings and manual listings of teasers with a single set of variations that combine both layout of the teasers on the page and variations of the teasers themselves.

But, to put something like this in core requires consensus and consensus requires trust that my use-case is your use-case and the solution would work for both. One way is to built it as a plugin then everyone can try themselves or even install on their client sites. The plone way is for someone to spend a bunch of money building a new idea like this, release it and then hope it gets used by a bunch of people and then it will get re-built again as a core component. Maybe 3 different companies do this and you get 3 solutions competing as plugins and the best will float to the top over time.

Yes it's true this is the fairest way and creates good solutions. But what it hides is the lost opportunities. Because as a company I constantly have to make the following choice

Do I solve this problem a) just for this client and never release it. might cost $1000 b) just for the customer but release it as a plugin with docs and tests etc. might cost $1500 c) in a more general way either as core component or a very useful plugin to others. might cost $2000-$2500 but could save money later

I always prefer (c) but the risk is also great that it won't get accepted or used and so it's lower risk to pick (a). The reality of Plone is that there is way more (a) choices being made across all companies. It's a shame and a waste. However some select few companies have more information that changes the risk equation. They can get key feedback quickly to know what is more likely to be accepted into the core, so lowering the risk of option C.

There has to be a better way. I'm suggesting that better way is a UX person, paid by the foundation, who we all trust who spends half a day each week or fortnight, prioritising which UX problems need solving and giving feedback on either UX problems reported in github or community, or on proposed solutions. Someone who is patching the quanta roadmap based on feedback. Someone who could apply the holistic view and say that adding X would make some plugin idea work for this other set of users that you weren't considering. Someone that would increase the confidence that (c) is worth the risk and so would result more useful solutions to exist in the plone ecosystem. Volunteers need direction.

[tiberiuichim]

I suspect you all think I'm trying to solve the "layout" problem which I'm not.

No, at least personally, I'm not.

I'm more interested in the discussion "how do we communicate effectively, how do we reach consensus and move forward things that are stuck".

[stevepiercy]

I'm more interested in the discussion "how do we communicate effectively, how do we reach consensus and move forward things that are stuck".

I think we can agree that the current way of moving things forward that are stuck is suboptimal. We have identified why that is:

1. lack of time
2. lack of money to hire someone to make time to unstuck the things

We can't get more of 1, so let's get more of 2. I personally would like 2 to become reality, not just for UX, but for Documentation as well.

Where can we get more of 2?

• Kickstarter and other third-party fundraising campaigns.
• Work with the Plone Foundation to create a PayPal Giving Fund page (no transactions fees on US-based transactions) or other such online donation tool. Side note, the Donate link in the footer of plone.org does not take the visitor to a page where they can make a donation. How the heck does one give money to the Plone Foundation? 🤷
• Hit up our clients to fund UX development.
• Write grant proposals. Here are a few potential grantors.
  • Plone Foundation
  • Python Software Foundation
  • In the Volto Team meeting, I learned about Google Season of Docs (h/t @nileshgulia1). I would like to make a proposal to the Plone Foundation for 2024 to make that happen.

Perhaps there are React or JavaScript foundations that fund development?

I challenge you all to take the lead to create the hired UX position. If I can take the lead to submit a grant proposal for Documentation, then you all can do the same for a UX position. 🎤 💧

[djay]

I suspect you all think I'm trying to solve the "layout" problem which I'm not.

No, at least personally, I'm not.

I'm more interested in the discussion "how do we communicate effectively, how do we reach consensus and move forward things that are stuck".

@tiberiuichim in the general case, other than bringing an UX expert in we all trust, I'm not sure. the "trust me, my users are average and they haven't complained" method isn't great. And the "even though we are developers, this seems like a cool UI to me" approach isn't great. Just getting anyone to look at a demo and think about a different UI than they were expecting is a hard ask. Core developers need to trust someones design somehow without them spending that much time themselves thinking about it. I can't see that happening without someone like albert being involved. And the idea that everything we need is already in the quanta roadmap is not the reality.

For this specific case of if a unified listing block would work well enough to be considered for core?

1. I can create a mockup how pinning items would work. But I'm not sure its going to be convincing without a working version
2. We have a working version of a switchable manual teaser listing block. But it's not a seperate plugin so you can't just install it on a new site without taking the rest of the theme with it. But I'm happy to give anyone a login to our demo site if they want to try it.
   • it also won't tell us if the idea of combining a manual listing block and a query listing block into one is going to be a confusing mess. @tiberiuichim version of this is the best information we have on this.
3. The work required to make a standalone plugin would be a few weeks maybe.
   • Start with the existing listing block and integrate the new Row block code into it
     • We can't really reuse our existing code since it's based on volto grid and so can't have multiple rows. We also don't use the new teaser block code.
   • rip out the ability to add different subblocks into the row and have seperate settings for each list item. Its one settings for the whole block
     • ie get rid of settings icons per cell. still needs a delete icon though
   • Change the list items to be inline editable. perhaps using the new teaser code.
     • But this is a little tricky when we did this in our existing code. because we didn't want settings per block and the user confusing over which block they are editing. So everything had to be edited inline only. Links and images were a little tricky but we used a popout link widget and it works ok.
     • if using existing teaser block then need to make each teaser block get it's settings from the parent Listing block instead, e.g. show or hide image, description, date etc.
     • All the query part of the listing would also need to use this same component (so it's now your universal list item idea @tiberiuichim) but would be in read only mode.
   • add in a pin/star button to move items between query part of the listing and the Row block part (maybe support DND too)
   • Put in some kind of demarkation divider showing where the manual listing ends and the query listing starts
   • add some variations so can support cards in a grid, vertical results list, or simple list of links vertically and a table
   • change the listing code to remove any items we linked to from the query listing

Option (3) is something we can't do for awhile so if someone else wants to have a go feel free. Given there is no consensus it's not going to work as GSOC of course even though we would be willing to mentor it.

Or maybe a completely different solution needs to be explored like adding some kind of bulk "convert to" action to a row block.

[djay]

I've added above the idea of the wix style repeater block that repeats a single block type.

Wix style repeater block

wix style repeater block (as suggested by @stevepiercy) is similar to the manual listing block above except that the item being repeated has it's own layout where you can exactly layout "fields".

It's not desirable in plone to allow exact layouts but a plone version might repeat a single block type, and take the repeated blocks variations/settings and centralise them in the repeater block settings.

Wix repeater blocks allow setting as either query based repeaters (connecting it to a database collection) instead. Then it would be similar to @tiberiuichim idea of reusing teaser blocks for listing blocks variations and manual listings. This would be like the idea of unified listing block but without the idea of having pinned manual teasers.

[djay]

@sneridagh @tiberiuichim thought I'd summarise the my takeaways from the last volto meeting

• There needs to be primitives that make making container type blocks easier and more consistent. How you add, remove and access settings for subblocks should work the same if it's a form block, tabs or grid/row. DND in and out etc. Currently block developers do all this themselves.
• There needs to be Row/Grid block in core (https://github.com/plone/volto/pull/3180, https://github.com/eea/volto-columns-block) that solves the layout issue of having different kinds of blocks next to each other or in a table like grid. I personally this should also be the solution for floating videos and images (https://github.com/plone/volto/issues/4439)
• It also makes sense to have a seperate repeater/group block that repeats the same block many times. It's not really the same usecase the Row block where you want control over every block. You want them all to look the same and make it easy to change how they look, by bulk changing the settings of all the subblocks and by having variations for how the repeated blocks flow.
  • having the contents of the blocks being manually enter or determine by a query within the same repeater block or two different repeater blocks is an open question

[djay]

@sneridagh @tiberiuichim @albertcasado I simplified the proposed solutions to this problem a lot so it should be easier to read now. We will slowly move our solution towards the repeater block idea but it would be a lot easier if there was a base DND and block container solution we could build on. That would include the UI for adding and removing sub blocks.