More Location Fixes.

[Davide DB]

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.

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.

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

--------------------------

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150714/f3038faf/attachment-0001.html>