taybenlor's comments

taybenlor | 13 years ago | on: Starters Guide to iOS Design

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.

taybenlor | 13 years ago | on: Starters Guide to iOS Design

I've personally seen points used as an area measure, but I think you're more correct. I'll update the article later tonight.

taybenlor | 13 years ago | on: Show HN: Feedback app

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.

taybenlor | 13 years ago | on: How To Prototype In Xcode Using Storyboard

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.

taybenlor | 13 years ago | on: Show HN: An HTML5 game we made in 72 hours for Ludum Dare

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.

taybenlor | 13 years ago | on: Animating with physics instead of a timing function

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.

taybenlor | 13 years ago | on: Animating with physics instead of a timing function

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).

taybenlor | 13 years ago | on: Animating with physics instead of a timing function

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).

taybenlor | 13 years ago | on: Why I loved building Basecamp for iPhone in RubyMotion

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.

page 1