Table quirkiness

[Bob Williams]

I’ve found tables a very useful feature, but in terms of UX, they’re proving rather quirky. Some of the behaviors I’m seeing include:

– After clicking the + button to add a row, the location of the new row is unpredictable. It truly seems to insert in any random position, from before the first row to after the last row and anything in between.

– After editing a cell value, I will sometimes hit return or tab to commit the change and go to the cell below or adjacent to the current one. Sometimes that works, but sometimes, TF does what I expect and then immediately moves the selection to the cell in the upper-left corner. Whether the secondary shift happens seems completely random, though it seems like once it starts doing it for a given table in a given session, it basically does it every time.

– Likewise with the mouse: after editing a cell value, I will sometimes click another cell to commit the change and go to the other cell, but TF will do that and then immediately shift the selection to the cell in the upper-left corner. Again, seems random but keeps doing it once it starts doing it.

– If I have a cell selected before the last row and hit return, the selection is simply moved down. But if I do that while on the last row, a new row is added (well, usually). This is sensible enough (save for that “usually” part), but when TF decides to move the selection to the top row, the last row may be scrolled out of view so that you can’t even see it, meaning if you’re not paying real close attention, you may add a row without realizing it, and if you are paying attention, you have to use a bunch of key presses to scroll back to where you were or reach for the mouse to do same.

All of this is very hostile to data entry. You have lots of annoyance from actions you don’t want to happen happening, and when they do, they force you to take corrective action in response, such as by scrolling your intended target cell back into view and re-entering it to edit the value. Adding salt to the wound is the fact that it all happens unpredictably.

Additionally, instability of row ordering as new rows are inserted means that my unsorted rows are very unlikely to stay in their natural (as entered) order. I’ve been playing around with some workarounds that involve having a hidden sorting column, but they’re not great solutions for various reasons, and it just really feels like a detail I shouldn’t have to deal with when I’m not coding my own solution against an RDBMS. Besides, this is giving me flashbacks to the not-very-great experiences I had with old-school BASIC’s line numbers many, many moons ago :-).

I’m on a Mac Studio running Monterey, so maybe some of this is due to bugs related to that? Anyone else seeing these behaviors? Or maybe I’m missing some feature that would easily wrangle these things? Would love suggestions from folks out there.

[Bob Williams]

And if the UX around tables simply is what it is at this point (is it a newish feature?), I’d also love to hear about any workflow tips people have that they’ve figured out for doing table data entry as efficiently as possible.

[Brendan]

Hi Bob,

The issue with where the new row is inserted is due to the sort order of the Table field. You could add a Date & Time field to have the records sorted chronologically so that new records would be added to the top or bottom depending on the sort direction. There is no “natural (as entered) order” unless you have the sort field set to a Date & Time field.

I haven’t seen the issue with Tap Forms immediately putting the selection at the top-left. I wonder if the record is being updated and refreshing the entire display? I’d like to see a copy of your form template so I could test it out.

Thanks,

Brendan

[Bob Williams]

If I haven’t right-clicked on a table column and selected either of the sort options, the table visually shows that no sort order is being applied: the column header is gray, and the sort direction triangle is hollow. As soon as I choose a sort option from the context menu, both of those things change, showing that a sort order has been applied and what that order is.

From a user POV, this suggests that there simply is no sort being applied before selecting one. In such case, I’d expect the rows to remain in the order I entered them, and it’s this order that I’m referring to as the “natural order”.

I get that deep under the hood, the database itself my treat sort order in the absence of an explicit sort as undefined, but that feels like an implementation detail that shouldn’t leak all the way up to the user level of an app like this. As a general rule, things should stay where the user put them and not move around on their own. In this case, it’s akin to unsorted rows in a spreadsheet arbitrarily reordering themselves — that would be a maddening experience, and no spreadsheet has ever worked that way.

A date field (or an auto-increment field, which I also played with as a solution) is a decent workaround, but it’s more noise in the user’s system that they don’t directly need, and it’s more hassle to set up and maintain. As a suggestion, I think TF should track natural order internally and maintain that order unless the user chooses otherwise. This will also enable an “insert row here” feature, which doesn’t logically make sense in the current model.

As to the changing selection issue, some more testing suggests that it’s related to a script field on the form, specifically, the document.saveAllChanges(); line. Note that the script doesn’t change the table in any way; it simply iterates over the table and outputs a summary. If you need more, let me know and I’ll send you my file.

[Brendan]

Ah ya, the saveAllChanges() function will refresh the record display, so I can see how that causes you to lose the selected cell.

I agree that the Table view should work better with respect to sorting. I’ll work on that.

Thanks for the feedback.

Brendan

[Bob Williams]

Any suggestions for how I might set up my forms and/or scripts to ameliorate the saveAllChanges() selection issue caused by the refresh? When I’m trying to edit data in a table, it makes for a lot of extra moving around, and worse, I keep misstepping and accidentally entering data into the wrong cell.

For context, I have a table with rows for notes, the fields of which include a short-notes field and a long-notes field. I have a separate script field (not in the table) that builds a summary of all the notes in the table by doing some fancy string concatenation. It’s the summary script that’s calling saveAllChanges(). Maybe there’s some way to delay the script run until focus leaves the table? Or some way I’m missing from within the script itself to grab the selection right before the save call and then restore it right after?

[Daniel Leu]

I do something very similar. In my custom layout, I have two buttons that execute each a separate script, one to update the summary field and one to clear it. This way, the content of the table is only evaluated for the current record when I ask TF to do it.

[Author]

Posts