Is there any plan to allow some sort of sharing / collaboration ?

[Transisto]

I've been looking at MLO for many years but never got to using it because there is no and I fear there will never be any sharing and collaborating feature.

Maybe having a webapp view where the employee can just mark as completed or add comments to a list of task to do.

I'm currently using workflowy for that.  I think MLO is missing out on the network effect by not allowing a functional but limited free version that is web based.

[Joel Azaria]

I don't specifically agree with the web version idea but a better sharing and collab function I can definitely get behind.

As it stands there is a most rudimentary sharing that can use a shared folder on the local network (LAN) or an FTP server and you can share the whole file or just selective branches.  If you want to share the whole file I think cloud sync works as well but cloud sync won't support selective branch sharing.  And syncing is a manual process (remember to press F9 or changes won't propagate to the shared file).  It works decently* but has a very 1990's feel to it.

Conflict resolution (ie. if two people change the same record before/between syncs) is very much a manual process and better make sure people on both ends of the sync KNOW HOW to navigate it or expect someone will get into trouble.  

And for my 2c it's exactly that 1990's manual sync/conflict resolution logic that has to enter the 21st century before any of this can happen.  So long as all of this is manual (and the Cloud Sync service has done little if anything to improve this) any attempt at improving collaboration is just putting lipstick on a pig.

My 2c.  Possibly worth exactly what you paid for them... 

*it worked for me for a while but just the other day I lost an entire branch (my entire Inbox and Speedox) that I was sharing with my assistant.  We cannot tell for sure if the problem was caused by the sync or by manual error.  Make sure to crank up MLO's backup settings to the max (30 versions, use dailies, weeklies, monthlies and if I think of any other ways to capture add'l/further backups I'll be all over that too.)  Just a full disclosure fyi.

[Dwight Arthur]

Joel: I'm interested in your views regarding 21st century collaboration. If you and your assistant make different chsnges at the same record/task, what would happen?
-Dwight
MLO Betazoid on Android SGN4

--
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 mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.
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/213e1dd9-fc00-4e28-bf8d-109cb458bfed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Elizabeth Lindsay]

I feel like I'm a user on an island.  I don't want to share.  When I share, I have a totally different structure of tracking a project.  When it is "my" project and I have an element that is "waiting for", I don't need a full-blown separate tool, I just use contexts.  I really prefer MLO to be individual.

[Joel Azaria]

Hi Dwight, 

Must've missed your reply but better late than never - 

When you say "different changes to the same record/task" I'm assuming you mean that we change two different fields on the same record, ie. I add to the notes and she changes the due date and reminder, is that your question?  If so, they changes should be merged as there is no true conflict.  My changes don't alter or affect hers nor vice versa.  For the ultra paranoid (of which I confess I'm sometimes one) a resolution dialog could pop up highlighting the changes and offer the merge.   The only "special" case I can think of off-hand is marking a task as complete.  Certain actions may conflict with this (ie. I mark smth complete and she changed the reminder, start or due date to some point in the future.  Again though the solution would be to determine if any true conflict exists and then ask the user.

Now if your question is what happens if we both change the due date, the solution is to check first if we both changed it to the same value (because if so, then there really isn't a conflict.)  If a conflict actually exists, ask the user.

And I'll add that for this to work well, the existing conflict resolution dialog has to be reworked.  Currently it's a horrid mess that only a programmer would be comfortable to navigate and beyond a handful of conflicts quickly grows tedious and counter productive.  That however is a question you did not ask and will be left for discussion at another time.

[Joel Azaria]

Oh for the record, I came to the forums today to report that MLO yesterday ate the exact same branch AGAIN.

Thankfully I have the tools and know-how/skillset to recover from this (AGAIN) but even then it is T E D I O U S.

And frankly wearing thin.  Honestly, how a simple sync can be so damned broken is ponderous.  It's 2016.  Is it so wrong to expect certain things to just work?  Frankly most of the ins and outs of sync were worked out in the 90's.  I don't remember having nearly as many problems syncing DOZENS of apps (and one in particular that was EXTREMELY SIMILAR to MLO) on the Palm platform.  That covers a Palm III, a IIIxe, a Handspring Visor, a Tungsten E, then a Treo 600 a 755 and then a Centro - some 15 years +/- of usage - with all my apps and data carrying through day by day, device to device, with hardly ever a data loss that came from sync (actually none that I remember but let's be realistic, it could have happened and I don't recall, we're talking at least 5-7 years ago I left the platform and my tenure spans back to the very early 90's)

If sync logic and conflict resolution was worked out that far back, what Mars Rover challenges has MLO introduced in the last 5-10 years that are so difficult to overcome?  Or is the sync just not well conceived...

I'd have to vote for the latter because in 2016, data loss is just verboten.  We're not talking about an amateur programmer and some shareware hack - this is a $70 per license, supposedly polished, business productivity app.  

Data loss = face palm fail.

[Joel Azaria]

Dwight, to add to my earlier comment - 

Here's a screencap of MLO showing conflicts resolution.

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.

On Thursday, December 24, 2015 at 7:15:20 PM UTC-5, Dwight Arthur wrote:

[Dwight Arthur]

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.

[Joel Azaria]

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.