Method for fast repeat data entry when counting results

[Alan_Thorp]

I have an app that has a table used for recording test results. The values are recorded one after the other in fairly quick succession. Around 2 seconds to 6 seconds per value.

I have two methods to enter the data at the minute. The first is for a form to open, the value to be entered, the form saved, then the form to reopen for a new row and the next value to be entered. This is repeated until the last value is recorded, and the next reopened form can be cancelled out of. This works okay on a computer, but on a phone or tablet it is slow because the onscreen keyboard has to close and reopen as well.

As a second alternative method I created a series of actions off one button to add a user defined number of blank rows to the table and then open the table. At this point the user can then enter quick edit mode on the table and enter the values more quickly because the only column that is editable is the value column so the onscreen keyboard will advance to the next row.

This second method works okay, but there are a couple of potential issues. One obvious one being that if the user accidentally presses cancel they lose all their data. The other is only really anecdotal because I’ve not been able to replicate it myself. What I’ve heard is that they can put the app down sill in quick edit mode and come back to it a short time later <2 minutes, and the data has gone. The tablet is still in quick edit mode and hasn’t locked or anything. I’m pretty sure that this could be solved through them not bein lazy and saving the data incrementally when they need to put the device down.

So, my question really is, Does anyone know of a quick and more secure that I could use for this type of data entry?

[Marc_Dillon]

The main issue seems to be the keyboard having to close and open constantly. Would you say that is accurate? I’m wondering if you can find a way to keep the keyboard always open on your device, or install a 3rd party keyboard that can do so, or even get a blue-tooth keyboard if that’s possible in your situation. I did a quick search for how to keep the keyboard open on Android, but unfortunately didn’t find much. Perhaps you’ll be more motivated to search harder than me though.

---

I would agree that your Table quick-edit method sounds wayyyyy to risky.

---

Maybe, if you’re really only entering a single value, you could just have it all happen inside of a single record, and a single form view? Then upon saving that one record, it auto-creates as many other records as it needs?

[Alan_Thorp]

Hi Marc,

Thanks for your reply. I think that for the form entry it is a combination of form closing and reopening along with the keyboard. I think that this is one thing that could be improved with the AppSheet interface. I should probably do a feature request for that.

The quick edit table would be fine if it saved as you went, but instead it rolles it all up into some sort of form style edit, but then deploys the changes as individual ones. I don’t really understand the design idea here because we already have instant saves using the standard quick edit in the detail view. If it had been designed like this, but acting on a table level then it would have been reltively safe, (as long as your cat doesn’t walk across your keyboard…)

I did consider the idea of putting it all into one record while I was writing the post above. I could have the values comma separated and split them out into individaul rows afterwards. Seems a bit clunky though and relies on the user to do something special that is not intuitive.

I’ve just noticed that my parent record, where I’m adding each child from via an action, has a photo as the title. I may get rid of this and see if it speeds things up a little.

[Marc_Dillon]

Alan_Thorp:

I think that for the form entry it is a combination of form closing and reopening along with the keyboard.

Sure. I guess I didn’t explain my other idea that only has to do with the keyboard closing/opening. That idea was to use your existing blank record creation portion of your second method, but then use an inline Action to enter the values via INPUT() instead of Table quick-edit.

Can the values be standardized at all? Like could you just present a few Enum buttons to click on, and completely avoid the keyboard?

[Wesley]

I don’t know if this would work but two concepts that may help…

1. Scrolling horizontally through detail views of parent table

2. Having a set of quick edit columns in the parent record for the inventory to be recorded and eventually copied to the child record where it’s stored, and upon update of row the data is copied from parent into new child row, and then child data is cleared from parent columns. There was a great post on this for adding order detail rows like item or product children to a parent without leaving parent row view/form I just can’t find it at the moment.

[Alan_Thorp · Accepted solution]

Ok, so I have found a fix that has speeded things up enough. About 1-2 second transition, depending on the device.

Basically the first method uses an action on the parent to go to a form view of the child. I was just reopening this form once it was complete which was what was taking the time. I got rid of this and replaced it with an event action in the behaviour section operating when the form is closed. The action is going to the same view as the original action, so just going back into the form immediately.

I know that it isn’t what either of you suggested, but having suggestion helped me think about the problem in a different way, so thankyou.

[Marc_Dillon]

You’re saying a deeplink on Form Save is faster than Appsheet’s Form auto re-open?

[Alan_Thorp]

Yeah. So from what I can gather it is more about the transition time between views rather than he action.

The auto re-open has to:

• Drop onscreen keyboard
• Close the form
• Return to the parent view that the action was triggered from
• Re-open the form on the child
• Raise the onscreen keyboard

The action to the same form has to:

• Drop onscreen keyboard
• Slide in a new form from the right
• Raise the onscreen keyboard

All this is slowed down more if your device is a bit old and crap like my 2017 Samsung A5, (slow and steady though).

I think that being able to alter the transition between views would make apps run faster. Similar to the way slides transition in Power Point. You can make them fade in, slide in or just appear, etc. It’s the old argument of function over form. Most of the time I don’t care too much what something looks like as long as it is efficient, but sometimes things need to look nice at the expence of efficiency.

[Marc_Dillon]

I see. Interesting.

[Alan_Thorp]

I’ve added a feature request if you want to vote it up and make comment:

Variable transition types between views

[Wesley]

What kind of data needs to be recorded quickly using a keyboard?

Is it feasible in your case to record test result values using multiple 1 character out of X characters enum columns to generate the actual result since a quick edit enum would appear quicker than a keyboard?

For example, if recording a 3 number percent or decimal you choose 5, then 2, then 9 out of enum columns with choices 0-9 to create a column 52.9% (or 0.529%) from concatenation of the period character and these values.

[SkrOYC]

To this point we have no idea what kind of data you need the user to add to each record.
Using Enum or EnumList and Buttons and a strong expression under suggested values would do the trick

[Alan_Thorp]

Hi Wesley,

I think that that is a great idea. Usually it is numbers from 0 to 20 so I could make buttons for them all with the column type as Enum.

The values are whole numbers by the way, measured against distance. Distance auto-calculates so that is not an issue for input. I thought that I metioned the values in the original post, but looks like I didn’t. Sorry!