More Location Fixes.

[Linus Torvalds]

On Mon, Jul 13, 2015 at 4:42 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 1. empty location field
> 1.1. no GPS data (so that means we had no dive site, I guess)
> 1.1.1, user types in name, picks one of the completions
> 1.1.2. user types in name, doesn't pick one of the completions
> ...

So quite frankly, I think the fact that 1.1.1 and 1.1.2 might be
different is a big design mistake.

I really think the very fact that you ask "what should. the semantics
be" ends up being a sign that the interface is bad. Because even if we
pick semantics that everybody agrees on, what does it mean that we had
to ask that question? Really?

To me, it means that any new user who wasn't part of the discussion is
clearly *not* going to find whatever semantics we picked - whether we
all agree on them or not - to be intuitive.

So let me suggest something that is at least easier to explain than
your "16 scenarios so far".

I suggest that we really have two VERY CLEARLY separate cases:

 - the user wants to type in the dive site name (with name completion,
the same way we have text completion for buddy names etc etc)

 - the user wants to pick a previous dive site that he/she has dove
many times before.

and I think we should keep those two cases separate, and not ever mix them up.

So the two cases are:

 (1) when the user types in a dive site name, whether it is a
"completion" or not is entirely immaterial - all it does is set the
name. Nothing else.

     And by definition, since the user didn't pick an old dive site,
the newly created dive site is a new unique dive site. This never
changes any other dive sites, and it never changes the GPS coordinates
fro this dive. You *only* edited the name for that dive.

 (2) when the user picks a dive site from a list, the user picks
*that* dive site (and that GPS information). We throw the old dive
site away.

     Now, we *might* want to warn and ask for confirmation if "throw
the old dive site away" means that we actually lose the GPS
information. The test for that would basically be: (a) does the dive
site we throw away have GPS information, and (b) was this the last
user of that dive site, so that it now is "orphan".

But the important part - for me - is that these two choices are very
*clear* and obvious. I think the thing I really really hate about the
current dive site model is how that text entry field we have now does
*both*.

So I think *that* is the real bug we have now. The
text-field/drag-down that mixes old dives sites with new is wrong. It
mixes up those two choices, which means that any semantics we give it
is automatically wrong and confusing.

In other words, I really think that the "Location entry" text field
should _just_ be a text field. Yes, it autocompletes, but even when it
auto-completes it does nothing else. So it would be (1).

And I think the button to the right of it is what should open a "list
of pre-existing dive sites". So we'd have a clearly separate way to
actually pick old dive sites, and this would be (2).

So now there is clear separation, and no question about semantics. Add
a tool-tip thing maybe to *explain* it, so that when a person hovers
over the button on the right it says "pick an existing dive site and
its GPS information", and when the user hovers over the divemaster
text-field it says "edit the name of the dive for this dive, creating
a new dive site".

So the advantage of this is that it's fairly easy to explain, and it
supports very naturally the whole notion of

 (a) diving a lot at the same sites (perhaps a local one) for when you
do *not* tend to use the companion app to get GPS locations (since why
would you: using the companion app every time you dive at the Yellow
House would just be crazy)

 (b) you use the companion app, and you basically start off assuming
that you'll just create new dive sites, but you may still want to
auto-complete the name, and the workflow should *not* behave
differently whether you download the GPS location first or last.

So note how there are no "16 cases". There are two fairly simple
cases, and they have clearly separate GUI elements. So there's never
any mix-up between the two.

Hmm?

                         Linus