Re: More Location Fixes.
On Tue, Jul 14, 2015 at 03:10:30PM +0200, Davide DB wrote: On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel d...@hohndel.org wrote: So that's 16 scenarios so far... who can think of more? Hi Dirk, Examples by Linus caught me off guard. At this point I really do not know what's the correct behavior. I thought we depict possible scenario more than one month ago but there we thought a different UI so we need to start again. So there are two different UIs here. One is when showing a dive. The other is when editing dive sites. And regardless whether we love the little quick edit or not (that just adds the ability to edit notes and description right from the dive view... I'm not sure it's worth the amount of work that it currently absorbs but Tomaz keeps telling me it's really easy), we need to cover the ability of the user to make changes starting from the dive view, as that is how existing users will use it (and that's certainly how I will use it and Linus will use it). And like it or not, our preferences do matter a bit here. That's why I want to make sure we actually clearly define what happens when the user is looking at a dive and making a change to the dive site. I think your scenarios are good. Who remember what we agreed months ago and we wrote several times? Nobody! Me neither. I think much of what we agreed upon was about the dive site management mode. The one that is gone and has not been reimplemented, yet. E-mail it's the wrong tool for keeping track or deciding a complicate workflow with user and UI interaction. In the hope it will serve as a warning for the future :) We should really work on some shared sketch or even a classic sequence diagram and then use email to comment them but once decided we should stick to them and publish them somewhere for developers use. My try. BRANCH #ONE 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions The dive will reference the dive site already there. BRANCH #TWO 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. Excellent BRANCH #SEVEN 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) Yes, if we have another fix within 20m we should show that. Which tells me that if you have GPS data and type something in, not only should we auto-complete on name but we should ALSO list dives that are within 20m (or maybe a little more) of that GPS fix. Which adds a whole list of other cases here, doesn't it? -- I'll keep the use cases 2... existing text in the location field for another email. Good call. I did notice that in all the cases above you forgot about the a)/b) (accept/reject). In most cases that's kinda obvious (just discard). And I think even in the cases where this would have created a new dive site we just discard it. For now I think the simplest logic would be to assume that all changes made go away and we are exactly in
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel d...@hohndel.org wrote: So that's 16 scenarios so far... who can think of more? Hi Dirk, Examples by Linus caught me off guard. At this point I really do not know what's the correct behavior. I thought we depict possible scenario more than one month ago but there we thought a different UI so we need to start again. I think your scenarios are good. I'm really sorry for Tomaz. I did not mean to waste his time. Who remember what we agreed months ago and we wrote several times? Nobody! Me neither. E-mail it's the wrong tool for keeping track or deciding a complicate workflow with user and UI interaction. In the hope it will serve as a warning for the future :) We should really work on some shared sketch or even a classic sequence diagram and then use email to comment them but once decided we should stick to them and publish them somewhere for developers use. My try. BRANCH #ONE 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions The dive will reference the dive site already there. BRANCH #TWO 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. BRANCH #SEVEN 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) -- I'll keep the use cases 2... existing text in the location field for another email. Maybe all of them are related to a dive site management scenarios rather than new dive being added. Once we are set with the above cases I can rewrite them from scratch and I will tattoo them on my left cheek :) -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Happy Bastille day all, On 14 Jul 2015 11:10 pm, Davide DB dbdav...@gmail.com wrote: On Tue, Jul 14, 2015 at 1:42 AM, Dirk Hohndel d...@hohndel.org wrote: So that's 16 scenarios so far... who can think of more? Hi Dirk, Examples by Linus caught me off guard. At this point I really do not know what's the correct behavior. I thought we depict possible scenario more than one month ago but there we thought a different UI so we need to start again. I think your scenarios are good. I'm really sorry for Tomaz. I did not mean to waste his time. Who remember what we agreed months ago and we wrote several times? Nobody! Me neither. E-mail it's the wrong tool for keeping track or deciding a complicate workflow with user and UI interaction. In the hope it will serve as a warning for the future :) We should really work on some shared sketch or even a classic sequence diagram and then use email to comment them but once decided we should stick to them and publish them somewhere for developers use. My try. I mostly agree with how you think the cases should be handled. And definitely agree with the objective of determining and agreeing on the best method. I've added a few comments. BRANCH #ONE 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions The dive will reference the dive site already there. BRANCH #TWO 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu I don't think the auto-prompt should include sites with existing gps data further than x m from the new gps coordinates. BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. BRANCH #SEVEN 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) As I said above, I think the 'alert' should be that existing nearby sites show in the prompt, before a name is selected. -- I'll keep the use cases 2... existing text in the location field for another email. Maybe all of them are related to a dive site management scenarios rather than new dive being added. Once we are set with the above cases I can rewrite them from scratch and I will tattoo them on my left cheek :) -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 4:45 PM, Dirk Hohndel d...@hohndel.org wrote: So the summary of those last couple of cases should be If the user picks an existing dive site from the auto completion no existing data in that dive site is changed, but if that dive site has no GPS data, then that data may be added from the current dive the user is on. Makes sense? Yes And you are right - now we have all this wonderful information, distributed across ten emails. We need a better way to store this. Right now, instead of a dive site I have to pick up my child at the school :) I will try to resume all these use cases again in a new email later today so it will be easy to review everything again. I hope in the meantime Linus and others could chime in with other comments. Bye -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 11:40:06PM +1000, Rick Walsh wrote: BRANCH #THREE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions Use cases #3 is more complicated. I'll pass the baton to other users :) but in the meantime... first question: Has the completion chosen GPS data? Eventually can we assume it's the same? Hence this branch is meaningless without splitting it in more 3 more branches: If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. Well, I don't know. Scenario. I keep doing boat dives to the same sites (we'll be in Palau the fourth time this fall and I bet we'll go back to the Blue Corner and many other sites we've been to frequently). I use the phone app to track GPS points, anyway, and download them. Now I have a site with no name and a GPS location (well, I won't because I always do names first before downloading GPS, but Linus and some others do it the other way around). So now Subsurface showme that this was really close to the Blue Corner and I say right, I remember, we dove the Blue Corner today. Now if I want a new location because it's a different boat anchor point, I completely type in Blue Corner and save that. New site, same name, close by the others. Or I just want to pick the existing one (or one of the existing ones, I have three distinct anchor points for Blue Corner because they are different dives, depending where you start). And I get the GPS coordinates from that dive site that I picked. The interesting question is assuming I have GPS data, assuming I remember the site was also called Blue Corner, assuming that site is in Hawaii, should the Blue Corner from Palau even be offered as completion? I'm leaning towards no (not knowing how easy or hard that would be for Tomaz to do). At the very least it should be marked differently in the completion list if possible... maybe the completion list could add distances if both the current dive site and the completion dive site have GPS locations. And here I go again, coming up with fun ideas to distract Tomaz from doing what he's working on :-( BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Existing. See above. You pick a site, you use those coordinates. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu I don't think the auto-prompt should include sites with existing gps data further than x m from the new gps coordinates. See above - we should give the distance and let the user decide. 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.2. user types in name, doesn't pick one of the completions The dive will use a new dive site with text typed in by the user. One question arise here: even if the user choose a brand new name, should we check if GPS data are already there under a different dive site? (eventually giving him an alert... are you sure that you want to create a new dive site for something you already have?) As I said above, I think the 'alert' should be that existing nearby sites show in the prompt, before a name is selected. After talking to Tomaz in a hangout I have learned that that is very hard to do on the completer (as that is just text based). But of course if the user has Marble enabled then they can see the dive sites nearby on the globe. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 03:52:39PM +0200, Davide DB wrote: Happy Bastille day all, Happy Bastille to you :) I hear from my history teachers that it was a very happy day for the people at the Bstille back then as well... If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. I see you point. I forgot to mention it in my previous email. Actually this involve a pre-check or pre-filtering selections once GPS data are imported. This will require a significant amount of code change / code addition. I'm not saying it can't be done, but I'm not sure we'll have it in the next version. BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... If the user is just editing a dive and she picks an existing dive site from the drop down, that should pick that dive site and NOT MODIFY IT. If the user wants to modify the existing dive site, that needs to happen in the yet to be implemented dive site management system. There is one exception to the rule. 1.2.1.2 (Davide forgot to number this one). User starts with an empty location field but we have GPS data for this dive, user types in a name, picks an auto completion and the auto completion has no GPS data. Then and only then should we modify the auto completion and add the GPS data. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 04:05:57PM +0200, Davide DB wrote: On Tue, Jul 14, 2015 at 3:27 PM, Dirk Hohndel d...@hohndel.org wrote: And like it or not, our preferences do matter a bit here. Absolutely unnecessary statement. Nah - the occasional reminder that there are people here who have certain preferences... I'm not trying to impose my view but just contributing with my view for the sake of a better application. You are. And I'm grateful. Very grateful. Your work has really brought us along. I just pointed out that we need to make sure that the workflows we come up with make sense for Linus and I as well. See the emails that Linus sent on that topic. That was not at all intended to be perceived as a negative comment on the awesome work that you do helping us to figure out what the right flow should be in the end. I think this is just another case of email being an imperfect communication mechanism. Sorry that I chose my words poorly. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu This one? I really think that if the completion has GPS data that's the GPS data we pick. We can add something like by picking this dive site your GPS location moved by approximately m/km/miles/light years for cases where that move is more than 20m or 50m. I did notice that in all the cases above you forgot about the a)/b) (accept/reject). In most cases that's kinda obvious (just discard). And I think even in the cases where this would have created a new dive site we just discard it. For now I think the simplest logic would be to assume that all changes made go away and we are exactly in the same state as before this edit operation started. This was my intention. For the sake of simplicity Good. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 4:24 PM, Dirk Hohndel d...@hohndel.org wrote: This will require a significant amount of code change / code addition. I'm not saying it can't be done, but I'm not sure we'll have it in the next version. CANCELLED BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... If the user is just editing a dive and she picks an existing dive site from the drop down, that should pick that dive site and NOT MODIFY IT. If the user wants to modify the existing dive site, that needs to happen in the yet to be implemented dive site management system. OK. You pick an existing one and you stick with its whole data. There is one exception to the rule. 1.2.1.2 (Davide forgot to number this one). User starts with an empty location field but we have GPS data for this dive, user types in a name, picks an auto completion and the auto completion has no GPS data. Then and only then should we modify the auto completion and add the GPS data. /D Ouch, Actually it's there but I numbered it in a wrong way. It's Branch #Six BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.2 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 3:40 PM, Rick Walsh rickmwa...@gmail.com wrote: Happy Bastille day all, Happy Bastille to you :) If the dive already has gps data, I can't see the value of autocompleting the name based on other names, unless the options are limited to sites at about the same location, or sites that don't yet have coordinates. If the user types anything else, it should be a new site. It really doesn't matter that's there's another site called House Reef or Blue Hole; it's still a different site. I see you point. I forgot to mention it in my previous email. Actually this involve a pre-check or pre-filtering selections once GPS data are imported. BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 3:27 PM, Dirk Hohndel d...@hohndel.org wrote: And like it or not, our preferences do matter a bit here. Absolutely unnecessary statement. I'm not trying to impose my view but just contributing with my view for the sake of a better application. BRANCH #FIVE 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.2 completion GPS is different from the incoming GPS data Hu This one? I did notice that in all the cases above you forgot about the a)/b) (accept/reject). In most cases that's kinda obvious (just discard). And I think even in the cases where this would have created a new dive site we just discard it. For now I think the simplest logic would be to assume that all changes made go away and we are exactly in the same state as before this edit operation started. This was my intention. For the sake of simplicity -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 4:16 PM, Dirk Hohndel d...@hohndel.org wrote: Scenario. I keep doing boat dives to the same sites (we'll be in Palau the fourth time this fall and I bet we'll go back to the Blue Corner and many other sites we've been to frequently). I use the phone app to track GPS points, anyway, and download them. Now I have a site with no name and a GPS location (well, I won't because I always do names first before downloading GPS, but Linus and some others do it the other way around). So now Subsurface showme that this was really close to the Blue Corner and I say right, I remember, we dove the Blue Corner today. Now if I want a new location because it's a different boat anchor point, I completely type in Blue Corner and save that. New site, same name, close by the others. Or I just want to pick the existing one (or one of the existing ones, I have three distinct anchor points for Blue Corner because they are different dives, depending where you start). And I get the GPS coordinates from that dive site that I picked. The interesting question is assuming I have GPS data, assuming I remember the site was also called Blue Corner, assuming that site is in Hawaii, should the Blue Corner from Palau even be offered as completion? I'm leaning towards no (not knowing how easy or hard that would be for Tomaz to do). At the very least it should be marked differently in the completion list if possible... maybe the completion list could add distances if both the current dive site and the completion dive site have GPS locations. And here I go again, coming up with fun ideas to distract Tomaz from doing what he's working on :-( I agree After talking to Tomaz in a hangout I have learned that that is very hard to do on the completer (as that is just text based). But of course if the user has Marble enabled then they can see the dive sites nearby on the globe. Of course. It's impossible making a user comfortable with the above choices only via a text autocompletion. Using Marble for UI interaction open other completely different scenario/interactions I guess... We should use Marble as visual aid while adding new dives. PS When I add dives, I'm of the gps-before-name party -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 04:33:12PM +0200, Davide DB wrote: On Tue, Jul 14, 2015 at 4:24 PM, Dirk Hohndel d...@hohndel.org wrote: This will require a significant amount of code change / code addition. I'm not saying it can't be done, but I'm not sure we'll have it in the next version. CANCELLED Let's say marked for later consideration :-) BRANCH #FOUR 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.1 completion has GPS data 1.2.1.1.1 completion GPS data fall within a certain range into the incoming GPS data The dive will reference the dive site already there. Of course. The question is do we want to use the old or new gps coordinates for the site? Good point. I would keep always the same gps data otherwise, 20m at the time we could silently drift of 200m after 10 dives there. Actually the best option would be to ask to the user... If the user is just editing a dive and she picks an existing dive site from the drop down, that should pick that dive site and NOT MODIFY IT. If the user wants to modify the existing dive site, that needs to happen in the yet to be implemented dive site management system. OK. You pick an existing one and you stick with its whole data. There is one exception to the rule. 1.2.1.2 (Davide forgot to number this one). User starts with an empty location field but we have GPS data for this dive, user types in a name, picks an auto completion and the auto completion has no GPS data. Then and only then should we modify the auto completion and add the GPS data. /D Ouch, Actually it's there but I numbered it in a wrong way. It's Branch #Six BRANCH #SIX 1. empty location field 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.1.2 completion has not GPS data The dive will reference the dive site already there and GPS data will be added. So the summary of those last couple of cases should be If the user picks an existing dive site from the auto completion no existing data in that dive site is changed, but if that dive site has no GPS data, then that data may be added from the current dive the user is on. Makes sense? And you are right - now we have all this wonderful information, distributed across ten emails. We need a better way to store this. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 11:51:40AM -0700, Linus Torvalds wrote: On Mon, Jul 13, 2015 at 4:42 PM, Dirk Hohndel d...@hohndel.org wrote: 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions 1.1.2. user types in name, doesn't pick one of the completions ... So quite frankly, I think the fact that 1.1.1 and 1.1.2 might be different is a big design mistake. I really think the very fact that you ask what should. the semantics be ends up being a sign that the interface is bad. Because even if we pick semantics that everybody agrees on, what does it mean that we had to ask that question? Really? It means that this is complecated. And that we want to think about the different cases and make sure that what we pick makes sense. To me, it means that any new user who wasn't part of the discussion is clearly *not* going to find whatever semantics we picked - whether we all agree on them or not - to be intuitive. I don't think you can draw that conclusion. What we are doing here is that we are breaking it down to make sure we understand the scenarios and we ask ourselves what would be the reasonably expected thing to do in those scenarios. So let me suggest something that is at least easier to explain than your 16 scenarios so far. I suggest that we really have two VERY CLEARLY separate cases: - the user wants to type in the dive site name (with name completion, the same way we have text completion for buddy names etc etc) - the user wants to pick a previous dive site that he/she has dove many times before. No, that's not the distinction. Because both start with typing in the name and Subsurface doesn't know which of the two cases it is. and I think we should keep those two cases separate, and not ever mix them up. So the two cases are: (1) when the user types in a dive site name, whether it is a completion or not is entirely immaterial - all it does is set the name. Nothing else. And by definition, since the user didn't pick an old dive site, the newly created dive site is a new unique dive site. This never changes any other dive sites, and it never changes the GPS coordinates fro this dive. You *only* edited the name for that dive. (2) when the user picks a dive site from a list, the user picks *that* dive site (and that GPS information). We throw the old dive site away. Now, we *might* want to warn and ask for confirmation if throw the old dive site away means that we actually lose the GPS information. The test for that would basically be: (a) does the dive site we throw away have GPS information, and (b) was this the last user of that dive site, so that it now is orphan. But the important part - for me - is that these two choices are very *clear* and obvious. I think the thing I really really hate about the current dive site model is how that text entry field we have now does *both*. And that is exactly the thing that I WANT. Because that's how users USE the field. So I think *that* is the real bug we have now. The text-field/drag-down that mixes old dives sites with new is wrong. It mixes up those two choices, which means that any semantics we give it is automatically wrong and confusing. In other words, I really think that the Location entry text field should _just_ be a text field. Yes, it autocompletes, but even when it auto-completes it does nothing else. So it would be (1). And I think the button to the right of it is what should open a list of pre-existing dive sites. So we'd have a clearly separate way to actually pick old dive sites, and this would be (2). No, that is not what I want. That's a horrible user experience. So now there is clear separation, and no question about semantics. Add a tool-tip thing maybe to *explain* it, so that when a person hovers over the button on the right it says pick an existing dive site and its GPS information, and when the user hovers over the divemaster text-field it says edit the name of the dive for this dive, creating a new dive site. So the advantage of this is that it's fairly easy to explain, and it supports very naturally the whole notion of (a) diving a lot at the same sites (perhaps a local one) for when you do *not* tend to use the companion app to get GPS locations (since why would you: using the companion app every time you dive at the Yellow House would just be crazy) (b) you use the companion app, and you basically start off assuming that you'll just create new dive sites, but you may still want to auto-complete the name, and the workflow should *not* behave differently whether you download the GPS location first or last. So note how there are no 16 cases. There are two fairly simple cases, and they have clearly separate GUI elements. So there's never any mix-up between the two. Hmm? NACK This makes sense to you because of the way
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 12:34:27PM -0700, Linus Torvalds wrote: On Tue, Jul 14, 2015 at 12:15 PM, Dirk Hohndel d...@hohndel.org wrote: Now I fly to Hawaii and go diving. I run the companion app. I am one of the people who first download the GPS fixes before they start editing the dives. You realize that in many places you can't even do this? Because you may not have interenet? Any workflow that depends on order of companion app is broken. Right. You are the one who was yelling at me when you were in Hawaii and did exactly that. Exactly the steps that I described. And it didn't do exactly what I described as the output here. How do you expect anyone to be able to implement what's in your rants if your rants keep changing? Seriously. You haven't thought this through. Your model cannot work. Hmm, in the last email you were complaining about the fact that we actually ARE thinking it through. And now you are complaining that we are NOT thinking it through. Complicated. And the fundamental reason it cannot work is that you mix up two things. If you get GPS information from typing a name, the behavior is broken, because that breaks the I had no internet, so I'll have to download GPS data later, but now I have GPS data because I happened to picka name that already existed, so now it will never do that. No it doesn't. You aren't paying attention. You aren't reading what people are writing. If you pick a dive site from the list that is CLEARLY marked as having a GPS location and for most normal users will even be CLEARLY marked with taxonomy data. So there is nothing confusing here. You picked a site with GPS data. You got that GPS data. If you think I have GPS data from the phone, I just can't upload that right now and the site was Blue Corner then you type in Blue Corner and do NOT pick the pre-existing site. You just type it in and accept that name. You get a new site with that name and no GPS data. You download the GPS from the webservice when you have internet and it does exactly what you wanted it to do. Easy, intuitive, obvious. Picking Blue Corner but not getting the GPS location is a ridiculous idea - what's the point of having dive sites to auto-complete from if you don't get their data. And stop ranting about the fact that you somehow need to explicitly tell Subsurface whether you want an existing dive site or a new one. You may not know if you have that site. And you don't have to. And if it acts differently depending on whether you write the whole name, or whether you then see the name and auto-complete, that's also obviously a complete disaster because that kind of difference is a UI disaster. I may not be a UI person, but I know shit when I see it. Excellent. Thank you for your constructive commentary. So exactly *how* do you suggest you solve it in your world-view? See above - start typing the name (if this is what you want to be the beginning point) - the completion needs to have the *choice* of cases, ie a drop-down menu, where the first choice is no GPS, but the other choices have that GPS marker (that we have in the divelist too). Why would there BE a completion with no GPS if the only dive site of that name has a GPS location attached to it? And if you explicitly press cursor down (and _only_ if you do that), then the globe scrolls to that entry. There could be multiple entries there, you need some way to see where it scrolls. HAVE YOU EVEN USED THE CURRENT CODE That's exactly what happens. But it's also important that the globe *not* scroll until you do that, because maybe you had the globe at the explicit point it was, because you were looking up the dive site names around that area! And again, it's important that this is an explicit choice. Really. It *has* to be. If it's not a button press ahead of time, it needs to be a button press (or keyboard action) after you've seen the list. Not some implicit if you complete the name thing. Because that cannot work, and you need to admit that. And you need to admit that you are just rambling and aren't following what's being developed. It IS an explicit choice. It has been discussed here as an explicit choice. It has been implemented as an explicit choice. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 5:07 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Jul 14, 2015 at 12:56 PM, Dirk Hohndel d...@hohndel.org wrote: If you pick a dive site from the list that is CLEARLY marked as having a GPS location and for most normal users will even be CLEARLY marked with taxonomy data. So there is nothing confusing here. You picked a site with GPS data. You got that GPS data. Dirk, YOU are the one not reading things. If you think I have GPS data from the phone, I just can't upload that right now and the site was Blue Corner then you type in Blue Corner and do NOT pick the pre-existing site. You just type it in and accept that name. You get a new site with that name and no GPS data. You download the GPS from the webservice when you have internet and it does exactly what you wanted it to do. Easy, intuitive, obvious. Not intuitive at all. We went through this already. Thats' what we had in Hawaii, and it sucked. If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. uh... that's not what's happening - it will not screw up your gps coordinates. It sure as hell is not intuitive. Seriously, Dirk. We *had* that interface. I used it. I wasn't the only one confused by it. See the whole previous discussion about it, where Miika did the exact same thing. linus - the thing you tested wasn't what we have today ( and I *think* I never made it fully work ), so no - we didn't had this interface. You cannot call ti intuitive if two people independently made the mistake of picking the textual auto-complete, and were surprised when it screwed up the data. So my suggestion was that the first entry in the list NEVER ADD GPS LOCATION. Even if all the *divesites* with that name have GPS location. Exactly so that you *can* auto-complete the name, without screwing up GPS. Because I thought we already agreed that that was a requirement. Your argument is crap, and let me quote it: I'm confused ( really ). if you Write the Blue Corner without clicking on the list it will create a dive site without gps data, and it seems that's what you are saying is the same thing we have. Picking Blue Corner but not getting the GPS location is a ridiculous idea NO IT IS NOT! I know have new GPS location. I want to pick Blue Corner without getting the new GPS locations screwed up. Calling that thing a ridiculous idea is wrong. It's not ridiculous, it's *obvious*. I may have old GPS information. Or, it can be a big dive site with the same name but different GPS information (my Turtle Reef example). Pick a slightly longer name just to drive the concept home. Pick something that isn't as easy to type. I want to auto-complete the *name* of the dive site, not get GPS data that screws things up. Linus - this is simple to add - in a way that will be easy to auto complete the name picking it in the list and not screwing up the location data OR to use an already created location if the user chooses so. this would work for you? : - First entry of the Complete Popup should *always* only complete without gettting any gps information - Other entries would complete gps information ( remember that the new list is very different from the old one and it shows the country / place / coords ) and if user selects those it would set the dive site instead of creating a new one. That is _not_ ridiculous, and I don't understand how you can even claim it is. It's how things used to work, and they worked very well indeed. Right now the dive site model has actually made things *worse*. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 1:19 PM, Tomaz Canabrava tcanabr...@kde.org wrote: If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. uh... that's not what's happening - it will not screw up your gps coordinates. Note that I have no GPS, because I haven't done the companion app sync yet, because I have no internet can also be important. Because if that fills in GPS information, then that means that my _future_ sync with the companion app will not fill in the GPS data any more. See? This is what I was talking about when I said that behavior should not depend on whether you have synced with the companion app before or after editing the dive location name. Because there just isn't one correct case. Yes, sometimes you want GPS data, because you didn't even have a companion app running, or you just decide that yeah, I have a good enough fix from before. And sometimes you _don't_ want GPS data, even if you don't have any yet, because you want to fill it later. I'm confused ( really ). if you Write the Blue Corner without clicking on the list it will create a dive site without gps data, and it seems that's what you are saying is the same thing we have. But I do actually want the name expansion, not the type it out. I don't want to write the whole name if I already have it. For example, the name might not be Blue Hole. It could be Laje Dois Irmâos, Fernando de Noronha, Brazil. Things with special characters that I figured out after-the-fact, and can't necessarily even type with my keyboard without looking up the keyboard map (just out of curiosity, I checked: Right-Alt+6 to get a dead ^, followed by 'a'. Although apparently it *should* have been 'ã' - Shift-RightAlt-Tidle + 'a' on my keyboard). Do you really want em to type it out, just because I know I don't want GPS information, because I'm going to get the GPS info from the companion app when the internet starts working again? Fernando de Noronha did have intenet, but it was kind of flaky. Some other places have been even worse. So maybe I already have the dive site name, but I do *not* have GPS location, and I don't *want* GPS location (because I know it I have better info on my phone, or one of those Turtle Reef is 20 miles of west Maui coast-line things), but I do want to just get auto-complete. Hey, I use auto-complete for dive buddy names. And that's despite the fact that the most common dive buddy name I have has four letters. For something like Molokini Backwall drift: Reef's End? Yeah, I'll auto-complete it, thank you very much. And I just think that in general, the whole we have to have a discussion spread out over several weeks, three different versions, and people can't even agree on the semantics is a sign that we should *not* have some kind of subtle rules and implicit behavior. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Good morning, On 15 Jul 2015 7:11 am, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Jul 14, 2015 at 1:19 PM, Tomaz Canabrava tcanabr...@kde.org wrote: If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. uh... that's not what's happening - it will not screw up your gps coordinates. Note that I have no GPS, because I haven't done the companion app sync yet, because I have no internet can also be important. Because if that fills in GPS information, then that means that my _future_ sync with the companion app will not fill in the GPS data any more. See? This is what I was talking about when I said that behavior should not depend on whether you have synced with the companion app before or after editing the dive location name. Because there just isn't one correct case. Yes, sometimes you want GPS data, because you didn't even have a companion app running, or you just decide that yeah, I have a good enough fix from before. And sometimes you _don't_ want GPS data, even if you don't have any yet, because you want to fill it later. I'm confused ( really ). if you Write the Blue Corner without clicking on the list it will create a dive site without gps data, and it seems that's what you are saying is the same thing we have. But I do actually want the name expansion, not the type it out. I don't want to write the whole name if I already have it. For example, the name might not be Blue Hole. It could be Laje Dois Irmâos, Fernando de Noronha, Brazil. Things with special characters that I figured out after-the-fact, and can't necessarily even type with my keyboard without looking up the keyboard map (just out of curiosity, I checked: Right-Alt+6 to get a dead ^, followed by 'a'. Although apparently it *should* have been 'ã' - Shift-RightAlt-Tidle + 'a' on my keyboard). Do you really want em to type it out, just because I know I don't want GPS information, because I'm going to get the GPS info from the companion app when the internet starts working again? Fernando de Noronha did have intenet, but it was kind of flaky. Some other places have been even worse. So maybe I already have the dive site name, but I do *not* have GPS location, and I don't *want* GPS location (because I know it I have better info on my phone, or one of those Turtle Reef is 20 miles of west Maui coast-line things), but I do want to just get auto-complete. Hey, I use auto-complete for dive buddy names. And that's despite the fact that the most common dive buddy name I have has four letters. For something like Molokini Backwall drift: Reef's End? Yeah, I'll auto-complete it, thank you very much. Could the best solution be broken into two parts? 1. You haven't yet synced the companion app but you select your dive site from the list, so that new dive is assigned that existing site. 2. You sync the app, and the coordinates for that dive put it 20m (or whatever) from that site. IIf this occurs you are prompted with 3 options: -Adopt existing coordinates (leave as is) -Create a new site with same name (might be a different mooring, might be a different ocean, either way you consider it different) -Update that site's location with the just downloaded coordinates And I just think that in general, the whole we have to have a discussion spread out over several weeks, three different versions, and people can't even agree on the semantics is a sign that we should *not* have some kind of subtle rules and implicit behavior. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 12:15 PM, Dirk Hohndel d...@hohndel.org wrote: Now I fly to Hawaii and go diving. I run the companion app. I am one of the people who first download the GPS fixes before they start editing the dives. You realize that in many places you can't even do this? Because you may not have interenet? Any workflow that depends on order of companion app is broken. Seriously. You haven't thought this through. Your model cannot work. And the fundamental reason it cannot work is that you mix up two things. If you get GPS information from typing a name, the behavior is broken, because that breaks the I had no internet, so I'll have to download GPS data later, but now I have GPS data because I happened to picka name that already existed, so now it will never do that. And it used to be broken the other way, where typing in the name would overwrite GPS data. That was obvious crap too, although you used to defend *that* behavior as well. And if it acts differently depending on whether you write the whole name, or whether you then see the name and auto-complete, that's also obviously a complete disaster because that kind of difference is a UI disaster. I may not be a UI person, but I know shit when I see it. So exactly *how* do you suggest you solve it in your world-view? I claim you need that extra button. You *have* to have some actually visually obvious way to decide between just pick the name or pick this dive site. Really. Not 16 rules for implicitly doing something magical. Now, *how* that extra button works might be tweakable, but not whether it exists. If you don't have that explicit choice, and if it's not clear, your model really *cannot* work. You need to face the truth, not make up some workflow up front that can be shown to be obviously broken. See above. Really. Now, if you don't like the button press ahead of time, make it a completion choice. But it needs to be an *explicit* choice. Do something like: - start typing the name (if this is what you want to be the beginning point) - the completion needs to have the *choice* of cases, ie a drop-down menu, where the first choice is no GPS, but the other choices have that GPS marker (that we have in the divelist too). And if you explicitly press cursor down (and _only_ if you do that), then the globe scrolls to that entry. There could be multiple entries there, you need some way to see where it scrolls. But it's also important that the globe *not* scroll until you do that, because maybe you had the globe at the explicit point it was, because you were looking up the dive site names around that area! And again, it's important that this is an explicit choice. Really. It *has* to be. If it's not a button press ahead of time, it needs to be a button press (or keyboard action) after you've seen the list. Not some implicit if you complete the name thing. Because that cannot work, and you need to admit that. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Tue, Jul 14, 2015 at 12:56 PM, Dirk Hohndel d...@hohndel.org wrote: If you pick a dive site from the list that is CLEARLY marked as having a GPS location and for most normal users will even be CLEARLY marked with taxonomy data. So there is nothing confusing here. You picked a site with GPS data. You got that GPS data. Dirk, YOU are the one not reading things. If you think I have GPS data from the phone, I just can't upload that right now and the site was Blue Corner then you type in Blue Corner and do NOT pick the pre-existing site. You just type it in and accept that name. You get a new site with that name and no GPS data. You download the GPS from the webservice when you have internet and it does exactly what you wanted it to do. Easy, intuitive, obvious. Not intuitive at all. We went through this already. Thats' what we had in Hawaii, and it sucked. If I start writing Blu and it auto-completes to Blue Corner, then an interface that says but you mustn't choose that name, because that will screw up your GPS coordinates is a horrible interface. It sure as hell is not intuitive. Seriously, Dirk. We *had* that interface. I used it. I wasn't the only one confused by it. See the whole previous discussion about it, where Miika did the exact same thing. You cannot call ti intuitive if two people independently made the mistake of picking the textual auto-complete, and were surprised when it screwed up the data. So my suggestion was that the first entry in the list NEVER ADD GPS LOCATION. Even if all the *divesites* with that name have GPS location. Exactly so that you *can* auto-complete the name, without screwing up GPS. Because I thought we already agreed that that was a requirement. Your argument is crap, and let me quote it: Picking Blue Corner but not getting the GPS location is a ridiculous idea NO IT IS NOT! I know have new GPS location. I want to pick Blue Corner without getting the new GPS locations screwed up. Calling that thing a ridiculous idea is wrong. It's not ridiculous, it's *obvious*. I may have old GPS information. Or, it can be a big dive site with the same name but different GPS information (my Turtle Reef example). Pick a slightly longer name just to drive the concept home. Pick something that isn't as easy to type. I want to auto-complete the *name* of the dive site, not get GPS data that screws things up. That is _not_ ridiculous, and I don't understand how you can even claim it is. It's how things used to work, and they worked very well indeed. Right now the dive site model has actually made things *worse*. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Guys I could not follow you trough all the exchanges. I'm not sure I understood everything hence I'm not able to recap the workflow as I promised. I'm convinced that most of the misunderstanding originate from the fact that emails are the wrong tool for this. Tomaz save us all :) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 4:42 PM, Dirk Hohndel d...@hohndel.org wrote: 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions 1.1.2. user types in name, doesn't pick one of the completions ... So quite frankly, I think the fact that 1.1.1 and 1.1.2 might be different is a big design mistake. I really think the very fact that you ask what should. the semantics be ends up being a sign that the interface is bad. Because even if we pick semantics that everybody agrees on, what does it mean that we had to ask that question? Really? To me, it means that any new user who wasn't part of the discussion is clearly *not* going to find whatever semantics we picked - whether we all agree on them or not - to be intuitive. So let me suggest something that is at least easier to explain than your 16 scenarios so far. I suggest that we really have two VERY CLEARLY separate cases: - the user wants to type in the dive site name (with name completion, the same way we have text completion for buddy names etc etc) - the user wants to pick a previous dive site that he/she has dove many times before. and I think we should keep those two cases separate, and not ever mix them up. So the two cases are: (1) when the user types in a dive site name, whether it is a completion or not is entirely immaterial - all it does is set the name. Nothing else. And by definition, since the user didn't pick an old dive site, the newly created dive site is a new unique dive site. This never changes any other dive sites, and it never changes the GPS coordinates fro this dive. You *only* edited the name for that dive. (2) when the user picks a dive site from a list, the user picks *that* dive site (and that GPS information). We throw the old dive site away. Now, we *might* want to warn and ask for confirmation if throw the old dive site away means that we actually lose the GPS information. The test for that would basically be: (a) does the dive site we throw away have GPS information, and (b) was this the last user of that dive site, so that it now is orphan. But the important part - for me - is that these two choices are very *clear* and obvious. I think the thing I really really hate about the current dive site model is how that text entry field we have now does *both*. So I think *that* is the real bug we have now. The text-field/drag-down that mixes old dives sites with new is wrong. It mixes up those two choices, which means that any semantics we give it is automatically wrong and confusing. In other words, I really think that the Location entry text field should _just_ be a text field. Yes, it autocompletes, but even when it auto-completes it does nothing else. So it would be (1). And I think the button to the right of it is what should open a list of pre-existing dive sites. So we'd have a clearly separate way to actually pick old dive sites, and this would be (2). So now there is clear separation, and no question about semantics. Add a tool-tip thing maybe to *explain* it, so that when a person hovers over the button on the right it says pick an existing dive site and its GPS information, and when the user hovers over the divemaster text-field it says edit the name of the dive for this dive, creating a new dive site. So the advantage of this is that it's fairly easy to explain, and it supports very naturally the whole notion of (a) diving a lot at the same sites (perhaps a local one) for when you do *not* tend to use the companion app to get GPS locations (since why would you: using the companion app every time you dive at the Yellow House would just be crazy) (b) you use the companion app, and you basically start off assuming that you'll just create new dive sites, but you may still want to auto-complete the name, and the workflow should *not* behave differently whether you download the GPS location first or last. So note how there are no 16 cases. There are two fairly simple cases, and they have clearly separate GUI elements. So there's never any mix-up between the two. Hmm? Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 4:14 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jul 13, 2015 at 12:00 PM, Tomaz Canabrava tcanabr...@kde.org wrote: Just to be sure: If I have a dive with divesite Yellow House with gps coords then I write on it's dive site the name Leeds, it should reject because I have gps coords? So what I _think_ should happen is that you just create a new dive-site. You have a completely new dive site with a new name, and whatever GPS it had from before. Of course, if that new name and GPS then happens to match another dive site, at that point the two matching ones would be the same. But I think this depends on the interface. I think there are two very different models at play, and both are valid: (a) when you are editing a dive (or multiple dives) I really think that you need to automatically (and silently) just create new divesites when somebody edits things (and this would be true whether the name changed or the GPS location changed, or both changed). So this would be the quick-edit thing as part of the dive location. I'll focus on this part since it's what I'm doing now - there's no Dive Site Management Mode yet. Imagine that you have a dive with dive_site.name = Blue Hole with coords, but it was a mistake and you wanna change to Turtle Reef If the user types the name of a dive site, let's say Turtle Reef, it should list on the dropdown the list of all Turtle Reefs that it currently has ( plus the taxonomy or the gps coords if taxonomy is not found ) ( now I also think I should add the coords even if the taxonomy is found because we can have two 'blue holes' in the same country / place and such ) If the user clicks on a particular Turtle Reef from the drop down, it will select *that* dive_site to be the dive's dive site, replacing coords. If the user clicks in nothing ( but changed the name of the dive site to Turtle Reef), the user will have yet another Turtle Reef dive site created for him with no GPS coords. now here I can: 1 - copy the coords from the old dive site 2 - leave without no gps coords and ask him to enter it again. 3 - Change the name of the the dive_site to be 'turtle reef' 4 - Select the first Turtle Reef from the dive_table ans set it ( this is what my last patch does ) I'll create the code for 1. And - I wanna make something that will make you happy and not hatred, so that's why I'm asking a lot of questions here. (b) there's a separate issue of some dive site management mode which is independent of the actual dives. So this would be some totally different mode, where you are *not* editing a dive, but you are doing things like oh, let's clean up the name of that divesite that I've been to many times, or Ugh, I have ten copies of this dive site, and they differ in minimal ways in spelling or are 10m apart in the GPS location, I want to merge these into one single dive site. I think (a) and (b) are completely different things, and have to work very differently. When I'm editing a dive and filling in the information for that dive, doing dive site management is absolutely the *last* thing the interface should do for me. It's why I absolutely *hated* how subsurface worked when you typed and auto-completed a dive-site name: it ended up then throwing out the GPS location you already had, and replacing it with some old dive site data. Which is really seriously buggered, especially since dive sites with the same name really are not unusual at all (blue hole being the classic example, but one I know well is turtle reef, which is something Lahaina divers uses as a generic name encompassing many different dive sites, and if you didn't write up the actual specific name, you really can have Turtle reef with GPS locations ten _miles_ apart, rather than ten _meters_. And when you have two dives that are ten miles apart, the fact that they happen to share a name absolutely does *not* mean that they are the same divesite. It just means that maybe later you might want to specify the name better. Or maybe you'll never get around to it. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
Okay,
This *seems* to be working, I tested it quite a lot to make sure I didn't
broke anything very obvious:
change the name of a dive site to something that already exists, it will
use the first dive site with that name from the dive_site_table
change the name of a dive site to something that doesn't exists, it will
create a new one
click on the name of a dive site on the drop_down list, it will store the
dive_site_uuid to use as the dive's dive site
On Mon, Jul 13, 2015 at 3:22 PM, Tomaz Canabrava tcanabr...@kde.org wrote:
Now it works.
(I think there's something missing, will keep working here)
From 90d1bf9f0f3a23d385dfa9616d8d3dd047129d74 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava tomaz.canabr...@intel.com
Date: Mon, 13 Jul 2015 15:38:46 -0300
Subject: [PATCH 4/4] Move code that handles Location to a sane place
Dark times are ahead upon us. So, This fixes a few thigns
related to Location Management, it is working :)
Signed-off-by: Tomaz Canabrava tomaz.canabr...@intel.com
---
qt-ui/maintab.cpp | 70 ++-
qt-ui/maintab.h | 2 +-
2 files changed, 19 insertions(+), 53 deletions(-)
diff --git a/qt-ui/maintab.cpp b/qt-ui/maintab.cpp
index c68138f..66e42e3 100644
--- a/qt-ui/maintab.cpp
+++ b/qt-ui/maintab.cpp
@@ -818,13 +818,24 @@ void MainTab::reload()
mydive-what = displayed_dive.what; \
}
-void MainTab::updateDisplayedDiveDiveSite()
+void MainTab::updateDisplayedDiveSite()
{
const QString new_name = ui.location-text();
const QString orig_name = displayed_dive_site.name;
const uint32_t orig_uuid = displayed_dive_site.uuid;
const uint32_t new_uuid = locationManagementEditHelper-diveSiteUuid();
+ qDebug() Updating Displayed Dive Site;
+ if(current_dive) {
+ struct dive_site *ds_from_dive = get_dive_site_by_uuid(current_dive-dive_site_uuid);
+ if (!dive_site_has_gps_location(ds_from_dive)
+ same_string(displayed_dive_site.notes, SubsurfaceWebservice)) {
+ ds_from_dive-latitude = displayed_dive_site.latitude;
+ ds_from_dive-longitude = displayed_dive_site.longitude;
+ delete_dive_site(displayed_dive_site.uuid);
+ }
+ }
+
if(orig_uuid) {
if (new_uuid orig_uuid != new_uuid) {
displayed_dive.dive_site_uuid = new_uuid;
@@ -835,7 +846,7 @@ void MainTab::updateDisplayedDiveDiveSite()
} else {
qDebug() Current divesite is the same as informed;
}
- } else {
+ } else if (!orig_uuid) {
if (new_uuid) {
displayed_dive.dive_site_uuid = new_uuid;
copy_dive_site(get_dive_site_by_uuid(displayed_dive.dive_site_uuid), displayed_dive_site);
@@ -854,6 +865,10 @@ void MainTab::acceptChanges()
struct dive *d;
bool do_replot = false;
+ if(ui.location-hasFocus()) {
+ this-setFocus();
+ }
+
acceptingEdit = true;
tabBar()-setTabIcon(0, QIcon()); // Notes
tabBar()-setTabIcon(1, QIcon()); // Equipment
@@ -866,7 +881,6 @@ void MainTab::acceptChanges()
struct dive *added_dive = clone_dive(displayed_dive);
record_dive(added_dive);
addedId = added_dive-id;
- updateDisplayedDiveDiveSite();
get_dive_by_uniq_id(added_dive-id)-dive_site_uuid = displayed_dive_site.uuid;
// unselect everything as far as the UI is concerned and select the new
@@ -925,7 +939,6 @@ void MainTab::acceptChanges()
MODIFY_SELECTED_DIVES(mydive-when -= offset;);
}
- updateDisplayedDiveDiveSite();
if (displayed_dive.dive_site_uuid != cd-dive_site_uuid)
MODIFY_SELECTED_DIVES(EDIT_VALUE(dive_site_uuid));
@@ -1406,54 +1419,7 @@ void MainTab::on_location_editingFinished()
return;
}
- QString currText = ui.location-text();
-
- struct dive_site *ds;
- int idx;
- bool found = false;
- for_each_dive_site (idx,ds) {
- if (same_string(ds-name, qPrintable(currText))) {
- found = true;
- break;
- }
- }
-
- if (!found) {
- uint32_t uuid = create_dive_site(qPrintable(ui.location-text()));
- ds = get_dive_site_by_uuid(uuid);
- if (same_string(displayed_dive_site.notes, SubsurfaceWebservice)) {
- ds-latitude = displayed_dive_site.latitude;
- ds-longitude = displayed_dive_site.longitude;
- delete_dive_site(displayed_dive_site.uuid);
- }
- displayed_dive.dive_site_uuid = uuid;
- copy_dive_site(get_dive_site_by_uuid(uuid), displayed_dive_site);
- markChangedWidget(ui.location);
-
- LocationInformationModel::instance()-update();
- emit diveSiteChanged(uuid);
- return;
- }
-
- if (!get_dive_site(idx))
- return;
-
- if (current_dive) {
- struct dive_site *ds_from_dive = get_dive_site_by_uuid(displayed_dive.dive_site_uuid);
- if(ds_from_dive ui.location-text() == ds_from_dive-name)
- return;
- ds_from_dive = get_dive_site(idx);
- if (!dive_site_has_gps_location(ds_from_dive)
- same_string(displayed_dive_site.notes, SubsurfaceWebservice)) {
- ds_from_dive-latitude = displayed_dive_site.latitude;
- ds_from_dive-longitude = displayed_dive_site.longitude;
- delete_dive_site(displayed_dive_site.uuid);
- }
- displayed_dive.dive_site_uuid = ds_from_dive-uuid;
-
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 11:47 AM, Tomaz Canabrava tcanabr...@kde.org wrote: change the name of a dive site to something that already exists, it will use the first dive site with that name from the dive_site_table Can you please make sure that this only happens if the GPS data is missing (or matches). I'd hate to lose GPS data again. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
This is the code that does (1) please check if I got it right. On Mon, Jul 13, 2015 at 4:24 PM, Tomaz Canabrava tcanabr...@kde.org wrote: On Mon, Jul 13, 2015 at 4:14 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jul 13, 2015 at 12:00 PM, Tomaz Canabrava tcanabr...@kde.org wrote: Just to be sure: If I have a dive with divesite Yellow House with gps coords then I write on it's dive site the name Leeds, it should reject because I have gps coords? So what I _think_ should happen is that you just create a new dive-site. You have a completely new dive site with a new name, and whatever GPS it had from before. Of course, if that new name and GPS then happens to match another dive site, at that point the two matching ones would be the same. But I think this depends on the interface. I think there are two very different models at play, and both are valid: (a) when you are editing a dive (or multiple dives) I really think that you need to automatically (and silently) just create new divesites when somebody edits things (and this would be true whether the name changed or the GPS location changed, or both changed). So this would be the quick-edit thing as part of the dive location. I'll focus on this part since it's what I'm doing now - there's no Dive Site Management Mode yet. Imagine that you have a dive with dive_site.name = Blue Hole with coords, but it was a mistake and you wanna change to Turtle Reef If the user types the name of a dive site, let's say Turtle Reef, it should list on the dropdown the list of all Turtle Reefs that it currently has ( plus the taxonomy or the gps coords if taxonomy is not found ) ( now I also think I should add the coords even if the taxonomy is found because we can have two 'blue holes' in the same country / place and such ) If the user clicks on a particular Turtle Reef from the drop down, it will select *that* dive_site to be the dive's dive site, replacing coords. If the user clicks in nothing ( but changed the name of the dive site to Turtle Reef), the user will have yet another Turtle Reef dive site created for him with no GPS coords. now here I can: 1 - copy the coords from the old dive site 2 - leave without no gps coords and ask him to enter it again. 3 - Change the name of the the dive_site to be 'turtle reef' 4 - Select the first Turtle Reef from the dive_table ans set it ( this is what my last patch does ) I'll create the code for 1. And - I wanna make something that will make you happy and not hatred, so that's why I'm asking a lot of questions here. (b) there's a separate issue of some dive site management mode which is independent of the actual dives. So this would be some totally different mode, where you are *not* editing a dive, but you are doing things like oh, let's clean up the name of that divesite that I've been to many times, or Ugh, I have ten copies of this dive site, and they differ in minimal ways in spelling or are 10m apart in the GPS location, I want to merge these into one single dive site. I think (a) and (b) are completely different things, and have to work very differently. When I'm editing a dive and filling in the information for that dive, doing dive site management is absolutely the *last* thing the interface should do for me. It's why I absolutely *hated* how subsurface worked when you typed and auto-completed a dive-site name: it ended up then throwing out the GPS location you already had, and replacing it with some old dive site data. Which is really seriously buggered, especially since dive sites with the same name really are not unusual at all (blue hole being the classic example, but one I know well is turtle reef, which is something Lahaina divers uses as a generic name encompassing many different dive sites, and if you didn't write up the actual specific name, you really can have Turtle reef with GPS locations ten _miles_ apart, rather than ten _meters_. And when you have two dives that are ten miles apart, the fact that they happen to share a name absolutely does *not* mean that they are the same divesite. It just means that maybe later you might want to specify the name better. Or maybe you'll never get around to it. Linus From e2460acddcfb87d6fb9291184fcd0c3fa475004b Mon Sep 17 00:00:00 2001 From: Tomaz Canabrava tomaz.canabr...@intel.com Date: Mon, 13 Jul 2015 17:11:03 -0300 Subject: [PATCH 5/5] Change Location Management to make Linus Happy Do not overwrite a dive site if the name is the same as any other dive site, create a new one and duplicate the information. Signed-off-by: Tomaz Canabrava tomaz.canabr...@intel.com --- qt-ui/maintab.cpp | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/qt-ui/maintab.cpp b/qt-ui/maintab.cpp index 66e42e3..2efaa52 100644 --- a/qt-ui/maintab.cpp +++ b/qt-ui/maintab.cpp @@ -841,8 +841,15 @@ void
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 1:17 PM, Tomaz Canabrava tcanabr...@kde.org wrote: This is the code that does (1) please check if I got it right. I'm not convinced that's right either. I suspect that if the dive site name matches an old dive site, and we don't have GPS location, we do want to take the GPS location from the old one. And maybe the same is true of things like dive site notes etc. HOWEVER. It's complicated by things like maybe we match an old dive site temporarily, ie we might be in the situation where we have two old (different) dive sites called Blue Hole and Blue Hole, Belize and as we type the dive site in, we first match Blue Hole, and then later match Blue Hole, Belize. Why does that matter? Because the first match might give us the gps location for Blue Hole, and then the second match sees that we now have GPS location information, and _not_ update this. We used to have exactly that issue with the old auto-complete of the dive site name. We ended up having a special flag saying whether the GPS information was manually edited or automatic. So selecting a dive site would overwrite the GPS data if it was automatic (ie from a previous dive site name match), but *not* overwrite it if it was manually/explicitly added. And I'm not sure that's the right solution either, but that worked very well in practice in our old model. You could switch between old dives sites (and that would switch between their GPS locations too), but if you *explicitly* set the GPS data, it ended up being sticky. Maybe the right thing to do is to never take GPS location and notes from a name match (like your patch seems to do), and simply make that part of the dive site management that doesn't exist yet. That at least wouldn't overwrite data by mistake, but it does sound like an extra (and inconvenient) step, so I don't really think that's a good model either. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 02:13:20PM -0700, Linus Torvalds wrote: On Mon, Jul 13, 2015 at 1:17 PM, Tomaz Canabrava tcanabr...@kde.org wrote: This is the code that does (1) please check if I got it right. I'm not convinced that's right either. I suspect that if the dive site name matches an old dive site, and we don't have GPS location, we do want to take the GPS location from the old one. And maybe the same is true of things like dive site notes etc. HOWEVER. It's complicated by things like maybe we match an old dive site temporarily, ie we might be in the situation where we have two old (different) dive sites called Blue Hole and Blue Hole, Belize and as we type the dive site in, we first match Blue Hole, and then later match Blue Hole, Belize. Why does that matter? Because the first match might give us the gps location for Blue Hole, and then the second match sees that we now have GPS location information, and _not_ update this. We used to have exactly that issue with the old auto-complete of the dive site name. We ended up having a special flag saying whether the GPS information was manually edited or automatic. So selecting a dive site would overwrite the GPS data if it was automatic (ie from a previous dive site name match), but *not* overwrite it if it was manually/explicitly added. And I'm not sure that's the right solution either, but that worked very well in practice in our old model. You could switch between old dives sites (and that would switch between their GPS locations too), but if you *explicitly* set the GPS data, it ended up being sticky. Maybe the right thing to do is to never take GPS location and notes from a name match (like your patch seems to do), and simply make that part of the dive site management that doesn't exist yet. That at least wouldn't overwrite data by mistake, but it does sound like an extra (and inconvenient) step, so I don't really think that's a good model either. One thing we should do is figure out what the behavior is that we want. Very, very crisply. Henrik, Davide, I'm looking at you here. Tomaz has redone this code three times now. Because the definition of what we should be doing is all a bit too much intuitively you do this and a bit too little of if (a) then b. Having Tomaz work on this is an amazing resource for us. We shouldn't waste this by sending him running in circles. Linus, I really appreciate that you are thinking this through and are explaining in detail what your thoughts are. That's really helpful. There are so many scenarios... we should really try to break them down and turn this into a decision tree... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: More Location Fixes.
On Mon, Jul 13, 2015 at 04:09:09PM -0700, Dirk Hohndel wrote: On Mon, Jul 13, 2015 at 02:13:20PM -0700, Linus Torvalds wrote: On Mon, Jul 13, 2015 at 1:17 PM, Tomaz Canabrava tcanabr...@kde.org wrote: This is the code that does (1) please check if I got it right. I'm not convinced that's right either. I suspect that if the dive site name matches an old dive site, and we don't have GPS location, we do want to take the GPS location from the old one. And maybe the same is true of things like dive site notes etc. HOWEVER. It's complicated by things like maybe we match an old dive site temporarily, ie we might be in the situation where we have two old (different) dive sites called Blue Hole and Blue Hole, Belize and as we type the dive site in, we first match Blue Hole, and then later match Blue Hole, Belize. Why does that matter? Because the first match might give us the gps location for Blue Hole, and then the second match sees that we now have GPS location information, and _not_ update this. We used to have exactly that issue with the old auto-complete of the dive site name. We ended up having a special flag saying whether the GPS information was manually edited or automatic. So selecting a dive site would overwrite the GPS data if it was automatic (ie from a previous dive site name match), but *not* overwrite it if it was manually/explicitly added. And I'm not sure that's the right solution either, but that worked very well in practice in our old model. You could switch between old dives sites (and that would switch between their GPS locations too), but if you *explicitly* set the GPS data, it ended up being sticky. Maybe the right thing to do is to never take GPS location and notes from a name match (like your patch seems to do), and simply make that part of the dive site management that doesn't exist yet. That at least wouldn't overwrite data by mistake, but it does sound like an extra (and inconvenient) step, so I don't really think that's a good model either. One thing we should do is figure out what the behavior is that we want. Very, very crisply. Henrik, Davide, I'm looking at you here. Tomaz has redone this code three times now. Because the definition of what we should be doing is all a bit too much intuitively you do this and a bit too little of if (a) then b. Having Tomaz work on this is an amazing resource for us. We shouldn't waste this by sending him running in circles. Linus, I really appreciate that you are thinking this through and are explaining in detail what your thoughts are. That's really helpful. There are so many scenarios... we should really try to break them down and turn this into a decision tree... OK, putting my money where my mouth is. 1. empty location field 1.1. no GPS data (so that means we had no dive site, I guess) 1.1.1, user types in name, picks one of the completions 1.1.2. user types in name, doesn't pick one of the completions 1.2. GPS data (e.g. from Subsurface web service - dive site with no name) 1.2.1. user types in name, picks one of the completions 1.2.2. user types in name, doesn't pick one of the completions 2. existing text in the location field 2.1. no GPS data 2.1.1, user types in name, picks one of the completions 2.1.2. user types in name, doesn't pick one of the completions 2.2. GPS data 2.2.1. user types in name, picks one of the completions 2.2.2. user types in name, doesn't pick one of the completions I'm sure I'm missing cases... what other scenarios do we need to consider? Right, for each of the cases above a) user clicks accept b) user clicks cancel So that's 16 scenarios so far... who can think of more? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
