<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Let's simplify.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In Pd vanilla the file abstraction UX works like this:</div><div class="gmail_default" style="font-family:verdana,sans-serif">1. Create a new file and save it, with or without some editing.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2. Load as object in desired patch; open and edit.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">3. Eventually you have multiple instances. If you edit one and forget to save, you can edit another instance and lose everything from the first one if you save in the second one.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">4. Somewhat inexplicably, there is a failsafe check in Pd (but not in Purr I think?) where if the instance canvas is dirty and you do something that selects the text of the corresponding object instance – you move it, or you click in the text field – you get a prompt which asks you if you want to save it.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">5. If you edit an instance but don't save, and then load a new instance, none of those edits appear.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The reason for a failsafe on 4 but not on 3 I think is just because it's a lot easier to implement, and would be kind of a pain for the user to have to pop every dirty instance and ask if you wanted it to be saved... saving a dirty canvas means that you're planning not to save changes in any subsequent one, so it should probably exit after any "Yes" selection. But that's a pain, so it's not a feature, and so users just get used to saving appropriately and crying if they accidentally kill a night's work.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">--------------------</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">So for [ab ] objects, the UX could be more or less identical, but there are two options:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">A. [ab ] canvases themselves are marked dirty, and saving them updates the definition in memory but not in the file. To do that, you have to save in a root window or [pd] subpatch etc.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">B. a change in an [ab ] canvas marks the root dirty, as with [pd ] canvases. Suppose you've edited several instances without an intervening save, when you do save, which of the edits should be saved? Probably whichever one was most recently edited, and damn the rest, with wailing and gnashing of teeth if you edited the wrong one most recently.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I *think* that the 4. failsafe above would be possible with both of these options. And if you went with option B. here, there's no harm if, as with 5. above, new instances don't reflect unsaved changes, so long that making a new instance doesn't count as most recently edited – the user will probably default to "oh shit forgot to save" and then save immediately, so that should reflect the desired result. I think both options are also compatible with an [ab define].</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Dynamic patching marks no canvas as dirty unless there are mouse/keyboard events. Assuming there aren't, with option B, a save should not save the dynamically patched results of any instance, but keep the original definition. Option B. amounts more or less to keeping track of a pseudo-dirty flag on each [ab] canvas, reflected as an actual dirty on root.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I think all of this is also compatible with implicit storage of the definition or with [ab define] templates.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">----------------------</div><div class="gmail_default" style="font-family:verdana,sans-serif">LATER</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">consider a better failsafe for file abstractions and [ab ] abstractions.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">--------------------</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Am I missing anything obvious?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 10:45 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Aug 13, 2020 at 6:38 PM Guillem Bartrina<br>
<<a href="mailto:guillembartrina@gmail.com" target="_blank">guillembartrina@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> in the last meeting we discussed a bit about the fact the way ab private<br>
> abstractions are saved (so the definition is updated) is a little<br>
> counter-intuitive for users (e.j. creating a new instance of an<br>
> abstraction that hasn't yet been saved gives us an empty canvas).<br>
><br>
> On the one hand, I don't see a major issues here. The user just has to<br>
> get used to saving the abstractions when he finishes editing them.<br>
><br>
> On the other hand, there is the UX side. We can think of a situation<br>
> where the user has edited the definition somewhere and forgot to save it<br>
> (so it is still dirty) Then he creates new instances and they don't look<br>
> as they should, so the user has to find the dirty canvas (perhaps among<br>
> many others) and save it.<br>
<br>
Just as a measuring stick-- I think the ideal UX would be that any change a user<br>
makes to a given instance *immediately* updates in all the other instances. Such<br>
a design would remove the entire concept of a "dirty" [ab] so that "dirty" only<br>
applies to the parent canvas.<br>
<br>
I *think* implementation details of Purr Data rule out such a design,<br>
but I did want<br>
to mention it as something to measure UX against.<br>
<br>
><br>
> An easy solution we came up with was to open the save dialog (Yes, No;<br>
> the Cancel option doesn't make sense) within each dirty canvas every<br>
> time we create a new instance (or when we close the file). The problem<br>
> here is the case when we have multiple dirty canvases of the same<br>
> private abstraction.<br>
<br>
Or even of different private abstractions. This is a problem with file-level<br>
abstractions, too. It quickly becomes untenable to track what's going on when<br>
abstractions keep popping up to ask for permission to be saved. At least in<br>
my own experience, when the number of abstractions that pop up to show<br>
the dialog is greater than 1, there is a 100% chance that I've forgotten<br>
what I was doing and can no longer provide a useful answer to the dialog. :)<br>
<br>
><br>
> Do we want the user to go one by one, choosing Yes or No and keeping the<br>
> definition of the last Yes-ed canvas? Or when the first Yes is clicked,<br>
> all the remaining dirty canvases are discarded?<br>
><br>
> Another approach could be to simply warn the user about the existence of<br>
> dirty canvases of that private abstraction.<br>
><br>
> Another could be a custom dialog (maybe using dialog_external) where all<br>
> dirty canvases are listed and the user has to choose either one or none<br>
> of them.<br>
<br>
I see at least one special case:<br>
<br>
1. I create [ab new]<br>
2. I add some content to it.<br>
3. I may or may not close the window for [ab new].<br>
4. I create another [ab new].<br>
<br>
In all cases I can think of, the user will want that 2nd instance to<br>
be filled with the<br>
contents they added to the 1st instance, *regardless* of whether they saved the<br>
contents in the first instance.<br>
<br>
Also: if I create [ab new] and there are currently no definitions for<br>
"new", shouldn't<br>
the subpatch window automatically be displayed like [pd]? What's the<br>
use case where<br>
the user doesn't immediately want to start adding content to that<br>
private abstraction?<br>
<br>
><br>
><br>
> Tomorrow I will also write about the absontrol/absanity topic and some<br>
> other things.<br>
<br>
Sounds good!<br>
<br>
Best,<br>
Jonathan<br>
<br>
><br>
> Best,<br>
><br>
><br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div>