Behaviour Editor: Break Link Can Occur miles from link
-
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.
-
@Murtaza Way to miss the points. All of them.
None of my points were around this being the most intuitive deletion option, or even more intuitive than the current technique.
Nor did I suggest I think this might be more intuitive.
You think you have experience. You think you understand what you're doing with UX. You couldn't be more wrong.
There's ample evidence.
Let’s get just some of the ways you’ve considered UX lined up:- A permanent delete button right next to the duplicate button (both less than 44 pts)
- Touching a line causes it to be deleted, even during a multitouch input
- No indication of a selection event occurring
- No indication of a currently selected node (or otherwise) on the nodes
- Dragging an object doesn’t result in it being selected
- Multitouch gestures don’t release selected objects
- Dragging two nodes at the same time causes insane link/connection behaviour
And, the punchlines:
- No proper handling of multitouch on a creative canvas with draggable objects - on an iPad.
- No UNDO in an editor capable of instant destructive interaction - and is a coding environment.
And this is before we consider that there’s no multi-select of behaviours, but there's multi-drag that causes disastrous layout weirdness, the atrocious way the links/connections behave between “behaviours”, the naming of the nodes as behaviours and every other transgression against usability you’ve managed to rack up in this most important aspect of your app, the coding environment.
And the headliner, you ask, in this little assortment?
No frame redrawing pause of cocos2D whilst in the Editors, so a static coding environment drains battery like nothing else in the app store, when the user is thinking and not even touching the screen.
So not only do you not know much about UX, you don’t seem to care enough about your users to investigate the underlying cause of cocos2D’s frame redrawing and memory management problems when using it as a presentation device for something that would be far better done in UIKit with auto layout, UIViews and all of their MANY builtin benefits.
Yes, there's some benefits to using cocos2D for your visual coding layout and rendering engine, but you're not using any of them, and suffering all the foibles of not fixing cocos2D to make it suitable for this role... at the expense of users time in your app and their batteries.
Given the above have been permitted to roll out the door, and I’ve seen you defending at least some of these in isolation over the course of years everywhere from reddit to education sites, and many of them have been in existence for years, how well equipped do you think you are to begin considering what questions need to be asked of any focus group and/or testers you're recording?
Given you can't observe or prioritise any of the above to get fixed, what do you see?
Do you see that you might not even know what to proposition testers with?
-
K.
Thanks for the lecture.
