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. On the whole, I find MLO above average, mostly because of the conflict resolution screen which you find offensive. 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. 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. (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. Could this be improved? Yes, of course. I think that the biggest issue is that displaying GUIDs to users almost never ends well. There should be some unambiguous yet easily understood identification of the task's parents in both trees. Also, loss of data as a result of dysfunctional synch is clearly and absolutely wrong. 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. 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. 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/d4195bef-8239-49ca-9d1d-12e6aff0599c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
