HLD updates for new Spright chat components: welcome and disclaimer

[jattasNI]

Pull Request

🤨 Rationale

We would like to unify as much of the chat implementation as practical across Angular and Blazor. These are two components that have Blazor implementations in an application codebase that we want in an Angular codebase too, so we want to introduce them to Spright: a welcome screen and a disclaimer at the bottom of the conversation.

(Older Figma designs for illustration only)

Welcome

Disclaimer

👩‍💻 Implementation

Update the chat component HLD with an implementation proposal for these components.

🧪 Testing

N/A

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[jattasNI]

@mollykreis @rajsite heads up that I moved this out of draft and it's ready for your review. No intense time pressure, but I hope we'll have devs starting work on these components this month so I don't want to let it sit for too long.

[rajsite]

FYI @jattasNI didn't get to it today and I'll be OOO rest of week, I don't expect to get to review till early next week

[mollykreis]

This is likely a controversial comment, but I'm curious why you've picked a default of _self. I know that the general guidance is that links should open in the same tab, but it seems like viewing the terms and conditions of the AI from within a product would be a case where switching to ni.com (assuming that's where the terms and conditions are) would be pretty disruptive to what someone was trying to do (e.g. editing a resource in SystemLink). Would that be a case where opening by default in a new tab would be acceptable?

[jattasNI]

Interesting thought. I didn't put much consideration into that choice, just matching the default value of target for a elements.

Desktop apps would definitely continue to want target="_blank" to avoid navigating within the embedded browser hosting Nigel. So the question is really what SystemLink would want.

I suspect you're right that most users SystemLink that click the link would prefer it in a new tab. But my first thought is that I don't believe that suspicion is enough to justify us ignoring / changing the SystemLink pattern on opening links in new tabs, which says to do that only if interrupting a complex workflow where data loss would be likely. I don't think the common case would be to click this while editing a resource. (To be honest, the common case will be never to click the link at all :-D)

So my vote is to keep the default as _self and for SystemLink to use that default. But I'll keep the thread open for Milan to weigh in.

[rajsite]

+1 for _self

Another framing I'm workshopping is that instead of thinking "is it convenient to open in a new tab" consider "should the user be forbidden from ever opening in the same tab".

I don't really see a compelling reason why a user would be forbidden from visiting the link from the same tab.

If there is something semi-useful that they may have typed in the webapp should be doing good webapp things like caching the content in local storage or something. If the user is in the middle of a workflow like an agent tool call that would be interrupted then hopefully any navigation would tell the user that (i.e. temporarily register an onunload handler, etc, but not permanently because that breaks back / forward cache).

[mollykreis]

I'm sure I don't fully understand all the use cases around logging in to the AI, but a few things stand out to me as potentially problematic:

• Is there a use case for an app having this button present in the app but hiding it via CSS based on app state? If so, I'm not sure the standard pattern to detect slotted content will correctly handle slotted, but hidden, content?
• You mentioned part of the reason to slot this button was to avoid exposing a bunch of properties for the button on the welcome content (e.g. "login-disabled"). However, in a scenario where the login button is disabled, it seems odd to show the text "Log in to get started".
• The default slot and the login message seem magically tied together. I think the coupling of the login message with the button would be better if the button was going in a named slot.

Given all that, I'm wondering if it makes more sense to have more of the content in the welcome content slotted. For example, have a slot for the login message and a separate one for the login button, or possibly even have a single slot where someone could put both the button and the text. Alternatively, maybe there should be a boolean attribute that controls whether or not to show the "Log in to get started" so that it isn't implicitly tied to a button being slotted.

[rajsite]

Kinda similar I wonder if the post login content being kinda hard coded in nimble is too rigid. could imagine more instructions "type something or drop a test report to begin", etc being app specific. May even be buttons, etc to choose a file or something.

[rajsite]

We've talked about how message had gotten weirdly overloaded (system and outbound have a larger api with all this footer stuff they don't need) and how we could refactor to spright-chat-message-inbound, spright-chat-message-outbound, and spright-chat-message-system.

What do you think about this and future message types being added as such, so instead spright-chat-message-welcome and it's not a child of spright-chat-message?

Another alternative is we keep adding on to a monolithic component so <spright-chat-message message-type="welcome">

We could do the current pattern but it has odd degrees of flexibility like being a child of <spright-chat-message message-type="inbound"> or <spright-chat-message message-type="outbound"> which seems unintended.

[rajsite]

Also framework router integrations are a pain (all the ngRouter / nimbleRouter stuff)

[rajsite]

I can imagine the disclaimer content varying by application. And have similar concerns to above, i.e. maybe an app really wants a button to view the disclaimer content or needs router integration for the link. Maybe the disclaimer needs more context or warnings for different applications ("uploaded images are sent to a third party", "uploaded content will not be used for future training",etc)

Wondering if the component itself is needed. Should the slot just have text font / color set on it and be kept flexible?

[rajsite]

+1 for _self

Another framing I'm workshopping is that instead of thinking "is it convenient to open in a new tab" consider "should the user be forbidden from ever opening in the same tab".

I don't really see a compelling reason why a user would be forbidden from visiting the link from the same tab.

If there is something semi-useful that they may have typed in the webapp should be doing good webapp things like caching the content in local storage or something. If the user is in the middle of a workflow like an agent tool call that would be interrupted then hopefully any navigation would tell the user that (i.e. temporarily register an onunload handler, etc, but not permanently because that breaks back / forward cache).

[rajsite]

from token naming

element: message?
part: welcomeContent?
type: gradient?

I think type should be image like we did for the ni-nimble-section-background-image token and not introduce a new type.

Reserving the right to wiggle around based on the other discussions for elements but think I'd lean more to:
element: chatWelcome (grouping under chat like we have calendar and graph elements and this is very chat specific, not general use it seems)
part: background
type: image

[rajsite]

template will read the correct gradient value for the current theme using `messageWelcomeContentGradient.getValueFor()

Can't the token just be a linear-gradient css image value like section-background-image and applied in styles?

[rajsite]

Kinda similar I wonder if the post login content being kinda hard coded in nimble is too rigid. could imagine more instructions "type something or drop a test report to begin", etc being app specific. May even be buttons, etc to choose a file or something.