These were remarks and comment from Dirk On Wed, Feb 18, 2015 at 1:58 AM, Dirk Hohndel <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
