usability: button labelling should be consistent

I'm not sure. The button in "new term" doesn't actually save anything -- it
refreshes the form (adds/removes the controls when you change the date range).
If you change the button label to "Save", that would imply that you actually
change something in the database, while actually you don't.

I do not know what the "Update" button in section's schedule view does.

Terms > New term
================

mgedmin wrote:
>I'm not sure. The button in "new term" doesn't actually save anything -- it
>refreshes the form (adds/removes the controls when you change the date range).
>If you change the button label to "Save", that would imply that you actually
>change something in the database, while actually you don't.

I think the bigger issue at hand is that normal users don't have a lot of
experiences interacting with complex dynamic web forms in the browser. The
current implementation is that you "set parameters" in the top part of the page,
and those parameters determine you "input options" in the lower part of the
page. This is a rather 'uncommon' user interface. So, this issue isn't really a
trivial "label" issue, but more an issue about how to create user-friendly
interfaces for complex data input! To be honest, I'm not sure that this can be
done in distributed development... I think you need face to face meetings. But
this is becoming a bit too philosophical for a bug report.

(a section) > Schedule
=======================

mgedmin wrote:
>I do not know what the "Update" button in section's schedule view does.

Again, this proves my point. At least you, as a developer of the darn thing,
should understand what it does... :-P

In fact, I say that the interface needs a rethink from a usability perspective.
There should be a guiding vision...

Compare also with issue 308.

I think the issue with the term adding procedure is that it is more like a wizard than a form, but isn't
identified as such.

Did someone already change the section/schedule to say "save?"