Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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. –  Andrei 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. –  Andrei Feb 19 '13 at 11:07

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
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? –  Andrei 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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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