More Location Fixes.

[Dirk Hohndel]

On Tue, Jul 14, 2015 at 03:10:30PM +0200, Davide DB wrote:
> On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> >
> > So that's 16 scenarios so far... who can think of more?
> >
> >
> Hi Dirk,
> Examples by Linus caught me off guard.
> At this point I really do not know what's the correct behavior.
> I thought we depict possible scenario more than one month ago but there we
> thought a different UI so we need to start again.

So there are two different UIs here.

One is when showing a dive. The other is when editing dive sites.
And regardless whether we love the little quick edit or not (that just
adds the ability to edit notes and description right from the dive view...
I'm not sure it's worth the amount of work that it currently absorbs but
Tomaz keeps telling me it's really easy), we need to cover the ability of
the user to make changes starting from the dive view, as that is how
existing users will use it (and that's certainly how I will use it and
Linus will use it). And like it or not, our preferences do matter a bit
here.

That's why I want to make sure we actually clearly define what happens
when the user is looking at a dive and making a change to the dive site.

> I think your scenarios are good.
> 
> Who remember what we agreed months ago and we wrote several times? Nobody!
> Me neither.

I think much of what we agreed upon was about the dive site management
mode. The one that is gone and has not been reimplemented, yet.

> E-mail it's the wrong tool for keeping track or deciding a complicate
> workflow with user and UI interaction.
> In the hope it will serve as a warning for the future :) We should really
> work on some shared sketch or even a classic sequence diagram and then use
> email to comment them but once decided we should stick to them and publish
> them somewhere for developers use.
> 
> My try.
> 
> BRANCH #ONE
> 
> 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
> 
> The dive will reference the dive site already there.
> 
> 
> BRANCH #TWO
> 
> 1. empty location field
> 1.1. no GPS data (so that means we had no dive site, I guess)
> 1.1.2. user types in name, doesn't pick one of the completions
> 
> The dive will use a new dive site with text typed in by the user.
> 
> BRANCH #THREE
> 
> 1. empty location field
> 1.2. GPS data (e.g. from Subsurface web service - dive site with no name)
> 1.2.1. user types in name, picks one of the completions
> 
> Use cases #3 is more complicated. I'll pass the baton to other users :) but
> in the meantime... first question:
> Has the completion chosen GPS data? Eventually can we assume it's the same?
> 
> Hence this branch is meaningless without splitting it in more 3 more
> branches:
> 
> BRANCH #FOUR
> 
> 1. empty location field
> 1.2. GPS data (e.g. from Subsurface web service - dive site with no name)
> 1.2.1. user types in name, picks one of the completions
> 1.2.1.1 completion has GPS data
> 1.2.1.1.1 completion GPS data fall within a certain range into the incoming
> GPS data
> 
> The dive will reference the dive site already there.
> 
> BRANCH #FIVE
> 
> 1. empty location field
> 1.2. GPS data (e.g. from Subsurface web service - dive site with no name)
> 1.2.1. user types in name, picks one of the completions
> 1.2.1.1 completion has GPS data
> 1.2.1.1.2 completion GPS is different from the incoming GPS data
> 
> Hummmm
> 
> BRANCH #SIX
> 
> 1. empty location field
> 1.2. GPS data (e.g. from Subsurface web service - dive site with no name)
> 1.2.1. user types in name, picks one of the completions
> 1.2.1.1 completion has not GPS data
> 
> The dive will reference the dive site already there and GPS data will be
> added.

Excellent

> BRANCH #SEVEN
> 
> 1. empty location field
> 1.2. GPS data (e.g. from Subsurface web service - dive site with no name)
> 1.2.2. user types in name, doesn't pick one of the completions
> 
> The dive will use a new dive site with text typed in by the user.
> One question arise here: even if the user choose a brand new name, should
> we check if GPS data are already there under a different dive site?
> (eventually giving him an alert... are you sure that you want to create a
> new dive site for something you already have?)

Yes, if we have another fix within 20m we should show that. Which tells me
that if you have GPS data and type something in, not only should we
auto-complete on name but we should ALSO list dives that are within 20m
(or maybe a little more) of that GPS fix. Which adds a whole list of other
cases here, doesn't it?

> --------------------------
> 
> I'll keep the use cases "2... existing text in the location field" for
> another email.

Good call.

I did notice that in all the cases above you forgot about the a)/b)
(accept/reject). In most cases that's kinda obvious (just discard).
And I think even in the cases where this would have created a new dive
site we just discard it.

For now I think the simplest logic would be to assume that all changes
made go away and we are exactly in the same state as before this edit
operation started.

> Maybe all of them are related to a dive site management scenarios rather
> than new dive being added.
> 
> Once we are set with the above cases I can rewrite them from scratch and I
> will tattoo them on my left cheek :)

I'd go with one of your cheeks that usually isn't on display.

/D