Location, location, location

[Linus Torvalds]

On Wed, Jul 15, 2015 at 6:38 AM, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
> I see the benefit of the autocomplete to create a new site with the same
> name as an existing site isn't so much that it saves a few keystrokes, but
> that it is explicitly either creating a new site or assigning a dive to an
> existing site.  It helps avoid confusion.

Not just confusion. It gets rid of special cases.

So the whole "make a new divesite" option is not *just* about not
having to type the dive site name in full.

I don't think the people who complain have really used the old
subsurface location model with the GPS information very much. Or if
you did use it, you didn't realize how subtle it was, and what kind of
odd internal tricks it did.

But the old code really worked very well. I can say that from having
used it by now on several hundred dives together with the companion
app in various forms (I have 286 dive site entries in my log).

So take it from me - the old divesite name editing really worked very
well. I've done it more than a few times.

And the new divesite model has so far been *worse* than the old one,
although I think Dirk and Tomaz's most recent model may finally change
that.

Now, as an example of the kind of logic we had for the divesite
editing, see this comment:

        // if we have a location and no GPS data, look up the GPS data;
        // but if the GPS data was intentionally cleared then don't

and that was in the days when you saw the GPS location and the name
together, so you could do things like:

 - pick a dive site name
 - finishing that filled in the gps text-filed *if* the dive didn't
have a GPS location already, and if the text field was empty
 - if you decided you didn't like that, you could just clear the gps
location afterwards, and it was right there and obvious

I'm not saying that the above is perfect, but I *am* saying that the
above was very flexible, and actually worked really quite well. There
was never any subtle issues: you would not lose GPS information, and
if you got added GPS information it was very clear and it was editable
right there without any special cases (no need to go into a "edit dive
site" mode etc).

And what's nice about the model is that it really works well even when
things go wrong. Pick the wrong dive site name because you are working
on a laptop (traveling, you know) with a touchpad on a boat? Or just
because you're a moron and picked the wrong name because you
mis-remembered it? Not a big deal. It's trivial to fix.  You could
just pick anotther name without changing the GPS location (because you
know the GPS location was right), _or_ you could just clear the GPS
location and pick another name and it would fill in the new GPS
location. Note how those special cases "just worked".

Now, what's *not* nice about that old model is that it was a major
pain in the ass to just handle multiple dives with the same dive site,
and wanting to edit them. And you couldn't add notes etc. So really,
the new model has the potential to be much better, but it needs to get
the basic editing cases right, and it needs to handle the above kind
of fat-fingering issues right without making it a big pain. "I picked
the wrong dive site name by mistake" shouldn't be a problem.

And that "I need to fix up a mistake" does actually require that when
you pick a different site, you have the explicit *option* between:

 - oops, when I fat-fingered and picked the wrong site, I also picked
the wrong GPS, so I need to overwrite that too, and pick the new site
with the GPS information from that site.

 - oops, when I fat-fingered and pick the wrong site, I actually had
the right GPS (because I had gotten it with the companion app), so
when I pick the right name I really need to make a *new* dive site
with the GPS information I have.

Notice how that was something you used to be able to do fairly
naturally? And that really was something that the new model did *not*
handle well at all. There was the "16 different cases" list that Dirk
listed a couple of days ago, and that I objected to. His sixteen cases
didn't even actually count the above as two cases, because the above
fat-fingering looks 100% the same to subsurface: we started out with a
divesite with both name and GPS, and we simply have two different end
results we want to have.

Also, the people who say that it's crazy to want to create a new dive
site when you already have a dive site with the same name have clearly
*never* used the companion app on a boat.

Seriously, if I go boat diving with the companion app, the "New dive
site" is the *only* thing I will ever do, unless I've been at that
site more than ten times or so ("Mala Pier") and I just know it's not
even worth it making another entry or I can validate it against the
google map satellite data some way. I want to have *at*least* three or
four different GPS fixes from the companion app before I start saying
"ok, this is the right GPS location".

Why? I've used the companion app enough that I know problems happen.
The boat moves and the gps location is off by a mile or two, or the
companion app doesn't get a GPS fix for an hour, the timezone was
wrong, yadda yadda. The companion app works very well, but anybody who
thinks it is perfect has clearly never used it. You really want to
double- and triple-check the results.

So on a boat dive in particular, you should basically always default
to "New dive site". Then, when you have five or six different entries
for the same dive site, you go in and check that they actually cluster
well, and hopefully some day there will be a management interface that
says "combine these divesites to one single divesite, and pick the GPS
location from _this_ divesite (or take the average of _these_ dives,
or whatever)"

So no, the people who say that "creating a new site when you already
have that site is crazy" are just wrong. You don't know what you're
talking about. That "pick a new site" is not just not crazy, it's a
*common* case.

But note how "create a new site" is not just about "I want several
fixes from the companion app". It's also how you fixed the
fat-fingering ("keep the GPS location, pick a new name") and it's also
how you handle the "ambiguous name" case when you notice that you have
divesites with the same name at different locations.

In other words: it gets rid of all the special cases. It makes the
*user* pick what is the sane thing to do, and it solves at least three
different problem cases.

And a sign of a good solution is exactly that it solves multiple
different problem cases. I really think that the screenshot Dirk
posted has the potential to be the *right* solultion for dive site
naming, and that "New site" is _integral_ to it being the right
solution.

                  Linus