Add display text image support

[kirsty-hames]

Subject of the issue/enhancement/features

I've had this come up on numerous projects in the past and have also gone about implementing this in various ways but I think there is a frequent need to include images within component display text. Common in content for systems training or subjects with hands on equipment etc.

I've raised this for MCQ but I also have the need to support this in Textinput too. Potentially this could be a useful additional to support in components globally rather than a per plugin basis? For instance, you could have an accordion which includes a diagram, then each item of the accordion looks at the sections of the diagram etc.

Expected behaviour

See example below (excuse the placeholder content). From a content perspective, I'd expect a user to read the question (body), look at the image for the answer, read the instruction text then select an option and submit. For this reason, the image would need to be inserted between the body and instruction.

Please give a thumbs up if you would find this a useful additional or add any comments below. Thanks in advance.

[joe-replin]

It's a neat idea. I can see a few wild approaches.

1. Text & Graphic components merge into core. adapt-contrib-graphic becomes the new component header across all components.
2. I like the idea of some sort of content repository of items that can be inserted anywhere in the content. A separate JSON file can house blocks of content, images, resource items, etc. And whenever you need to pull from that common asset repository, you simply reference it. However, I don't see that being easy-to-use from a building perspective.
3. Simplest approach - The component header template has an added graphic. Possibly a sorting order as well?

[oliverfoster]

1. This isn't quite what would happen. Yes, some of the behaviour would move out of the graphic and into the header.jsx but not all of it. Same with the Text component, most of its behaviour is in header.jsx but not all of it.
2. This is very possible, except that there is no UI in the AAT for viewing, placing or editing the properties of adhoc sub-objects.

• I have previously allowed rendering all kinds of things with handlebars helpers, but it's too complicated to inject and configure an entire component as handlebars in, for example, the body of a text component. Wordpress has something similar, it's horrible to use in practice.
• An alternative for media is to carry on with formalising the _graphic object, but swap it for _media, a little like graphicLottie and graphicVideo, such that it's possible to use any kind of 2 dimentionally rendered medium with an appropriate renderer. This relies on being able to define schema rules for medium types (as they will each have their own controls config), plus being able to swap out the UI in the AAT for the different rule types. as well as a plugin structure for adding new renderers.
• Having an external content repository is always extremely messy (same problem with knowledge management systems), they tend to become overwhelmed with mostly irrelevant content, this is as in order to make them effective, all content should be uploaded to them and that the future usability of an item of content cannot be determined at the time of capture.
• In the context of a course, we do have a content repository, it's the files on disk with the json references to them in the content, in the AAT, managed by the assets UIs. Where and when you can use each asset type is determined by the schemas.
• Linking text from a separate json to a content body should be almost already possible (except that there is currently no way of loading json that has an undefined model/view pair), you can see this with the using helper; {{using 'id'}}{{body}}{{/using}}. But as you can see, the reference has to happen in the existing component text field, linked using rendering helpers, thus implying some coding skill and being secondary to AAT user interface.
• Being able to inject preexisting image assest more easily into text does sound like something worth doing, I'm not sure the AAT would cope though, as assets need to be explicitly referenced in schema fields to be included.

3. Same as option 1.

[kirsty-hames]

Thanks @joe-replin and @oliverfoster for your comments above. I agree that point 2 would be desirable but there's some big concerns there over compatibility/usability to support AAT. Is it still worth looking at a simple approach for this, inlcuding image support in the core header.jsx?

3. Possibly a sorting order as well?

I think this would be useful. Generally I find it's the order of text/image that is likely to move around but I noticed this PR for List to include a bodyAfter property. So I think there is a need for a flexible order.

[oliverfoster]

You looking at title, body, graphic, instruction, widget, bodyAfter vs title, graphic, body, instruction, widget, bodyAfter?
(Perhaps bodyAfter should be footer instead?)

[oliverfoster]

Perhaps it's time to move _imageAlignment from Accordion into core, both at header.jsx for positioning and image.js where required, and instead of an external attribute, put the attribute on the _graphic object with full left right top bottom?

"_graphic": {
  "_alignment": "full top",
  ...
}

That way we could use it all over, where needed.

[kirsty-hames]

I like the idea of using _imageAlignment as we already use this for image alignment in popups too (Hotgraphic, hotgrid and Question feedback). In all instances though it's just the body and image within a container. For header.jsx, we've got title and instruction too. Unless we just put a wrapper around body and image?

[oliverfoster]

I think it's fine to have it just for body and image. Slightly confusing mind to refer as top/bottom. Top is not above title, bottom is not below widget. Top is instead above body and bottom is below body. Food for thought.