Adding a collapsible panel from the UiKit

[FFawzy]

After a discussion with Luke and Zoe on what they might need soon as a new interactive element, they decided to go with a collapsible panel. https://uikit.commercetools.com/?path=/story/components-panels--collapsiblemotion

@zbalek please Zoe, take a look at the Ui Kit design and see how it would look like in our docs site.

The functionality is available from the Ui Kit but we need the design from you to be able to start with this ticket.

Thanks

[nkuehn]

@FFawzy @lukpan It would be a more professional process if you described the didactic use case you want to realize and leave the choice of UX/UI pattern to Zoe and the grooming process. It does not rule out mentioning possible implementation ideas both on UX and implementation / available components level but without any scenario description it's really not very useful as a design task

Pre-empting an implementation without describing the use case and its value requirements is pretty much guaranteed to result in suboptimal results.

[FFawzy]

@nkuehn , my fault. I missed adding it to the description here.

this issue is coming based on this use case provided by @lukpan

"To break up large slabs of text and hide them behind the accordion. Also again makes learners exercise decisions to engage with the content."

the collapsible panel was suggested by @zbalek in the exploration ticket

[nkuehn]

Playing the devil's advocate here: "To break up large slabs of text and hide them behind the accordion" is not a use case or user outcome wording. It's just a different way to formulate a specific UI. "Make learnings exercise decisions to engage with the content" is a bit more towards a UX requirement but to be honest "decisions" is a bit broad. Is clicking a tab or accordeon panel already a "decision"?

[nkuehn]

P.S. on why I'm critical here: Accordeons have all sorts of ugly edge case problems and are by no means trivial to get to work robustly all the way down to mobile viewports. It would help finding a good UX pattern if the requirements were more open but on the other hand gave much more guidance on the typical content situation.
For examle

• what typical number of content sections of whom only one should be visible do you expect? 2-5? 4-10? 7-20?
• can two of them be visible at the same time?
• how long and how rich is the content inside them? Including full expressivity like images, videos, tables, cards etc or would a limited subset be OK like we have it for card content or RAML descriptions or release notes ? (for example this matters in deciding because full expressivity that makes all our existing content components work would require full content width to not get into a complete mess of breakpoints)

• would one of the content fragments be always visible or would "exploration" imply that no content is visible at first and users have to take a click to see some content at all?

  Given all that, @zbalek can make her mind about possible options. There are many UI patterns that achive "make a decision to see certain sections of content" (tabs, tabs on the side with fixed height content, accordeons, jump lists, modals opened from buttons, ...)

  FYI @lukpan

[lukpan]

Hi @nkuehn @FFawzy @zbalek

For the accordion, I was thinking something along the lines of how it is used here in Stripes docs. (previous link here was in correct, now it is correctly linking to accordion example).

The above example contains a lot of options to have hidden in an accordion (too many I would say). I don't imagine this many being needed for our learning content. I would say three or four content sections would be most likely.

The accordion feature would be very useful with the developer learning path. It would allow for a user to read content that is 'generic' and common to SDK programming languages in the regularly way we have been using until now. Then, if the steps in a process, for example, diverge according to these languages, then the accordion would be a valuable tool to be able to break this up according to the language and allow the learner to choose the section according to their needs.

Another use case would be in presenting multiple examples on one topic. The user would be able to select one piece of content at a time, absorb that information, and then move on to the next. Visually it reinforces the idea that this information is connected and on a similar level, allowing for cognitive links to be formed. Very valuable for chunking information.

Learning checks in Self-Learning can be created to present multiple processes that the learner needs to decide which is the most appropriate solution to a problem. The use of accordions (or this could be tabs too, both would work) would allow these process to be presented more clearly, exposing only one of them at a time. They also allow for the learner to be able to spot visually the differences between the processes by how the text changes on the page, signaling to the learner where the changes are and key decision points they should consider.

With regards to 'learner making decisions', simple interactive components like accordions and tabs physically engage the learner and give them a further sense of control over their interaction with the content. They are small decisions that they are making, but they add another interactive layer for the learner.

Should more than one content section be visible at a time in an accordion? I think most times having one would be most useful, but then again sometimes the learner might find it beneficial to have multiple open. It would be good to at least have the possibility.

How long and how rich is the content inside them? Ideally having full expressivity would be the ideal case, but I could live with text, image to begin with. Video would also be nice though, especially if we emphasise this more as we are planning.

Would one of the content fragments be always visible or would "exploration" imply that no content is visible at first and users have to take a click to see some content at all? No real learning opinions here from me. This is probably more a UX decision.

[nkuehn]

Thank you @lukpan ! I understand "decision" now, more learnign psychology perspective than my everyday understanding of decisions.
Some further ramifications below but I think we could talk about it, too to not make it sound more problematic than it is.

---

For the use case of different "Paths" (e.g. programming languages) I think accordion is not the best pattern. The next path is still below the expanded path so it would suggest to also read that although the intent was to split and re-unite. For that, tabs sound much more sensible to me. Also, is picking your programming langugage really a "decision"?

---

For the use case of multiple examples, yes, that could be something that is linear "stacked".

---

Learning checks in Self-Learning can be created to present multiple processes that the learner needs to decide which is the most appropriate solution to a problem.

First convincing use case in this thread, thanks!

---

They also allow for the learner to be able to spot visually the differences between the processes by how the text changes on the page

At least concluding from the Stripe example I disagree that this helps. It was making things just much worse to have them in tabs. If I want to really compare two things that's a table or a graphic in side by side layout. If the comparison does not fit the screen height, a tab or accordion just makes it worse (I can never directly see the difference between the alternatives because I have to scroll to toggle and then scroll back).

---

Concerning the Stripe example where they combine making the sections of the page accordion-ed (with every accordion having an index nav entry, too) AND having long tabbed content inside them was confusing the hell out of me. The tabs' content is longer than the screen and there is no indication what the end of the content in the tab is vs. where the the general content flow beings again. So I basically scrolled down to memorize the content, then switched to another tab, then scrolled down again to try to reconcile where the tabbed content ends and the next starts. My learning from that is that we should definitely not allow nesting structure-building elements into each other and have guidelines on content length etc.

[zbalek]

Hi @FFawzy - please see the design ticket here: https://github.com/commercetools/learning-tech/issues/458

[nkuehn]

Summary from Talk between me and @lukpan : Stripes example was confusing becasue they mixed required and optional pieces in one list of collapsibles that looked like an accordion but behaves like individual collapsibles.

Finding: for non-optional content it's just a distraction and a section heading does the job. But for optional content it's interesting. But let's not overengineer it into a accordion, individual collapsible panels are enough expressivity.

To be defined: Would they have the status ofa heading in the document outline (and be linkable)? If yes, a specific level or any level? --> important for the search crawler and the implementaiton (auto expand if linked there). To prevent misuse, we could even consider that the implementation does not support it starting opened by default -> if it's open by default you don't need it, use a section.