Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Surprises When Designing An iPhone App

jackg.org

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Surprises When Designing An iPhone App

#21

Post by staufman »

lazerwalker wrote: post #11

"there must be an iOS equivalent of the tag, right? Apparently not." It's not a silver bullet (it can sometimes give you a bit of a performance hit), but the Nimbus library has a UILabel subclass that makes bolding a substring a lot less painful than manual NSAttributedString munging: http://docs.nimbuskit.info/group___nimbus_attributed_label.h...

Agreed. I actually wrapped this library with a simple HTML parser that can understand basic tags (, , , etc.) and translate them into calls to Nimbus.

At some point, I'd love to incorporate a Fireball markdown parser so that authored and styled content from our servers can just be pulled from our app.

Re: Surprises When Designing An iPhone App

#22

Post by rpwilcox »

flixic wrote: post #15

I'm designing iOS and Android apps full-time for over a year now. A couple of tips from me: - He's very right about previewing on the device. I like xScope better than Silkscreen, because it can stream anything, both file, or screen region, and overall it's a nice designer's utility belt. There's nothing like that for android, at least I haven't found anything that works, and Android needs this even more, because it…

Absolutely agree with the last point. While I wouldn't expect a designer to throw down much Objective-C quickly, the "move this element 5 points to the right" game can be played by a designer.

Add 5 minutes of guidance from a developer and some forethought (subclasses for common button idioms in your app and how to apply them to elements; storyboard overview; a hand from a developer to hook up a table view cell nib, etc) could save the developers a lot of time. Even gawds, understanding the naming conventions around assets.

Re: Surprises When Designing An iPhone App

#23

Post by ed209 »

flixic wrote: post #15

I'm designing iOS and Android apps full-time for over a year now. A couple of tips from me: - He's very right about previewing on the device. I like xScope better than Silkscreen, because it can stream anything, both file, or screen region, and overall it's a nice designer's utility belt. There's nothing like that for android, at least I haven't found anything that works, and Android needs this even more, because it…

Previewing on Android: There is this http://code.google.com/p/android-ui-utils/

Re: Surprises When Designing An iPhone App

#24

Post by Aqua_Geek »

Groxx wrote: post #13

For provisioning woes, do as much as you can within XCode (you can provision a LOT from the organizer). It takes care of a lot of the 'download this, then that, install these, don't forget X, etc' steps. Most tutorials on the interwebs won't send you down this route though, because it's relatively new (version 4.something). tl;dr: open the Organizer, go to Devices, click Provisioning Profiles in the top left, and cli…

While I agree with most of your points, I discourage doing everything from within Xcode. Yes, the Organizer will get you up and running and at least get your app onto a device, but anything beyond that it quickly breaks down.

Re: Surprises When Designing An iPhone App

#25

Post by justjimmy »

I never design an interface without checking with the developers I work with. Is this possible? What's the time frame? How hard would it be to iterate? Can we do this nifty slide and layering action?

Then check with the product team/manager - is it worth it? Do we have the time/resources for the extra level of 'coolness'?

Then check with the DB/Backend guys - would this flow work, these values, these sort orders, creating of these groups, how does it fit with legacy entries?

Then check with the test users with interactive mock ups/wireframes - does it fit together? Does it flow? Are there confusion anywhere in the sign up process? I see you are entering this ridiculously long user name that is going to break the design? No, don't go ther - back to the drawing board.

If you have OCD like me and your math is off (ie trying to retain a 1px border on both retina and non retina of a shape that consist of multiple strokes is just asking for trouble), you can spend ages tinkering. Luckily, and hopefully, non retina iOS will be phased out soon.

As you get better, you'll slowly learn to see ahead and anticipate all the moving parts but dang, it can be a tricky journey. Lots of learning to go for me.

ie: I've yet to come across a app that previews my mocks up to my iPhone nicely. ATM I'm using Box. Dropbox doesn't work cause they, for some reason, wants to destroy the file by compressing it while on a mobile device.

Re: Surprises When Designing An iPhone App

#26

Post by potatolicious »

chrisdevereux wrote: post #12
10dpd wrote: post #3

"there must be an iOS equivalent of the tag, right? Apparently not." Just use three labels, with the middle label set to bold.

In iOS 6 at least, UILabel supports attributed strings. I have no idea what took so long either.

Or, really, how thick the API is around it. Attributed strings won't see very wide adoption until someone (preferably Apple?) gives us an easy to use markup language around it.

Manually screwing around with NSRange's is not the way forward.

Re: Surprises When Designing An iPhone App

#28

Post by ef4 »

richardwhiuk wrote: post #9
jamesjguthrie wrote: post #4

> Provisioning and distribution is a nightmare I fully agree. I threw myself in at the deep end - never spent any length of time on Mac OS and only working from tutorials for Xcode, it was atrocious trying to figure it out!

It's deliberately hard, because developers are trying to implement a use case which Apple has tried to prevent. The are four different options: a) Developer builds which have to be installed using Xcode for each phone. That won't work for anyone able to install. b) Ad-Hoc builds, which must be specified for each phone. Again that doesn't scale. c) Enterprise builds, which install on a unlimited number of phones. This…

> Ad-Hoc builds, which must be specified for each phone. Again that doesn't scale.

It's not strictly one-to-one. You can stick all your test devices into one provisioning profile, and then all your builds will work on all the devices.

So the hardest part is asking your test users for their UUIDs.

Re: Surprises When Designing An iPhone App

#29

Post by flixic »

ed209 wrote: post #23
flixic wrote: post #15

I'm designing iOS and Android apps full-time for over a year now. A couple of tips from me: - He's very right about previewing on the device. I like xScope better than Silkscreen, because it can stream anything, both file, or screen region, and overall it's a nice designer's utility belt. There's nothing like that for android, at least I haven't found anything that works, and Android needs this even more, because it…

Previewing on Android: There is this http://code.google.com/p/android-ui-utils/

Did you manage to get it working? Because me and a fellow android developer couldn't.

Re: Surprises When Designing An iPhone App

#30

Post by SeoxyS »

staufman wrote: post #21
lazerwalker wrote: post #11

"there must be an iOS equivalent of the tag, right? Apparently not." It's not a silver bullet (it can sometimes give you a bit of a performance hit), but the Nimbus library has a UILabel subclass that makes bolding a substring a lot less painful than manual NSAttributedString munging: http://docs.nimbuskit.info/group___nimbus_attributed_label.h...

Agreed. I actually wrapped this library with a simple HTML parser that can understand basic tags ( , , , etc.) and translate them into calls to Nimbus. At some point, I'd love to incorporate a Fireball markdown parser so that authored and styled content from our servers can just be pulled from our app.

You might be interested in something I plan to open source at some point: a native Markdown lexing / parsing engine meant to be used to stylize markdown for Core Text / NSAttributedString.

Here's the meat of it in a gist: https://gist.github.com/29dabe4b6e762ee221df

Post reply on HN