#3633: wxGUI: wording of menu entries for data import
------------------------------+-------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.6.0
Component: wxGUI | Version: unspecified
Keywords: data import menu | CPU: Unspecified
Platform: Unspecified |
------------------------------+-------------------------
Yesterday I was confronted with some confusion by people who do know GRASS
GIS, but do not follow all detailed discussions and evolutions.
They wanted to import a series of shape files from a directory. They knew
they had to use v.in.ogr to do so, and since they had the memory that some
time back the menu entry followed by [v.in.ogr] was the right one to this,
they chose that one, instead of the first entry which indicates [v.import]
and mentions reprojection which they didn't need.
As v.in.ogr actually allows to import a whole series of shapefiles at once
from a given directory they tried this, without understanding that
v.in.ogr only creates one output file and so all the imported files were
included as different layers in the same output vector map which is not
easy to deal with for less advanced users.
Thus my idea: maybe we could change the wording of the menu entries that
open a wizard, and not a real module GUI, in order to make it clearer and
to make these entries potentially independent of the modules that are
behind the wizards ?
This would mean rewording the GUI entry for the *.import modules from the
current
"Simplified vector import with reprojection" [v.import]
to something like
"Simple vector import wizard with optional reprojection"
and only use the [ModuleName] syntax when it really is a generic module
GUI that is called.
#3633: wxGUI: wording of menu entries for data import
--------------------------+------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.6.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: data import menu
CPU: Unspecified | Platform: Unspecified
--------------------------+------------------------------
Comment (by wenzeslaus):
Replying to [comment:1 mlennert]:
> Any opinion on this ?
I agree that if the wizard is very different from the module, or even
perhaps when it is a wizard or a more fancy dialog as opposed to the
generated one, it should not include module name in square brackets.
(However, mentioning somewhere the name of the module is desired.)
> Would this still be an option for 7.6 ?
I think so.
> Or are menu entry names considered API changes ?
I don't think so. What this breaks are translations (hopefully fixed
before the actual release) and tutorials (documentation should be updated
with the change). I would say that it is nice to keep the strings the same
or almost the same within a minor version so that tutorials can say
something like "use with 7.4" or "developed for 7.4". However, easier,
more intuitive interface outweighs stability of some tutorial somewhere
(as I said the documentation should be changed together with the string).
Speaking more generally, the reason why it is not an API change is that
these are being interpreted by humans doing tutorials or following notes
who can deal with changes in wording and focus on the meaning instead.
In GRASS GIS, the issues coming from changes is user visible strings are
mitigated by the fact that tutorials are often written using commands
rather than screenshots and menu and dialog navigation. Although these are
very useful and desired, they are (or can be) only additional material.