Deeply-nested StreamFields need better UX

Background

StreamField is undoubtedly awesome, but we have a problem that the more complicated a StreamField becomes the more difficult it is for an editor to use or maintain, and has no visual connection to how it will appear to the end-user.

An example of the problem is a StreamField block called cards that we had on a recent project. Out of the box, in StreamField, it looked like this: Admin view

And on the front end as follows: Front end view

I’m aware that arguably these cards should have been created in a different way e.g. a page reference that pulls the relevant content from the page it’s referencing if the content model allowed; or using a custom block to inject CSS/ JS to allow better styling. @alexgleason ended up using the second option, which he’s released as a pip installable package. It looks like:

I think this is still problematic, though is a vast improvement on how it appears out of the box.

Possible solutions

I think there’s two ways we can move StreamField from a UX point of view:

1. Take a clearer field approach for each StreamField block (similar to Wordpress’s advanced custom fields or CraftCMS’s matrix)
2. Have the semantic value of each block, that isn’t purely text, captured outside of StreamField (e.g. in a dialogue, side-panel or separate page) and give the editor a clearer visual representation of what they’re creating (similar to the Medium, Squarespace or Google Doc UIs)

Attempt at a solution

I think option 2, where the semantic value of each block is introduced outside of StreamField would lead to the richest editorial experience.

I’ve uploaded a project on InVision with that in mind. The first screen is at https://invis.io/ZA64KWAUB. There are hotspots throughout the screens to indicate the user flow, and should allow you to get a general sense of my thinking. I stress it is a little clumsy, and has a number of UI elements changed, which for the purpose of this exercise would have been better left as they currently are within Wagtail, but I think is enough to start a conversation.

The InVision screen is based on StreamField blocks we needed for a recent project: text, image, embed, call-to-action, cards, code block and downloads. The workflow is not completely out of keeping with the existing pattern on Wagtail, a user reveals a dialogue if they interact with a ImageChooserBlock() or PageChooserBlock().

To take the cards as one example (since I used it above to show the problem) Above: Card presented visually as a card, rather than set of fields, with option to add additional card

Above: Dialogue opened with set of fields to populated card.

Above: Additional elements required to populate the field (here an image) would happen within the dialogue rather than opening a new dialogue (since no-one once modals on top of modals!)

Above: Populated field set

Above: User has to hover above the card and click edit to amend the content within it.

Note: I’m missing controls on the individual cards to move/ delete them, if you could just pretend they are there that would be great 😃

The final page, with all elements added is as below:

Possible UX issues

Beyond the obvious technical issue that what I’m suggesting above is currently impossible within the confines of hallo.js, and difficult to get oEmbed to behave in this way, there are a couple of UX issues that others have flagged since I showed them this work

• Talking with @tmsndrs he noted that we run the risk of trying to pre-define use cases for StreamField. @gasman does a pretty good summation of why that would be a bad idea on the ‘Add distinct icons to blocks’ pull request. However, I think there probably is room for us pre-defining things (or at least creating pip installable blocks similar to Alex’s cards). Our attempts to avoid pre-definition have led us to a situation where out of the box StreamField blocks can get very confusing, very quickly
• Again talking with @tmsndrs we run the risk that this predicates the population of content around a desktop presentation of the article e.g. an editor could finesse the article around the needs of the desktop user without thinking about mobile devices
• This implementation would still be unable to represent a ‘Snow Fall’ style implementation of StreamField. There’s no way I can think of that could actually do that. The few I’ve seen that try (all Wordpress plugins) that mess with z-indexing or fixed background positioning within the admin get very confusing very quickly. I think it’s fine to have that limitation.

Would welcome thoughts, from the perspective of whether this really is a problem, whether my assumption of the direction to take for the solution is the correct one, and then whether the solution itself goes someway towards solving the problem.

[davecranwell]

Some thoughts:

• How does the developer control or dictate the “visual presentation” of any field or group of fields and how long will that take per field/field-group/panel/whatever?
• Which developer controls the “visual presentation” The wagtail core team, or the implementer?
• Would we/the implementer need to also prepare a set of example displays before we launch this change?
• Are we not making life much harder by semi-simulating the published page appearance? The closer it looks to the real thing, the more the disparities with the real thing will become apparent and the more clients will request it looks even more like the real thing: it’s the WYSIWYG Uncanny Valley. Not to mention the work involved in preparing the “visual presentations” themselves. I can completely see why many CMS have opted to display fields in a way the least similar to the live page. Wagtail is definitely treading a fine line with its Streamfield appearance.
• It strikes me that the work involved to create a page where each of the blocks of simulated content triggers a modal containing actual fields, can’t be that much less than having the real preview of the page do the same thing.

[gasman]

Completed as of the StreamField UI updates in 2.7.