A RoomBooking type: a grid of rooms and days/times.
A User type which includes a ‘list of texts’ field to hold that user’s bookings.
OnClick, there are two steps:
Step One: The current user’s name is placed in the appropriate RoomBooking grid’s field
Step Two: The ‘booking’ is added to the current user’s BookedList List of Texts field (a list of their bookings).
If the user clicks multiple cells too rapidly, Step One is fine, but it sometimes misses Step Two.
There are dozens of cells in the RoomBooking grid, so hiding or covering all the cells while the steps are performed won’t work.
Is the a way to momentarily suspend any user input during the workflow?
The problem seemed to stem from (step2) first concatenating five fields (week_numb, day, time, date, room) before adding to the list of texts. By first storing it temporarily in a user’s field, then copying it into the list, it works 99% of the time. Still experimenting.
One approach to the WF steps would be to set a “busy” flag, then do your DB and UI stuff, then have a pause/delay, and then clear the busy flag. Use a Conditional on the clickable cell to make it “not clickable” when the busy flag is set.
Odd as it might seem, actions (steps) are not guaranteed to be sequential when there are both DB (server-side) actions and client-side actions in the same WF.
The issue you’re encountering is, I suspect, related to the fact that more than one “process” is attempting to update the same DB record if another WF is initiated too soon. Making the cell unclickable and inserting a delay should help.
(If anyone else has another approach or insights to share, please chime in!)
The problem comes with the user clicks on other cells. (As in… “I want to book these three time slots!” - click-click-click.) When displaying just one day’s schedule grid, there are 12 -one-hour slots times 8 studio rooms, so I’d have to busy all 96 cells. The bar fight is long-since over.
Pretty interesting. I’m able to see its non-sequentiality by viewing the items land in the user list of texts field. But adding the intermediary step (concatenating the five fields to the user type first, then transferring it to the list) works so far.
That’s why using a “busy” flag and setting a Conditional on the clickable items in the RG (to disable clicking when busy) and then inserting a delay should help.
I ran into a problem similar to this I figured the underlying problem: it takes mili seconds to write the database, so if the user clicks really fast, he/she can click faster than the time it takes to write on the database which will mess up things.
This problem of fast clicking happens in traditional programming outside of bubble too. Bubble is high level so we can’t control the running time of things.
This was my solution to fast clicking:
user clicks → worflow event 1 happens → popup appears that says “action completed” (user will have to closeout this popup before he/she can click again) ->workflow event 2 happens… try that and see if fast clicking still is problem. The popup is supposed to stop the fast clicking as the user will need to close out the popup before he/she can click again.
Yeah, that’s similar to my first suggestion, except that I proposed dismissing the popup automatically after a delay. As you noted, the popup can be used to display a status message - e.g. “One moment…” (pause) “Reservation complete!” (pause) then close the popup.
Just wanted to emphasize that the pause (delay) is key if you wish to avoid user interaction (e.g. to dismiss a popup as in @cdorozco16’s suggestion) , as that will give the DB operation time to complete.
It it was a light switch, and the user flicked it up and down, and occasionally it didn’t work (busy…) the user would think it faulty.
I liked the elegance of building the list simultaneously, but I maybe should separate these two tasks:
Booking the slots by itself works fine, even rapid-fire.
making a list showing all that user’s booked slots, that could be a separate WF initiated by the user when they want to see their list of booked slots. I’ll try that.
We’re having a similar discussion in this thread. We want running workflows after a change, so you could set up a listener. Since your setup would be single-tier, it shouldn’t have the same bug experienced in my testing. Take a look, let me know if adding a (trigger custom workflow when data changes" correctly offsets the second change to after the first one.
I see you have some good UX suggestions in terms of popups above, but if you want to reduce that friction that may be a good way around it.
Another possible approach… Clicking the cells could simply “mark” (select) those slots, requiring the user to click a Reserve Selected Slots button to commit them all to the DB in one fell swoop. That would circumvent the original issue entirely.
