wxGUI: wording of menu entries for data import

[mlennert]

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.

What do you think ?

[mlennert]

Any opinion on this ? Would this still be an option for 7.6 ? Or are menu entry names considered API changes ?

[wenzeslaus]

Replying to 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.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed