volto: PLIP: I can easily switch back and forth a listing/row of teaser styles (repeater block with selectable source and manually added items)
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
- ie certain blocks types are marked to be repeatable. the repeater block lets you globally set
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)
- I can enter teasers fully manually (ie manual title, description, image)
- I can reorder teasers after adding
- I can have a set of teasers side by side or vertically
- I can have many variants of how rows or grids of teasers appear and switch between them easily
- I add teasers where title is filled in automatically from the target content
- I can have a set of teasers determined by single folder contents
- I can have a set of teasers determined by a query
- I can have a set of teasers that are inline buttons/tags rather than in a grid
- I can customise a single title of a teaser in a query set of teasers
- I can have a manual set of teasers but stored in a field like “related items”
- I can quickly add a teaser by DND from a finder
- I can a have a set of teasers determined by a query except a few which I pick to be first
- I can switch a set to teasers from using a query to be a manual ordering
- I can reuse a query or “source” between in many teaser sets so as not to type it again?
- I can have a set of teasers that use different variations in the same set
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 26 (25 by maintainers)
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.
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.
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 :
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.
I think we can agree that the current way of moving things forward that are stuck is suboptimal. We have identified why that is:
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?
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. 🎤 💧
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”.
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.
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.
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
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.