Automatic App Documentation

peterdykstra · 06-21-2019 11:03 AM

Automatic App Documentation

Every AppSheet app consists of a unique combination of data sources, table structures, customized interfaces, variable formatting, various types of actions & workflows (and much more). These attributes are contained within the app’s ‘app definition’ that the app creator makes & maintains with the AppSheet Editor.

An exportable summary of each app definition is now available to app creators as a quick reference of the composition of each app. Visit ‘Info’ > ‘Properties’ > ‘App Documentation’ to access the documentation page for each app.

Jonathon

This is great.

I believe someone in the community was asking for a feature, a few months ago, to help identify all the places in an app a column or variable may be referenced.

This makes that possible with a quick ctrl+f

Mike_A

@Peter - Thanks to the team for working on this. Really helps to preserve a record and troubleshoot applications.

Two initial observations:

Wish the major headers in the summary included hyperlinks to the sections for fast access (eg: Tables, Columns, Slices, Views, Format Rules, Actions, Workflows, Reports, etc).
View Icon Name - it would help when reconstructing a view to know the name of the icon used (and not just show the icon). Since the icon list is now larger, can be tough to find the exact same icon again without the name.

Love the reformatted report. With so many pages, will need to use it a bit to provide other feedback…

Mike_Rundell

A great enhancement.

As I posted some time ago as an improvement recommendation it would also be handy to summarize tables, format rules etc that are redundant and not referenced or used in more complicated apps so the developer can use the summary to clean up the app to improve performance.

Michael2

I assume AppSheet is using a PDF engine other than the one the apps use for reports. Are there any plans to extend this PDF engine to the app creators. One advantage I see with the documentation PDFs over those that can be created with apps is page header and footers. I would definitely appreciate being able to add headers and footers. Makes for a much more complete and polished report. Not to mention being able to keep order within the printed document.

@Peter

Efren

I have used this documentation for a long time, however my app has grown and it has become entertaining to use it, some ideas that I think would support us a lot in the development …

I do not find the Security Filters per table.
A more detailed table of contents, with hyperlinks, would be great, for example …
Data Summary
16 Tables
1-table 1
2-table 2
3-table 3
4-table 4 …
,
,
16- table 16

100 Columns
Table 1
column 1
column 2
column 3
…
table 2
column 1
column 2
…

Thx

peterdykstra

This is great feedback, thanks @Efren - will make sure it’s reviewed and considered for the next update to the documentation.

Bellave_Jayaram

I am building some metadata extraction and visualization tools using python and this report- my request would be that while making changes, please preserve the HTML table structures currently in the documentation. If I could be added to the beta testing of this prior to release, I would greatly appreciate that.

aucforum

@Peter I think Appsheet needs to formally have a way of encouraging and assisting those who are wanting to make third party development tools and add-ons for Appsheet. @Bellave_Jayaram and @Stefan_Quartemont clearly are making useful things in that regards. I got a few ideas based my own experience I would like to evolve in that direction too. Please let those in Business Development (and anyone else) know.

Efren

@Peter what a good idea, working together with external developers (@Stefan_Quartemont, @Bellave_Jayaram), maybe there are others, surely you will find some way to summon them, to enrich such a great app, I am sure that working together, they will be more productive in benefit of the AppSheet community! thanks to everyone…

scott_marquardt

Nice feature, but a very frustrating point.

I’d like to have this in tabular form – at least for some important tables. It’s laborious to copy and transpose the field definitions, but the main problem is that they don’t all contain all possible attributes. For example, display name is only in the definition if there is one, which makes transposition off by a column. I have no idea how many other attributes might behave this way as well.

The idea that attributes needn’t show up if they’re valueless is wrong-headed. That they may be null is actually a piece of information about the field. And it’s not best practice to count on the reader thinking “Ah, something I reliably remember would be in this list if it had a value isn’t in this list, so it must not have a value.” That’s the “mystery meat” issue where you have to have an entire schema memorized in order to know whether a given instance has a null for an attribute that’s not shown.

Display name (and any other attributes) should always be indicated.

And it’d be sweet if the app could just output the attributes of the fields in tabular form. The value of this would be being able to filter attributes by their value during development, in large part to determine which sets of fields conform to a particular attribute prescription. In fact this would be invaluable, and it would be onerous to have to build it manually whenever needed (during dev, attributes are constantly changing).

edit: Yeah, formula version and other conditionally present attributes mess up the whole idea of adapting this readily to a tabular format. Argh.

Steve

Nope. Displaying all null-value properties is wrong-headed.

Your approach to interpreting the doc is flawed.

scott_marquardt

Interpreting the doc is easy. It’s fine for what it does. I’m critiquing it on the grounds that it doesn’t support my particular needs without onerous effort.

Shall I magically make my particular need disappear?