Hi,
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
Anna
Il sab 3 feb 2024, 05:34 Anna Petrášová via grass-dev <grass-dev@lists.osgeo.org> ha scritto:
Hi,
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
Do you think an interface to eodag library, to download sentinel and Landsat images for example, could be a topic for gsoc?
Anna
Best
Luca
On Sat, Feb 3, 2024 at 4:39 AM Luca Delucchi <lucadeluge@gmail.com> wrote:
Il sab 3 feb 2024, 05:34 Anna Petrášová via grass-dev <grass-dev@lists.osgeo.org> ha scritto:
Hi,
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
Do you think an interface to eodag library, to download sentinel and Landsat images for example, could be a topic for gsoc?
I suppose so. As long as somebody (you?) would mentor it, we can add it (including test of skills etc).
Anna
Best
Luca
That would be cool Luca! eodag allows you to download different EO datasets.
Do you think of a GSoC project idea to include eodag support for i.sentinel.download, i.landsat.download and i.modis.download or as a new module to download EO data in general? If you are willing to mentor, I can be your second… mainly to test and make annoying questions 
Vero
I sent the ideas page to OSGeo admins (the deadline is today), although I think we can keep adding topics. Please also fill out this form https://forms.gle/dZDYovvmhrQRah73A if you plan to mentor.
Thanks,
Anna
On Mon, Feb 5, 2024 at 7:33 AM Veronica Andreo <veroandreo@gmail.com> wrote:
That would be cool Luca! eodag allows you to download different EO datasets.
Do you think of a GSoC project idea to include eodag support for i.sentinel.download, i.landsat.download and i.modis.download or as a new module to download EO data in general? If you are willing to mentor, I can be your second… mainly to test and make annoying questions
Vero
On Mon, 5 Feb 2024 at 13:33, Veronica Andreo <veroandreo@gmail.com> wrote:
That would be cool Luca! eodag allows you to download different EO datasets.
Do you think of a GSoC project idea to include eodag support for i.sentinel.download, i.landsat.download and i.modis.download or as a new module to download EO data in general? If you are willing to mentor, I can be your second... mainly to test and make annoying questions
Yes, the idea could be to add it to i.*.download, I was also thinking
of having a common library in grass python library as an interface to
eodag, but I'm not sure if it makes sense...
However I tried to log to the wiki and I'm not able, and password
recover also didn't work
Vero
--
ciao
Luca
www.lucadelu.org
On Tue, Feb 6, 2024 at 12:11 AM Luca Delucchi via grass-dev
<grass-dev@lists.osgeo.org> wrote:
On Mon, 5 Feb 2024 at 13:33, Veronica Andreo <veroandreo@gmail.com> wrote:
> That would be cool Luca! eodag allows you to download different EO datasets.
>
> Do you think of a GSoC project idea to include eodag support for i.sentinel.download, i.landsat.download and i.modis.download or as a new module to download EO data in general? If you are willing to mentor, I can be your second... mainly to test and make annoying questions
>Yes, the idea could be to add it to i.*.download, I was also thinking
of having a common library in grass python library as an interface to
eodag, but I'm not sure if it makes sense...However I tried to log to the wiki and I'm not able, and password
recover also didn't work
Regina has updated the GRASS Wiki again and we have done a series of
tests, fixing plugins and such.
Please try again, now with your OSGeo-LDAP account.
A "user merge" may come up. Let me know if it gets blocked so that I can assist.
Markus
--
Markus Neteler, PhD
https://www.mundialis.de - company
https://grass.osgeo.org - FOSS
https://neteler.org - freelancing & blog
On Mon, 12 Feb 2024 at 18:08, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Feb 6, 2024 at 12:11 AM Luca Delucchi via grass-dev
<grass-dev@lists.osgeo.org> wrote:
> On Mon, 5 Feb 2024 at 13:33, Veronica Andreo <veroandreo@gmail.com> wrote:
> > That would be cool Luca! eodag allows you to download different EO datasets.
> >
> > Do you think of a GSoC project idea to include eodag support for i.sentinel.download, i.landsat.download and i.modis.download or as a new module to download EO data in general? If you are willing to mentor, I can be your second... mainly to test and make annoying questions
> >
>
> Yes, the idea could be to add it to i.*.download, I was also thinking
> of having a common library in grass python library as an interface to
> eodag, but I'm not sure if it makes sense...
>
> However I tried to log to the wiki and I'm not able, and password
> recover also didn't workRegina has updated the GRASS Wiki again and we have done a series of
tests, fixing plugins and such.Please try again, now with your OSGeo-LDAP account.
A "user merge" may come up. Let me know if it gets blocked so that I can assist.
It worked properly now, I added the EODAG proposal, I didn't add any
test yet but I'll hope to do it ASAP
Markus
----
ciao
Luca
www.lucadelu.org
Hello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.
Thanks,
Māris.
sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev (<grass-dev@lists.osgeo.org>) rakstīja:
Hi,
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024It's not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
Anna
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Maris,
Would you mind sharing more details on this idea? I’m afraid I was not able to attend/hear the discussion about this welcome screen in Prague. I hope though we do not end up with a new startup screen. It took so much time to reach an agreement and finally remove it.
Vero
Dra. Verónica Andreo
Investigadora Adjunta de CONICET
Instituto Gulich (CONAE - UNC)
Centro Espacial Teófilo Tabanera (CETT)
Falda del Cañete - Córdoba, Argentina
+54 3547 400000 int. 1153
https://veroandreo.gitlab.io/
I agree with Vero. I am not sure we had enough time to evaluate the current state yet. I don’t remember the details of our discussions, so if you provide a description of what exactly you mean, that would be helpful. In terms of a GSoC project, the main issue I see is that the mentors need to provide clear instructions on what the student should do, especially for this case, and we apparently don’t have a consensus here. So I would be willing to mentor it only as long as we develop a plan ahead of time we can all agree on. Given the past experience, I am somewhat skeptical we can all agree on something:) But I’ll try to be open to ideas!
Dra. Verónica Andreo
Investigadora Adjunta de CONICET
Instituto Gulich (CONAE - UNC)
Centro Espacial Teófilo Tabanera (CETT)
Falda del Cañete - Córdoba, Argentina
+54 3547 400000 int. 1153
https://veroandreo.gitlab.io/
Personally I like the new interface, but Maris’ proposal for wizards to create new projects sounds helpful. Rather than a startup screen that stalls users, there could be temporary icons floating on the map canvas that prompt users to create a new project in different ways. Would disappear as soon as data is added to the map. A helpful guide/shortcut that users could choose to ignore. Still, any startup hints might be annoying like Clippy the infamous paperclip. I can find an example from other software if the idea is of interest. Or the logo that pops up when you start GRASS could have buttons for creating new projects; if a user doesn’t click on them while GRASS is starting, then it will open in the default / previous project.
Best, Brendan
Dra. Verónica Andreo
Investigadora Adjunta de CONICET
Instituto Gulich (CONAE - UNC)
Centro Espacial Teófilo Tabanera (CETT)
Falda del Cañete - Córdoba, Argentina
+54 3547 400000 int. 1153
https://veroandreo.gitlab.io/
I believe the welcome screen would most likely be dismissed. The other possible solutions Brendan brings up may be difficult to implement with wxpython. But we tried to do something similar with Linda using the info bar, which shows info/buttons for first-time users. She tested that with mixed results, people often just dismissed it. But I think it could be further refined. For example, maybe we could move it to map display to make it more prominent. The other direction is to better detect when users are doing something likely wrong (import projected data to default project) and then suggest alternatives.
Dra. Verónica Andreo
Investigadora Adjunta de CONICET
Instituto Gulich (CONAE - UNC)
Centro Espacial Teófilo Tabanera (CETT)
Falda del Cañete - Córdoba, Argentina
+54 3547 400000 int. 1153
https://veroandreo.gitlab.io/
Seeing the new startup screen idea description, the “Proposals for a new GRASS GIS startup mechanism” wiki page on Trac wiki might be a good read:
https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup
Dra. Verónica Andreo
Investigadora Adjunta de CONICET
Instituto Gulich (CONAE - UNC)
Centro Espacial Teófilo Tabanera (CETT)
Falda del Cañete - Córdoba, Argentina
+54 3547 400000 int. 1153
https://veroandreo.gitlab.io/
Hello Māris,
just to add some other info, we did several surveys among GRASS users about first-time user experience with Anna, Martin and Vashek and we also tested old and new startup mechanisms in a real environment within the usability testing - you can have a look at our article: https://www.mdpi.com/2220-9964/12/9/376.
As Anna has already written, the results of usability testing were indeed mixed but I would like to emphasize one thing - most of the usability participants (first-time users) said to me that they simply expect they will be directly redirected to the main software window where they can start working without knowing anything about the software. The current “info bar” solution goes in that direction and although I have to admit that it has flaws there are ways how to make it better and Anna has already written some points.
I think it would be nice to focus on how to make the current solution better (it is definitely doable and even desirable) and not go back to some alternatives to the old solution.
Above that, it would be extremely time-consuming to implement any dialog wizards and at the same time the impact of that “dialog” solution is very uncertain - one important thing we also learned from surveys and discussions inside/outside the community is that the one good generally acceptable solution simply does not exist here - it will always be a compromise.
Just my two cents.
Linda
---------- Původní e-mail ----------
Od: Maris Nartiss via grass-dev grass-dev@lists.osgeo.org
Komu: Anna Petrášová kratochanna@gmail.com, Veronica Andreo veroandreo@gmail.com
Kopie: GRASS-dev grass-dev@lists.osgeo.org
Datum: 15. 2. 2024 13:04:24
Předmět: Re: [GRASS-dev] GSoC Ideas
Hello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.Thanks,
Māris.sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev (grass-dev@lists.osgeo.org) rakstīja:Hi,
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
Anna
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
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
cancels the wizard, just fine. Let him enjoy the demo project and
display first time screen also on the next startup iff there is no
project with data in the GISDBASE. This would not interfere with a
big, fat warning if someone tries to import external data into sample
projects (NC, Spearfish, ...) or any other enhancements that could be
done.
Huh, I think I answered most of points from previous emails (except
going into details of potential architecture (thus Anna for wxPython
expertise) or user friendliness (thus Vero)). Thank you to everyone
who read this far and sorry for all unintentional fuss I caused.
Probably Linda you are right – it is too ambitious for an experimental
project that might get tossed away at the end. I see that Anna has
already removed the idea from the wiki, most likely for good. Do not
restore it, let it be so. We can return to this idea at any point
later if we feel need for it. I have plenty to do to fix pointer
juggling bugs in the new module I have almost finished (anisotropic
smoothing).
Māris.
piektd., 2024. g. 16. febr., plkst. 10:41 — lietotājs Linda Kladivová
(<L.Kladivova@seznam.cz>) rakstīja:
Hello Māris,
just to add some other info, we did several surveys among GRASS users about first-time user experience with Anna, Martin and Vashek and we also tested old and new startup mechanisms in a real environment within the usability testing - you can have a look at our article: https://www.mdpi.com/2220-9964/12/9/376.
As Anna has already written, the results of usability testing were indeed mixed but I would like to emphasize one thing - most of the usability participants (first-time users) said to me that they simply expect they will be directly redirected to the main software window where they can start working without knowing anything about the software. The current "info bar" solution goes in that direction and although I have to admit that it has flaws there are ways how to make it better and Anna has already written some points.
I think it would be nice to focus on how to make the current solution better (it is definitely doable and even desirable) and not go back to some alternatives to the old solution.
Above that, it would be extremely time-consuming to implement any dialog wizards and at the same time the impact of that "dialog" solution is very uncertain - one important thing we also learned from surveys and discussions inside/outside the community is that the one good generally acceptable solution simply does not exist here - it will always be a compromise.Just my two cents.
Linda---------- Původní e-mail ----------
Od: Maris Nartiss via grass-dev <grass-dev@lists.osgeo.org>
Komu: Anna Petrášová <kratochanna@gmail.com>, Veronica Andreo <veroandreo@gmail.com>
Kopie: GRASS-dev <grass-dev@lists.osgeo.org>
Datum: 15. 2. 2024 13:04:24
Předmět: Re: [GRASS-dev] GSoC IdeasHello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.Thanks,
Māris.sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev (<grass-dev@lists.osgeo.org>) rakstīja:
>
> Hi,
>
> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
>
> Anna
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi all, Johnny Come Lately here. Like and subscribe.
This thread pretty much reenacted the long discussion in Prague last June. The only conclusion at the time was for this proposal to not jeopardise the work done on the new GUI. It seems that Maris is sticking to that. I hope this proposal can still take shape at some point, if nothing else to understand its implications.
On a broader perspective, there is an obvious tension here between ease-of-use and correctness-of-use. A ready-to-use GUI will always be the preferred choice of users, both novice or seasoned (just give me the damn CLI!). But the educational aspect of GRASS should not be disregarded either. As an (other) example of how this tension has concrete implications, I leave below a link to the document by the Australia/New Zealand authority trying to dissuade communities like this one from using the WGS84 datum ensemble.
Best.
--
Luís
Sent with Proton Mail secure email.
On Friday, 16 February 2024 at 19:42, Maris Nartiss via grass-dev <grass-dev@lists.osgeo.org> wrote:
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 agreeon 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
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
cancels the wizard, just fine. Let him enjoy the demo project and
display first time screen also on the next startup iff there is no
project with data in the GISDBASE. This would not interfere with a
big, fat warning if someone tries to import external data into sample
projects (NC, Spearfish, ...) or any other enhancements that could be
done.Huh, I think I answered most of points from previous emails (except
going into details of potential architecture (thus Anna for wxPython
expertise) or user friendliness (thus Vero)). Thank you to everyone
who read this far and sorry for all unintentional fuss I caused.
Probably Linda you are right – it is too ambitious for an experimental
project that might get tossed away at the end. I see that Anna has
already removed the idea from the wiki, most likely for good. Do not
restore it, let it be so. We can return to this idea at any point
later if we feel need for it. I have plenty to do to fix pointer
juggling bugs in the new module I have almost finished (anisotropic
smoothing).
Māris._______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Thanks Maris for the long reply, see below
On Fri, Feb 16, 2024 at 1:42 PM Maris Nartiss <maris.gis@gmail.com> wrote:
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.
Well, we have been discussing this topic for a loong time, so you should have expected more passionate responses…
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.
Sure.
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.
If I invest my time into GSoC, I want the result to be merged. So personally, I am not going to mentor an “experimental” project. We have done this before, students didn’t stay with the project and we had unusable results at the end.
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.
Generally I agree.
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
continue exploring alternatives and thus was the GSOC proposal.
I share the concerns, I personally just don’t think any welcome screen or wizard is going to address them. They would likely be dismissed and then we are in the same situation. We have had welcome screen and wizard for a long time and that was a stumbling block for users. I don’t think simply redesigning it helps. We should think of some other ways, I don’t have a solution now, if we have, we can have a GSoC project.
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.
Could you please create an issue for this?
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).
I think Vashek’s point was to gently remind you there has been a lot of discussion going on in the past, not to resurrect one of those ideas:)
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
cancels the wizard, just fine. Let him enjoy the demo project and
display first time screen also on the next startup iff there is no
project with data in the GISDBASE. This would not interfere with a
big, fat warning if someone tries to import external data into sample
projects (NC, Spearfish, …) or any other enhancements that could be
done.
I agree with a lot of points you are making but I guess I still don’t understand exactly what your suggestion is and how it would make things better and for whom…
Huh, I think I answered most of points from previous emails (except
going into details of potential architecture (thus Anna for wxPython
expertise) or user friendliness (thus Vero)). Thank you to everyone
who read this far and sorry for all unintentional fuss I caused.
Probably Linda you are right – it is too ambitious for an experimental
project that might get tossed away at the end. I see that Anna has
already removed the idea from the wiki, most likely for good. Do not
restore it, let it be so. We can return to this idea at any point
later if we feel need for it. I have plenty to do to fix pointer
juggling bugs in the new module I have almost finished (anisotropic
smoothing).
Māris.piektd., 2024. g. 16. febr., plkst. 10:41 — lietotājs Linda Kladivová
(<L.Kladivova@seznam.cz>) rakstīja:Hello Māris,
just to add some other info, we did several surveys among GRASS users about first-time user experience with Anna, Martin and Vashek and we also tested old and new startup mechanisms in a real environment within the usability testing - you can have a look at our article: https://www.mdpi.com/2220-9964/12/9/376.
As Anna has already written, the results of usability testing were indeed mixed but I would like to emphasize one thing - most of the usability participants (first-time users) said to me that they simply expect they will be directly redirected to the main software window where they can start working without knowing anything about the software. The current “info bar” solution goes in that direction and although I have to admit that it has flaws there are ways how to make it better and Anna has already written some points.
I think it would be nice to focus on how to make the current solution better (it is definitely doable and even desirable) and not go back to some alternatives to the old solution.
Above that, it would be extremely time-consuming to implement any dialog wizards and at the same time the impact of that “dialog” solution is very uncertain - one important thing we also learned from surveys and discussions inside/outside the community is that the one good generally acceptable solution simply does not exist here - it will always be a compromise.Just my two cents.
Linda---------- Původní e-mail ----------
Od: Maris Nartiss via grass-dev <grass-dev@lists.osgeo.org>
Komu: Anna Petrášová <kratochanna@gmail.com>, Veronica Andreo <veroandreo@gmail.com>
Kopie: GRASS-dev <grass-dev@lists.osgeo.org>
Datum: 15. 2. 2024 13:04:24
Předmět: Re: [GRASS-dev] GSoC IdeasHello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.Thanks,
Māris.sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev (<grass-dev@lists.osgeo.org>) rakstīja:Hi,
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
Anna
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <grass-dev@lists.osgeo.org> napsal:
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
I add a new topic related to space-time datasets and Data Catalog [1]. Martin
Hi,
so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <grass-dev@lists.osgeo.org> napsal:
I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
It’s not updated yet, I plan to add more topics. If you want to mentor a topic, we can discuss it here.
I add a new topic related to space-time datasets and Data Catalog [1]. Martin
Thanks for adding the topic, please also include a test of skills and at least for now assign yourself as a mentor, I can be a co-mentor.
Anna