No worries Dwight. I'll reply in contexts below. On Friday, February 5, 2016 at 11:48:33 AM UTC-5, Dwight Arthur wrote: > > Hi, Joel. Sorry that it too so long to reply, but when I viewed your > screencap on my phone, I couldn't get the display resolution high enough to > be legible. I had to wait until I could see it in Windows :( > > I've been using sync since the days of synching Lotus Notes on the > mainframe with cc:mail on my pc, maybe in the late 1980's. I have hated > most synch processes in that time, and the first ones that I really liked > have been recent Google products. The ones I have hated the most have been > the ones that have done what you want, using some algorithm to decide what > I was trying to do and change my stuff to match it's vision. Invariably, > even if the algorithm is right most of the time, it will eventually get it > wrong. The smarter and the more powerful the algorithm, the harder it is to > notice that something has gone wrong, to dope out just what exactly the > blasted thing was trying to do, and to fix it. Following long hard > experience and many bitter late-night hours, I have a deep distrust of > algorithms that try to know what I want better then I do. >
I too have a long history with 'sync' technologies and I understand quite thoroughly your feelings. I think you misunderstand my intentions though - I'm not advocating for smart sync algorithms but rather simply that our sync be smart enough to not call a conflict something that really isn't. For example when I change a note and my assistant changes a due date - there is no conflict. Or if I change a due date and she changes it to the same thing - there is no conflict. This is precisely what google sync is doing* However in all cases, if there's even a slight ambiguity or question, I would advocate to err on the side of asking the user. That was my point about marking a task complete being special - any other change to the task record might indicate it's not complete and so any move at that point is ambiguous. Ergo, ask the user. *Google sync has another component that preempts conflicts and that is that all changes are pushed immediately. This decidedly lessens any chances of changes elsewhere conflicting because it increases the chances that changes elsewhere already see the most current data. If our 'cloud' sync provided such functionality we'd perhaps be a very long way closer to a resolution but it does not and so we are not. > > On the whole, I find MLO above average, mostly because of the conflict > resolution screen which you find offensive. > To be clear I don't find the resolution dialog offensive I find it unpolished. Very big distinction to me. The dialog is needed and a best friend at times, in concept, but it's execution and lack of finishment is a hindrance and in some cases (as the one I pointed out) a detriment. However MLO is far from above average as today's world most consumer facing software has already adopted the cloud models a la Google so that these issues do not exist. For reference see Todoist, Nozbe, Nirvana, RTM, Toodledo, Producteev, and even gmail, gcalendar, et al. Most if not all of these do not even have a "conflict resolution dialog" in there lexicons. It simply doesn't exist. > I do not always understand what this screen is up to, but I like it > because it clearly shows me that the algorithm is about to try something > and gives me a chance to stop it. > And so you've already made my point. There should not ever be a case where two power users such as you and I would "not always understand what this screen is up to" In simple terms if I can't figure what is going on here, what snowball's chance in hell does a basic user or even average power user have? I've been at the tech edge of the tech game for 30 +/- years now. If I can't do it how can we expect my sister or my mom (the "average" user bases - young and old) to do it? The answer is *we can't*. > > I can't comment on what "normal" people would think of your conflict, as I > really do not understand "normal" people. I'm clearly not normal because I > have written code that uses GUIDs. > Thankfully to a degree I can. I confess I'm not "normal" either but I provide support, assistance and even education to "normal" users and have for a long time. On that basis I'd say I have a slightly "enriched" viewpoint - being of technical mind but having access and insight and often "walking and working with" the "normal" ones. > (https://en.wikipedia.org/wiki/Globally_unique_identifier) > But here is how I would read it: > The selected task has been moved in the local tree and has also been moved > on some other profile that syncs with the local tree. The two moves ended > up with the task in two different places, involving different parents and > also involving different positioning in the branch under the new parent(s). > Chances are that the positioning under the parent is a side issue with the > main issue being the different parents. If I got this message I would > cancel the sync and then go to my local tree to see where the task is now > located. Perhaps that would give me enough information to know how to > resolve the issue, if not I would go to the other platform and see what is > going on with this task there. Chances are, on my profile anyhow, that any > task at position 12,301 would be in the Inbox which probably means that the > local tree has it in a better place. I would pick which location seemed > more useful then restart the synch and adjust the conflict resolution if > necessary. > Thank you for the link Dwight but I quite well understand what it is and in fact I rather interpreted this example the same way. Be that as it may, the dialog and information it presents is useless in making a *decision*. The only thing I know is that something somewhere didn't land as expected. I can now launch a full scale investigation of my Android, my MLO-D and my assistant's MLO-D which seems like an absolutely spectacular use of my precious time (and doesn't guarantee that I'll get to the bottom of it) because what's the likelihood that I was syncing my todo system just now because I had something to do? /sarcasm > > Could this be improved? Yes, of course. I think that the biggest issue is > that displaying GUIDs to users almost never ends well. > Unless your users are programmers it's not almost. It's never. > There should be some unambiguous yet easily understood identification of > the task's parents in both trees. > At least NAMING the previous and new parents would be more helpful. A VISUAL representation of what's happening might actually be deemed *useful* > Also, loss of data as a result of dysfunctional synch is clearly and > absolutely wrong. > *Beyond agreed*. And to be clear, the data lost was not that which is shown in the conflict box. The conflict box data shown persisted (although I still have no idea why MLO thinks Parents changed - as best I can tell they were not.) The data that disappeared did so through **silent** wizardry and black magiks. > > But I would not be recommending GUID hiding to the developers as I would > rather see their resources put into preventing conflicts rather than > cleverly resolving them. If you fully synch every change before the next > change is made, there will never be a conflict. > I would like to see developer resources go to fixing flaws before cosmetics as well but there is no question that *both* seriously need attention. As for fully syncing every change that's almost preposterous as MLO doesn't keep a transaction log but rather a full backup of it's file after every sync and further limits those backups to *30*. On many days it would be possible and even likely to barrel right through that limit (and thus start rolling over needed backups) even before the error is caught. On the first occasion of this data loss that was precisely what happened and I ended up having to hand merge/resolve the files (from my Android profile if memory serves) at a cost of days effort and about a week+ of no MLO. > That, Joel, is my view of a 21st century synch, one where you and your > assistant set out to modify the same task but one of you gets there first > and a half second later when the other one goes to make a change, the first > change is already there. You should not worry too much about simultaneous > changes as Einstein showed that simultaneity is impossible. The worst that > should happen is that one of you gets a message that says - sorry, couldn't > save that change because Joel was changing that task, please try again. > However the reality is, at least in my case, that such contention does not occur. We are rarely working in MLO at the exact same time let alone changing the same tasks at the same time. What's more likely in our use case is that she batches up a bunch of changes and hasn't yet synced or I've not synced before I make an entry or change. Let's not complicate the issue more than it is by supposing non-existant edge cases, though in either your supposed edge case as well as my reality, a sync mechanism that is automatic and pushes changes (to all live nodes) the instant they're committed (eg. as does Google's sync) does make the chances of these issues much more negligible. > > On Wednesday, February 3, 2016 at 7:22:55 PM UTC-5, Joel Azaria wrote: >> >> Dwight, to add to my earlier comment - >> Here's a screencap of MLO showing conflicts resolution. >> >> >> <https://lh3.googleusercontent.com/-9HQzq8j_BNs/VrKYK7vCglI/AAAAAAAACLk/NHp4jloNqKw/s1600/Conflict%2BResolution%2Bdialog.jpg> >> >> >> Look at the "conflicts" and tell me what any "normal" person will make of >> this. What "conflict" actually exists? Is any non-MLO programmer supposed >> to even have a concept of what a GUID or the Position at parent is? And >> even if they are technically adept (as I am) and understand to a degree >> WHAT these things are, how shall I interpret this data? Do I know for what >> earthly reason MLO changed the Parent GUID or Position and based on this >> "display" of the "conflict" how do I interpret which direction is "better" >> to resolve this? >> >> My best guess here is: I have no f*****g clue why the GUID changed, it >> MIGHT be related to moving the task in the tree but that's not obvious and >> even if that IS the reason here I don't see why MLO can't resolve this on >> it's own. Assuming for a moment however that MLO *CAN'T* resolve this >> on it's own, what on god's green earth am I supposed to do with the >> information *as it's presented* to fix it? If, *IF, *MLO truly can't >> figure out on it's own what to do here, could not the *humans* behind >> MLO's programming come up with a better way for other *humans* to >> understand and interpret what's being asked of them here? It's a >> rhetorical question - the answer is yes - IF they'd invested the care or >> time. This dialog was acceptable during development and for >> *programmers* to understand. This is just lazy and pointless to foist >> on end users. I'm technically adept guy. If I can't make heads or tails >> of this, how do you think it strikes the "90%" who are not? >> To me it's obvious that they just never went back and polished this turd >> (or worse - they have no concept of how utterly useless it is.) >> >> So when you ask what I would call 21st Century sync or collab I want to >> be clear that there's a ton of things that need addressing, particularly >> beyond/outside of the flawed and lossy sync algorithms I spoke about >> earlier, and I could probably write novellas on it if i were so inclined >> but given the lack of participation and openness the devs display here and >> lack of any *real* inclusion of the users in the dev process I see no >> reason to invest that kind of time and effort only to watch it fall on deaf >> or non-caring ears (or worse, not even reach the ears at all.) >> >> Before we get 21st century sync or MLO we'll need 21st century >> development. Despite a number of [shallow imo] efforts to portray >> themselves as such I still think [actually I KNOW it in my bones] they just >> don't get it. >> >> As a simple example, Andrey showed us that he's aware of Trello in a blog >> post. I certainly hope then that he's aware of Trello's development. To >> date though I see that he's taken no cues from it in terms of letting his >> users in on even a simple dev roadmap. We know as much about and have had >> as much input into MLO-D v5 as we did into MLO-a v2 right up to the time an >> actual installable binary appeared. >> And by that I mean we have a couple of "pretty" screenshots and heck of a >> lot of silence. >> >> If MLO corp wants users like me (or anyone for that matter) to >> contribute and collaborate with them then I expect them to treat the users >> as contributors and collaborators. At the VERY LEAST that means starting >> and maintaining an open, truthful and timely dialog and demonstrating a >> willingness to take user input, direction and needs/requests seriously. >> None of which has even remotely been demonstrated beyond some hollow >> *words*. >> >> >> So until such time that they make any real efforts we are just >> unwittingly drafted "bug finders" (often by accident) paying and working >> for post-reactionary development that lives in a vacuum. >> >> >> hth, >> J. >> > -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/bee58df4-18d2-4da8-bad8-d0dc6d21d840%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
