"Save" and "discard" buttons are hard to find in lengthy forms

[syntakker]

Bug Description

In all forms that are too long to be shown in total in the browser, the user has to scroll to reach the "save" and "discard" buttons. This makes it unnecessary hard to do quick updates and - especially to unexperienced users - to find these central elements at all.

Steps to Reproduce

This applies to a number of forms, including those for case data, case person, contact data, contact person and event.

Expected Behavior

The "save" and "discard" buttons should always be visible. This can be solved via a sticky button panel.

System Details

• Device: PC
• SORMAS version: 1.51.0-SNAPSHOT
• Android version/Browser:
• Server URL:
• User Role:

[ChristopherRiedel]

@syntakker I do not think this is a good idea. I fully understand the problem, but it will lead to many people not entering important data. In many cases, the page will look like it has ended above the sticky panel. The only point where this can be noticed is the scrollbar on the right side, but that doesn't seem to be enough.

[syntakker]

I do not think it is a good idea to hide central controls from the user by default. If you save a realistic 1 second of scrolling per case or contact, it adds up to about 28 hours per 100.000 cases or contacts, which we unfortunately have now.

I added an arrow indicating more scrollable content:

The arrow disappears when the end of the page is reached:

The arrow is not visible in short forms:

@Candice-Louw does this make sense from an UX point of view?

[syntakker]

@ChristopherRiedel btw, for now, the scrollbar - which is indeed somewhat hard to notice - is the only indication that there might be buttons to commit or discard your entries at all.

[syntakker]

For reviewers: if the rendering of the arrow is odd or the arrow does not reliably disappear when it should, please let me know which system and browser you are using and send screenshots.

[MateStrysewske]

@bernardsilenou @kwa20 I'd like to hear your opinion on this. Can you have a look at the screenshots and the feature request in general and say what you think about it?

[kwa20]

@MateStrysewske I generally like the feature but understand the concerns. I personally already use the unsaved changes prompt to navigate through tabs quickly so I don't have to scroll down and save every time. Since I am familiar with the system though, I might not represent the general user.

From the screenshots it seems as if a continuing page is indicated by a fading form in addition to the arrow. Since we don't have any large gaps on lengthy forms, I think this would be sufficient to show that the end of a page hasn't been reached. Furthermore, compulsory entries will still have to be made and clicking save doesn't navigate out of the form. Therefore I would support the implementation. Alternatively, I could also try to get some more feedback from users directly.

@bernardsilenou @Candice-Louw What do you think?

[HellerDominik]

Hey, @JonasCir linked me this issue.
I totally understand the frustration coming from the issues here. Some Interfaces tackle this by completely ignoring a save and discard mechanic and go with the concept of everything entered will be saved.

Another idea could be to have a little feedback after you did an input and leave the input field, like a flowing text which says "Input for Birth Date saved".

I worked on another issue which was about redesigning the header and we came to a conclusion that it might be good to change the information architechture on the screen by taking the info from the tiny box in the top right corner and putting it into the actual header. Like this:

You could use this space that we have now, in the top right corner, to put the save and discard buttons there?

Only thing that you might want to tackle, in this case, is this issue: https://github.com/hzi-braunschweig/SORMAS-Project/issues/3147 which is about keeping the header on top of the screen all of the time.

So my suggestion would be to make the header stick to the screen, even when scrolling, redesign the header so the information required is more in the focus and using the space in the top right corner to save or discard the information.

[bernardsilenou]

Dear All,

• The floating arrow showing that the page continues downward is nice to have. In addition, we can also male it show upward in case the user is at the end of the page. Can we use another colour other than red? eg dark blue?
• I think it would be good to have the save and discard icons only at the end of the form. The reason for this is that we want to "force" users to read through form before saving in order to increase data completeness. I read the issue again and realize Chiss already mentioned what i am writing

[MateStrysewske]

I'd agree with the solution proposed by @bernardsilenou. In the longterm, we should definitely make sure that we use the whole width of the window for our forms which would make this discussion obsolete for most forms; however, I think that will be a topic for the migration to a different UI framework.

[syntakker]

@bernardsilenou:

• giving the downward arrow a less prominent colour contradicts the importance of not missing parts of the form you stress
• the only way to reach the bottom of a page is to scroll down. An upward arrow is obsolete, unless you assume the user has forgotten that he just scrolled down or thinks that for some reason it would be impossible to scroll up again

@MateStrysewske: @bernardsilenou proposes two solutions:

1. minor adjustments
2. ditch the proposal and keep things as they are

Which of these do you refer to?

To summarize:

• I (@syntakker) advocate that a mere second saved by scrolling less could make a difference, given the number of cases. This however under the assumption that the form is used for updates most of the time, i.e., the user has a specific information he wants to add or update (for creation of cases or contacts there is a short form)
• @kwa20 has presented a workaround for the user which already works, however by slightly abusing another feature of SORMAS. This workaround saves the user from scrolling as long as the header is visible (see also #3147), but it is left to the user to figure out
• @HellerDominik proposes solutions which would keep the controls in sight or auto-save, thus not forcing the user to scroll through all of the form either. These solutions would need to be specified and implemented.
• @ChristopherRiedel and @bernardsilenou express concerns about parts of the form being missed by the user, the solution being to force the user to scroll to the end when using a form, i.e., not using a sticky button panel. Experienced users - who supposedly know all of the data to be entered - may have figured out @kwa20's workaround

So?

[MateStrysewske]

I would:

• Keep the downward arrow; I think this is a good addition that will tell the users that they have to scroll down to see additional content. However, I agree with Bernard concerning the colour; I think it's pretty invasive and contradicts the rest of the colour scheme. I'd also prefer to have it in some shade of blue that is already used elsewhere in the application. I think users will still see it.
• Keep the save/discard buttons where they are right now, i.e. below the form, not sticky; again, I totally understand your point, but we know for a fact that it will lead to problems in countries with less experienced, technically versed or motivated users because they will miss fields that aren't necessarily mandatory, but should still be filled in if possible.

Moving the buttons to the header is not a good idea in my opinion because a) it breaks the flow of the web page and b) it kinda suggests that the lists to the right of the forms belong to the forms, which isn't true. Also, it basically worsens the problem described in my second point.

Auto-saving is a bad idea as well in our case because it will lead to accidental data entry. One of the reasons coming from Nigeria for the addition of the "Unsaved changes" warning that was recently implemented was that users there frequently make inadvertent data entry because they're accidentally clicking or typing somewhere in the form, which will lead to data loss and/or wrong data when the data is automatically saved.

[kwa20]

What if we address the concerns by adding the condition that for initial entries, you are supposed to scroll through the whole form before the button panel gets "picked up"/sticky? Users would then have to work through the whole form before the button panel becomes sticky. This would mean that users would not miss fields when first entering the data for a case/contact but can also make quick changes when reopening such forms.

[MateStrysewske]

@kwa20 The problem is that we don't know whether the user enters the form for the first time or not. The create forms are displayed in popup windows and only contain a subset of the data; afterwards, the user is redirected to the full form and is supposed to go through all the fields of the individual tabs (ideally). However, the user doesn't necessarily do that immediately, they might do it later when they have more time - in any case, we can't say for sure whether it's the initial data entry or not.

[syntakker]

@MateStrysewske I see the point. I think @kwa20's workaround is an acceptable way to go, especially since it kind of auto-sorts users according to their experience. Maybe mention this in a line in the documentation. Just adding an arrow is not a major improvement, and it is technically different without the sticky bottom panel. However I will give it a try when I have the time. For now I will close the PR and this issue.