There's this program written by VBA running in Access. Every time we enter some data on a form and press the next record button on navigation bar data is saved automatically. I would like to know if there's a possibility to change this behavior, for example, to ask the user before saving the data.
It may be possible to use the before update event for the form with cancel and undo, but it is by no means infallible.
If there is some problem with data entry, do not think that asking will help, I have tried "Are you sure?" before, and the user gets into the habit of clicking yes automatically, followed by "oops".
Related
I have a question regarding my Powerapps I've built.
With this app user have to update or confirm the data that is stored in a sharepoint list. I have included the "modified by" column to see when someone has updated the data.
My problem is that if the data is up to date and the user submits the form there is no change in the modified by column. Because of that, I can't see if everybody has checked their data.
How can I achieve this even if no changes are made?
I thought of an extra column where the user has to put in something, but I don't know how to keep this empty every time so that the last input won't be shown anymore.
Thanks for your help.
Best regards,
Elena
If you want to allow users to submit/confirm without being able to change you can use some logic.
The first part of the logic is as normal, let the user submit the form as usual.
Make a flow that is being triggered after the normal update that takes the Row ID of your data and for example sets the record to inactive and back to active as this will triggers the modify date to be set.
I'm looking for insights about how users with disabilities make use of implicit submission (https://www.w3.org/TR/html50/forms.html#implicit-submission) ?
I'm wondering if submitting a form on enter key when focus is in a input text is a must in the accessibility world or not ? I'm sure it could be useful in some scenarios, but I know it could be harmful also in others...
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ? what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?
On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...
I know that JAWS and NVDA offers keyboards shorcuts to go to the next buton, so I wonder if it's really userful for them. What are expectations of users navigating the web with a reader or keyboard navigation on that matter ?
I'm a screen reader user. Implicit submission with enter key is, I think, an absolute must.
Except if it causes more annoyance than it solves, but it's extremely rare.
Generally, screen reader and keyboard-only users are much slower than normal users.
And I confirm that it's quite annoying to have to navigate manually to the submit button when the enter key doesn't work as expected.
By chance, if you are doing things correctly, it's implicit, you don't have to do anything to support it.
The most elementary rules to not break implicit enter submission are:
Use <input type="submit"/>, <button type="submit"/> or <input type="image"/> to indicate the submit button automatically triggered upon pressing enter.
Use onsubmit event on the form, rather than onclick on the button
Make sure that the form has only a single submit button
The submit button must be present, not disabled, and not display:none in order for implicit submission via enter to work.
The button may not be visible on the screen though, if it's your wish.
The second rule reminds you that onclick on the button is bad, because it isn't triggered when pressing enter while being in another field.
Thus breaking implicit submit. This is the most common reason for implicit submit to not work as expected.
The third rule ensure that the right button is pressed when doing implicit submit.
If there are multiple buttons, normally the first one in DOM order should be taken, but browser have sometimes different behaviors, especially IE. So the best is to always avoid it.
Now for your little fears:
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?
In principle it won't happen unexpectedly.
When entering a text field, it is announced to screen readers, whether it is single line (<input type="text"/>) or multiline (<textarea>)
In case of doubt, remember to attach an appropriate label that makes sense.
If the label is "comment", "message" or "address", I can reasonably expect that the field is multiline; if it is "First name" or "city", I implicitly know that it isn't.
what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?
It's very common, but you shouldn't be afraid of it.
It's your job to provide clear and efficient error messages to the user, allongside with as simple as possible navigation inside the form.
The more it is difficult to go back, understand and fix errors, the less chance the form is going to be finally submitted; it drops very quickly, and even more with screen reader users.
How to do it well is another question.
Most forms on the web has the behavior of implicit submission built-in, so users of assistive technology would not be surprised by it, and I've not experienced it as an issue when using screen-readers.
However, you should ensure that you always provide a proper button for submitting the form as well. See WCAG 3.2.2
You should also ensure to make it as easy as possible to go back and change the data afterwards/at a later time.
QuentinC's answer is excellent, so I won't answer every point.
I would recommend that you don't attempt to interfere with implicit form submission, unless you have a very good reason for doing so.
For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?
For <textarea>, pressing enter usually produces a new line, and implicit form submission doesn't happen. For <input type="text">, pressing enter causes implicit form submission.
Some applications override this behaviour though (in confusing ways, in my view). A common example is with messaging applications, which have overridden the enter key, so it means "send message". To get a new line, they put some custom behaviour, such as CTRL+ENTER to make a new line. This isn't the default behaviour of a <textarea> though. To make matters worse, different messaging applications do the opposite. A few offer a user preference to configure whether pressing enter sends a message, or adds a new line (Slack offers a preference).
On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...
This is the main reason to avoid interfering with the browser's default behaviours for implicit form submission. As a keyboard user, I often make use of this. Screen readers offer various navigation shortcuts, but these aren't available to a sighted keyboard user who isn't using assistive technology.
I'm working on an application using Play 2.0.4 in Scala, and one of the features I was asked to implement is to build a form that remembers all of the edit history. Basically, there should be a button next to every field that shows the details of every change, because the app users may want to rollback or use the edit history information later.
The first idea pops up in my mind is to assign a hidden div to every field that appends every change, and only shows the div when users click on the corresponding button. This doesn't sound very hard, but I feel like it may make the HTML a mess (since each user has his own record, each record has many fields). Or I could make a copy of the database and store all the changes inside, with the primary keys changed to be both the id of the form, and the edit time.
Thoughts? Am I overthinking the problem? Is there a more elegant way to store all of the edit history? We estimate that there would only be around 200 people in the company using it, so I guess I can let efficiency slide a little...
Thanks in advance.
I would normalize and persist the record in the database. This would allow you to have history on changes by having a history table for each section that they with to rollback.
This would allow manageability of restorations based on sets of data and significant changes can be tracked. Managing each field separately would be very cumbersome and least pragmatic.
Basically, what pros/cons are there to using multiple forms in the same web page vs one form with multiple submit buttons? Any difference at?
Ah? Multiple submit buttons on a single form will all submit the entire form when pressed... there's really no advantage to having multiples, unless you're overriding how the submit process works so each button only submits it's own area. In this case they'd probably not even by submit buttons, but just buttons with sum JS code to handle submission.
Multiple forms are discrete spaces of data collection, each can have it's own submit button... but only one of them can be sent at a time (and depending on the browser you may loose what's in the other forms).
Neither approach is particularly good from a user interface perspective since it'll be confusing.
The real question is, what are you trying to do that prompts you to ask this?
The two behave differently and there are good reasons to choose one over the other.
Multiple Forms on a page allow you to send data to two different locations. A common example is to have an input form as the main focus of a page going to one location, and a search form that appears as part of the generic header/footer. These both go to separate locations and submit only the HTML form elements within their appropriate <form/>
Multiple submit buttons offer you the ability to give different purpose to a submitted set of form elements. E.g. One form may have a bunch of submit buttons all with name attributes, meaning you can add conditional logic on the server side to say: "Continue", go " Back" or even "Save for later". All reference only the form elements within it's parent tag.
Two side notes are: 1) You can't nest forms. 2) JavaScript can change this default behaviour if you wanted it to. :)
Edit: with reference to a comment you made, if you wanted to do without JavaScript (a wise choice while it's not needed), you could do some careful thinking and keep POSTing the form to itself. Each time checking which form button has been clicked (top tip, give them all the same name and you can just switch case through it) and do whatever you need to do, including performing validation. E.g: When they hit "add media", you'd save the media uploaded and return a reference of it to the screen as a hidden input. The user can then continue to add things to the other boxes and when complete, hit your save button, at which point you do all the main saving work and make sure you tie the uploaded file to it as well.
You effectively keep adding stuff to their screen until they hit the save and then you perform a save method and redirect to a thank you page (or whatever logic suits your scenario). :)
All fields in a form are sent when one of their submit button is clicked. It's for you to see if you need all fields or not.
I have a data entry form that when it closes opens another form for further updating the just newly entered data. However, at times no further update is necessary. How can I suppress the 2nd form from opening when there is no need for further update? Presently the form opens even when there are no recordsets present. (need a similar Event like for the report "On No Data")
Have a bit field such as a checkbox with default set to true open second form. Uncheck it to avoid the system from opening the next form. You will need to handle this in your code and check if that check box is checked or not.
Of course we will need more details such as why you are currently opening this second form...in addition, cant you check if any changes were made and if they were then open that second form else dont? Also what lang ?
Without knowing more about what you're working on, I'd say you would have to modify the process that shuts down the first form to check if the second form is needed. In .NET, for example, you could add code to the OnClosing event for a WinForm to check. If it's needed, open it as normal, if not then don't.
Subject: Tool Kits. Tool Kits consist of 1 or more tools. If tools already exist, no need for 2nd form to pop up. If tools are new, I need to fill in one of the 3 fields in the drop down listing. I like the idea of adding code to the OnClosing event, but do not understand what you mean by WinForm.