[alextweedly]

The kind of data-driven apps that (IMO) no/lo-code is well suited for have a number of common patterns. 
One in particular is so common it's almost ubiquituous:
 - an 'overview' page (either layout or table element) showing all/some of the records of a table.
 - a button within the per-record part of that display which takes you to a view or edit page
 - a button which adds a new record, and takes you to a page almost identical to the view or edit page above

It is wrong (IMHO) that you need to write *any* code at all to achieve this. There should be an option in the right-hand pane while editing a button which allows you to specify that this button changes screen (and gives maybe a drop-down of other screen to select which one to go to), and sub-options to indicate whether new record or the recordID of the current record in the layout.

On those lines, the sample app for contacts has 3 almost identical pages - add, detail and edit. As far as I can see, these have each been described (at some length), though they vary only very slightly (labels on the cancel/save/add buttons, whether or not the 'back' button is visible). There ought to be a way to share the commonality of the pages. For instance, if you decided to add a field (or rename a field like 'first name' to 'given name') you'd have to do it in multiple places.

So there's an additional tiny feature request - copy/paste screen.

[mhcanela]

Hi Alex,

For copy/paste of screens, you can already do this in Appli-
1. Click on the screen background.
2. Use hotkey ctrl/cmd-c to copy the screen. (I've opened a case for us to add this to the right-click context menu)
3. Use hotkey ctrl/cmd-v to paste the screen.

As far as the common app patterns go, we definitely agree that apps should be writeable with as little coding as possible. We plan to add templates (similar to your first example of an overview page) to Appli in the future, though we haven't scheduled this feature yet. As far as the button specification you're talking about, this is something we'll need to discuss internally to see how we would want this to work. I've created a new case for this.

Finally, with regards to sharing commonality between pages, this touches on a feature that we are currently in the process of planning -- components. With components, you would be able to share elements across your app, so you could edit the styling of one button, and it would update across the app. Once the feature is released, you would be able make a group into a component and place instances on all the different pages. Then, when you added a new field to the group, it would also be added across your app. I've also created a new case for our team to discuss the idea of commonalities of different screens, which might warrant a separate feature.

[alextweedly]

Those sound cool - I look forward to seeing / using them.