Dive site management on daily build 4.4.2.669

[Dirk Hohndel]

On Thu, Jun 11, 2015 at 12:57:11AM +0200, Davide DB wrote:
> > 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.

Yes. I'm having problem with the reverse geocoding - the mapquest service
appears to be migrating and has stopped working when used through proxies.

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

Here your language has me puzzled a bit again...
So you are saying "in Subsurface 4.4 and earlier (I think that's what you
mean with V2) we had all location data (name and GPS coordinates) on the
Notes tab. But in 4.5 we will have both (plus description, notes and
tags/taxonomy) on the dive site edit screen?

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

I'm not quite sure why the dropdown menu is so distracting :-D

> > a label that is editable, I assume?
> 
> Not really. See below

Now I'm confused.


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

OK

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

How would that work? What would that label state? Just an empty text if
you have no dive site selected, yet? I thought it would be much more
intuitive if you could just "name" your dive right there - just like you
used to be able to do. And if you then want to add more data, you click on
the "edit dive site" button...

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

Well - in my mind one of those options was the user typing it in, but you
don't seem to want that.
But I have another question. You said earlier that you wanted it to be no
drop down, either. So I'm assuming you truly want this to be a read-only
label and to make any changes whatsoever one has to switch to dive site
editing?

I'm not sure I like that idea as much.

Here's my usual workflow after a dive:

- I always have the companion app running while on a dive boat
- I download from my first dive computer
- I quickly add the dive site names, dive masters, buddies, maybe a few
  quick notes
- I download from my other dive computers
- finally I sync with the GPS web service and the GPS locations

The way I envision this, I can do all this without EVER having to switch
to the dive site view.
In the third step I simply enter the dive site names. If they are existing
dive sites, I automagically get the right dive site already. If they are
new ones, as I "Apply changes" for the dive edit a new dive site with the
new name gets created. And then in the final step the GPS data is added to
those sites.

But if the dive site is a read only label, then for every single dive I
need to click on "dive site edit", then on '+' to add a new site, then
save that site. That seems way complicated for no benefit that I can
discern.

Please explain to me what I'm missing.

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

No, Steve Jobs would say "it's MAGICAL!"

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

I hear you. I'll honestly admit that I don't like it.

> It's much simpler

No, it's much more complicated. And I think to the casual user it's far
less intuitive.

What do others think?

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

Already fixed (well, it's no longer a profile - Tomaz says he will soon
add some kind of picture functionality).

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

Will do :-)

/D