[GRASS-dev] on the subject of toolboxes ...

Hi,

before any work begins on this in earnest at the code sprint, I'd just
like to reiterate my take on the toolbox idea. i.e., (and insofar as I
understand the proposal as it exists!) any move towards splitting up
GRASS's build system and distribution package(s) would be a really
really huge mistake.

I would like to offer an alternate proposal which solves the same "new
user confronted with an overwhelming 747 cockpit of controls" problem,
but which does not splinter the core software.

Namely, implement "views" in the wxGUI preferences section, with
tick boxes where you can hide or show groups of modules as desired.
A core set of common modules would always be ticked in a greyed-out box,
and an "enable all" button would be present. Beyond that you can pick
and choose.

As our use cases vary widely, simply breaking up into "Core, Beginner,
Advanced" is too simplistic, and rather a grouping based on keyword
clusters (e.g. "remote sensing", "terrain analysis", ...) would be
more useful..

anyway, this needs to be discussed well before doing anything radical.

the problems as I understand people see them:

* As a by product of GRASS's enormous number of modules, the
discoverability and perceived learning curve can be a bit
overwhelming to new users.
   * Even as an advanced user, when you try to find something in the
menus there is a lot of scrolling past modules you don't use
(e.g. for me, wildfire modeling) which slows you down.

Both fair enough points, and hopefully with things like the wxGUI
module search tool, the module synopsis PDF, and optional "views"
of the menu tree we can go a long way to solving that.

[*] n.b. I'd still like to split the d.vect GUI button up into simpler
components (see d.stations, d.varea wrapper shortcuts in addons svn
for an idea of what I mean), in addition to the "kitchen sink"
advanced/full control access to the real module.

One of the major benefits of GRASS compared to other kitchen-sink GIS
is that you DON'T have to mess around with installing toolboxes. Every-
thing you need is there already. We tend to take this for granted, but
it is a huge plus in our favour. I came to GRASS after fighting for
years with installing additional Matlab and Arc toolboxes, and GRASS
was a huge breath of fresh air not to have to deal with that any more.
(and this problem hasn't gotten any better, I still have to deal with
and despise dongles and flexlm for proprietary toolboxes, and even
without having to deal with those there is always the DDL-hell, 32/64bit
versions, and missing libraries to deal with.. argh! & yay pre-packaged
everythings!)

In addition to that, I (and I suspect many of our users) spend a lot
of time out in the field, days away from any internet connection.
Even the most robust "Click here to install the missing component"
just doesn't work out there. Any often in the field you have to develop
workflows on the fly, so you can't really know what you'll need until
you get out there and the data starts coming in. And even when you think
you've prepared everything you could possibly need, the one thing you
can be sure of is that you haven't.

I know for me, the "already there" availability of GRASS modules
well outside the normal ones used in the common toolset/workflow
of my field of study has helped my career and my personal understanding
as a geoscientist enormously. It's the nexus of an interdisciplinary
approach with different folks from different fields all repurposing the
same tools for different ends and from different POVs. I think it is
another thing we sort of take as normal around here, but really it is
an incredibly valuable and rare thing, and should be jealously guarded
with long ranting emails.

* Another argument given: The the base installer is too big.

Just to look at the (soon) Debian 64 bit package sizes:

15K grass_6.4.2-1_all.deb
             Meta-package, depending and recommending the rest

11M grass-core_6.4.2-1_amd64.deb
             The C, Python, and Shell libraries and modules

6.3M grass-doc_6.4.2-1_all.deb
             The man pages and help page images

2.3M grass-gui_6.4.2-1_amd64.deb
             The two Tcl/Tk GUIs, the WxPython GUI, NVIZ, xganim, etc

212K grass-dev_6.4.2-1_amd64.deb
              The header and build files needed to build GRASS modules

25M grass-dev-doc_6.4.2-1_all.deb
              The GRASS Programmer's manual

So a typical install is under 20MB. This is incredibly small!, and no
problem even over slow/broken/expensive internet like we have down
here in the southern south Pacific. Add max dependency software and you
approach the size of the MS Windows installer, 60MB. Still not so bad
considering the commercial alternatives come on DVDs and want gigabytes.

In short, the disk space / download-time argument is a non-issue. GRASS
is smaller than the onboard-video driver download for my new motherboard.
Users are more harmed by having to download (e.g.) six different files
than they are by having to download a single larger file, which possibly
contains some components which will go unused.

One final concern is that by relegating modules seldom used by the dev
team into what would essentially be second class toolboxes, those modules
will wither and die, and our more outside-of-the-mainstream users will
suffer for it. --- We have a great position catering to niche users
who are not served by the other mainstream offerings. nurture them well!

So keep all modules installed, just give an option to focus the menus on
the relevant "toolkit(s)" of your choice.

comments? criticisms! both most welcome..

united we stand, divided we fall,
Hamish

Hi dev’s,

2012/5/20 Hamish <hamish_b@yahoo.com>

Namely, implement “views” in the wxGUI preferences section, with
tick boxes where you can hide or show groups of modules as desired.
A core set of common modules would always be ticked in a greyed-out box,
and an “enable all” button would be present. Beyond that you can pick
and choose.

As a user I fully apply to this proposal !
that’s already how it works in some other software like QGis or Drupal, and everyone seems to like it …

I see an other good reason for this choice: it would be possible to have a box with the full index of modules and some explanations (like on the web manual), I think it will help new users to find the module they need !

cheers,
Sylvain

+1


From: grass-dev-bounces@lists.osgeo.org [grass-dev-bounces@lists.osgeo.org] on behalf of Sylvain Maillard [sylvain.maillard@gmail.com]
Sent: Sunday, May 20, 2012 4:00 PM
To: Hamish
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] on the subject of toolboxes …

Hi dev’s,

2012/5/20 Hamish <hamish_b@yahoo.com>

Namely, implement “views” in the wxGUI preferences section, with
tick boxes where you can hide or show groups of modules as desired.
A core set of common modules would always be ticked in a greyed-out box,
and an “enable all” button would be present. Beyond that you can pick
and choose.

As a user I fully apply to this proposal !
that’s already how it works in some other software like QGis or Drupal, and everyone seems to like it …

I see an other good reason for this choice: it would be possible to have a box with the full index of modules and some explanations (like on the web manual), I think it will help new users to find the module they need !

cheers,
Sylvain

Thanks Hamish for this discussion.

Il 20/05/2012 03:51, Hamish ha scritto:

before any work begins on this in earnest at the code sprint, I'd just
like to reiterate my take on the toolbox idea. i.e., (and insofar as I
understand the proposal as it exists!) any move towards splitting up
GRASS's build system and distribution package(s) would be a really
really huge mistake.

I think there are two issues here:
- development cycle
- distribution.
I agree warmly that distribution should make life as easy as possible for users, so a
single package (standalone installer) is the main way to go.
As for development, I think splitting the release cycle of GUI and CLI would be
advisable, as they have different cycles, speed of development, and dependencies.
More clearly: if a [new|fixed|improved] command is ready, and its native GUI is not,
are we sure we want to keep this away form users that can profit form this using the
CLI or a different GUI?

Namely, implement "views" in the wxGUI preferences section, with
tick boxes where you can hide or show groups of modules as desired.
A core set of common modules would always be ticked in a greyed-out box,
and an "enable all" button would be present. Beyond that you can pick
and choose.

I find filtering (as done in QGIS and in Sextante) quite simple and useful. Adding
tagging would be enough IMHO. Views could be interesting.

One of the major benefits of GRASS compared to other kitchen-sink GIS
is that you DON'T have to mess around with installing toolboxes. Every-
thing you need is there already.

Agreed - that's why I'm still uncomfortable with addons (even though I understand its
rationale).

In short, the disk space / download-time argument is a non-issue.

Agreed fully. Modularity, however, is always a Good Thing (e.g., I appreciated very
much your splitting because I do not want to install GUI stuff on a server, etc.).

One final concern is that by relegating modules seldom used by the dev
team into what would essentially be second class toolboxes, those modules
will wither and die, and our more outside-of-the-mainstream users will
suffer for it.

Agreed.

comments? criticisms! both most welcome..

Hoe this mine will be useful.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc

On 20/05/12 03:51, Hamish wrote:

Hi,

before any work begins on this in earnest at the code sprint, I'd
just like to reiterate my take on the toolbox idea. i.e., (and
insofar as I understand the proposal as it exists!) any move towards
splitting up GRASS's build system and distribution package(s) would
be a really really huge mistake.

+1

I would like to offer an alternate proposal which solves the same
"new user confronted with an overwhelming 747 cockpit of controls"
problem, but which does not splinter the core software.

Namely, implement "views" in the wxGUI preferences section, with tick
boxes where you can hide or show groups of modules as desired. A core
set of common modules would always be ticked in a greyed-out box, and
an "enable all" button would be present. Beyond that you can pick and
choose.

As our use cases vary widely, simply breaking up into "Core,
Beginner, Advanced" is too simplistic, and rather a grouping based on
keyword clusters (e.g. "remote sensing", "terrain analysis", ...)
would be more useful..

+1

In addition to that, I (and I suspect many of our users) spend a lot
of time out in the field, days away from any internet connection.
Even the most robust "Click here to install the missing component"
just doesn't work out there.

Not just out in the field. We train people from countries where even
power is not a certainty, and internet more a question of chance, even
when they sit in their office.