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. 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. 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 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) 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). 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. 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. 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]. When you add GPS data to an existing dive, reverse geocoding format would take precedence over previous data (aka overwrite). NOTES TAB -------------------------------------- IMHO the new Location field into the Notes panel should be just a NOT editable texbox. 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 There's no "manage button" but there is a new tab named "Dive site" that is an extended view on the dive location. 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. 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. 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... Any operation on this panel will trigger an edit! 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'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) -- Davide https://vimeo.com/bocio/videos _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
