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. https://www.icsm.gov.au/sites/default/files/GMIWG%20Advisory%20on%20WGS%2084%20and%20Web%20Mapping%20%E2%80%93%2015%20June%202020.pdf -- 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 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. > > > _______________________________________________ > 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
