HN user

taybenlor

795 karma

Application Developer and Hobbyist Designer. I have no idea what I'm doing. http://taybenlor.com

Posts12
Comments67
View on HN

Things like:

  * Scalability - you can resize a button and get the correct look
  * Simplicity - you don't need to create 1x and 2x resources
Downsides are that it can be slow and it muddies up your code base.

People writing their first web app rarely do. Though in this case most of these things are covered by Rails' "Secure by Default" approach.

Also, comments like these are what turn newbies away from programming. It's really hard to start out, encouragement and a point in the right direction is what's needed.

Edit: Ahhh actually, you probably didn't realise that OP was a newbie because mods changed the title of the post. That's unfortunate. Carry on.

We've had some of our designers at work use this approach. I think it's quite good for illustrating intentions. But then building on top of the designed Storyboard doesn't quite work out.

Storyboards work well for simple apps with standard UI. Once you start building something custom or complex they are a poor tool. If you have a designer then they're likely going to be making custom UI which will need code (maybe lots of it). The Storyboard quickly becomes a crazy mess of placeholder views, implementation details, arrows and blank screens. The designer can no longer use it to demonstrate their ideas and you've probably completely ripped out their original work.

If your only intention is to make a interactive demonstration of screen progressions - then this is perfect. But don't think that this has the same reusability as making a HTML+CSS+JS mockup.

If you go around and talk to everyone you can see what the goal is and what problems you'll face. You need to get the Radio fixed within 40 days. The engineer can fix it the fastest, however you need the rest of the team (and the fire) to support him.

As the game progresses talking to people shows different problems that could arise and how you might solve them. It's interesting as talking keeps up morale and gives you insight into how to beat the game.

You're right. I went overboard with my conclusion, the intention was to focus attention on the fact that using a single tool results in lots of similar results and to highlight the flaws in that tool. There are plenty of other tools we could use, not just the one.

Sorry, I'm not quite sure what you're saying is wrong. I understand your point about physics engines perhaps being the wrong tool here, and I can see that. But the main focus was on how the standard tooling for UI animations is incapable of modelling movement with dynamic "distances" (I put distances in quotes because you could be transitioning colour, height, scale or any other attribute of the object).

TL;DR: If a transition changes values that are dependent on dynamic user input you get an unrealistic effect where small differences take as long to transition as large differences (because transitions usually have a fixed duration).

I got into iOS development via RubyMotion. I was a Rails developer for a few years, now I'm an iOS developer (using Objective C). I've only really started with Objective C and XCode. Objective C isn't a huge barrier, but Cocoa and XCode definitely are. That's one of the reasons I really enjoyed RubyMotion.

If I could choose (and wasn't working with other people) then I would go with RubyMotion. The toolkit is a lot less mature than XCode. But the productivity is definitely higher and there's much more room for improvement via the OSS community.

RubyMotion side-bonus: you don't have to merge (basically) binary files when you're working entirely with code for UI.

The other side to this is that higher numbers give them the benefits of scale. Ordering 1000 rather than 100 of a particular part allows you much cheaper prices. Which means higher chance of success. Having to deal with a few million dollars worth of orders is a good problem to have. Much better than the same product, but only a few thousand.