Feature request: a!sectionLink

RE: Feature request: a!sectionLink

Peter Lewis — Mon, 17 Jun 2024 18:12:14 GMT

Unfortunately I don't have any additional update at this time - it's still something we're considering, but I don't have a release timeline for improvements in this area. Thanks for commenting though - can you share a little more about your use case?

RE: Feature request: a!sectionLink

John B. — Mon, 17 Jun 2024 16:29:47 GMT

Good afternoon, Peter!

Is there any status update for #5230?

I'm open to discuss more about my use case as well.

RE: Feature request: a!sectionLink

Chris — Mon, 11 Jul 2022 18:04:07 GMT

[quote userid="2478" url="~/discussions/f/general/25109/feature-request-a-sectionlink/97571#97571"]

Alright sorry for the delay all, but we have two product use cases to track these:

#401 - Allow sections and boxes to be collapsed automatically using business logic
#5230 - Provide an easy way to scroll to the relevant part of the screen

[/quote]

Awesome! 😁

RE: Feature request: a!sectionLink

Peter Lewis — Mon, 11 Jul 2022 17:56:26 GMT

Alright sorry for the delay all, but we have two product use cases to track these:

#401 - Allow sections and boxes to be collapsed automatically using business logic
#5230 - Provide an easy way to scroll to the relevant part of the screen

RE: Feature request: a!sectionLink

Mike Schmitt — Thu, 07 Jul 2022 13:34:58 GMT

[quote userid="2478" url="~/discussions/f/general/25109/feature-request-a-sectionlink/97430#97430"]almost sounds like some kind of table of contents view would meet both cases[/quote]

I think the main requested item here, i.e. a new type of link which references/focuses an on-form section (or preferably any component if possible) has quite a bit broader of a potential use case set than just a TOC (that is, if i'm understanding you right).

RE: Feature request: a!sectionLink

Peter Lewis — Thu, 07 Jul 2022 12:26:45 GMT

Makes sense, but it almost sounds like some kind of table of contents view would meet both cases. I can submit product use cases internally for both improved navigation for large pages and for the expandable / collapsible boxes.

RE: Feature request: a!sectionLink

Chris — Wed, 06 Jul 2022 19:20:10 GMT

Yes good point that the section would need something like a "saveInto" for it's collapsed status as well. Also would need to apply to Box Layouts, which I use much more often than the Section Layouts actually.

..But not to hijack the thread with the collapsibility feature request. Probably should have its own thread on that 🙂

RE: Feature request: a!sectionLink

Mike Schmitt — Wed, 06 Jul 2022 19:14:33 GMT

[quote userid="2401" url="~/discussions/f/general/25109/feature-request-a-sectionlink/97396#97396"]where we could dynamically collapse/open section layouts on an interface[/quote]

I've had times where I really want this too. The way I'd phrase it is, section layouts should be given a way to have their "collapsed state" controlled from externally (and, preferably, a way to save their current collapsedness status for external monitoring as well). Picture, perhaps, a parameter called "isCollapsed" which can read/write into a local variable (etc), and would both cause the section's collapsedness to change if it's changed externally, and change the value of the variable it targets (when applicable) when collapsed/uncollapsed internally.

RE: Feature request: a!sectionLink

Chris — Wed, 06 Jul 2022 19:10:42 GMT

One example I could see using this is for Record Summary interfaces. Often there, I'll have one longer read-only page of all data entered in the request, approval history, related employee information, etc. Sort of the single place for all with access to review anything and everything that occurred with the request, which can get long. As we don't want to 'wizard' them through a review, only scroll, to be able to create sort of a table of contents with bookmarks/anchor links at the top would be nifty.

On a related note, this reminds me of a feature request (that I'm not sure has been submitted?), where we could dynamically collapse/open section layouts on an interface. It is not possible now, but could solve a similar use case in a different way, with dynamic links that open/close sections on the form below. Would also be nice! Then we could avoid the scroll, scroll, collapse, scroll, scroll, collapse, scroll, finally arrive at your section.

a!localVariables(
  local!sectionCollapsed: false,

  {
    a!linkField(
      links: a!dynamicLink(
        label: concat(if(local!sectionCollapsed,"Show","Hide")," the section below"),
        value: not(local!sectionCollapsed),
        saveInto: local!sectionCollapsed
      )
    ),
    a!sectionLayout(
      label: "This is a Section",
      isCollapsible: true,
      isInitiallyCollapsed: local!sectionCollapsed /* Does not work dynamically :( */
    )
  }
)

RE: Feature request: a!sectionLink

Peter Lewis — Wed, 06 Jul 2022 18:46:58 GMT

It's an interesting thought - do you think this is something that is more common because of the release of Portals? I say this because most of the time I see this kind of paradigm, it's on a read-only page, and historically forms are much more common that read-only pages within Appian. Or is there an example you're thinking of with a long form where you'd rather have this navigation paradigm than a wizard?

RE: Feature request: a!sectionLink

Harshit Bumb (Appyzie) — Wed, 06 Jul 2022 17:17:07 GMT

Peter Lewis any thoughts about it?

RE: Feature request: a!sectionLink

Mike Schmitt — Wed, 06 Jul 2022 16:15:14 GMT

[quote userid="2401" url="~/discussions/f/general/25109/feature-request-a-sectionlink/97377#97377"]a!bookmarkLink()[/quote]

The name definitely needs some brainstorming, lol... it would necessarily be self-descriptive without making someone mistake its functionality for something else.

RE: Feature request: a!sectionLink

Chris — Wed, 06 Jul 2022 15:36:45 GMT

a!bookmarkLink()?

I could see this being of some use, and maybe not too much of a lift to incorporate.. The more functionality the better.

RE: Feature request: a!sectionLink

Mike Schmitt — Wed, 06 Jul 2022 13:53:05 GMT

My point is, in my hypothetical implementation, Appian would (and as far as I know, easily could) create this functionality such that all we need to do is make a link with a!interfaceLink and a valid UID found somewhere on that form. It could use their own bespoke highlighting functionality or just reuse existing stuff.

RE: Feature request: a!sectionLink

Richard Michaelis — Wed, 06 Jul 2022 13:48:20 GMT

sorry my miswording. I meant jumping to the section and kind of refocus on that.

RE: Feature request: a!sectionLink

Mike Schmitt — Wed, 06 Jul 2022 13:40:40 GMT

I didn't mention anything about refreshing (and neither did Harshit in the original post) - can you explain what this would entail and/or what constraint you're imagining?

AFAIK what I describe above (just like what Harshit lays out) could be made to work just like on-page links do in classic HTML.

RE: Feature request: a!sectionLink

Richard Michaelis — Wed, 06 Jul 2022 13:38:51 GMT

but is the UID sufficient to jump to a refreshing section?

RE: Feature request: a!sectionLink

Mike Schmitt — Wed, 06 Jul 2022 13:37:53 GMT

Or just a!interfaceLink() where the main parameter it accepts is a UID (string). Simultaneously, all on-form components (including sections, boxes, and input fields etc) are upgraded with a new optional parameter where an arbitrary UID can be set for that item (where the only requirement is that each one is unique). Then on click of a!interfaceLink, the form would auto-focus (along with scrolling to) that component.

(note: i'm not in love with the name interfaceLink, but the main point is that it can and should be something much more general than "section", IMHO)

RE: Feature request: a!sectionLink

Richard Michaelis — Wed, 06 Jul 2022 11:15:09 GMT

hm...got it.... I Think it should be possible to jump to section or boxlayout.
Perhaps with an additional parameter like "validationgroup" but than called "sectionName" per layout you try to jump to.

RE: Feature request: a!sectionLink

Harshit Bumb (Appyzie) — Wed, 06 Jul 2022 11:08:19 GMT

Yes. That is right. Sometimes, we tend to have like activity trackers/history timelines that do not look good with paging. Similarly, sometimes, the interfaces are intentionally kept long so the user can experience the feel of browsing through some feed.

RE: Feature request: a!sectionLink

Richard Michaelis — Wed, 06 Jul 2022 10:59:45 GMT

hmmm.... i get where are you coming from. If im honest, my first thougt was. "but why are your interfaces so big"?
Usually i am fan of a higher number of interfaces but with a limited amount of interaction/information per interface than just 1,2 very big ones.
They become complicated to maintain especially the original designer is not available any more.

Am i right, that this issue comes in general from the wish to navigate on large interfaces?