Tabs feature Process Modeler/Chrome in Appian UI

RE: Tabs feature Process Modeler/Chrome in Appian UI

Mike Schmitt — Wed, 08 Jun 2022 17:32:31 GMT

In a single Card you could have any combination of components including a dedicated Rich Text Icon which renders at the right edge of the Card and performs "Close" functionality.

RE: Tabs feature Process Modeler/Chrome in Appian UI

thevarunbawa — Wed, 08 Jun 2022 17:26:39 GMT

Thanks Mike. We were able to implement that. But the only challenge we got is to have an X mark at the corner of that tab to close it. For now we have put an extra "Close" button in the form to close that current tab.

Is there any way that we can close the tab and have the same look and feel like one in image below.

Thanks

RE: Tabs feature Process Modeler/Chrome in Appian UI

Mike Schmitt — Wed, 08 Jun 2022 15:32:20 GMT

You could potentially do this with any of the "appian tabs" patterns available in the Appian documentation. See, for example, "cards as tabs" or similar options. All you'd need to do is code the "available tabs" to display based on a list, and your grid links, when clicked, would push the value corresponding to that row into that local list and a new tab would become available at that point. I don't have an implementation of this per se, but it shouldn't be hard to do.

RE: Tabs feature Process Modeler/Chrome in Appian UI

thevarunbawa — Wed, 08 Jun 2022 15:16:43 GMT

For now we have created a close tab button in the form itself to close the current tab with the logic you mentioned above.

But, I am still curious if can add an X in the corner like image attached rather than having a button on form.

When I make card as clickable link it it is clicked as whole single button not like other tab functionality like closing on X and activating the tab on clicking on remaining portion.

RE: Tabs feature Process Modeler/Chrome in Appian UI

davel001150 — Wed, 08 Jun 2022 13:39:47 GMT

That's going to need a few variables.

You could have a list of tabs that show, then forEach( items: list of Tabs, expression: doohickie at the top of the page)

The doohickie at the top of the page (really laying on the technical jargon today) could feature a red X rich text with a dynamicLink that removes the one at this index from list of tabs.

Then you would possibly need separate variable to store which index on the list is currently being displayed. That doohickie might be shaded or blue or something when that's set, and that Section will have it's showWhen true.

Next, you need to account for what happens when the user deletes the tab they're looking at right now. Maybe the X is gray and they can't while they're looking. Maybe you find the tab to the immediate left and select that and display it. Maybe none of the tabs are selected and you display nothing. If you don't deliberately decide the edge case now, what you're bound to get is a pink box.

RE: Tabs feature Process Modeler/Chrome in Appian UI

thevarunbawa — Wed, 08 Jun 2022 13:11:53 GMT

yeah correct. I tried implementing the same way and it worked. thanks. But only issue is with closing of tab now. Can we achieve this functionality that we can have a small X button in the corner of tab to close the current active or any inactive tab?

Couldn't figure out a way to achieve this. Tabs are opening but no way to close them.

Thanks for help. Really appreciate it.

RE: Tabs feature Process Modeler/Chrome in Appian UI

davel001150 — Wed, 08 Jun 2022 13:03:52 GMT

a!startProcessLink(), if that's even what you want to go with, does not necessarily involve having an interface at all. It just runs in the background, however long it takes. The user interface is completely unaware of it and just moves on before it's done. Who even knows when it's done?

The interface just goes to the next line of your saveInto,

a!save(local!showFirstForm, false)

a!save(local!showSecondForm, true)

The rest is up to the showWhen parameters of your sections, or however you choose to lay out your interface. In this way, you really never DO leave the same bit of SAIL. It's always the same bit of SAIL the user is looking at; just within that different parts displayed or not displayed which mimics navigation.

RE: Tabs feature Process Modeler/Chrome in Appian UI

thevarunbawa — Wed, 08 Jun 2022 04:03:42 GMT

Similar to above image, this is in same chrome tab.

RE: Tabs feature Process Modeler/Chrome in Appian UI

thevarunbawa — Wed, 08 Jun 2022 03:57:16 GMT

I am little confused with updating variables, let's say first approach, user clicks the link, process model kicks and flow moves to User input task, I can send a flag as true, something called, "clickedOnLink". And then pass the clickedOnLink to UI, then how can I tell interface that rather than overriding the current view and then showing in the same tab, create a new tab in same interface next to the one in which you have that data grid, and open the summary details UI in that new tab. Like image I attached in Danny Verb comment

RE: Tabs feature Process Modeler/Chrome in Appian UI

thevarunbawa — Wed, 08 Jun 2022 03:48:36 GMT

The chrome tab is one and same only but withing that same chrome tab and Appian UI, we need multiple tabs.

In Appian UI, it is a grid showing data, when clicked on any row to show its data, that should open in the same UI, same chrome tab but new tab in the same UI.

Similar to Process Modeller tabs, the chrome tab is same but in Process Modeller, it opens new tab in same Modeller UI.

RE: Tabs feature Process Modeler/Chrome in Appian UI

davel001150 — Tue, 07 Jun 2022 20:05:43 GMT

If you're meaning the tabs that are within Appian, so that you have one Chrome tab showing multiple Appian tabs, I think something like what you want could be possible with some rigging.

So, when your process is done and you're kicked back to the same screen, you need to update one of the parameters (you could also possibly manage with local variables) that tells the interface to display the other tab instead.

If you're doing a!startProcess, you have the option of starting the process first, then changing the variable that says which interface tab is showing. That happens right away, so it's almost inevitable that you will show the screen before the data is updated. In that case you would assuredly need a refresh, possibly automatic and manual.

You can also configure it to attempt a query or two in sequence that will likely take just longer than the process you called, and at the end of the chain of localVariable updates, the last one in the chain is the variable that determines which "tab" is showing on your interface. That might be a good approach if you happen to need all the data you're querying to display on the new "tab" anyway.

RE: Tabs feature Process Modeler/Chrome in Appian UI

Mike Schmitt — Tue, 07 Jun 2022 20:02:00 GMT

[quote userid="22226" url="~/discussions/f/user-interface/24833/tabs-feature-process-modeler-chrome-in-appian-ui/96075#96075"]fn!urlforrecord() can be used to generate a URL navigating to a specific record summary. Place that URL in a!safeLink() to open the summary in a New Tab[/quote]

Not to nitpick, but (thankfully) in any reasonably up-to-date version of Appian, this is no longer needed -- since a!recordLink() and a!safeLink() can both be overridden to open in either "SAME_TAB" or "NEW_TAB".

RE: Tabs feature Process Modeler/Chrome in Appian UI

Danny Verb — Tue, 07 Jun 2022 17:25:01 GMT

I'm a bit confused about your requirements since you mentioned the same chrome tab and a new chrome tab. Assuming you're referring to showing the summary details of a record, you can use two functions to help: fn!urlforrecord and a!recordLink()

fn!urlforrecord() can be used to generate a URL navigating to a specific record summary. Place that URL in a!safeLink() to open the summary in a New Tab

a!recordLink() takes in similar inputs but when clicked will open the summary in the Same Tab