[Geoserver-devel] Apply on every page, button order, and submit vs save

Hi,
playing with the GeoServer configuration months ago I got annoyed that it wasn’t possible
to just apply a configuration change, check the results, and then go straight to do some changes.
Or else, it was possible only in the styles page…

So I spent a few of weekends (well, 1-2 hour a weekend really) to add an apply button to many
configuration pages, covering most of the core ones.

On review Niels noticed inconsistent button order, the styles page has Apply/Submit/Cancel,
while in most of the other pages I did Submit/Apply/Cancel.

I’m inclined to agree, the Apply/Submit/Cancel order seems like a better option… but before
moving to do changes, I wanted confirmation, it’s not a small change to do.

Niels also noticed that there is a mix of submit and save buttons around… changing the code
variable names to make them consistent would be a lot of work, but making just the
user experience consistent is hopefully just a matter of changing a i18n translation.
So, submit or save?
I’d go for “save”. There is a downside of this, lots of GUI images to be re-snapshotted,
and possibly quite a bit of text to be modified.

In the Apply PR I had to go through that already, for some I took new pictures, for others
I just removed the buttons from the image, they were not actually adding much info.
It’s a bit faster than re-snapshotting the GUI, especially for plugins that one might not have handy
(in my case, it was datastores).

If we go for the submit/save inconsistency elimination, is there anyone that would help
with the text and GUI screenshots rework?

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

This is great, thank you Andrea :slight_smile:

Feedback:

A detail:

  • We do have dialog like Browse or Delete, which open a “dialog” for interaction that offer OK/Cancel experience (and WICKET AJAX DEBUG)

  • In some cases “Save” is distinct from “Submit”, for example when editing a multi page data structure like WPS permission it is possible (common even) to loose your work but saving a “sub page” but not “submitting” the completed result. Long term these may be best represented as pop-up Dialogs like browser, short term can we change these screens to “OK/Cancel” so as not to give the impression they are saving …

My opinion:

  • Use “Save” (not “Submit”) as we are saving a change, not submitting a form for later processing
  • Use “Save|Apply|Cancel” consistently when saving.
  • Use “OK/Cancel” consistently when not saving.
  • Use “Delete/Cancel” when deleting.
  • We can use CSS to introduce visual distinction (SAVE | APPLY | Cancel) if we wish

Two offers of assistance:

  • I will talk to GeoCat about updating the documentation, I agree trimming the images is a good first cut, but many are out of date anyways
  • If we can isolate the “Save|Apply|Cancel” into a div how do you feel about having it float to a consistent location on screen during scrolling. Having to scroll to the bottom or top of the page is an awkward time waste, this is especially frustrating when used with “Apply” as you lose your spot on long forms.

    Jody Garnett

On Sat, 16 May 2020 at 07:38, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
playing with the GeoServer configuration months ago I got annoyed that it wasn’t possible
to just apply a configuration change, check the results, and then go straight to do some changes.
Or else, it was possible only in the styles page…

So I spent a few of weekends (well, 1-2 hour a weekend really) to add an apply button to many
configuration pages, covering most of the core ones.

On review Niels noticed inconsistent button order, the styles page has Apply/Submit/Cancel,
while in most of the other pages I did Submit/Apply/Cancel.

I’m inclined to agree, the Apply/Submit/Cancel order seems like a better option… but before
moving to do changes, I wanted confirmation, it’s not a small change to do.

Niels also noticed that there is a mix of submit and save buttons around… changing the code
variable names to make them consistent would be a lot of work, but making just the
user experience consistent is hopefully just a matter of changing a i18n translation.
So, submit or save?
I’d go for “save”. There is a downside of this, lots of GUI images to be re-snapshotted,
and possibly quite a bit of text to be modified.

In the Apply PR I had to go through that already, for some I took new pictures, for others
I just removed the buttons from the image, they were not actually adding much info.
It’s a bit faster than re-snapshotting the GUI, especially for plugins that one might not have handy
(in my case, it was datastores).

If we go for the submit/save inconsistency elimination, is there anyone that would help
with the text and GUI screenshots rework?

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

This is great, thank you Andrea :slight_smile:

Feedback:

  • Danger of classic bike shedding topic!

Been on this since early February, last thing I need is a long winded discussion and scope creep.
Want to close this ASAP and leave eager volunteer to pick up on extras.

  • In some cases “Save” is distinct from “Submit”, for example when editing a multi page data structure like WPS permission it is possible (common even) to loose your work but saving a “sub page” but not “submitting” the completed result. Long term these may be best represented as pop-up Dialogs like browser, short term can we change these screens to “OK/Cancel” so as not to give the impression they are saving …

Did not think about it, fair point… so I guess the inconsistency will stay until someone can get dedicated time to look individually, has become too much work (the only change I was volunteering to do was a i18n one, mind).

My opinion:

  • Use “Save” (not “Submit”) as we are saving a change, not submitting a form for later processing

For someone else to look at, as indicated above.

  • Use “Save|Apply|Cancel” consistently when saving.

Works for me, I can do this.

  • Use “OK/Cancel” consistently when not saving.
  • Use “Delete/Cancel” when deleting.

Both for someone else to look at, as indicated above.

  • We can use CSS to introduce visual distinction (SAVE | APPLY | Cancel) if we wish

Same as above.

Two offers of assistance:

  • I will talk to GeoCat about updating the documentation, I agree trimming the images is a good first cut, but many are out of date anyways
  • If we can isolate the “Save|Apply|Cancel” into a div how do you feel about having it float to a consistent location on screen during scrolling. Having to scroll to the bottom or top of the page is an awkward time waste, this is especially frustrating when used with “Apply” as you lose your spot on long forms.

Seems interesting, for someone else to look at, too

Cheers
Andrea

···

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

  • In some cases “Save” is distinct from “Submit”, for example when editing a multi page data structure like WPS permission it is possible (common even) to loose your work but saving a “sub page” but not “submitting” the completed result. Long term these may be best represented as pop-up Dialogs like browser, short term can we change these screens to “OK/Cancel” so as not to give the impression they are saving …

Did not think about it, fair point… so I guess the inconsistency will stay until someone can get dedicated time to look individually, has become too much work (the only change I was volunteering to do was a i18n one, mind).

I understand hopefully the reason above explains this inconsistency to Niels. I hope we can use i18n for the OK/Cancel items.

How about it Niels want to take a run at making this consistent with OK/Cancel for these “sub pages”? I would rather see these changes done once, so we update the docs once.

My opinion:

  • Use “Save” (not “Submit”) as we are saving a change, not submitting a form for later processing

For someone else to look at, as indicated above.

  • Use “Save|Apply|Cancel” consistently when saving.

Works for me, I can do this.

Thanks!

  • Use “OK/Cancel” consistently when not saving.
  • Use “Delete/Cancel” when deleting.

Both for someone else to look at, as indicated above.

  • We can use CSS to introduce visual distinction (SAVE | APPLY | Cancel) if we wish

Same as above.

Two offers of assistance:

  • I will talk to GeoCat about updating the documentation, I agree trimming the images is a good first cut, but many are out of date anyways
  • If we can isolate the “Save|Apply|Cancel” into a div how do you feel about having it float to a consistent location on screen during scrolling. Having to scroll to the bottom or top of the page is an awkward time waste, this is especially frustrating when used with “Apply” as you lose your spot on long forms.

Seems interesting, for someone else to look at, too

Sounds good,

Jody

···


Jody Garnett

On Sat, 16 May 2020 at 15:38, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
playing with the GeoServer configuration months ago I got annoyed that it wasn’t possible
to just apply a configuration change, check the results, and then go straight to do some changes.
Or else, it was possible only in the styles page…

Excellent work, I’ve often felt the need for an apply button, so thank you for doing this.

So I spent a few of weekends (well, 1-2 hour a weekend really) to add an apply button to many
configuration pages, covering most of the core ones.

On review Niels noticed inconsistent button order, the styles page has Apply/Submit/Cancel,
while in most of the other pages I did Submit/Apply/Cancel.

I’m not really bothered as to the order but it would be nice for it to be consistent across pages.

I’m inclined to agree, the Apply/Submit/Cancel order seems like a better option… but before
moving to do changes, I wanted confirmation, it’s not a small change to do.

Niels also noticed that there is a mix of submit and save buttons around… changing the code
variable names to make them consistent would be a lot of work, but making just the
user experience consistent is hopefully just a matter of changing a i18n translation.
So, submit or save?
I’d go for “save”. There is a downside of this, lots of GUI images to be re-snapshotted,
and possibly quite a bit of text to be modified.

Again I don’t have a preference but would like it to be consistent. I’m happy to do some screenshotting and doc updates.

Ian

Hello,

In response to the emails:

  • I prefer save > submit where possible, I have found ‘submit’ to be confusing to users, so I would get rid of that as much as possible

  • The chose order is less important, but I have a personal preference for ‘save | apply | cancel.’

  • Yeah, I’m happy to chip in with some ‘monkey’ work…

Kind Regards

Niels

···

On 17/05/2020 23:13, Jody Garnett wrote:

  • In some cases “Save” is distinct from “Submit”, for example when editing a multi page data structure like WPS permission it is possible (common even) to loose your work but saving a “sub page” but not “submitting” the completed result. Long term these may be best represented as pop-up Dialogs like browser, short term can we change these screens to “OK/Cancel” so as not to give the impression they are saving …

Did not think about it, fair point… so I guess the inconsistency will stay until someone can get dedicated time to look individually, has become too much work (the only change I was volunteering to do was a i18n one, mind).

I understand hopefully the reason above explains this inconsistency to Niels. I hope we can use i18n for the OK/Cancel items.

How about it Niels want to take a run at making this consistent with OK/Cancel for these “sub pages”? I would rather see these changes done once, so we update the docs once.

My opinion:

  • Use “Save” (not “Submit”) as we are saving a change, not submitting a form for later processing

For someone else to look at, as indicated above.

  • Use “Save|Apply|Cancel” consistently when saving.

Works for me, I can do this.

Thanks!

  • Use “OK/Cancel” consistently when not saving.
  • Use “Delete/Cancel” when deleting.

Both for someone else to look at, as indicated above.

  • We can use CSS to introduce visual distinction (SAVE | APPLY | Cancel) if we wish

Same as above.

Two offers of assistance:

  • I will talk to GeoCat about updating the documentation, I agree trimming the images is a good first cut, but many are out of date anyways
  • If we can isolate the “Save|Apply|Cancel” into a div how do you feel about having it float to a consistent location on screen during scrolling. Having to scroll to the bottom or top of the page is an awkward time waste, this is especially frustrating when used with “Apply” as you lose your spot on long forms.

Seems interesting, for someone else to look at, too

Sounds good,

Jody

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.


Jody Garnett

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)

As for the PR can we merge, and then start a new PR for group work on internationalization and documentation changes?

···


Jody Garnett

Not ready for merge, need to fix the button order, but agree it’s a good idea to move the other changes to a separate PR, they are related, but not same.

Cheers
Andrea

···

Regards, Andrea Aime

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

I made the promised PR for fixing submit->save.

https://github.com/geoserver/geoserver/pull/4289

Cheers

Niels

···

On 18/05/2020 19:49, Jody Garnett wrote:

As for the PR can we merge, and then start a new PR for group work on internationalization and documentation changes?


Jody Garnett

On Mon, 18 May 2020 at 00:58, Niels Charlier via Geoserver-devel <geoserver-devel@lists.sourceforge.net> wrote:

Hello,

In response to the emails:

  • I prefer save > submit where possible, I have found ‘submit’ to be confusing to users, so I would get rid of that as much as possible

  • The chose order is less important, but I have a personal preference for ‘save | apply | cancel.’

  • Yeah, I’m happy to chip in with some ‘monkey’ work…

Kind Regards

Niels

On 17/05/2020 23:13, Jody Garnett wrote:

  • In some cases “Save” is distinct from “Submit”, for example when editing a multi page data structure like WPS permission it is possible (common even) to loose your work but saving a “sub page” but not “submitting” the completed result. Long term these may be best represented as pop-up Dialogs like browser, short term can we change these screens to “OK/Cancel” so as not to give the impression they are saving …

Did not think about it, fair point… so I guess the inconsistency will stay until someone can get dedicated time to look individually, has become too much work (the only change I was volunteering to do was a i18n one, mind).

I understand hopefully the reason above explains this inconsistency to Niels. I hope we can use i18n for the OK/Cancel items.

How about it Niels want to take a run at making this consistent with OK/Cancel for these “sub pages”? I would rather see these changes done once, so we update the docs once.

My opinion:

  • Use “Save” (not “Submit”) as we are saving a change, not submitting a form for later processing

For someone else to look at, as indicated above.

  • Use “Save|Apply|Cancel” consistently when saving.

Works for me, I can do this.

Thanks!

  • Use “OK/Cancel” consistently when not saving.
  • Use “Delete/Cancel” when deleting.

Both for someone else to look at, as indicated above.

  • We can use CSS to introduce visual distinction (SAVE | APPLY | Cancel) if we wish

Same as above.

Two offers of assistance:

  • I will talk to GeoCat about updating the documentation, I agree trimming the images is a good first cut, but many are out of date anyways
  • If we can isolate the “Save|Apply|Cancel” into a div how do you feel about having it float to a consistent location on screen during scrolling. Having to scroll to the bottom or top of the page is an awkward time waste, this is especially frustrating when used with “Apply” as you lose your spot on long forms.

Seems interesting, for someone else to look at, too

Sounds good,

Jody

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.


Jody Garnett

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel