Greetings All,
Now that I am able to create a CDT, I immediately see that I have some decisions to make with respect to what the UI looks like. In my world, we have reservations with various pickup and dropoff types. Previously, I have just thrown them all into one reservation table/record and used pickup_type = A, F, T, P and dropoff_type = A, F, T, P to show or hide different datawindows to display the data as necessary.
For one reservation that I display the pickup or dropoff type could be:
'A' = Address
'F' = Flight
'T' = Train
'P' = Private Jetport
Here is an example of Pickup Type = A / Dropoff Type = F (DROP AT AIRPORT):
And here is an example of Pickup Type = A and Dropoff Type = A (DROP AT ADDRESS):
I would like to create interfaces that show the screens mocked up as above. Obviously, the dropoff layout for an address is laid out very different from dropoff layout for an airport. And of course they use different fields / columns in the table row.
Again, right now I have it all in one table. So to achieve this would I need to split my one 'TRIP' record into three tables as 'TRIP HEADER', TRIP_PICKUP_INFO, TRIP_DROPOFF_INFO with various pickpup / dropoff types that would specify which interface to use given pickup = A/T/F/P and dropoff = A/T/F/P? Or can I select different UI's based just on the value of pickup_type and dropoff_type?
I have taken a bunch of Appian UI courses online, but I have not seen any where the different User Interfaces are exchanged in different parts of the layout.
I 'guess' I could have 8 different UI's that I select from given the combination of pickup = A/T/F/P and dropoff = A/T/F/P but that seems a bit messy and difficult to maintain.
THANKS EVERYONE FOR YOUR HELP IN ADVANCE!!
Paul
Discussion posts and replies are publicly visible
I suggest to design the data in a way that makes sense in terms of good data design. The UI is something which should be aligned to the needs of the user. In Appian I try to create processes with tasks and UIs tailored to what the user has to do. So I avoid that one big UI with a ton of show/hide logic pattern at almost all cost.
I am currently working on a similar scenario. I have a generic entity with a type, and when I start my processes, I need to add a bunch of type specific data. I put the ID of the generic entity into the type specific entity and have some logic which loads the data based on type. Works pretty well for now while I need to keep an eye on list scenarios to not get into read amplification situations.
I try to keep a rather simple data model in DB based on a business view on the entities.
Does that help?
Thank you, Stefan!!Are there example applications in Appian that demonstrate 'show/hide logic pattern' and related logic?
It seems that the 'Card Header & Two Columns' UI might suit my needs where the two columns are either replace or filled with alternate data elements depending on Trip Type?
I am following / not following.
Thanks!!
To get started, try to create the most simple interfaces separate for each type. At least two of them. Then you might want to put similar parts into an extra interface and use it as a reusable component.
Regarding patterns. I suggest to go through this list
https://docs.appian.com/suite/help/21.2/SAIL_Recipes.html
Agreed with what Stefan said - also if you want to try and show different sections, the "showWhen" property is useful because you can provide a condition for when the section should be displayed.
Here's an example with an interface wizard that uses the showWhen property in a slightly different way: docs.appian.com/.../recipe-build-a-wizard-in-sail.html
Thank you, Stefan. I will definitely refer to this. Paul
Thank you, Peter!! I appreciate that. 'ShowWhen' sounds like an interesting area of functionality. I guess I am obviously not the first person who wants a flexible interface. Best, Paul
Important here, in regards to security. Hiding an element means more a "does not exist" than a "just hidden". So if you hide e.g. a button, then the user has no chance to still click it. Same for sections with sensitive information.
Thank you, Sir.