Behaviour Editor: Break Link Can Occur miles from link
-
Yeah I find myself breaking links by mistake all the time and not even realising it, getting me frustrated wondering why it’s not working.
-
This has gotten ridiculous. So, if you don't mind, I'll communicate appropriately:
Think Fruit Ninja and Cut the Rope, and every other convention of slicing a thin link ON A TOUCH SCREEN.
Then consider the area, context and expectations of touch screen users (on iOS, in particular) and all the other factors required to make an ideal, and begin from there.
Thinking about this problem in isolation leads to ridiculous mistakes.
Like there being no visual indication of a selected “behaviour” node.
And showing selected nodes as selected nodes should be pretty high up on your todo list because you’ve got an undoable, utterly destructive delete operation right next to a duplicate operation on buttons that are already less than the 44 point minimum recommended by Apple. So… I guess, given that, it shouldn’t be too much of a surprise that “touching” a link/connection will delete it.
I recommend at least a cursory glance at the HIG of Apple: It isn't perfect, but wasn’t written by complete muppets.
The idea that you can touch a link is where you got lost. You can’t conceive of it (as a user) nor is it easy to execute. It’s a destructive action on a proactive choice that’s not discernible. How this crossed anyone’s mind as a good idea, in a space without UNDO, is utterly beyond my comprehension.
And it’s not something to be thinking about when the known and recognised convention for slicing exists. This is, after all, an engine for making games. There’s no conceivable world where you two (Ham & Murt) haven’t at least been exposed to Cut the Rope, Fruit Ninja and all their resultant conventions and clones.
So, first, fix the fact that selected nodes aren’t visually indicated. This is the single biggest problem in the UI and UX of the Behaviour Editor.
Yes, this is a bigger problem than the lack of UNDO. Bigger than calling nodes “behaviours” and the weird descriptive sentences that creates, too.
Once that’s fixed, any single finger swipe gesture that crosses over a link/connection (to the currently selected node) slices that connection.
You only need create a state (of a node) when its connectivity/links can be sliced as opposed to when they can’t, so you can continue to retain a single finger swipe gesture ifor drag-to-select… when that feature comes to the “Behaviours” Editor.
This state already exists, it’s when a node is selected.
But nobody knows which is selected… because there’s no visual indicator…
Now do you get why I’m ranting? You’re compounding problems because you’re not dealing with the original problems nor, seemingly, even recognising the original problems of the UI and UX, and how they create the subsequent problems, so you’re seeking yet another “remedy” that’s going to make ever greater future problems and ever more need for “focus” groups.
This is all so simple to solve: show the currently selected node with a highlight (and/or shadow) and place its connections/links into a sliceable state, by “elevating” them with a very slight shadow.
Now the user knows those links/connections are special and different (in state) from all others on the screen, and that they can probably interact with them. And there’s a fun way to do just that, slice them!
But this only gets more logical when you see how many other problems have to be dealt with in terms of the current UX and UI…
EXAMPLE USAGE: the user can select a node, slice its connections/links to parents and children, drag it off to the side for safe keeping, and turn it off, before replacing it for creativity exploration, testing ideas, iteration, debugging, etc.
Why: because there’s no UNDO, no copy/paste of nodes and no other ways of safe iteration, debugging, idea testing or creative exploration. So you have to get this right, make it fun and enjoyable, rapid and discernible, all because the primary uses of slicing connections is as workarounds for missing functionality and features. Problems of your creation, largely by omission.
Sensing some condescension and arrogance? Sorry about that. It was all I could do to suppress the disdain.
-
I agree that we need to bring back behaviour focus when it is selected. I was never happy it was removed in the first place.
I don't like the idea of a swiping gesture to cut the line. Yes it works in games like fruit ninja or cut the rope. But thats because the only interaction you can do is slice. I feel like in hyperPad it will be to finicky, and cause issues.
That being said, I like the idea of having the connections only being able to be disconnected while the behaviour is in a selected state.Maybe the circle that the lines come from turns into a cut icon when the behaviour is selected. And just tapping that will remove that connection. Or just put a cut icon in the middle of each line when the behaviour is selected.
-
Your "way" adds needless steps, needless adornment, needless coding effort and restricts future directions of interactivity creation on links/connections.
But it’s the extra steps that are the worst part.
I think you’re just making work for yourself and arguing for the sake of it.
But I'm getting ahead of myself. It's not right to expect users to conceive of touching links/connections to be possible, or a thing, for deletion because of what those links are, and how they're represented and their responsiveness (or lack thereof). There are some node editors in which this does make sense, and nearly all of them have visual indicators of where a link/connection can be touched, by way of an adornment. Some of these adornments have purposefulness, too. Actually, most of them do.
Eventually you’re going to want to have that same purposefulness, or at least some of it, at which point you’re going to need that adornment. Bug testing, flow analysis, messaging analysis, control behaviours, branching etc… all sorts of things can be done “midstream” through these links that will eventually become channels of communication that are transparent to users in different ways. Right now they’re virtual channels of communication without anything else about them.
Slicing them is both the most accurate and the most efficient way to isolate a “behaviour” and comes with one enormously powerful addition that no other means has -- it permits the complete isolation of a behaviour from ALL of its children (or parents) in one gesture. You can slice, in one gesture, all links above or below a selected behaviour. And, for those of us that really use your app and have to contend with the fact that there's no UNDO, this is the way to replace behaviours in the safest possible way for experimentation, discovery, iteration and creative development.
Trust me, slicing is the answer you’re looking for. This wasn’t dreamt up by me in a heartbeat, and I’m only using Cut the Rope and Fruit Ninja as one of hundreds of possible examples because they’re funny and pertinent to games. Anywhere there’s visual linking, with lines, on a touchscreen, slicing is the right answer. I shouldn’t have to explain this.
It’s so blindingly obvious.
Again, touching lines isn’t and shouldn’t be a thing until you have adornments because you need them for what happens along the lines of communication that a link/connection indicates. This is going to be something you’ll want, not just for branching, but also for debugging checkers and all the other goodies that should go along these links. Slicing should be the simplest possible action to break a link, or many links, in one gesture.
Think bigger. Don’t think just about this problem. Think about the next ones.
And keep considering the ideal, and the ideals of current usage within the current sphere of problems.
Slicing is the metaphor that’s fun, and it’s the only way to make this decisive and enjoyable, and work in exactly the way it should, and retain the rest of the control that’s ideal… the stuff you aren’t yet considering, and the problems that users have to currently contend with in terms of hyperPad limitations i.e. that users need to replace “behaviours” because of all the things missing… like UNDO.
Want more evidence of swiping/slicing’s ubiquity on iOS?
Open your Mail app. Swipe left on a mail item. See that? Swipe all the way left and it’s gone, in one gesture. Getting things to the minimal number of appropriate gestures is the goal. Slicing is the appropriate gesture, and a foundational tool in the armoury of a touch user, ESPECIALLY ON IPADS!!!
Slicing got so popular that it became part of the first Twitter app on iPad, and hasn’t looked back since, now becoming the default operation to categorise away/out and delete with a full slice/swipe.
-
What's the extra step in my way vs yours?
If I read yours correctly the user needs to
- Select behaviour
- Swipe the connected line to delete it
My way:
- Select the behaviour
- Tap icon on line to delete it.
Comparing the swiping gesture in a list item/table is not the same as swiping to delete a connecting line. I don't think the UX translates since the displayed UI is so drastically different.
Note: I'm not saying that the swiping gesture wouldn't fit. I just don't think it's as obvious as you think it is. Even the swipe gesture on iOS goes unnoticed.Either way we'll do testing and see what works. But just thinking about it now, I can see the gesture getting in the way of other planned functionality.
Any ways, we get the feedback. No need to write another book on it ;).
-
@Murtaza said in Behaviour Editor: Break Link Can Occur miles from link:
Either way we'll do testing and see what works. But just thinking about it now, I can see the gesture getting in the way of other planned functionality.
-
@Murtaza Even just only being able to tap to remove wires only while the parent behaviour is selected would be good. I agree though swipe to cut wires wouldn’t be good.
-
@Aidan-Oxley said in Behaviour Editor: Break Link Can Occur miles from link:
tap to remove wires
Think this through.
-
@Deeeds I’ve been using tap to remove wires for ages, and I mostly like it, nice and simple and quick, but I like what @Murtaza said they might change with them, mainly only being able to cut them when the behaviour is selected. I still think swipe to cut wires would be bad. If you have swipe to cut wires, then what happens when you try to drag the screen somewhere else?
Random side note: what are they actually called anyway? I call them wires because all the way back in GamePress they were curvy and looked like wires, I think they may have even had plug like graphics.
-
One place I could actually see swipe to cut wires working is if a side menu is added (similar or identical to the small menu on the right of the screen in scene editor, which would actually be pretty useful). Otherwise, swipe to cut wires and drag to move screen will not work together, even if swipe to cut wires becomes active when a behaviour is selected, because there are times when I need to move the screen around with a behaviour selected.
-
@Aidan-Oxley I know you're good with "tapping on wires". It's all you've known.
FWIW, I agree with you, in terms of an immediate, low effort, instant fix: the best immediate fix is to restrict deletion by direct touch to ONLY those wires that connect to the currently selected Node.
The other thing to do, make sure there's a visual indication of the currently selected Node.
To talk about UX and UI without having addressed this issue of selection indication is missing wood for trees.
-
@Aidan-Oxley Swipe to cut wires ONLY works for wires coming from the selected item, and only from within a screen based proximity to a wire. It's not like you can drag your finger across the screen and slice every wire you see.... but you can slice every wire from underneath or above a node, in one movement. This is the greatest power move of this feature.
As to pan and zoom... that's two fingers!!!
One finger is either drag to select a region (everywhere when there is no node selected) or it's drag to select a region when away from the wires of a selected node, or slice when in the vicinity of a wire attached to the currently selected node.
This isn't rocket science.
Adding more modes of operation, like in the Scene Editor, is completely unnecessary and at odds with the way iOS should be operated. This is a failure of hyperPad to get around the limitations of using cocos2D as the Editor renderer without figuring out how to integrate with UIKit's multitouch facilities.
-
@Aidan-Oxley @Murtaza
Think of it this way:
One Finger = selection and interaction
Two fingers = Canvas Operations (e.g. pan and zoom)
Three fingers = Custom Special Operations (I would set this to UNDO)
-
@Deeeds I don’t want to use two fingers to drag screen. Would rather it stay consistent with scene editor, which is why I’m starting to think a small side menu would be pretty good.
-
@Aidan-Oxley Your experience is ONLY in this app.
And you want it consistent for your expert status. You're the last person qualified to make assessment of what would be good UX for newcomers.
You have muscle memory and want that rewarded and considered.
To some extent, you're right. It should be consistent across the two. But it should be two fingers.
It's bewildering that you don't know this.
Or recognise your isolated familiarity with hyperPad almost certainly disqualifies your judgement.
-
@Deeeds You seriously think I want hyperPad to stay the way it is just so it’s easier for me to use, and keep my “expert” status??
-
Oh no, hyperPad have changed how to delete wires, I’m not an expert any more!
-
All I’m trying to think about is how to help make hyperPad better and more consistent/better to use overall, I’m not thinking at all for newcomers, that’s where more advanced documentation or tutorials would come in.
-
@Aidan-Oxley Holistic consideration of the user experience is what's better for newcomers.
You're only thinking how to make it better for you.
Normal thinking for an expert in anything, they want their proficiency to increase, that's how they became an expert.
-
We actually had similar gestures early on. It didn't go well.
As much as you think it may work, the real world is very different. We have hours and hours of footage of people using our app and gestures are not as intuitive as you think.
Even in other apps, gestures are not that intuitive. Take mail for example, a lot of people don't even know the gestures exist.
Sometimes the easiest thing for the user is a nice clear button telling them what to do.
