Hierarchy Views

[Grant_Stead]

Expanding Tree - root/node style
Chart Style - Think org Structure
And as a group and sort option for drilling, tables/decks…

All we would need to do is indicate which column in the table contains the Parent Ref…
Maybe a customization on what level to start at, and hide/show “blank” levels…

Hierarchy is a easily achieved by having a REF column within that table the ties back to the same table… So the user can indicate the parent… EX: an employee table could have a REF column back to the employee table to select that person supervisor. With the Chart style view we could then look at a dynamic org chart that we can click and pan on. Or with the Tree, we could drill into it by supervisor.

@morgan Pretty Please?!
@praveen With sugar on top!

[Laurene_Haynesw]

Of course we might have to do a google meet so I can share my screen. lihaynesworth@gmail.com

[Grant_Stead]

We could do that… Or we love using loom.com

[Laurene_Haynesw]

Whatever works I am an amenable person.

[Laurene_Haynesw]

When do you think you are chanced ?

[Bellave_Jayaram]

It is not ok to post misleading posts and links. You may be barred from posting for violating.
FYI, @Peter

[San_Tou]

that looks awesome! I am trying to create a treelike view (like this) so that we can store all working instructions. How did you create such view/interface? Thanks.

[San_Tou]

@Grant_Stead would you mind to share how best (with the current Appsheet features) to create a treelike form that is as close to a subdatasheet structure (so you can expand it by clicking the parent row, like the picture you shown)? Thanks.

[Austin]

I was given back one of my votes today and I have already spent it here. Back to not being able to vote

[Grant_Stead]

You can not. That is the point of this feature request. It’s one of the few things that you can’t fake or make a work around for.

[San_Tou]

I see. Thanks for the clarifications and hope that will be brought in soon enough

[pravse]

We won’t get to it in the first half of 2021. But we might in the second half. Let me explain.

We have some resources focused on improving app UI presentation. Some of their efforts will be to fix things that are currently broken. We have particular enphasis on the fullscreen/desktop experience. Then when it comes to new views, the first priority is doing better with charts. We’re actively working on that now.

So what comes after that? There are two things requested here in the community with many votes: (a) Gantt view, and (b) Hierarchy view. Of the two, we think Hierarchy view may be more generally applicable so we’re leaning in this direction.

For hierarchy view itself, there are two kinds: (a) a hierarchy of the same entity with self-references — like an org-chart — this is what Grant has been asking for since the first time I talked with him, (b) a hierarchy of different nested entities but shown in a single nested view without needing to explicitly drilldown (this is also discussed in this thread). We’ll need to tease these apart and figure out which of them is reasonably feasible to do and maps to the most common use cases. I’m not saying we can do either or we cannot do both – I just don’t know yet because we haven’t yet looked at it. But thanks to the high vote count, it will be something we try to do after we make progress on charts.

[Grant_Stead]

I’m so glad to see things starting to stabilize with the platform. I agree, while Gantt is nice… Hierarchy is way more fundamentally important.

praveen:

(b) a hierarchy of different nested entities but shown in a single nested view without needing to explicitly drilldown

I’m not sure I follow. Would this be like parent / child nested view?

This thread here also had some traction, dropping it here for posterity.

New Chart Type Suggestion: Hierarchy Feature Requests

Sometimes it can be very helpful to see connections between things in a literal sense. Prime example: Spec graph view. [image] This can be very helpful to illuminate the connections to things, and having a similar representation inside an AppSheet app as a chart could be useful in some instances. I could see something where you add tables to a list (like selecting the columns that should be included in a chart), and we would see some sort of hierarchy chart showing how things are structur…

[sorin_mihai]

Exactly this collapsible deck view would be … Amazing.
It is so deeply needed because it’s a real focus breaker heaving to go inside the deck element to see it’s children (along with everything else there is to see in the detailed view), then go back to scroll on through (but from the beginning again) the parents in search for that child. It just breaks the focus from the parents and it’s a waste of precious time and clicks. And the comparison with a discussion hierarchy is very good, although by far not the only application.

Table view is no comparison, because design-wise it is so far from a deck view. And to collapse a card view … maybe but it’s children should collapse as deck view elements, otherwise they would be too big if they were to collapse also as deck view elements.

And the nested elements is close bot not customizable enough. It has to be collapsible, you have to be able to hide or show it by hitting that down arrow as it is in the given example by @Grant_Stead .
And you should be able to set a max elements to display in the collapsed menu, so if there are 325 children, it will collapse a maximum of 15 and the … and you have to go in to see all of them.

This I think, would really spice up the usability and functionality and application range of deck view.

I made a little collage just to showcase the best case scenario for one of my apps, where I have projects that are made up of objects. The objects are always under 10-15, 5 of them most commonly, so collapsing them down in a deck view would be perfect, as you wouldn’t have to go in the detail view just to get a glimps at what is still to be done and also they are not that many as to crowd the Projects deck view with Objects and get you disoriented.

The collapsible decks elements should also be defined as Views that are nested and they should be able to be set up as Deck views that are Reference Views and then Nested to the main Deck View, which already has those nested elements as referenced children so that it only displays it’s children, respecting the options set up in the deck view. This way one can control what info is shown in the collapsed child Deck View which may be different from the info shown in the parent collapsible Deck View … many tangling words, but the point is quite intuitive I’m sure.

My guess is this request fits well here. If you think it’s something else then maybe I should post it as a different feature request do let me know what you think.!

Thanks

[San_Tou]

Seasons greetings to you and the team, thank you again for the good work.
Just wondering if you are close on getting this feature sorted? I have seen something similar as a template/sample Hierarchical Menu but not exactly the same. I would be over the moon when this feature is finally released. I enclosed a screenshot of the current database (MS Access front end).

I guess the key is that by being able to expand/collapse the subdatasheets, one can retain the original table which gives continuity to the context.

Thank you again.