Create a way to show more details to an event

[Yolgie]

Currently we have much more information about events than we can show.

One way of making this additional info visible could be to on selecting an event or clicking on a details button to make this tile bigger and add addional fields that we want to display.

Coordinate with the UUSC Fellow for UX on what to show and how to do this.

[mahdikhashan]

Wireframe for the UI design link: https://excalidraw.com/#json=zIGQ_UzEHFelbd0hsIZKT,ZkABIJCI4WR2_IYjnH2yYQ

for the 1st iteration, I have only used even.description and event.tags.

[kadhonn]

it looks quite nice but i also want something which really shows ALL the properties of the event, especially those not handled otherwise.

also, maybe we could split up the a11y icon into a nicer list somehow?

[mahdikhashan]

would you share the properties we want to show here? also, I agree with you about splitting up the a11y icon, I'll find a way to show it.

also, I need to figure out the appropriate layout for the component.

[kadhonn]

by default we should at least show all properties that we can filter for

and then somewhere else also all properties we don't show anywhere ese

[mahdikhashan]

ok, then let me first implement the first iteration and then add the properties we are filtering for. to see how layouting can be improved.

[mahdikhashan]

properties to display on the expanded event component, in the second iteration,

1. event type
2. show repeating events
3. date from - to
4. venue
5. city
6. accessibility

[mahdikhashan]

after researching about the effect of this feature on the user experience, I have reached to a point to continue by implementing it either as a dialog drawer or modal to prevent layout shift.

It also can affect a11y, since some user may find it unpleasant to follow the shift in layout.

so, the decision is to instead of injecting the details in the events row, when the user clicks or taps an event element (or on a link or a button) open a drawer/modal and show the properties.

@kadhonn do you have any input?

references:

1. https://web.dev/articles/cls
2. https://developer.chrome.com/docs/crux/methodology/metrics#cls-metric

[mahdikhashan]

Second iteration with modal, and properties from filter drawer

[mahdikhashan]

Third Iteration with event drawer

[kadhonn]

well, the two links you posted about cls are interesting but are only talking about unexpected layout shifts
clicking and expanding an event is not unexpected, is it?

[mahdikhashan]

it talks about expected shifts under "User-initiated layout shifts" section of the first link. but, every layout shift has an effect on the UX and A11y, expected or unexpected.

let me make sure it does not affect A11Y first, then UX second. and I'm guessing that a drawer or modal is more predictable than an expandable element in this scenario for a person who requires accessibility. since we are already using a drawer for filters, it may make more sense to stick to the current behaviour and not introduce new one (regarding the predictability of the navigation in a11y).

it can also be a valid case to be discussed with the integriert studieren institute.

I can also implement it and we can check it later with UX fellow against the personas.

[mahdikhashan]

the expanding feature would be like this, did we mean to cover the whole row with an expanded event?

event-detail.mp4

[mahdikhashan]

we talked in our daily today, our concerns at the moment are: white spaces, details that we want to embed in the element and a11y.

[mahdikhashan]

in our meeting today we decided to keep the portotypes in separate branches so then we can work on them at the same time.

[mahdikhashan]

we may need to consider extending the PictureProxy to have a functionality to request pictures in requested size.

[mahdikhashan]

one a11y concerns for the Modal and Drawer prototypes is to prevent mouse or keyboard trap.

[mahdikhashan]

some progress with the modal:

next steps:

1. add more properties
2. style the image background
3. style the modal, the background color can be the same as the event element category
4. add a close icon
5. fix and add the tab container

event-details-modal.mp4

[mahdikhashan]

what am I doing in the code that I'm not happy with is keeping the propeties with data attributes, I think it is not clean and there could be a better way.

also, I can not append the eventHandler to the events that are loaded after the I press the "mehr laden" button.

[kadhonn]

we may need to consider extending the PictureProxy to have a functionality to request pictures in requested size.

that should not be hard, and also we can do that easly in another step as enhancement

[kadhonn]

what am I doing in the code that I'm not happy with is keeping the propeties with data attributes, I think it is not clean and there could be a better way.

i wrote in your PR already, it is better to prerender the modal/drawer content for each event but keep it invisible

also, I can not append the eventHandler to the events that are loaded after the I press the "mehr laden" button.

why not?
it should work to simple retrigger the registering after the load more code is done

[mahdikhashan]

You are right, I'll prerender modal/drawer content. I'll implement the retriggering functionality.

[mahdikhashan]

some progress with modal

Screen.Recording.1403-02-02.at.00.45.30.mp4

[mahdikhashan]

event-details-modal-responsive.mp4

[mahdikhashan]

event details drawer

event-detail-drawer.mp4

[mahdikhashan]

two-column layout:

[mahdikhashan]

in the drawer, I prefer to have a two column layout instead of the single column I used for the modal.

[mahdikhashan]

two column layout with drawer

two-column-layout-drawer.mp4

[twatzl]

Personally I prefer the two column layout. Possibly because that is what I used for museumsbahn-events.at as well. 😅

I think a modal always introduces a new layer in the UI that is not really needed. The drawer also has this kind of overlaying effect. With the two column layout the information stays "on the same level". I hope this makes sense.

btw maybe a thing that should also be considered is what should happen when you get sent a link to a specific event from someone. Like:
https://museumsbahn-events.at/events/2024-04-30T22_00_00.000Z-01-mai-2024-saisoner%C3%B6ffnung-im-eisenbahn--und-bergbaumuseum---lokpark-ampflwang

[kadhonn]

i also like the two-column layout more

and to be honest, i am not quite sold on either drawer nor modal right now :/
i tend more to the drawer simply for consistency with the filter-drawer

and regarding direct-links, patzi and me a loong time ago decided they are not important for us, you should share the actual link of the event, so the source, not a boudicca link
but we can of course revise this decision

[mahdikhashan]

the latest update about this issue:

1. we talked about asking feedback from outside people, I'll wait till friday for a response from my guy.
2. I would also see if I can ask any other fellows for any feedback or help.

@kadhonn if I missed anything here, please let me know.

[p4dd9]

• the preview image as a clickable is not clear what happens
• keep an eye on accessible modals/drawers if done so (https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/) - restore tab where the user came from (e.g. event focus from item 3, should be restored after closing dialog/drawer)
• re-using filter-drawer: i would not re-se a reserved ui context which focus should be filtering and searching to make the ui clear what part is used for what
• i would also challenge our previous decision of not having directlinks/detailpages: imo, singleview by now, make sense - as user-flow, i might want to share details about the boudicca data of an event that could happen via
  --> additional data in the url query on the searchpage
  --> have a singleview!
  --> imo the focus should be that boudicca is the entry point to go to an external link with the purpose to help a user if the event is accessible before opening an external page

TL;DR i think a singleview would be nice (altought SPA logic will break if a new doc loads when navigating) with focus on external open and other recomemndations for events on the bottom

[kadhonn]

i think this is a good point about having a single-view: we can still make sure this single-view is accessible and has information about accessibility and people can share this single-view. this information can be lost when we only allow sharing the original url

but i am not sure if a single view is the best solution while browsing our result list. if every time i want to see more information about this event i need to open a new tab this could get annoying.

i still think in regards to usability the expanding event is the best option, because i can have multiple events open in parallel and it does not disrupt my scrolling. i think the main issue we had is that it creates gaps in our grid, maybe we can find simple solutions for that?
like getting rid of the grid, however this would look like then?
or filling it with a placeholder?
or accepting the gaps?

[mahdikhashan]

latest update on the issue:

1. the code need refactoring with respect to change requests on the open PR.
2. the modal now has a keyboard trap
3. tabbable table height should be fixed.