Hello all,
although I expected some discussion, I didn't expect a kind of Spanish
Inquisition. To make things easier for me (I still have to type single
handed), I'll try to address all issues in a single email.
At first we all must agree that coordinate systems, geospatial data
and thus also GIS is hard. We will never have a perfect (the final)
solution or a solution we all can agree on, but it shouldn't stop us
from trying out new things.
Second – from the GSOC web site: „Google Summer of Code is a global,
online program focused on bringing new contributors into open source
software development.“ It is not „get some code to merge into next
release“ and thus developing an experimental feature still is a good
way how to get familiar with the code base, contributing to os, issues
and features of GRASS.
Third – we should improve GRASS with a goal of making easy to do „the
right thing“ and to make hard to do „wrong“. We have (and should
keep!) plenty of „shortcuts“ for experienced users who understand what
they do.
And now let's dive into specifics (in chronological order).
Vero, I meant a first-run wizard, but choose a bad name. Sorry, my
fault. Although I had no fundamental objections against the old
startup screen, there is no need to resurrect it. He's dead, Jim.
Anna, there were many ideas floating around in Prague caused by the
„location“->„project“ proposal. And you are right, we couldn't agree
on a single solution (see the first point of this email). At the same
time there were concerns from me and others (IIRC Martin, Luís,
Helmut?) that it is still too easy to continue with a sub-optimal or
outright wrong CRS (location/project structure). Later on (after a few
too many beers) I tried to convince everyone (sorry Linda!) that we
should focus on that “easy to do right“ mantra. At the end we all
agreed (or everyone agreed just to silence me ;-) that we should
continue exploring alternatives and thus was the GSOC proposal.
Brendan, there's more than one way to skin a cat.
Anna, the current info bar is just bad for at least two reasons (sorry
Linda, I'm just opinionated). Although you state that most users just
dismiss it, I'll call it a lie – it is not possible to dismiss it at
all! Yeah, I'm just kidding, there is a bug in the code. I rm'ed my
.grass8 to see first start-up experience. See attachment with a cutout
from a full screen window I was presented with – one can not read
whole message or see any buttons as the widget is too small to fit all
of its content. And that's even before the text is translated to
Latvian, German or Finnish that will make the text even longer
(Äteritsiputeritsipuolilautatsijänkä is an actual name of region in
Lapland and makes a good word to test UI).
The info bar has fallen into the old startup window trap – try to
explain GRASS specifics (an important thing!) instead of providing
easy actionable options that all lead to „doing it right“. It is a
TL;DR, and why I should „create new project“ if I already have one
open? Keep in mind attention span of a goldfish (a.k.a. length of a
Tiktok video) we are dealing with. (Has anyone read this far? Let me
know in the comments and don't forget to like and subscribe.)
My idea did not interfere with implementing an offer to create a new
project in import tools if a reprojection from projected to ll project
is detected (I <3 how this sentence rolls-off my tongue) or any other
enhancements that also can (and should) be implemented.
Vaclav, thanks. I was thinking of something like A1 proposal, but even
simpler (three + 1 buttons) and the same time with a lot of black
magick (e.g. three clicks or less to have everything ready for any of
our intro tutorials, including opening a web browser with the chosen
tutorial and adding some layers to the map view; two clicks (+ file
browsing) to have users raster or vector data displayed).
Linda, in your paper you wrote: „Since both options were favorably
rated (85% responded positively to the first-run wizard and 74% to
info bars), we decided to implement an info bar as a technically
simpler and more flexible solution.“ The idea of this GSOC proposal
was to implement in some form the second option that would allow to
perform A/B testing with real users. As you (et al.) have done a huge
work with the codebase, now it would be much easier to implement than
some years a go.
I also understand that users want to start working with the software
right away. But here is a catch – most likely nobody will start GRASS
to work with data provided by the demo project. Either they will start
GRASS to do some exercises in a training course / to follow a tutorial
(= download one of sample datasets, add some layer to the map view),
or to work with data they have to solve the analysis problem they are
facing (= create a new project from supplied data, import file, add it
to the map view, display warning about computational region in your
info bar, if imported data were vectors and not raster). If user
cancel
