Dive site management on daily build 4.4.2.669

[Dirk Hohndel]

On Thu, Jun 11, 2015 at 10:09:19AM +0200, Davide DB wrote:
> >> 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
> 
> These heatmap shows where user's attention lingers the longest:
> 
> https://cdn.tutsplus.com/webdesign/uploads/legacy/022_F_Layout/heatmap.jpg
> 
> http://psychology.wichita.edu/surl/usabilitynews/91/images/eyetracking_corporate_site_about_us.png
> 
> This is a good article on it.
> http://psychology.wichita.edu/surl/usabilitynews/91/eyegaze.asp
> 
> Most concepts are valid for traditional UI too.

I don't see us having the resources to do an eye tracking study anytime
soon. But I understand your point.

> > 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.
> 
> You are right, having a textbox you save a click and your
> after-dive-workflow is exactly like mine (except I have just one DC).

I think this might be the work flow for most people who do recreational
boat dives. You come back from a day of diving with multiple dives.
I could envision people who do one complex tech dive and they would go
straight in and fill in details about the dive site so for them this would
be less annoying... and it's a lot more than one click. It's the visual
change of getting to a different screen and back. Any time you change the
screen on the user they need to re-orient themselves - and this happens
twice if I can't type in the dive site name right there.

> The problem I see is partially explained in my previous reply below.
> Moreover, in your/mine workflow the GPS syncing step is the last one.
> According to what you stated on the "duplicate dive sites" thread,
> when you apply the gps data you could end up changing dive sites
> (20/25 meter logic, same name, different name, etc...).

No, that's ONLY done when reading in a V2 XML file. So it's done when we
create sites from {name,GPS} pairs. When you enter data in the UI this is
not done.

> Maybe I'm wrong on this and your solution is slicker. Could be a case
> in which I write a wrong name for an existing dive and gps data
> download will screw up my dive sites?

Depends. If you have a dive site with no GPS data and you use its name by
mistake then yes, downloading the GPS data will potentially cause you to
add the GPS fix to that wrong site. But that could happen in your scenario
as well.
If the existing dive site already has GPS data that will not be
overwritten by a download from the Subsurface GPS webservice.

> >> > 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!"
> 
> Actually even if the user do not care about dive site, the magical
> dive site soldier acts in background.

Let me translate this back into Italian to see if I can understand it
then.... nope, still don't understand the sentence :-)

> >> 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?
> 
> Ok you bought me.

BTW - English idioms... "you bought me" means that I paid you money to do
something. To change your mind, to provide services, etc. I think you
might mean "you sold me on this", as in "I convinced you of my opinion".
:-D

Thank you for arguing with me. I keep trying to remind everyone that while
I argue forcefully and am rather stubborn in all this, I really really
want you guys to argue with me. If it hadn't been for Henrik and Davide
and some other arguing with me we would never have added dive site
support.

> Habemus Papam

Not quite sure it's a Holy Father just yet, but I think we are making
progress understanding how the user interaction should work. Now we need
to get Tomaz to implement this :-)

/D