[RFC ]Dive site tags: my try

[Davide DB]

These were remarks and comment from Dirk

On Wed, Feb 18, 2015 at 1:58 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> Davide,
>
> thank you so much for all the effort you are putting into this.
>
> While you were working on this, Tomaz and I were in a video call with a
> Luisa, a designer in Brazil who has helped us in the past and who wants to
> contribute more as well.
>
> It is very exciting to me to be going from "no one with any decent design
> sense" to having "a diver with design ideas" plus "a designer who can help
> turn this into beautiful software"...
>
> I believe Tomaz was planning to walk Luisa through some of your ideas
> today and tomorrow.
>
> On Wed, Feb 18, 2015 at 01:14:20AM +0100, Davide DB wrote:
>> This is my try to define a workflow for this new amazing feature.
>> Bear with me!
>>
>> I'll try to follow some use case and some excerpt from previous discussion.
>>
>> Precondition
>> * V3 xml format removes location, latitude and longitude from the
>> struct dive and replaces them with a dive_site_uuid.
>> - V3 xml format uses the struct dive_site to hold that information .
>> * V3 xml format is not compatible with previous version hence users
>> have to migrate to V3 format to use Subsurface.
>> * Once migrated you are not forced to explicitly use location structure.
>
> Yes.
>
>> Use cases
>>
>> MIGRATION PROCESS
>> ------------------------------------
>> Existing users must migrate to the new V2 xml format.
>>
>> "Data migration" and "new dive creation" behaviors are controlled via
>> a "Dive site management" user preferences panel. Let's see how the
>> migration process could be:
>>
>> Migration is triggered:
>>
>> - Opening a V2 logbook via File > Open.
>> - Importing a V2 logbook via Import > Import log file.
>
> So basically the feature that I thought most people use (you have a
> default file that automatically opens when you start Subsurface) is
> something that you didn't consider?
>
> Or is it that if your default file is a V2 file it ISN'T just opened but
> instead the user gets presented with a dialog that asks them how they want
> to migrate their data?
>
>> WELCOME
>> ----------------
>> A welcome dialog informs the user of what will going on in a minute
>> (doomsday device).
>> All instruction are given:
>>
>> http://i.imgur.com/sQ6NMdP.png
>
> I don't like the "will delete your logbook" language. It should say "will
> save a backup of your unmodified logbook in _this_location_ and then
> migrate your data in place" (or something along those lines).
>
> And you should get this dialog whenever a V2 file is opened. So open,
> import, and default file.
>
>> CONFIGURATION
>> ----------------------------
>> Next step give the user the choice to configure the process:
>>
>> http://i.imgur.com/2myW9jj.png
>>
>> Here I imagined two options: dives with GPS data and dives without GPS
>> data. User must opt-in both.
>>
>> User enable the reverse geocoding option for all the dives with GPS data.
>>
>> Once enabled he can choose which attributes (we could call them
>> geo-tags) fit for him.
>> For the UI I copied the nice idea from Miika for CSV file import but
>> simpler approach could be used.
>> Basically he can choose up to three geo-tags dragging them on the
>> three boxes/area.
>> The geo-tag list is what we can get from the reverse geocoding service
>> we will use (I do not know if there is a standard)
>
> I like this.
>
>> If user used some sort of structure in his dive locations he could
>> eventually choose to parse dives without GPS data too. He could
>> indicate which kind of structure he used. More or less as above (we
>> should choose its separator).
>
> Yes, separators would have to be a user option. This might work for the
> "very consistent" crowd :-)
>
>> I know, it's not perfect. In the above description dive location names
>> with gps data are not touched so some redundancy could easily happen.
>> We could use a mix of the two procedure described above.
>>
>> PREVIEW
>> --------------------
>>
>> Next step is the import/migration process by itself.
>> We need a progress bar nad we need a preview of what we are going to
>> save (and eventually accept, reject, edit)
>>
>> http://i.imgur.com/2eJXqgo.png
>>
>> The procedure will show a table for "GPS dives" and "manual dives"
>> showing names before/after.
>> We could accept all with a global check-box or one by one and
>> eventually edit the new name before saving.
>> I did not show file open/save dialogs.
>
> I understand what "accept" means. But what happens if a user doesn't
> accept a dive? Is there a manual process to set geo tags? Or is just the
> site name used with no geo tags?
>
>> In my opinion once we use the reverse geocoding service we should
>> graba nd save into the xml ALL the attributes/geo-tags regardless of
>> user choice. In other words: the user choose only what he will display
>> later.
>> This could be useful later for maximum compatibility when
>> interfacing/exporting to other logbooks.
>
> Why would we? If we can get those data once, we can get them again... I
> see no reason to fill up the XML files with all that information if the
> user doesn't care about it...
>
>> USER PREFERENCES
>> -----------------------------------
>>
>> User could decide to change dive site structure later.
>> Configuration is made via a new option in the user preference dialog.
>> In my wireframe I slightly rearranged the current dialog (more idea to
>> come...).
>>
>> http://i.imgur.com/RS5fjKJ.png
>>
>> Basically here there are more or less same options of the migration process.
>> Dive site structure format for dives without gps data should be of
>> help while creating a new dive manually or without companion app. [I'm
>> not fully convinced here].
>
> I'm not sure I understand what you are saying here.
>
>> When you add GPS data to an existing dive, reverse geocoding format
>> would take precedence over previous data (aka overwrite).
>
> Really? Shouldn't there be a "do you want to replace "THIS" with "THAT"
> dialog?
>
>> NOTES TAB
>> --------------------------------------
>>
>> IMHO the new Location field into the Notes panel should be just a NOT
>> editable texbox.
>
> That makes things easier. But if there is no site name, yet, that is a bit
> awkward. Unless you turn that field itself into the button and then if
> there is no site dat you turn the text into "click here to add a dive
> site".
>
>> Eventually near dive site name you have the geo-tags chosen (via
>> reverse geocoding or manually added). In my wireframe I imagined a
>> group box with geo-tags. In a hurry I did not draw all Notes controls.
>>
>> http://i.imgur.com/OphJsjy.png
>
> OK - that takes a lot of space - but we just dropped the coordinates.
>
>> There's no "manage button" but there is a new tab named "Dive site"
>> that is an extended view on the dive location.
>
> I want fewer tabs, not more :-/
>
>> Dirk wrote about a dedicated view to manage all dive sites...
>> I avoided it in my wireframes. It would be nice we could avoid another view.
>
> I'll push back on that. The current dive site view sucks. But imagine one
> where instead of the profile you have a "site photo" plus all photos
> associated with dives at this site? And instead of a dive list below you
> have a list of dive sites that you can manage? I think that adds
> substantial value.
>
>> A prerequisite would be that a "dive site" does not exist by itself
>> inside a logbook.
>> You cannot create a new dive site. You simply create a new dive as
>> usual and eventually a new dive site for it.
>
> That was my vision as well. In my scenario that's just a convention - in
> yours that =;s a requirement.
>
>> In this way (I hope) everything it's simpler and we could have a
>> design like mine.
>>
>> DIVE SITE TAB
>> ------------------------
>>
>> http://i.imgur.com/rxqX8Hv.png
>>
>> This is more or less the same as in the experimental build.
>> There is a new group-box with the current geo-tags chosen (again: via
>> reverse geocoding or manually added). In my wireframe they came from
>> reverse geocoding because there are GPS data.
>> There is an Update button near geo-tags: it queries again the reverse
>> geocoding service.
>> Geo-tags can be deleted with the X icon.
>> Maybe when I tried to use the service it was not available (network..)
>> so I could imagine to have a special icon indicating that this dive
>> site has not been correctly updated...
>
> OK
>
>> Any operation on this panel will trigger an edit!
>
> Yes.
>
>> DIVE SITE EDIT
>> -------------------------
>>
>> One weak side of this design is that the dive site tab could refer to
>> many dives (I've just deleted the stat tab for this :) ) but I think
>> we can live with it. Dive site is strictly related to the current dive
>> so the info is not misleading.
>> Of course, when we edit it we must alert user that we are going to
>> affet one or several dives:
>>
>> http://i.imgur.com/RD7FdQs.png
>
> I disagree with the text. The user is not "editing 49 dives". The user is
> "editing a dive site used in 49 dives". Very different.
>
>> I'm sure that I forgot a lot of things and that there are a lot of
>> flaws in my workflow or maybe it's too complicated or completely
>> different from what expected. I myself have some doubt :)
>>
>> Henrik, Dirk and me exposed a lot of different ideas. I hope this is
>> at least an helper to define the correct workflow.
>>
>> Good night (1:11 am here in Italy)
>
> Again, thanks for the amazing effory. This is really appreciated.
> I think you bring a lot of relevant and good ideas... let's see what
> others think
>
> /D



-- 
Davide
https://vimeo.com/bocio/videos