Dive site management on daily build 4.4.2.669

[Davide DB]

l 10/giu/2015 17:07, "Dirk Hohndel" <dirk at hohndel.org> ha scritto:

>
> > In the V3 current version I download some dives and by default they
> > have no location set. They are completely blank because right now ALL
> > data about location are under the dive site management: Location name,
> > gps data are all part od the dive site management so again what's the
> > meaning  working with a pile of unknown dives (no name no location). I
> > understand that the software is capable of but it seems just a gimmick
> > to me.
>
> So what you perceive as a gimmick is that you now can't just set a "name"
> for the dive, you have to go into the dive site management screen to do
> so? Is that your concern?
> Sorry if I'm slow on the uptake. I need more coffee :-)
>

Ok you bought me.  We have dives without dive sites :)
What I'm saying is that the new V3 enforce use of dive sites by desgin:

#1 The V2 > V3 import process will extract all possible dive sites
contained in the XML file.
#2 In spite of the V2 UI, current V3 UI have all location related
fields into the dive site panel. Moreover, even the Location name is a
dropbox (containing dive sites) hence it's difficult thinking of a
user who slip away from this logic.
#3 please, see below



But I agree with you that if I import my dives and I never touch the
location name I can avoid having dive sites.


> > The first approach was to use the location dropdown to browse dives.
> > We were never sure if we were editing a dive setting a location or
> > just browsing dives. They though to browse divesites but they were
> > actually changing location to a dive site...
> > Marble globe sometimes bolt at the minimum zoom and sometime loses the
> > location point.  I was not able to record a reproducible sequence.
> > From there a nightmare :)
>
> :-(

During this sort of blind test (actually I explained them the new dive
site feature improvement but I left them in fornt of the UI) they (and
me too) were attracted from that gorgeous dropdown on the notes panel
:)
Even knowing that to change current dive you click on the dive list,
our eyes were drawn upwards on the dropbox.
Given that actions on that control are very important I would avoid it.


> a label that is editable, I assume?

Not really. See below

>
> So let's see:
> - location editbox/label is empty, user picks edit
>   we switch to dive site management with empty fields, there is a drop
>   down there in which user can pick a dive site and a "pick for dive"
>   button or the user can fill out the data she wishes to fill out for that
>   dive (including a name) and "save divesite" and this is picked for the
>   current dive as well

Perfect.

Basically, in the same panel you can choose a dive site form your
database or you can add a new one. Two operations in the same panel.

My only suggestion would be to not use an editable textbox but just a label.

> - location editbox/label has a name in it, user picks edit
>   if this is an existing dive site name, we show the data for that site
>   if not, we show an otherwise empty dive site template with the name
>   populated
>   Just like in the previous case the user can pick a different site for
>   the current dive or make changes and save the divesite

Perfect. This is an edit action.
But if the location name control (editbox/label) is not empty, we
perform exactly the same operation as above.
I mean that if it's not empty, it contains already a dive site because
it was created in one of the above operations.

> If the user just added a location name, never went to the dive site edit
> screen and then saves the dive (so Apply changes in the Notes tab) then we
> look at the name - if it's a known dive site name we pick that one (no
> idea what to do if there are multiple dive sites with the same name...),
> if it's not we simply create a dive site with that name and no additional
> information and use the uuid of that dive site for the dive we just
> finished editing.

IMHO here lies the problem (POINT #3 from above). You said that a user
should not be forced to use dive sites but... When he writes freely in
the location name textbox and save, we (try to) apply the dive site
logic under the counter. It's a scam! :)

I suggest using a simple label for the location name control and a
[edit] button.

When we import dives (computer, logbook, etc.) we could use just a
placeholder name for them like "dive number XYZ" exactly like we
already do importing from the companion app.

Do you want to set your name? Click [edit] and you fall into your
first use case.
Do you want to edit a dive? Click [edit] and you fall again into your
first use case.

It's much simpler

> > #3 The main menu "manage dive siteS" is a dedicated view only for all
> > dive sites. It should have a design which clearly show that I'm not
> > working with dives (e.g. no profile view).
>
> Yes, there should be no profile. This was supposed to show pictures of the
> dive site but I forgot to ask Tomaz to change that.

> > It doesn't edit a dive site
> > by default but only explicitly. From there in the future I should have
> > all the tools to manage dive sites in my logbook like edit, find
> > duplicates, merge, etc...(something like the google contacts app).
>
> That may be past 4.5
> But there you would also be able to edit the taxonomy, etc.


For taxonomy, please see my reply on your  "Bringing back and old
conversation about Dive site tags"

Good night (her in Italy)