My app design workflow (bjango.com)
over 10 years ago from Marc Edwards, Founder at Bjango
over 10 years ago from Marc Edwards, Founder at Bjango
I learned that I have no idea what I'm doing.
Which parts were a surprise?
Feel free to ask any questions about the article.
It may be too soon to ask, but I would love to know which parts of your workflow have influenced your decision to build Skala.
My current workflow works, but is far from ideal. There isn’t much from the article that directly correlates with Skala. Skala’s very different. More on that later. :)
I love the attention to detail, Marc. Thanks for sharing.
I'm of course terribly biased, but reading your article and comments really makes me think that PNG Express would be a perfect addition to your workflow. I understand you're not likely to adjust your workflow now, but for others reading your article and liking the ideas but thinking exporting sounds cumbersome, I'd just like to add that a tool like PNG Express could help.
Here's a few examples of how I think PNG Express would improve the process:
Yeah, everyone should definitely take a look at PNG Express as an alternative.
That is a very detailed and powerful process, thanks so much for sharing.
Fantastic article as always, Marc. Really great tips, especially the suggestion to use gradients for edge effects.
I always love seeing your process, though I second the comment about Slicy, which does a bunch of the 1x/2x work automatically. I would love to find a shortcut way to scale layer effects from 1px to 2px and vice versa. That's usually the most annoying of the scaling changes.
I'm curious - why do you prefer groups to layer comps? I find the actions for quickly exporting layer comps to files for previewing flows extremely helpful.
“which does a bunch of the 1x/2x work automatically”
Please see my answer above. :)
“why do you prefer groups to layer comps”
I find that layer comps don't easily survive many changes. They're fragile and need to be treated with care. Duping things into groups makes your documents bigger, but nothing can go wrong. I think the entire concept is flawed for UI design work and I think there's better ways to solve the same problem.
This is an incredible article but I'm surprised at the amount of effort put into exporting and scaling when Slicy is around. It does most of this automatically with it's handy Group naming scheme and has sort-of Photoshop integration. It does have it's pitfalls but for the most part works extremely well.
I'd love to see how you structure your assets and code in you Xcode project too. Thanks for the great article Marc.
Slicy doesn’t handle everything Photoshop can do. Plus, the only way to run the Scale Patterns to 100% and Scale Mask Feathering by 200% / 50% scripts is in Photoshop. Text doesn’t scale. I’ve seen other issues, too. I’m not at all against using Slicy, but I’m far happier using slice sheets.
MacRabbit is an amazing developer with amazing products (I loved CSSEdit, Espresso is brilliant), but I feel that the task of replicating everything Photoshop can do is impossible, and I don’t trust any app that attempts it.
Don’t worry, Skala knocks this stuff out of the park.
“I'd love to see how you structure your assets and code in you Xcode project too.”
Image structure is pretty simple. All image filenames use reverse domain notation (sort of), with dashes to separate components rather than full stops (this is because OS X double click selection treats a dash as a word separator, which isn't the case for underscores).
navbar-icon-settings-down.png etc
If it's a big project, the UI sections are in folders. If it's a small project, they may all just get thrown in one folder. All filenames have to be unique with iOS and Mac projects anyway.
Great article and cool to read that we have almost the same workflow. :-)
This was definitely inspiring for me. I've been very stuck on doing @2x first and then creating slice sheets with both 1 and 2x assets. It takes way too long. Thank you for these great tips. I'm trying them out on my next project.
I'm curious how you handle those pieces that were not intended to be used more than twice in the app but did. Do you have a "GUI" slice sheet?
“I'm curious how you handle those pieces that were not intended to be used more than twice in the app but did.”
The slice sheet are separated into different documents purely to keep them manageable, and so reusable things can be moved into other projects easily (which means I just need to copy the PSD, restyle and export and the developer can reuse their code, because all the names and sizes are the same).
It doesn't really matter if an image is used in one place or ten in the app — everything that needs to be exported is part of a slice sheet somewhere. Although I do make a couple of exceptions. Default.pngs get their own documents, mostly because they're so big. Plus, I treat icons a bit separately, with one document per size, which helps when creating all the sizes in the first place.
I hope that helps.
I use slice sheets too but I have separate PSDs for each control or set of controls. I work at 2x/XDPI for mobile and sometimes 2x for web pages but I find my 2 year old Air struggling. Skala's great I have to say. Makes testing the look and feel and checking sizes so much easier.
I have a friend who constructs slice sheets with smart objects which is then used in the mockups. I find it useless for things like stretchable assets which is like half of the assets usually.
How are the smart objects used when exporting assets?
I use slice sheets too but I have separate PSDs for each control or set of controls.
I’ve found it hard sometimes to strike a balance between keeping the slice sheets small and easy to work with, verses more elements in each document, and therefore less documents. The sweet spot (for me anyway) is to group things sensibly and try to keep the slice sheets smaller than the display size when at 1×.
Designer News
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
Have feedback?
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now