Do we need message as a standard status in the inbox

[Febakke]

Description

Technically there is no difference between our forms and messages, this makes it possible to connect form and messages into connected services. If the app owner wants to tell the user they are on a message step they can use sub-status, but this might create a situation where we have different names and descriptions for the same functionality. Would it be better to have a standard way of handling messages?

This might be a part of a larger issue on how the inbox should handle our apps.

In scope

Research need from app developers Decide if this is something we need

Out of scope

Specification of message behavior and design

Analysis

Lorem ipsum

Conclusion

Short summary of the proposed solution.

Tasks

• [ ] Is this issue labeled with a correct area label?
• [ ] QA has been done

[torbjokv]

At DAT we have the need to send the organisation a message to their inbox with the reply of an application (or maybe just give general information?) like we have done with InsertCorrespondenceBasicV2 until now. While the message functionality (https://altinn.github.io/docs/altinn-studio/app-creation/message/) is flexible and meets most of our needs, its limited how we manage to adapt the text and buttons in the altinn inbox. Now there is a go to form button and a pencil icon, but we only want to give read only information in this case and there is no way to get rid of this as far as I know.

[altinnadmin]

Would it be better to have a standard way of handling messages

Currently the inbox is based on the very limited service types in Altinn 2, something that makes it difficult to handle the flexibility of apps in Altinn 3 in the inbox. An app is not always a message, or a form. It can be whatever.

Could we instead go the other way and simplify? For apps, just use the service owner logo as icon instead of the envelope and pencil, and just "Åpne" instead of "Gå til skjemautfylling" etc. That way we avoid these strange cases and all the related complexity.

[lvbachmann]

@altinnadmin That would somewhat simplify things, but an "Åpne" button which just leads to the same content in a new framing doesn't sound ideal...

[altinnadmin]

Hopefully one does not create apps that only shows the same content. Seems like a strange thing to do?

[lvbachmann]

@Febakke To shed some light on the question from @altinnadmin: Have we moved away from the hypothesis of the message text being shown in the inbox? If we have, I agree that same content in message box and service seems unlikely/strange.

[torbjokv]

At DAT we have the need to send the organisation a message to their inbox with the reply of an application (or maybe just give general information?) like we have done with InsertCorrespondenceBasicV2 until now. While the message functionality (https://altinn.github.io/docs/altinn-studio/app-creation/message/) is flexible and meets most of our needs, its limited how we manage to adapt the text and buttons in the altinn inbox. Now there is a go to form button and a pencil icon, but we only want to give read only information in this case and there is no way to get rid of this as far as I know.

My example here in maybe not the best as I guess the initial receipt when posting the form should be sufficient (I hope). A better example would be "Application approved: Innkvartering...." and then we would like to add our own archive reference in there somewhere together with some data/text provided by the caseworker (e.q. in case you got rejection, we need to tell them why). The latter points may of course be located inside the app.

[Febakke]

Originally this issue was created based on the fear that we would end up in a situation where apps use different words to describe the same functionality. Some might call it a message, correspondence or a letter. The solution to this might be to offer a standard message status defined by us, that hopefully would concise description of messages in the inbox.

@lvbachmann Well, yes in the first sketches we ended up not including any message text in the inbox, but that decision was not made with usability in mind. From the perspective of a user in the inbox, it is very hard for me to argue that it is better to have a simple message inside an app instead of inside the message element in the inbox. That said I do agree that our elements could need an upgrade. I could make a separate issue "improve our inbox elements" and include Altinnadmins suggestion?

@altinnadmin Could some confirmation text maybe be shown with the help of the sub-status description in this case?

[nkylstad]

This issue seems stale, can it be either closed or moved to a more relevant repo? @Febakke @altinnadmin

[Febakke]

I agree, it should be moved. Our lack of concepts (to my knowledge) around how status and longer connected services are presented outside the app is still a concern of mine. I guess issues like this might go beyond the Altinn inbox as it might not always be the place where the user will find or see a status on the apps. Also might be relevant for @sorensensig and "Arbeidsflate".

[altinnadmin]

To me it seems like we have these things to consider:

• Dialogporten will open up for service owners adding whatever "actions" they would like to expose in UI for a given element. So the future is very flexible. @nkylstad This also means that Studio must consider how to handle/implement this flexibility when creating/updating elements in Dialogporten for app instances. Best handled in a new issue.
• Altinn inbox will be replaced by Dialogporten + Arbeidsflate, so we should not make any big changes to the old stuff in Altinn II. The question is if there are minor changes that could be done to fix known challenges. Ref. #5495. F.ex use "Open" as button text for all apps from Studio.

[sorensensig]

I agree, it should be moved. Our lack of concepts (to my knowledge) around how status and longer connected services are presented outside the app is still a concern of mine. I guess issues like this might go beyond the Altinn inbox as it might not always be the place where the user will find or see a status on the apps. Also might be relevant for @sorensensig and "Arbeidsflate".

I share your concerns @Febakke on how we don't have a clear strategy on how apps are experienced outside the app itself and how they should convey an experience of connected services in the various places they are exposed to the user. I believe this might be one case-study we have to look at across product teams as the responsibility seems to fall between the cracks.

I know team arbeidsflate have looked into this issue as well and how apps ought to be experienced in the inbox. It doesn't seem like I can tag Mette (product owner arbeidsflate) here. @indiamaydesign can you bring up this issue with Mette and team arbeidsflate? However, this does not meet all of our needs for how connected services should be experienced as they might be exposed in other locations than the inbox.

[elsand]

As I'm reading this, "connected services" in this context is just a complex dialogue process consisting of various backs-and-forths between the user and the service owner - all within a single app instance. In Altinn 2, this would actually be distinct services; that is one or more correspondence services in addition to the formtask(s), with their distinct and mostly disconnected inbox elements and distinct access control/delegation.

The ability to express the various states of complex dialogue processes is at the very core of what we want to achieve with Dialogporten. The integration with Altinn 3 is in that regard a crucial piece of the puzzle, handling the state transitions for app instances and syncing the current metadata to "dialogs" in Dialogporten, which then is rendered in Arbeidsflate.

Here's a simple diagram over this:

Dialogporten has a roadmap issue (with links to a more or less empty epic in Dialogporten). The component mentioned above will naturally have to be the result of a close collaboration between the Dialgporten team and the apps team; I have already discussed this briefly with @tjololo.

Issues related to this relevant for studio are still TBD, but will presumably be mostly a more supportive/value-add nature. For instance, having some sort of preview functionality ("how will instances of my app look like in arbeidsflate on a given process step/task") would be great.