plugdata-team / plugdata

Pure Data as a plugin, with a new GUI
https://plugdata.org
GNU General Public License v3.0
1.55k stars 65 forks source link

remove 'dot' from subpatches/abstractions and use the Vanilla mechanism instead #1660

Closed porres closed 4 months ago

porres commented 4 months ago

From the discord channel I see that PlugData tries to visually differentiate abstractions and subpatches to the user with a 'dot'.

I also see that it seems that Vanilla had no way to differentiate a box that it is an abstraction, for instance, so a mechanism for that was designed for PlugData. Well, the truth is that Vanilla has a pretty good and better strategy for it, where the mouse cursor points up and tells you that the object can be clicked to open if it is an abstraction.

But first of all, let me reason that it is not that important for users to know that an object is an abstraction, which are supposed to work as regular objects. I guess one proof of that is the incredible and unbeatable industry standard and state of the art software called 'MAX' that rules the world... it has simply NO WAY of telling the user that an object is in fact an abstraction.

I don't agree with that though, forgive me MAX. I guess people that see a [pd] object should know it can be opened... and help files of abstractions should tell people that the object is an abstraction. That is to say that it is not that bad, but having a way to tell the user you can click and open it could be useful, and this is what beloved Vanilla does.

So why not just do what Vanilla does? It will also make both more relatable!

And let me tell you other advantages of Vanilla's beautiful approach...

It will also tell you that you can click on GUIS, like a bang object. It will tell you that it is possible to click on an array to edit its contents. It will also tell you that you CANNOT click on it if array editing is disabled.

I also just tested a few things and I see that you fail to show users that they can click on [array define], for instance, as it has no dot... well, if the cursor changed to point up, it would be evident and good.

Note that some objects in ELSE can be clicked. One example is [loadbanger]. But in PlugData that is not evident.

It is not evident as well that you can click on a GUI like [function].

Anyway, please consider getting rid of the dot, which is also not clear at all what it is supposed to mean for for someone who is well versed with patching environments like me (with experience in MAX and many forks of Pd).

timothyschoen commented 4 months ago

From the discord channel I see that PlugData tries to visually differentiate abstractions and subpatches to the user with a 'dot'.

I also see that it seems that Vanilla had no way to differentiate a box that it is an abstraction, for instance, so a mechanism for that was designed for PlugData. Well, the truth is that Vanilla has a pretty good and better strategy for it, where the mouse cursor points up and tells you that the object can be clicked to open if it is an abstraction.

But first of all, let me reason that it is not that important for users to know that an object is an abstraction, which are supposed to work as regular objects. I guess one proof of that is the incredible and unbeatable industry standard and state of the art software called 'MAX' that rules the world... it has simply NO WAY of telling the user that an object is in fact an abstraction.

I don't agree with that though, forgive me MAX. I guess people that see a [pd] object should know it can be opened... and help files of abstractions should tell people that the object is an abstraction. That is to say that it is not that bad, but having a way to tell the user you can click and open it could be useful, and this is what beloved Vanilla does.

So why not just do what Vanilla does? It will also make both more relatable!

And let me tell you other advantages of Vanilla's beautiful approach...

It will also tell you that you can click on GUIS, like a bang object. It will tell you that it is possible to click on an array to edit its contents. It will also tell you that you CANNOT click on it if array editing is disabled.

I also just tested a few things and I see that you fail to show users that they can click on [array define], for instance, as it has no dot... well, if the cursor changed to point up, it would be evident and good.

Note that some objects in ELSE can be clicked. One example is [loadbanger]. But in PlugData that is not evident.

It is not evident as well that you can click on a GUI like [function].

Anyway, please consider getting rid of the dot, which is also not clear at all what it is supposed to mean for for someone who is well versed with patching environments like me (with experience in MAX and many forks of Pd).

I think we should do a hover colour for subpatches/abstractions. I tend to dislike cursor changes, since they turn out differently on every OS. And hover colour is a pretty universal way to communicate that something is clickable.

For example, pure-data's cursor changes for abstractions/guis work for me on macOS, but not on Linux.

porres commented 4 months ago

For example, pure-data's cursor changes for abstractions/guis work for me on macOS, but not on Linux.

oh really? didn't know that! Damn... I should take note on that and also update the manual! And talk to the Pd Gang why that happens...

and yeah, your idea is cool and makes more sense than what we have

timothyschoen commented 4 months ago

For example, pure-data's cursor changes for abstractions/guis work for me on macOS, but not on Linux.

oh really? didn't know that! Damn... I should take note on that and also update the manual! And talk to the Pd Gang why that happens...

and yeah, your idea is cool and makes more sense than what we have

For future reference, this was on Fedora 40 with GNOME. Cursor theme might affect on this too (I use the default for GNOME).

alcomposer commented 4 months ago

I think we should do a hover colour for subpatches/abstractions. I tend to dislike cursor changes, since they turn out differently on every OS. And hover colour is a pretty universal way to communicate that something is clickable.

Changing colour on hover would only solve this for non-touch devices? Also, it would only let the user know when hovering that the object is an abstraction / subpatch, not when viewing a patch, or sharing a screenshot / patch image.

I'm only pointing that out. No stress either way. :-)

porres commented 4 months ago

what are non-touch devices?

it would only let the user know when hovering that the object is an abstraction / subpatch , not when viewing a patch, or sharing a screenshot / patch image.

I think that sharing a screenshot / patch image shouldn't be a concern, really, and yes, only by looking at it, the user will not know that you can click on it or not. Just like right now no one really knows that you can click on [loadbanger], or [initmess], or [array define], or [text define], or other I'm not consciously mentioning or just not aware of... and the [else/button] GUI, or arrays (which can or cannot allow clicks)

alcomposer commented 4 months ago

what are non-touch devices?

A mouse, trackpad, or trackball user interface. All of these have hover, I also think Apple Pencil has hover. But touch with finger doesn't.

porres commented 4 months ago

I see what you mean now, but I ask, do you think that finger touchscreen should play that much of an important role on this project? I'm biased as I hardly used a smartphone in my life, I have no ipad or a touchscreen laptop, and I think it's a disastrous experience. Maybe it's my age, but even touchscreen controllers are a terrible idea to me but I can still concede in this performance/controller scenario. Never by a long shot on the production workflow though. One way or another, I feel that users will have to at least split the workflow and use mostly a computer with non-touch devices, right?

alcomposer commented 4 months ago

iPads work really well with plugdata. But I will let @timothyschoen decide this one without feeding back into it too much.

porres commented 4 months ago

You can at least have accessories for that like the pencil and keyboard... it's suboptimal if you ask me and I feel like ipad owners that work with music in this level might also have a laptop for the main production work :)

alcomposer commented 4 months ago

I just wanted to add that for me, subpatches / abstractions represent a structure within PD language. Like a directory structure:

So for me showing that a node is a subpatch, or branch is like seeing a flippy triangle in Finder, or folder icon etc. Its a way to say "this is where there are more nodes". I understand that "pd thing" means subpatch, but abstraction has nothing to differentiate, and in some cases it's much more powerful.