The old startup screen is still used when the last used mapset is not in usable state

[lindakarlovska]

The Issue works as a discussion for how to start GRASS GIS when the last mapset is not in a usable state.
So far, we have worked with two proposals of GRASS GIS start for common users (we do not talk about first-time users, here the situation is complete - GRASS offers demolocation with first-time info bars for first-time users).

Describe the solution you'd like
We would like to entirely remove the old startup screen.

Describe alternatives you've considered
So far, we were thinking with Vashek about two options for how to proceed:

Proposal 1:

Proposal 2:

Additional context
This issue has been already a bit discussed in #1208.

here is the current conversation:

HuidaeCho
@lindakladivova @wenzeslaus I think I'm missing something here. What is the rationale behind all this workflow for creating an unrequested location and mapset? If a last used mapset is in an unusable state (not clear what it means... because another user is already using it? Or has GRASS crashed before leaving the mapset in an "unusable" and unfixable state?), shouldn't we try to fix the mapset instead of creating a new default location and mapset silently? What if the default mapset in the default location becomes "unusable"? Create yet another default mapset 2 in that same default location or a default mapset in a new default location 2? And keep creating a new mapset whenever the last used default mapset becomes unusable?

The last step in yellow is also unclear. Does it create a new default location first and then what does it suggest to do in "To continue..."? If the user continues, what happens? If not, then what? Continue to switch to the last used mapset (is it possible now?)? Not continue to start in the just created default mapset?

Other than the workflow, moving code for non-GUI functionalities to grass.app looks fine. BTW, grass.app sounds too general. What is this submodule mainly for? If for the "main GRASS GIS executable" (startup script?), I think grass.startup or grass.init would be more appropriate.

lindakladivova
Well, we are still not sure how to solve the case when the last mapset is not in the usable state. The notion is that the behavior should be consistent. In this proposal, if the last used mapset is not in the usable state (yes, GRASS crashed or another user is using it) we use the default location (demolocation) as workarounds in order to not use the old startup screen anymore. The GRASS GIS offers the default location and informs the user about that in the Info Bar which has the same form as the one used newly for every first-time user when starting GRASS. The text of the Info Bar is in the proposal in a yellow box. It has a character of advice because the user may be surprised why he is in demolocation, so the Info Bar explains why and advises what to do next.

As you have noted, there can be a case when the default mapset in the default location is in the usable state.. In this case, we can create the user mapset because we need "some" mapset, and show the Info Bar to the user as well.

Let's discuss about it :-) I believe we can come up with a better solution. I also created a second a bit more complex proposal which takes into consideration the last used location.

However, the disadvantage of the second proposal is that the GRASS GIS startup process would not be consistent. The first solution is always consistent - boot in the demolocation in each non-standard situation and provide the same message in the Info Bar. Another thing about the Proposal 2 is that it presents a new concept, which assumes that the PERMANENT mapset is some kind of default mapset. This would mean incorporating this idea into other segments of GRASS. For example, in the Data Catalog context menu, there should be a possibility to switch to location (its PERMANENT) from the location node.

HuidaeCho
My point is when a mapset becomes unusable, we should advise users how to fix it, not deviate them from their intended workflow. If GRASS crashed and the last used mapset became not startable because of some garbage, most of the case, I think we can fix it programmatically. If not (e.g, broken metadata files let's say), ideally, GRASS should be able to detect which part of metadata is broken and ask the user what's missing and fix it.

If someone else is using the last used mapset, we should give the user options with a warning that someone is using the mapset: 1) just don't start GRASS (maybe, with an email notification when the current user leaves, but it would require a whole different discussion and architecture) or 2) let the user create a new mapset in the last used location (because the user will be able to access data in the last used mapset by tweaking the search path) with her/his choice of a mapset name. In any case, when GRASS supports the last used mapset when no mapset is specified, that means we want to put them in the last used mapset or at least in the last used location, not in a world-wide latlong location in any case. That would be a big surprise for me when I assume that I would fall in the last used mapset in a certain projection (location). Starting in a world location may be fine when there are no locations at all, but still I would ask them if they want it or some other projection.

Trying to create a new default location or mapset can be very tricky because, again, we may be trapped in a loop where we have to keep creating a new mapset or location when the previous default mapset becomes unusable. In the second proposal, I would say the PERMANENT mapset is not meant to be a default mapset. I just feel like it's not a working mapset, but it's more for storing original data in a clean state before any analysis in other mapsets. Maybe, it's just me.

Now, are you planning to implement all this workflow only in the GUI startup? Or is it going to be part of the CLI as well to be consistent? Also, are you going to ask the user location or mapset names before creating them?

[lindakarlovska]

@HuidaeCho Ok, as I get it right, you like much more the second proposal. It makes sense but I would note that the state of Data Catalog is now quite straightforward, so it is very easy to create a new location, add a new database etc... - therefore, from my point of view, it is not a big surprise and problem to the user when he will be redirected to the demolocation. But on the other hand, we should try to minimize the number of cases when it happens, I agree with that.

As I remember, this solution was planned for GUI, because we mainly wanted to solve the problem of the old startup screen.

We had the idea that the mapset will be named according to the user name (if not possible to use PERMANENT). We already used this concept - after GSoC the "user" mapset was the part of demolocation. However, in surveys, some people perceived it too confusing so now there is only PERMANENT mapset in demolocation.

Maybe, we will need some startup screen anyway. We wanted to avoid it, but I am also a bit afraid about that loop you have described - keep creating a new mapset or location when the previous default mapset becomes unusable...

What @wenzeslaus think? Do you have any ideas?

[HuidaeCho]

@lindakladivova Please enlighten me what is wrong with the current startup. I think we have to start from there. Do you want to eliminate the barrier between locations and mapsets altogether for casual users (like how the current data catalog works)? Then, why? To attract more non-GRASS users who are hesitant to adopt a new "weird" GRASS paradigm because it's not familiar to them?

[lindakarlovska]

@HuidaeCho Yes, partly. I would like GRASS to be more user-friendly.

We have three different situations now:

1. Startup for first-time user
Demolocation and info bar are displayed. No startup screen occurs.

2. Startup in last used mapset if is in the usable state. No startup screen occurs.

3. The last used mapset is not in the usable state - the old startup screen still appears in this special case.

We would like to solve this special case and remove the startup screen - and the aim of our discussion is how to do it, I would prefer not to create another startup screen, I like the way without it...

[HuidaeCho]

@lindakladivova Thanks for the summary. For case 2, we don't have any problems. For case 1... Let's say students share a lab computer. One student has started GRASS once. Other students want to use the same GRASS database location, but they start GRASS for the first time from their account. Windows doesn't allow multiple remote logins, but UN*X does. It becomes case 3 in UN*X now if the first user is using the same mapset, if you agree? If the first user is not using the same mapset, is it case 1 (because it's the first time run from this account, preferred) or case 2 (another user's last used mapset, not preferred because we don't care about other users' last used mapset)? Or they can choose a new GRASS database location to make it our intended case 1 (first time with no locations). So either way, we didn't add any more cases here. It's just more complicated.

For case 3, I would like to create to a new mapset under the last used location always. Mapset name? Either ask the user or last_used_mapset-username. This "-username" suffix gives a hint to other users that it's not for them and we can only hope that they don't use it. What if they still try to use other user's dedicated mapsets (mapset-not_your_username)? Well... stop them and force them to use just "mapset" or create their own dedicated "mapset-username" in case "mapset" is "unusable"? Just don't allow any user in other user's own mapset. Again, this is still a lot of checks and can be problematic in terms of permissions later.

OR, maybe, create a new mapset in the last used location, but add an input textbox where a mapset is in the data catalog so they can type one themselves. Warning message why they need to do it above the catalog of course.

I have another question. Why do you prefer not to create another startup screen? Why do you try to not ask where to start? Is a startup screen an evil? If so, isn't it a necessary evil?

[lindakarlovska]

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)
You suggest to create a new mapset in the last used location, but add an input textbox. But there is another situation, the last used location can be deleted, what to do then?
We can use the concept of the last used location, and thus reduce the number of cases when the startup screen appears, but we probably won't get rid of the startup screen completely.

My point is that even though I remember myself when I started with GRASS at school, seeing just the startup screen first without any notion of how the software itself looks like - it was a nightmare for me. I think we agree on that. :-) In the current solution, this "nightmare" can still happen even to a completely new user (student at school) since GRASS could be used by another student earlier.

But maybe something like Moritz's proposal could be done here: https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#ProposalB1Moritz:Openintoapredefinedlat-longlocationbutgiveinformationmessage . We could boot into the demolocation (into the PERMANENT mapset or user mapset, depending on what is available, as we need a mapset to boot into), but show the user a startup screen in front of the software, which will be similar to the one we already have - allowing users to open or create a new environment. But at the same time, if he does not know what to do, he will be able to click and start in demolocation. @HuidaeCho What do you think about that?

@landam Won't you join the discussion too?

[marisn]

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.
If first time user friendliness is the target, bring in Clippy style wizard helping to make right choice.

[lindakarlovska]

@marisn Yes, dropping the user into a random location/mapset is evil, but I tried to explain properly in Info Bar why it is like that. And according to the second survey, it helps. I think people want to see some data - they suppose to see a map... not startup screen where they stuck. So, I think that now we lead the first-time user well (or at least better than before).

But I agree that the use of demolocation as a workaround for every user when the last used mapset is not in a usable state is not a good solution...

BTW, by Clippy wizard, do you mean something like Info Bar for first-time user but not as a part of demolocation but the part of the old startup screen and Location Wizard? I was also thinking about some help in Location Wizard because getting through the Location Wizard is probably the most difficult step the first-time user makes. (And almost no one uses other options in LW just the first one).

[petrasovaa]

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.

I am not sure if you used master branch for past couple months, if not, I suggest to test it to see how the start up looks like now. The workflow is now that you get into last used location, and in if you want to change it, there is data catalog right in front of you and you just switch the mapset from there. Data catalog basically serves here as startup screen, but is much better. I believe the workflow is much easier for both new and old users. It brings some new questions (this issue), but I don't think it's such a big deal.

[HuidaeCho]

First, I think this is a very important question. Can we even detect if a mapset is being used by someone else? Do we have a such mechanism?

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)
You suggest to create a new mapset in the last used location, but add an input textbox. But there is another situation, the last used location can be deleted, what to do then?

If the last used location is deleted, we should prompt the user and ask her what she wants to do instead of dropping her in a random location.

We can use the concept of the last used location, and thus reduce the number of cases when the startup screen appears, but we probably won't get rid of the startup screen completely.

I don't really think that the old startup was a major reason for user unfriendliness. Even commercial ArcGIS Pro has a startup screen. IMO, it is more of the concept of SRS-based locations/mapsets, the CLI nature of GRASS, and less appealing (non-native?) look of GUI that push back beginner users. Eliminating the startup wouldn't fix any of these issues until we change the architecture of data storage, which itself is a huge project and breaks backward compatibility.

My point is that even though I remember myself when I started with GRASS at school, seeing just the startup screen first without any notion of how the software itself looks like - it was a nightmare for me. I think we agree on that. :-) In the current solution, this "nightmare" can still happen even to a completely new user (student at school) since GRASS could be used by another student earlier.

I would say, going through the initial startup (including SRS selection) could be a "nightmare" for many novice users (not just not being able to see what it looks like), but that initial process is actually quite useful to remind them that the data structure of GRASS is different from other GIS systems. If we just put them in whatever default location we (developers) chose, it can give the very wrong hint and impression that GRASS just works no matter what projections your data is in. That's just wrong and they can easily fall into a lot of mysterious traps when they try to mix data from different projections (e.g., import data in a non-compatible projection). Isn't that more evil than guiding them through the right SRS selection from the very beginning?

[HuidaeCho]

@HuidaeCho You are right, Huidae. I'm thinking about different variants, but somehow I can't think of the possibility that the startup screen would be completely removed. It is probably a necessary evil :-)

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.
If first time user friendliness is the target, bring in Clippy style wizard helping to make right choice.

I totally agree with you.

[HuidaeCho]

IMHO evil is dropping user into a random location/mapset. Locations are tightly linked to SRS and thus such approach would promote users to just work with whatever SRS got chosen by a chance. Yes, the old startup screen wasn't easy to understand for first timers. Still the new approach gives nothing for experienced users like me – first thing I do on start up is to change location/mapset thus removing any advantages of skipping startup screen.

I am not sure if you used master branch for past couple months, if not, I suggest to test it to see how the start up looks like now. The workflow is now that you get into last used location, and in if you want to change it, there is data catalog right in front of you and you just switch the mapset from there. Data catalog basically serves here as startup screen, but is much better. I believe the workflow is much easier for both new and old users. It brings some new questions (this issue), but I don't think it's such a big deal.

I've been using the new GUI workflow. First, I was confused where I'm in because I have a long list of locations and mapsets, but overall, it works fine for me.

I just don't believe that it's possible to completely eliminate some sort of a startup or a popup over the default map display. At some point if the last used mapset or a fallback mapset is unusable, we have to ask. Doing more than that (e.g., creating another default mapset or creating a new user mapset silently) just makes things worse. I don't want GRASS to create a bunch of "default" mapsets for me, which I'll have to clean up later.

So.. again, what is the definition of a "unusable" mapset and how can we detect it? Depending on this definition, we may have different solutions.

[HuidaeCho]

Actually, isn't this issue this simple?

1. last used mapset usable => open it
2. last used mapset unusable => open the mapset creation dialog (the last used location by default)
3. last used location unusable => open the location creation dialog

Cases 2 and 3 both above the map display with a world map if we want to show something? But I don't really think that's any useful when the user is asked to create a new mapset or location.