Save a form as you go

antix80

Just something I've been mulling over. Sorry i can't post an example but I'll try to explain.

The company i work for has a webbased expense system on the intranet with various headings.. Fuel, travel, meal, parking, etc. - it's not just for employee expenses but I want to keep the example simple.

Clicking on a heading brings you to a page under which you can enter only receipts relating to that heading .. E.g click Fuel and it opens a page that lets you add a fuel receipt. while on this page, clicking "add" adds a new line for another receipt - once again only relating to fuel.
Upon clicking "save" your lines (2 in this example) are updated to a table in the database.

Then you move on to the next heading. Say parking... Go ahead and add 5 parking receipts. Click save.

there are now 7 items in the table.

It's quite clever, as it forces the user to save after entering a small number of lines, reducing the chance their data will be lost.

The user interface of the system is very glitchy but once data is in the table, it gets fed into the accounting database without errors or data loss.

I'd rather one form with a dropdown menu to choose between the heading (fuel, parking etc) , that "saves" (to prevent lost progress if user clicks back button or connection problem) each time the "add" button is clicked.

Ideally this "save" is something that would be done seamlessly without an obvious page refresh, but still allowing the user to edit previously lines. It should support perhaps 200 lines so v important not to lose data or create a situation where the browser has to clumsily reload and scroll to the bottom of a large list (you know that jarring effect where a page obviously reloads at the top then jumps down to the new line which is now positioned right at the first pixel) .

Is that something achievable, or would it be complex to implement?

fcrossen

This is straight forward enough using ajax. If it is for an intranet (where you can specify minimum supported browsers)) you can use modern API's like fetch, but if you are used to jQuery or have users on quirky browsers, then jQuery might save you hassle.

One thing to watch for is the user flow. For example, you want to disable the add button until you get a response from the server to avoid the same items being submitted twice. You might also need to refactor your server endpoints to account for the new requests.

And don't forget to secure your endpoints.

daymobrew

Another idea is to use a forms module e.g. Gravity Forms, a premium plugin that would require a WordPress installation.
I've never used GF but it is always highly praised. It has a "Save and Continue" option.

Ninja Forms, is a free WordPress plugin with premium add-ons like Save and Continue or Multi Part forms.

lawred2

daymobrew wrote: »

Another idea is to use a forms module e.g. Gravity Forms, a premium plugin that would require a WordPress installation.
I've never used GF but it is always highly praised. It has a "Save and Continue" option.

Ninja Forms, is a free WordPress plugin with premium add-ons like Save and Continue or Multi Part forms.

I'm not sure suggesting plugins for Wordpress is relevant here

antix80

fcrossen wrote: »

This is straight forward enough using ajax. If it is for an intranet (where you can specify minimum supported browsers)) you can use modern API's like fetch, but if you are used to jQuery or have users on quirky browsers, then jQuery might save you hassle.

One thing to watch for is the user flow. For example, you want to disable the add button until you get a response from the server to avoid the same items being submitted twice. You might also need to refactor your server endpoints to account for the new requests.

And don't forget to secure your endpoints.

Thanks for the reply!

Well to be honest I am only slightly familiar with web development. From a few modules in college I know a little about Java, VBA ,SQL, PHP .. So I know my limitations, but like to be aware of the best way of doing things.

Well.. years ago my employer was looking for essentially an accounting system. The IT manager in charge seems to have had little experience in IT, and acted as a PM/cheerleader at best. They brought in a contact they knew from the industry who developed a product that the two got together and convinced each other was suitable for the organisation's needs. It's a pigs ear, unfortunately.. I guess it's sort of how daymobrew suggested Gravity Forms... Sure, we could use it.. but would it meet our needs?



So I've been reading a bit about PostBack's and it's very interesting.

Here's a bit of code from the website:
<input name="amt2$i" type="text" value="0.00" id="amt2_i" class="Edit EditServer" onchange=" if(NumberVal('amt2$i')){ PostBack('amt2');}" autocomplete="off" style="text-align: right">

The onchange is interesting, as the data validation works just fine when there's an error.
BUT the Postback that occurs when a valid entry is entered causes the page to reload, which means if the connection was slow enough, and the user begins to type in another textbox, the textbox they began typing in is wiped clean when the page reloads.

Worse still (as if that wasn't bad enough).. if they click the "Submit" button, the onchange/postback (I'm not sure which) causes the mouse click to be completed ignored.

As a result, our user manual is filled with crap like "after typing in an amount, make sure you press tab. The tab button is located next to the Q on your keyboard" And as no one reads the manual, typically they'll close out of a screen without making sure their entries have been submitted.

Or (on another screen) "type in the closing balance. then double-click load"... because the first mouse click is ignored while the validation/postback is happening.

Is that an easy fix?

Also - surely with all the postbacks surely it shouldn't be possible to ever lose data after adding a new line? It should just be written to a table, perhaps when a new line is added (rather than when each field is updated)

There's this damning line I see in the code of the website: <!-- This will force the posback scripts to be activated. TODO: Find a better way... -->

28064212

antix80 wrote: »

Is that an easy fix?

Everything's an easy fix when you know how. The question is how much are you willing to pay for someone with that knowledge.

TBH, it's not sure what your aim here is. Are you asking if you would be able to implement changes with a little research? Or are you trying to get an idea on how much it would cost to get a professional in to do it?

antix80

28064212 wrote: »

TBH, it's not sure what your aim here is. Are you asking if you would be able to implement changes with a little research? Or are you trying to get an idea on how much it would cost to get a professional in to do it?

Just chatting more than anything.. It's not an area i currently work in but I'm still interested in improving my knowledge. May come in handy plus it gives me a few pointers on the types of knowledge that's useful.

Tbh just having a wee moan about work too. They're talking about adding functionality to this pile of garbage like debtors, creditors, accruals, rebills/interco.. While if i have input, I'll suggest that if they can't manage to design a form and to implement simple fixes - they either need a competent developer in-house for a while or a competent i.t manager.

Seems a lot of the system was a cookie-cutter project and our system was hobbled around limitations in that system. Which brings me to, if the bugs are in the system and can't be changed, the system isn't suitable.

igCorcaigh

I would save all of the data on the client, and only commit the data in one transaction on the final submit (http post).

You can bind each input field to a js object using knockout.js

igCorcaigh

antix80 wrote: »

Just chatting more than anything.. It's not an area i currently work in but I'm still interested in improving my knowledge. May come in handy plus it gives me a few pointers on the types of knowledge that's useful.

Tbh just having a wee moan about work too. They're talking about adding functionality to this pile of garbage like debtors, creditors, accruals, rebills/interco.. While if i have input, I'll suggest that if they can't manage to design a form and to implement simple fixes - they either need a competent developer in-house for a while or a competent i.t manager.

Seems a lot of the system was a cookie-cutter project and our system was hobbled around limitations in that system. Which brings me to, if the bugs are in the system and can't be changed, the system isn't suitable.

Sounds like a nightmare of a project!

antix80

igCorcaigh wrote: »

Sounds like a nightmare of a project!

Haha. Well what's implemented doesn't work. There's a lot of people supporting the users but the cost is just spread around. The company that hosts/supports/develops it is also raking in a small fortune.

Despite the crumby user interface sadly it's pretty robust in the background. I won't say the name of the system it feeds into but it does it reasonably well.

Thing is i don't think the front end/web interface can be scaled for more complex tasks, esp as it will carry all the existing glitches and limitations and more.

igCorcaigh

Best quarantine the existing ui and start new development using a modern front end framework. Don't build on the existing code.

antix80

igCorcaigh wrote: »

I would save all of the data on the client, and only commit the data in one transaction on the final submit (http post).

You can bind each input field to a js object using knockout.js

Knockout looks great.

The thing about saving on the client is, is it fair to say if the user closes the window before saving they'll lose their data? That's why i think it's best to save to the server as they go along..

igCorcaigh wrote: »

Best quarantine the existing ui and start new development using a modern front end framework. Don't build on the existing code.

I'd agree. I think there's nothing to build on. It's like someone's school project.

daymobrew

lawred2 wrote: »

I'm not sure suggesting plugins for Wordpress is relevant here

I understand where you are coming from but I felt it was worth giving a different view as OP says that the front end is crappy and not flexible. It might be easier to push data from a WordPress plugin than hack the existing system.

Talisman

Your idea to save the content to the server as you go has limitations that you need to be aware of. What happens if a user accidently closes the browser tab before completing the entire form?

Static HTML forms and a piece of JavaScript alone are not the correct tools to solve the problem and deliver a positive workflow. By positive workflow I mean it's impossible for some idiot to come up with a way to break the workflow. These people appear to have existed since the dawn of time and they will continue to exist after you have left the organisation. In my career I have worked with more than a few of these people and I have found it's best that you deliver them a tool that they can't break so that they can go about their blissful existence.

Keep the state on the client side - use IndexedDB, it's available in almost every web browser. Use the observer pattern to monitor the IndexedDB database for changes so that form state can easily be synchronized between browser tabs or sessions. Take a look at the Dexie.js wrapper for IndexedDB, I'm sure there'll be example code for that specific scenario.

Ideally you would implement this as a Progressive Web App which would work even if the server is offline. In this scenario the app would need to sync its data with the server when it comes back online. You could also develop a Desktop app using Electron.

antix80

Thanks for the input Talisman.

The current system is all "on the cloud" and while most users attempt their submission all in one go, some dip in and out during the month and a small percentage will work across different devices. But I do think there's a lot to be said about not syncing with the server so frequently. There's no real benefit. If the user has connection problems or there are server problems, there'll be data loss and the more the system is scaled, the more problems are bound to occur.

The system looks like it's only slightly dated and it looks like it works if someone stands in front of a group and enters test data in a certain way, but you're right, it's static html and js.. with few exceptions, users are clicking into separate screens for individual transactions (which "forces" writing the transactions to the database), but there are enough bugs to stump a user of any experience level. They expect users to take 2 training sessions of 3 hours, and then say "oh well, most of our users aren't professionals, or they're not computer literate, or they're slightly older, or they're too busy to bother figuring it out"...

Users are very frustrated even though most just have to enter 3 or 4 transactions a month. Can't believe they're seriously attempting to turn it into a fully-fledged accounting system. Mind boggling.