3

We're working on an iOS project and right now, and whenever the designer has some feedback about fonts, colors, positions of elements, what images should go where etc., I have to go back and go through each little detail and make sure it's fixed.

I'm thinking there's got to be a better way to do this, where the designer could somehow be directly involved in the application's design.

The first idea I got is to create a global plist (or a per-XIB plist) which contains the details of the different elements (size, font, title color, background image etc.) and just let the designer fill that in, and have a special class that looks over the plist and sets the properties accordingly. If I have the time I might implement this.

Is there some other method of working that saves the developer all that nit-picking designing time?

edit: Or maybe is there some way to do iOS development similar to how CSS works with HTML?

4
  • In what form does the designer send the feedback? Is it new design pages?
    – superM
    Feb 19 '13 at 10:58
  • @superM Usually feedback comes in the form of a PDF file filled with screenshots of the application, with arrows pointing to different elements, stating what this color should be, what font that element should have, the background image etc.
    – Alex
    Feb 19 '13 at 11:00
  • Our designer used to work like that, too. But I really didn't think it's that bad )))
    – superM
    Feb 19 '13 at 11:04
  • Yeah, it's doable. I just think there's room for improvement and separation of concerns as well.
    – Alex
    Feb 19 '13 at 11:07
3

This is a really great question. First of all, I would suggest a variant on your .plist idea. If you don't have one already, create a globally accessible class in which you can declare properties may that change often. For example, you can have a UIColor property for the text color you use throughout the app. When you need to use that color, just reference that property. Then if you ever decide to change the color, you will only have to change that one line in the globals class.

Also, I would be a bit hesitant on opening up Storyboard access to the designer. This is just because Storyboards are notorious for merge conflicts. So if you edit a screen in the Storyboard while the designer changes a tiny element, you're going to have some commit issues. It's much less of an issue if you're using individual .xibs though, because they're more isolated.

Edit: Or at least just try not to edit the same stuff at the same time. Problem solved.

0

If you are using XIB or Storyboard for development, give the designer access to that and let them modify the UI from there. This is the way we have handled this situation in one of our projects. This is useful, if you dont have much custom UI components and most of them can be set from XIB or Storyboard.

In order for this to work, you have to give access to the SVN location or the location where you have saving the version of your code, so that they can pick it and modify the same.

2
  • Thanks for the recommendation. Unfortunately, there is some overlap in the MVC pattern, where we have view code within the controller... Also there are many elements (like toolbars and buttons from nav controllers) that are instantiated and customised in code. Is there another fix in that case, that doesn't involve code refactoring?
    – Alex
    Feb 22 '13 at 10:39
  • 1
    @Andrei, In that case you might have to go with a global plist approach itself.
    – iDev
    Feb 22 '13 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.