Follow-up the UX of pre/custom actions

[framitdavid]

Based on the discussion within issue: #12151, we should consider user-testing our current implementation and then iterate if needed. 💯

@Annikenkbrathen has created a potential improvement:

Tasks

Preview Give feedback

1. Find service developers that has a understanding of actions
2. test with app migration
3. Follow up text on switch after user test feedback #12950
   status/ready-for-specification text/content ux +3

[framitdavid]

I added to sprint, to be able to update to the newest design system. Our custom actions implementation does not work with the current combobox. :)

[Annikenkbrathen]

Resultat etter brukertest

@framitdavid

Totalt 4 testere
4 av 4 foretrakk action select I tabs så jeg foreslår at vi bytter ut combox-selecten da den allerede byr på litt utfordringer

Action combobox (Dagens design)

• forstår valgmulighetene etter beskrivelsen. Forstår at det er to måter å sette opp actions på
• Føler fritekst skal brukes som et søk i listen, ikke til å lage et nytt valg.
• Føler det er feil å skrive inn eget navn i selecten
• forventer å finne sin egen handling i listen som man legger til enda en ny handling
• Vanskelig å legge merke til switchen som dukker opp om man skriver en egen
• Det kommer opp en tekst i nedtrekken når du begynner å skrive. "Dette burde vært en knapp som sto "legg til handling". Ønsker å trykke på det som dukker opp"
• Rart at lagre knappen er disable, men kan trykkes på. De fleste får til å lagre selvom det er rart.
• Det er en risiko for å ikke lagre dersom man ikke lukker visningen
• 2 stykker skjønte ikke at de måtte lagre etter å ha valgt

Action select I tabs

• Liker at egendefinert er mer skjult "det er vel ikke mange som trenger det?"
• Tydelig at du har to måter å legge til en handling på
• skjønner at om du velger å fylle ut både egendefinert og tab, så vil den siden som du er på når du lukker, være den som blir lagret.
• liker de siste oppfaterte titlene best. De skjønner meningen bak tab-overskriften

Switch "Handlinger skal ikke påvirke prosessen"

• vanskelig å forstå hensikten med dette valget.
• hvorfor vil man ikke påvirke prosessen? og kan man bestemme hvordan den påvirkes om man trykker ja? hvor setter vi opp hvordan den påvrikes? i gateways?
• ikke lurt å bruke "ikke" i teksten på en switch. Man blir usikker på hva som skjer om den er på eller av.
• siste setningen i hjelpeteksten er ikke vits å ha med. " Dette alternativet er kun tilgjengelig for egendefinerte handlinger." det er opplagt når den kun dukker opp ved det valget/ kun vises i Taben det gjelder.
• Ønsker et eksempel på bruk

Oppsummering

• De forstår og får til å legge til med begge design
• Noen skjønner ikke lagre konseptet på combobox, derfor fungerte tabs i et card bedre
• Switchen kan overses i combox designet, da den dukker opp litt diskret etter valget
• Det er flere forventninger som brytes i combox. lagre, at du ikke kan legge til egne handlinger i listen, at det dukker opp en uventet switch
• Action select I tabs: De skjønner forskjellen på Tabene, og at de kun kan velge en av de når de legger til
• Switchen er forvirrende. Her savner de et eksempel på bruk, og mer forklaring på hvordan det settes opp. Hva skjer med og hva skjer uten? Det bør også unngå å bruke ordet "ikke". også må det som mest sannsynlig er mest brukt, stå på som standard valg i switchen
  

[framitdavid]

Resultat etter brukertest

@framitdavid

Totalt 4 testere 4 av 4 foretrakk action select I tabs så jeg foreslår at vi bytter ut combox-selecten da den allerede byr på litt utfordringer

Action combobox (Dagens design)

• forstår valgmulighetene etter beskrivelsen. Forstår at det er to måter å sette opp actions på
• Føler fritekst skal brukes som et søk i listen, ikke til å lage et nytt valg.
• Føler det er feil å skrive inn eget navn i selecten
• forventer å finne sin egen handling i listen som man legger til enda en ny handling
• Vanskelig å legge merke til switchen som dukker opp om man skriver en egen
• Det kommer opp en tekst i nedtrekken når du begynner å skrive. "Dette burde vært en knapp som sto "legg til handling". Ønsker å trykke på det som dukker opp"
• Rart at lagre knappen er disable, men kan trykkes på. De fleste får til å lagre selvom det er rart.
• Det er en risiko for å ikke lagre dersom man ikke lukker visningen
• 2 stykker skjønte ikke at de måtte lagre etter å ha valgt

Action select I tabs

• Liker at egendefinert er mer skjult "det er vel ikke mange som trenger det?"
• Tydelig at du har to måter å legge til en handling på
• skjønner at om du velger å fylle ut både egendefinert og tab, så vil den siden som du er på når du lukker, være den som blir lagret.
• liker de siste oppfaterte titlene best. De skjønner meningen bak tab-overskriften

Switch "Handlinger skal ikke påvirke prosessen"

• vanskelig å forstå hensikten med dette valget.
• hvorfor vil man ikke påvirke prosessen? og kan man bestemme hvordan den påvirkes om man trykker ja? hvor setter vi opp hvordan den påvrikes? i gateways?
• ikke lurt å bruke "ikke" i teksten på en switch. Man blir usikker på hva som skjer om den er på eller av.
• siste setningen i hjelpeteksten er ikke vits å ha med. " Dette alternativet er kun tilgjengelig for egendefinerte handlinger." det er opplagt når den kun dukker opp ved det valget/ kun vises i Taben det gjelder.
• Ønsker et eksempel på bruk

Oppsummering

• De forstår og får til å legge til med begge design
• Noen skjønner ikke lagre konseptet på combobox, derfor fungerte tabs i et card bedre
• Switchen kan overses i combox designet, da den dukker opp litt diskret etter valget
• Det er flere forventninger som brytes i combox. lagre, at du ikke kan legge til egne handlinger i listen, at det dukker opp en uventet switch
• Action select I tabs: De skjønner forskjellen på Tabene, og at de kun kan velge en av de når de legger til
• Switchen er forvirrende. Her savner de et eksempel på bruk, og mer forklaring på hvordan det settes opp. Hva skjer med og hva skjer uten? Det bør også unngå å bruke ordet "ikke". også må det som mest sannsynlig er mest brukt, stå på som standard valg i switchen
  

Amazing work!! Thanks! 👏

[standeren]

Tested, but there are some small issues;

1. When adding an empty action (either not choosing a predefined action or saving an empty custom) we get an empty action in the process-file: <altinn:action /> - might not be illegal config, but noice. And you get the add-action-button UI, but with the Handling {INDEX} as text for the button.
2. When deleting an action that is not last, when there are multiple other actions, you will get the subsequent action in editmode but with the action-name of the deleted action so it is easy to miss that the original action that was in editmode was actually deleted. The ideal behavior here would be that the action in editmode was deleted and nothing else happened with the view of the other actions.
3. I believe this is a more critical fault; when enabling connecting action to next step the server action is set in the process-file, but if connecting it to the next process task type should be processAction (or no type which is the same) 🤔

And I also have a question concerning the UI; is it by design that the name of the action is written twice when in preview-mode? And nitpick, but we should skip the . in the switch-text

[framitdavid]

When adding an empty action (either not choosing a predefined action or saving an empty custom) we get an empty action in the process-file: <altinn:action /> - might not be illegal config, but noice. And you get the add-action-button UI, but with the Handling {INDEX} as text for the button.

I will investigate handling {INDEX} as text. As for the other aspect, I'll create a separate issue since it's already functioning like this in prod. However, I agree that there's room for improvement in that area. 😊

When deleting an action that is not last, when there are multiple other actions, you will get the subsequent action in editmode but with the action-name of the deleted action so it is easy to miss that the original action that was in editmode was actually deleted. The ideal behavior here would be that the action in editmode was deleted and nothing else happened with the view of the other actions.

I suspect that this issue arises because we are using the index as the key here. We need to find another way to handle the keys. Perhaps we can add an attribute for the Studio when adding actions? That way, we can ensure a stable key that we can use in the list of actions. It seems we cannot use index + action, as this may cause everything to re-render and the card will change modus to view instead of edit. We definitely need to find a solution with a stable key that does not change. I will look into that.

I believe this is a more critical fault; when enabling connecting action to next step the server action is set in the process-file, but if connecting it to the next process task type should be processAction (or no type which is the same) 🤔

I will look into this immediately and create a PR to ensure the deployments are not blocked by this, nice catch!

[framitdavid]

Closed due to fixes within the following PR: #13333