[L2Ork-dev] Patch private abstractions

Thu Aug 13 23:52:45 EDT 2020

Let's simplify.

In Pd vanilla the file abstraction UX works like this:
1. Create a new file and save it, with or without some editing.

2. Load as object in desired patch; open and edit.

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.

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.

5. If you edit an instance but don't save, and then load a new instance,
none of those edits appear.

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.

--------------------

So for [ab ] objects, the UX could be more or less identical, but there are
two options:

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.

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.

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].

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.

I think all of this is also compatible with implicit storage of the
definition or with [ab define] templates.

----------------------
LATER

consider a better failsafe for file abstractions and [ab ] abstractions.

--------------------

Am I missing anything obvious?

On Thu, Aug 13, 2020 at 10:45 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Thu, Aug 13, 2020 at 6:38 PM Guillem Bartrina
> <guillembartrina at gmail.com> wrote:
> >
> > Hi,
> >
> > in the last meeting we discussed a bit about the fact the way ab private
> > abstractions are saved (so the definition is updated) is a little
> > counter-intuitive for users (e.j. creating a new instance of an
> > abstraction that hasn't yet been saved gives us an empty canvas).
> >
> > On the one hand, I don't see a major issues here. The user just has to
> > get used to saving the abstractions when he finishes editing them.
> >
> > On the other hand, there is the UX side. We can think of a situation
> > where the user has edited the definition somewhere and forgot to save it
> > (so it is still dirty) Then he creates new instances and they don't look
> > as they should, so the user has to find the dirty canvas (perhaps among
> > many others) and save it.
>
> Just as a measuring stick-- I think the ideal UX would be that any change
> a user
> makes to a given instance *immediately* updates in all the other
> instances. Such
> a design would remove the entire concept of a "dirty" [ab] so that "dirty"
> only
> applies to the parent canvas.
>
> I *think* implementation details of Purr Data rule out such a design,
> but I did want
> to mention it as something to measure UX against.
>
> >
> > An easy solution we came up with was to open the save dialog (Yes, No;
> > the Cancel option doesn't make sense) within each dirty canvas every
> > time we create a new instance (or when we close the file). The problem
> > here is the case when we have multiple dirty canvases of the same
> > private abstraction.
>
> Or even of different private abstractions. This is a problem with
> file-level
> abstractions, too. It quickly becomes untenable to track what's going on
> when
> abstractions keep popping up to ask for permission to be saved. At least in
> my own experience, when the number of abstractions that pop up to show
> the dialog is greater than 1, there is a 100% chance that I've forgotten
> what I was doing and can no longer provide a useful answer to the dialog.
> :)
>
> >
> > Do we want the user to go one by one, choosing Yes or No and keeping the
> > definition of the last Yes-ed canvas? Or when the first Yes is clicked,
> > all the remaining dirty canvases are discarded?
> >
> > Another approach could be to simply warn the user about the existence of
> > dirty canvases of that private abstraction.
> >
> > Another could be a custom dialog (maybe using dialog_external) where all
> > dirty canvases are listed and the user has to choose either one or none
> > of them.
>
> I see at least one special case:
>
> 1. I create [ab new]
> 2. I add some content to it.
> 3. I may or may not close the window for [ab new].
> 4. I create another [ab new].
>
> In all cases I can think of, the user will want that 2nd instance to
> be filled with the
> contents they added to the 1st instance, *regardless* of whether they
> saved the
> contents in the first instance.
>
> Also: if I create [ab new] and there are currently no definitions for
> "new", shouldn't
> the subpatch window automatically be displayed like [pd]? What's the
> use case where
> the user doesn't immediately want to start adding content to that
> private abstraction?
>
> >
> >
> > Tomorrow I will also write about the absontrol/absanity topic and some
> > other things.
>
> Sounds good!
>
> Best,
> Jonathan
>
> >
> > Best,
> >
> >
> >
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200813/d7874d9b/attachment-0001.html>