Arrays Don't like Negative Numbers



  • @Murtaza that's wonderful news, on one front. And something I'm very glad you shared. Perhaps consider making an "about" page for the app and service, and including some of this information.

    @Murtaza you spend an inordinate amount of time attempting to control expectations and divert from core problems with the app. and provide breathing room for @Hamed to do his thing.

    If, as you say, Hamed has always been the chief coder and architect, then the following is far less acceptable treatment of users and indicates a need to consider user needs in a more holistic fashion.

    1. No UNDO in the Behaviour Editor
      This is so stunningly bizarre that it’s completely amazing. Not in an “I’m Tim Cook it’s amazing to be here today…” I mean in the loudest possible sense of “WTF? Have the creators never used their own app?”

    2. The delete button for behaviours is right next to the duplicate button.

    This is comically bad: they’re the smallest buttons, and the closest together, of any interface elements in the entire app…

    It doesn’t take an experienced UX designer, empath or genius product manager to realise this is a problematic layout for workflow and operation of the app. But since you’ve missed it, let me spell this out: The two most extremely opposite desires of a user are right next to each other, one of them is utterly destructive and cannot be undone.

    Imagine: I love this behaviour so much, and it’s so important to my game logic that I want to reproduce it for another similar purpose… oops…I deleted it because i was bumped, missed the button, was in a hurry, slipped… etc… and now I can’t undo this, and have to rebuild an item so important I wanted to duplicate it.

    Wait… this gets better… what if that behaviour is a user filled array with unique and arbitrary values in it?

    AND THERE IS NO UNDO in the behaviour editor!!!

    “Oh… but there’s branching, and cloud backups and everything else we provide… “ you say.

    Yeah.. and those things are from when? And have what in them? They’re a blackhole. The user doesn’t know what of their last activities are updated on the cloud or backups on device because there’s no way to compare them. But that’s not the real point. The real point is that an UNDO in a code editor is so blindingly obviously necessary that it absolutely boggles the mind it’s not there…. and you’re punishing careless or distracted users by putting the delete operation RIGHT NEXT TO THE DUPLICATE button.

    Surely this has caught you out, once… right? Or have you never used your own app… or are you so perfect in your operation of it that you’ve never made this mistake or any other mistake that needed UNDO?

    1. There’s no visual indication of which “Node” within the behaviour editor is currently selected.

    Clearly you don’t see this as a problem because it seems to have been like this forever. Astonishing. Baffling. There’s not any visual indication of a touch on a Node, either. But that would probably require that you consider having some kind of selected Node state, first.

    However, this is a very simple problem to solve: add a shadow around a selected Node, so it’s elevated from the “paper”, or add a border around it, or some other visual indication that one of the nodes is currently selected. This will prevent the following problem being an issue:

    1. When touching on a Behaviour node and immediately dragging it to another location, you have not selected it, only moved it.

    If, as sometimes will be the case, the user is moving nodes around whilst considering which to delete, and then taps the rubbish bin to delete one they’ve moved whilst considering it, they have deleted the last selected node, not the one they just moved. That last selected node might have been something useful, but far worse, it might not actually be on the screen at the moment, as the user might have zoomed and panned around their behaviours in such a way as to not be able to see what was deleted. Then when they run their project again, all hell breaks loose, or nothing happens the way they expect, and they’ve gotta go find what happened.

    AND THERE IS NO UNDO in the behaviour editor.

    1. When organising visual node spaghetti connections can be accidentally deleted.

    Visual code in hyperPad can easily become visual spaghetti for a bunch of reasons I’ll get at later. But the biggest problem is the need for a lot of branching with if statements, their branches disrespecting movement of their parents and the lack of bezier connectivity all compound by atrocious handling of node positioning and relationships. In that spaghetti mess, as the user tries to drag around nodes and find what they’re looking for in terms of a visual representation that means something to themselves, a connection can be immediately deleted by a careless touch or drag of a knuckle, and the user might not even see where from and to that went.

    AND THERE IS NO UNDO in the behaviour editor

    What’s interesting about all the above problems is that they’re compounded by each other and their own causes, and yet each is at least partially (or completely) mitigated by the provision of an UNDO feature in a code editor, the single most commonly used command/operation in ANY SINGLE creative software on earth, and the most important distinction between digital creativity and analogue, real world creativity.

    As I say, I don’t know how to say the above strongly enough that it would resonate with someone that would get this far in the “startup” that is GamePress and hyperPad, and be the chief architect and coder. It simply boggles my mind that this is possible, that this point has been reached.

    The only parallel I can think of is the lack of copy/paste in the first iteration of iOS. But that’s not near this level of disdain for user experience, because there’s no copy/paste in the Behaviour editor, either… nor the ability to select multiple nodes at the same time…

    I am stunned into rant mode by the lack of Undo in the behaviour editor.

    I’m not sure how to say this strongly enough that it resonates sufficiently in the mind of someone that hasn’t already considered the UNDO to be important and to take precedent over all other facilities in a creative environment. Add UNDO to the behaviour editor and move duplicate and delete away from each other!!!

    That the one person is lead architect and familiar with Objective-C and Xcode and has overlooked the UNDO functionality as a base requirement for creative endeavour is truly astonishing. That the two of you are brothers and split the roles of production yet neither have gotten around to adding UNDO is mind falteringly stunning. It says more than the fact that your above reply is the first time you've introduced your team and story to your users.



  • @Murtaza 5000 monthly users, and yet this slipped through the cracks:

    https://forum.hyperpad.com/topic/617/loop-conditional-comparison-operators-reversed

    I'm not sure what that says about your "users", but it's not good.



  • btw @iTap-Development if you were curious about the significant differences between a bug and a problem, the above (no Undo in Behaviour Editor) is a problem. It's a fundamental problem in the conception and articulation of a digital tool and far exceeds any of the bugs I've seen, with the exception of the constant crashing on opening of the developer version, which you are also experiencing.

    If there were a stream of new users, that crashing would be the deal breaker that drove them away.

    You and I overlook that crashing because we have experience and passion. Me the experience, you the passion. But new users will not be so kind. That's a bug that's become a problem for user adoption, acceptance, enjoyment and sharing of those qualities. It's going to create a bad reputation for the app... well, it would if there were enough new users to make it a problem.



  • @Deeeds Why do you want an undo option in the behaviour editor so bad? Accidentally delete a behaviour? You could put the behaviour back in 30 seconds. Yeah I think it could be useful but it’s not THAT important. Making a big change to an object that may or may not work? Duplicate the object, disable the original and hide it somewhere in your scene and then modify the duplicate. I do agree with you that crashing is a problem. It doesn’t annoy me so much because I’ve gotten so used to it lol



  • @Aidan-Oxley This isn't about me.


  • Admin

    I find it comical that you're questioning Hameds position in his own company. I think this applies here.

    " You don't know what you don't know"
    -Deeeds

    Regarding no undo in behaviours:
    This is not an oversight or bug. We discussed it and chose not to implement it. It's that simple. Would it be nice? sure. But the performance trade off was not worth it. Especially early on when the iPads had such little memory. Now that the iPads are more powerful it's definitely something we can look into.
    Usability wise, it just wasn't that important when compared to the main editor. Users are less likely to need undo in the editor. This is also something we tested.

    duplicate and delete
    This is an oversight. Pretty sure this was done by one of our jr programmers, and we didn't catch it. Makes sense to move them apart.

    As for overall UX and usability. We spend a lot of time doing in person interviews and recorded focus groups. When we do a major change to the UI, or add a new feature. We bring in groups of people who have never used the app, and some who are experienced with the app. We record their sessions. Watch their body language etc.
    A lot of your UX thoughts (that you mention else where, not in this thread), we originally had as well. But when we watched the hands of actual users, we were proven wrong. Ultimately the users win.

    No indication of which behaviour is selected:
    We had something in place early on that would bring focus to the behaviour. But during the rewrite/redesign it was removed. I can't remember the reason behind it, but there was one. (I think it was a performance reason as the shaders and the iPad didn't mix well at the time). We'll look into bringing it back. That being said, the name of the behaviour in the properties does tell you what you're editing...

    When touching on a Behaviour node and immediately dragging it to another location, you have not selected it, only moved it.
    Do you mean moving a behaviour shouldn't put it in it's "selected" state? That makes sense.

    *Visual node spaghetti
    This is unfortunately one of the drawbacks to visual node based programming. We have a few ideas we want to implement (like functions and reusable behaviours).
    As for the deleting part. I can see the problem here. Maybe we should have a popup to verify deleting.

    Regarding Loop operators reversed
    This is a relatively new behaviour. Not everyone has used this. It's a pretty advanced topic, and the majority of hyperPad users are not here yet. So it's possible to go unnoticed. Especially when it doesn't look like it affects existing projects and behaviours.


    I have a question for you (so we can better understand our users). What brought you to hyperPad? You mentioned you're in marketing. But you seem to have read a few programming tutorials too.
    Why use hyperPad? It's clearly not meeting your expectations, and you have some basic programming knowledge. What's keeping you here?



  • @Murtaza said in Arrays Don't like Negative Numbers:

    I find it comical that you're questioning Hameds position in his own company. I think this applies here.

    There are VC profiles of your cousin where he is titled lead programmer, and founder. There is nobody else given those titles in these areas, and you don't address it anywhere. So I assumed.... wrong of me. I stand corrected.

    But, as I say, it doesn't bode well that the lead programmer and his partner are actually the ones overlooking the creation of UNDO in a code editing environment.


  • Admin

    In a 3 person company, titles are meaningless. Depending on the situation that could have been purely based on alphabetical order. Or one he decided to give him self (which is totally fine, since it's his company too).
    There was actually a point where my title on linked in was Head Cheese... I am not cheese.

    As I said undo was a choice we made on purpose and not something we overlooked. But I really appreciate you thinking we're incompetent.
    We're always looking to hire additional programmers, so if you ever go beyond hyperPad and get an engineering/computer science degree maybe you can come and add undo :).



  • @Murtaza said in Arrays Don't like Negative Numbers:

    What brought you to hyperPad? You mentioned you're in marketing. But you seem to have read a few programming tutorials too.
    Why use hyperPad? It's clearly not meeting your expectations, and you have some basic programming knowledge. What's keeping you here?

    One at a time, in an order that might help make the reasoning and rationale clear:

    You mentioned you're in marketing.

    Yes, marketing is a curious field. One in which research is far more important than it is in the paired fields of UI and UX design, which is where I came from before marketing.

    Focus groups for anything involving design of any sort are like computers: Garbage in, Garbage out.

    But I digress...

    Why use hyperPad?

    I'm doing market research ;)

    What brought me to hyperPad

    Chipmunk!

    and the iPad. I really like iPads.

    What's keeping you here?

    Chipmunk, the iPad and my personal resolve to see what I'm doing through to completion.

    It's clearly not meeting your expectations, and you have some basic programming knowledge.

    It's not about my expectations. My commentary has been far more about what's expected of these sorts of endeavours from the perspective of your prospective and potential users. I get that this kind of abstraction is not common.

    For things I want, I'll reach out personally. And have.


    But you seem to have read a few programming tutorials too.

    Nice try. Swing harder. I have thick skin. And a hard head.



  • @Murtaza said in Arrays Don't like Negative Numbers:

    As I said undo was a choice we made on purpose and not something we overlooked. But I really appreciate you thinking we're incompetent.
    We're always looking to hire additional programmers, so if you ever go beyond hyperPad and get an engineering/computer science degree maybe you can come and add undo .

    Keep swinging. You're still hitting air.



  • @Murtaza said in Arrays Don't like Negative Numbers:

    But I really appreciate you thinking we're incompetent.

    I'm not sure I'd use the word "incompetent". I don't think you did enough research into the different ways UNDO can be implemented. When you discuss the memory and performance issue with regards your reasoning on it, I know you didn't look into it enough.

    Probably because you don't understood the significance of UNDO in digital creativity. Otherwise you'd have done the research on ways to economically build around the ability to undo, and probably created an undo list, too. It's still bewildering you chose this path. It troubles me that you have this little regard for your users, or this little interest in researching the capabilities and supports provided by the platform you're working on.

    Going back as far as 2010, Apple were spending an incredible amount of time demonstrating ways to implement UNDO and REDO efficiently because they'd become big believers in its significance to apps and their users' experiences. Beyond believers. I think we can consider the existence of undo to be expected in content creation and productivity apps since before you were born. Even in todo list apps.


  • Admin

    A few things.

    1. @Deeeds don't be disrespectful. I sent you a private message before about this. As you can see, everyone is just trying to help and you don't need to shoot them down and berate them. You're coming off as very aggressive and rude.

    2. At this point, our users are way better at using hyperPad than we are and in this public forum, we rely on their help to answer simple questions. Like @Murtaza said, a lot of "bugs" are just user error so it makes sense to troubleshoot the issue with others before myself or @Murtaza can come in and declare it to be a bug.

    3. Don't make assumptions about years of development when just coming into the platform. If you don't like something, let us know and we can have a public discussion of how things can work. Some things may look easy to add, but as most software developers know, NOTHING is ever that easy.

    4. Somethings are indeed broken. We don't know about all of the broken things. When dealing with software with 1000+ features, its easy to forget about certain items and miss some things. We rely on user feedback to find these issues. e.g. I constantly forget about some of the behaviours you guys ask about... because we have so much functionality!

    5. Everyone uses hyperPad differently, so we have to cater to how the majority uses hyperPad and not just you. appreciate our limitations and understand that we can't always cater to an individuals needs.

    In conclusion, relax. We're working on it.

    P.S, I can't re-create your issue... so I declare it not a bug. If you can create a little sample project with as few behaviours as possible, either I or someone on the forum can help troubleshoot it. like @Aidan-Oxley said, its not too hard to share a link onto the forum.

    P.P.S Its really hard to find your issues / feature requests with a huge wall of text. Keep it short and to the point, and you're more likely to hear a quicker response.



  • A few other things:

    When your professional tier, your highest priced premium version, crashes hard, and restarts, every single time it's loaded after the iPad sleeps (something iPads do because they're mobile devices with batteries!) and there's no indication of you acknowledging this problem or making any endeavour to properly fix it anytime soon... I think the onus of proof is on you for any and all signs of bugs and inconsistencies in performance.

    You're lagging on fixing a fundamental and massive flaw that you've done the dodgiest work around on possible, preventing your app from letting the iPad sleep.

    I am a prolific app buyer. In product categories of interest to me and my research. I buy and try prodigiously. Just in music apps, alone, I have bought just about every sequencer, DAW, effect, synth and sampler. Not one of these apps, some of which are vastly more complex than hyperPad and often made by individuals (not teams), has had the temerity to be in the market in such a crashy prone manner without addressing its users and making a fix as fast as possible.

    A real fix!

    And a lot of these apps are partly written in Assembler so they can really thrash the CPU for their DSP.

    Your "fix"? Prevent the app from letting the iPad sleep.

    For an app that doesn't idle in editor mode, that's insane! I'm amazed Apple hasn't sent you a warning about this or seen this show up in their automated testing. Perhaps you're not getting flagged because it seems like a game to their automated testing.

    We know it's not being given a lot of oversight due to a lack of users. But how's that going to change when you treat them this way?

    But, let's be honest, your app, in idle editor states, is flogging the CPU/GPU so hard that it destroys the battery life of iPad Pros!!!

    And you exploit this to avoid your users having their iPad sleep, and then crash and restart your app each time they turn back to it.

    You haven't even bothered preventing your app from flogging the CPU when in editor modes.. and IDLE!!!

    Are you guys really working on this full-time?


  • Admin

    In editor the cocos2D graphics engine is active. The entire canvas is the live game engine. Plus every action you take is being saved which are constant read/writes.
    These two things affect battery life.



  • @Murtaza You can stall the cocos2D graphics engine. It doesn't need to constantly refresh at 60fps when nothing is happening. That's one of the key design points of its actions based nature, and the same reason the early versions didn't have a traditional game loop.


  • Admin

    @Deeeds
    Oh, why didn't we think of that before! You're a genius! Thanks. You've single handedly solved all of our problems.



  • @Murtaza

    Sarcasm noted. Invert this approach to stop rendering when it's not necessary, see Brad Larson's answer:


  • Admin

    @Deeeds if you’re unhappy with our progress, ask Apple for a refund. We’re trying our best and it doesn’t seem to be good enough for you and that’s okay. We’ve been pretty attentive and patient with your arrogance and bullying but unfortunately, you’ve taken it too far and we’re putting a stop to it. Future posts where we don’t appreciate your tone will be removed.



  • @Hamed "arrogance and bullying"...

    Where's the bullying?

    Who feels bullied?

    Why?

    I am prone to arrogance. Not going to contest that. But bullying is something else, entirely. Please share an example. I'm very curious.



  • @Deeeds You’re making the devs feel bullied, the way you keep judging this app and they way they run and make it. You’re the first person to ever do this (at least on the forums). It’s like you know better, even though they’ve been working on this for over 6 years.


Log in to reply