I've been working a lot lately into mobile design and with the dev teams. Both iOS and Android. I've also been realizing, that implementing a design into mobile (both Android and iOS) is HARD (very) for a developer. It's not at all small, cheap css magic. Making a pretty design is not all. You also have to communicate accurately the design to the developer.
This has told me 2 very important lessons:
1. Always try to stick to guidelines the most you can.
Breaking a guideline can be tedious for both you and the developer (assets madness, code hacks). The OS can be made in a way, that your new style will be very hard to implement. Don't be a punk designer breaking guidelines for the sake of aesthetics and try to get something beautiful, respecting guidelines. You will cut implementation work time by at least 50%.
2. Prepare clean asset files.
I know what you're thinking, it's horrible, tedious, and you got better stuff to do. But unfortunately, as you're not a mobile developer, your developer is not a Photoshop guru and he won't know how to read your files. Thus, try to communicate a LOT with them. Teach them how to read your photoshop files. Also prepare very accurate, detailed, and CLEAN asset files. Your developers will love you!
To illustrate this is what I've been doing this past 3 days. I've decided to retouch slightly the Telly android design. And to stick to Google guidelines.
After reading all the guidelines, and talking for hours with the dev team about how assets are managed for GUI parts, I used this link to base my design and assets I will be preparing.
Then it was pretty easy. Come up with a new concept, prepare xhdpi, hdpi and mdpi design and finally prepare all the asset files for the integration.
This is the final result of it. All assets are sliced so I can export them straight up to the "res" bundle and edit android style xml files. This way the development team will only rely on an exported android ready bundle and not on a psd.
Here's the full sized version of it.
5 months ago
No offense to you, but Android looks kinda ugly IMO.
@Ari none taken. I'm not a fan of android style either. But believe me, the guidelines weren't done for the donkeys. They are intented for designers, to help them design the way the platform was built. I just followed that to get the most beautiful and simple design I could. Going for an iOS design on android is easy. I've done it with the atual telly.
Wow, this looks really good. I disagree @Ari
Good post! Stay away from Android. =)
I work to a pretty simular workflow to this and have found it has worked wonders for both design teams and developers, it has sped things up a lot.
One thing I have noticed; and this maybe something you've missed, is that some of the icons in the action bar have a shadow and some of them don't. I'm not sure if this was intentional but I thought I'd point it out just incase you'd missed it.
solid work, keep it up ;)
@Danny Keane thx man, it's indeed a mistake. Thx for the feedback!
Great stuff man! Thx for the advice!
good advice and great work
Very interesting, thanks!
if you use Draw 9-patch you should have one design which will be scaled to any android resolution. the app will be small and that is the advantage. i don't like 9png because its not very good if you use textures. google likes clean designs because they are small in size so your app can be nicely rendered on all mobile phones. after designing a lot of apps i have made decision to design only for the top android phones. there are so many mobile phone manufactures with so many different screen sizes and resolution.
Thanks for this advice! Our dev team is overseas and this will help a lot :)
great post man, glad to see some progress/advice being posted on here!
@Webelinx yes, you could do that, but you wouldn't be designing things properly for different densities. If you created an image asset with a 2px stroke and used it for both hdpi and xhdpi devices, the physical size of that stroke would be larger on the hdpi display. It could make your designs look pretty awkward.
Also, the developers have to use different assets for the different densities, which might force them to use some auto conversion tool. This could also compromise pixel sharpness and compromise your design.
I do agree that if you are designing for a specific market, then you can target specific phones, which keeps the work load down, but just make sure that you don't compromise your reach because you want some things to look a little different. Jeremy has a great point regarding designing with the guidelines in mind.
Great post, Jeremy.
@Jeremy Sallée ✦✦✦ Sleeek.
That's a strange way in implementing CABs. The pattern feels a bit too much like iOS.
Perhaps it's just way too many buttons on both top & bottom CABs. Some items could be tucked into the overflow button.
Some of the icons on the bottom CAB could be stuffed into long-press pop-up menu. I realize, that's a silly way of doing it, but that seems to be the way Android handling contextual actions. Also, long-press contextual actions could be diverted into CABs (modal pop-up isn't the only option).
The reason is pretty simple, too many icons == hard to tap. I think there's a guideline on how many icons you can stick into a CAB somewhere on the Android Design Guideline page. IIRC, it ain't that many (no more than 4 per action bar), the amount varies depending on the bucket as well (which makes designing the pattern a lot harder/inconsistent).
Interesting on how the design is missing "Up affordance" functionality. IMHO that's actually a crucial navigation feature. This might have more to do with the way the app is structured. Chucking in an App (Up) icon might really cramp the top Nav bar, so you might have to resort to using Sidebar navigation pattern (there are a few awesome libraries for this!). Just something to consider.
The icons, while they're gorgeous and very pleasant to look at, some would argue that it's best sticking to the native Android icons *ugh!*. The Android icon library doesn't cover much, but sticking to similar style would probably be the best route. Android users seem to love their consistencies (or lackthereof, *double ugh!*).
BTW, are you using Roboto on these mockups?
Regarding assets: I gave up on this long ago, and had to hire extra help in converting all assets into 4 different resolution targets/buckets (ldpi, mdpi, hdpi, xhdpi). We liked the idea of pixel sharpness for all four targets, so all the assets were adjusted for each bucket. Very time consuming work, but heh, worth every effort.
@Evan Hindra Thx for the feedback. Here's a little thought about my decisions.
Amount of icons in CAB. Yes I agree their amount is kinda hight, and we might explore another solution with the developing team (the sub action bar is just for the "holo" theme and will never be present into the app)
Typography: indeed I know Roboto ius the one. But I also have a branding to follow for Telly (I created that branding) and Museo Sans is the main branding piece I have. So we will use that one (google doesn't force you to use Roboto, and uploading a ttf file is easy into an app).
Icons: same as typography. I got some branding to follow, and the icons you see there are exactly the same as the ones I use for the iOS app. And it is not to follow and stick to the platforms guidelines, but to give a branding feeling for all user in telly.
Assets: well, lucky you that you could afford and find people for help. I'm unfortunatelly by miself to deal a brand, an iOS (both iphone and ipad), an android, and a web product. And I don't really trust my developpers to read the psd files. Somebody's got to do it right. So I do :)
You're mad crazy @Jeremy Sallée ✦✦✦ ! Managing everything yourself. Anyway, good luck on the app! I'm a huge fan of all your work. Can't wait to see the new Telly on Android!
4 months ago
What do you use for minimizing 9patch assets?
3 months ago
@Anton Borzov I don't get the question. Minimizing 9 patch?
keyboard shortcuts: ← previous shot → next shot L or F like
Show and tell for designers
What are you working on? Dribbble is a community of designers sharing screenshots of their work, process, and projects.
Copyright © 2009–2013 Dribbble LLC. All screenshots © their respective owners. Shipped from Salem, Mass. USA.
Follow Dribbble on Twitter