More Location Fixes.

[Rick Walsh]

Happy Bastille day all,

On 14 Jul 2015 11:10 pm, "Davide DB" <dbdavide at gmail.com> 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.
> I think your scenarios are good.
>
> I'm really sorry for Tomaz. I did not mean to waste his time.
>
> Who remember what we agreed months ago and we wrote several times?
Nobody! Me neither.
> 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.

I mostly agree with how you think the cases should be handled. And
definitely agree with the objective of determining and agreeing on the best
method.

I've added a few comments.

>
> 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:

If the dive already has gps data, I can't see the value of autocompleting
the name based on other names,  unless the options are limited to sites at
about the same location, or sites that don't yet have coordinates. If the
user types anything else, it should be a new site.  It really doesn't
matter that's there's another site called House Reef or Blue Hole; it's
still a different site.

>
> 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.

Of course. The question is do we want to use the old or new gps coordinates
for the site?

>
> 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

I don't think the auto-prompt should include sites with existing gps data
further than x m from the new gps coordinates.

>
> 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.
>
> 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?)

As I said above, I think the 'alert' should be that existing nearby sites
show in the prompt, before a name is selected.

>
> --------------------------
>
> I'll keep the use cases "2... existing text in the location field" for
another email.
> 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 :)
>
> --
> Davide
> https://vimeo.com/bocio/videos
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150714/ce498732/attachment.html>