Jump to content
You must now use your email address to sign in [click for more info] ×

[AD] Question to other UX/UI Designers about creating assets for multiple mobile screen?


Recommended Posts

Hello Guys,

Well i have been using AD for my UI design projects and i am enjoying it so far. Some of you guys may know that there are multiple devices with multiple screen sizes.

 

Multiple resolutions which doesn't scale up or down proportionally due to difference in aspect ratio.

So how do you guys start the design?

1. Do you create an artboard with smallest version then scale up or other way around?

 

2. How do you export the assets with AD? (By export i meant efficient way to export multiple size)

 

3. How do you deal with different aspect ratio?

 

I know that AD has good export tools where i can choose 1x, 2x for export but the aspect ratio for all screens are not same.

 

I started a design for Iphone 5 retina display. It has an aspect ratio of 16:9. So i can use 1x, 2x asset features to scale up or down.

4. But what about android with ratio 16:10 for some device?

 


My strategy was  to design for different ratio, starting with smallest device then scale up asset during export.

5. Is this an efficient way or do you have better way?

 

Note this question is not directly related to AD but the question general. But as i am using AD export feature so i am asking here to know if there is some efficient way that i didn't figure out.

Follow me: Instagram | Dribbble

Link to comment
Share on other sites

As to point #1: There are different approaches to UI design, one of the more recent ones being called “mobile first”, as opposed to the “traditional” approach of designing for desktop computers and then let it adapt to small viewports. Neither approach is wrong or right but merely personal preference and/or depending on the application, I’d say. You need to determine the prerequisites of the devices/user base for which the UI is designed: which technical limitations are there going to be (data transfer/bandwidth, display size, color/resolution etc.)? Some would argue it’s better to design from simple to complex, which is what “mobile first” is basically about.

 

As to point #3: That’s the wrong way of thinking in the first place. You shouldn’t design for specific aspect ratios or resolutions because as you already realized, different devices have different dimensions. Your UIs should be flexible to adapt to any size/ratio – in web design that is called “responsive web design” but it applies to any UI that is supposed to be used on different devices. Therefore, my recommendation would be to regard any design you create in AD as a template/wireframe, any artboard size you choose can only be a “snapshot” of the UI at that specific size, the first step of the actual real-life UI; in reality that UI would be programmed to adapt to various sizes/dimensions. You’d usually not export any “assets” except icons/images that can’t be created by code. And these images are usually not specific to a certain aspect ratio. Any buttons or interactive elements in the UI will usually be done with code, not exported as images.

 

So, to answer point #5: You would create various “snapshots” of the UI in different sizes and give guidelines on how the elements in the UI will behave if the viewport is resized to whoever is supposed to work with this.

Link to comment
Share on other sites

As to point #1: There are different approaches to UI design, one of the more recent ones being called “mobile first”, as opposed to the “traditional” approach of designing for desktop computers and then let it adapt to small viewports. Neither approach is wrong or right but merely personal preference and/or depending on the application, I’d say. You need to determine the prerequisites of the devices/user base for which the UI is designed: which technical limitations are there going to be (data transfer/bandwidth, display size, color/resolution etc.)? Some would argue it’s better to design from simple to complex, which is what “mobile first” is basically about.

 

As to point #3: That’s the wrong way of thinking in the first place. You shouldn’t design for specific aspect ratios or resolutions because as you already realized, different devices have different dimensions. Your UIs should be flexible to adapt to any size/ratio – in web design that is called “responsive web design” but it applies to any UI that is supposed to be used on different devices. Therefore, my recommendation would be to regard any design you create in AD as a template/wireframe, any artboard size you choose can only be a “snapshot” of the UI at that specific size, the first step of the actual real-life UI; in reality that UI would be programmed to adapt to various sizes/dimensions. You’d usually not export any “assets” except icons/images that can’t be created by code. And these images are usually not specific to a certain aspect ratio. Any buttons or interactive elements in the UI will usually be done with code, not exported as images.

 

So, to answer point #5: You would create various “snapshots” of the UI in different sizes and give guidelines on how the elements in the UI will behave if the viewport is resized to whoever is supposed to work with this.

 

 

I actually understand your point. But with mobile there is an issue with proportion. For example not all top bar or nav bar are similar in proportion. 

 

So for a certain snapshot if i choose icons of certain size then once it goes another device it may take more space that usually conflicting with other.

 

Your point is easier to implement on web. I actually follow the mobile first step. I am not sure about cellphone devices though. As its more asset based from what i understood by working with few dev.

 

Either these guys are working in the wrong way. Or there are some technical issue.

 

I wish mobile was similar to web. I mean the way html and css works.

Follow me: Instagram | Dribbble

Link to comment
Share on other sites

 

 

So for a certain snapshot if i choose icons of certain size then once it goes another device it may take more space that usually conflicting with other.

 

Why should this happen?

If you're creating (for instance) a 32x32pt icon it will take up the same space regardless of device ratio or density (DPI, LPI, PPI call it the way you prefer...).

What is changing with ratio is the available space that makes the device prone to specific orientations depending on specific tasks.

I can't understand how it could influence your asset's size.

 

 

Your point is easier to implement on web. I actually follow the mobile first step. I am not sure about cellphone devices though. As its more asset based from what i understood by working with few dev.

 

 

 

The developers I work with tend to ask me for raster assets only, basically icons, but also backdrops or patterns.

They want mockups as reference and  (if needed) I tend to add assets guidelines and metrics when the project needs custom ones.

When performance is important anything, apart from icons, is written from the ground typically.

When the project is on a budget they suggest libraries (KendoUI, Sencha, Ionic, etc...).

 

The mobile first is basically a "worst scenario first" approach and works very well whenever you have to fit a complex workflow in both small and large screens.

If you're designing for cross-device products leave apart OS specific guidelines and dogmas, and choose a common "good sense" driven approach.

The white dog, making tools for artists, illustrators and doodlers

Link to comment
Share on other sites

Why should this happen?

If you're creating (for instance) a 32x32pt icon it will take up the same space regardless of device ratio or density (DPI, LPI, PPI call it the way you prefer...).

What is changing with ratio is the available space that makes the device prone to specific orientations depending on specific tasks.

I can't understand how it could influence your asset's size.

 

 

 

The developers I work with tend to ask me for raster assets only, basically icons, but also backdrops or patterns.

They want mockups as reference and  (if needed) I tend to add assets guidelines and metrics when the project needs custom ones.

When performance is important anything, apart from icons, is written from the ground typically.

When the project is on a budget they suggest libraries (KendoUI, Sencha, Ionic, etc...).

 

The mobile first is basically a "worst scenario first" approach and works very well whenever you have to fit a complex workflow in both small and large screens.

If you're designing for cross-device products leave apart OS specific guidelines and dogmas, and choose a common "good sense" driven approach.

 

Thank you.

 

So i have been reading on this topic deeply. I realized i really have lack of knowledge on pixel and dpi. Not very clear. Thus i was asking this sort of questions.

 

I really appreciate help from you guys and i am reading from other sources too.

 

Do you have any sources that i can use to get a comprehensive understanding? I mean books or maybe tutorial as well.

 

About OS specific guidelines, ignoring them is both good and bad. Ignoring the bad, good is then i can design a particular mockup with good assumption and then make asset.

 

Issue is when iphone says make out status bar or nav bar this height, while android says that height. Oh, and it differs on each iphone too and some android are messed up as well lol.

 

You see the issue here. I can ignore the text size, image size and keep things similar. But what about fixed elements.

 

It's just till now i have been creating many assets. Doing things right but working hard not necessarily smart. So i am reading few books and clearing these issues out.

 

Once again thank you.

Follow me: Instagram | Dribbble

Link to comment
Share on other sites

About OS specific guidelines, ignoring them is both good and bad. Ignoring the bad, good is then i can design a particular mockup with good assumption and then make asset.

 

Issue is when iphone says make out status bar or nav bar this height, while android says that height. Oh, and it differs on each iphone too and some android are messed up as well lol.

 

You see the issue here. I can ignore the text size, image size and keep things similar. But what about fixed elements.

 

 

I didn't wrote to ignore, but to leave them apart in order to find a shared solution driven by good sense.

This means that you have to study both libraries and guidelines and find new design patterns that make sense for all OS users.

 

If you customer asks for perfect OS compliance and default controls, no chance: you have to develop two (or three) applications.

Material Design, Apple and Windows guidelines are different.

 

If you have more flexibility you could design your own assets and share them across devices.

Before deciding anything my suggestion is to always speak to the developers' team.

They can give you the right hints.

The white dog, making tools for artists, illustrators and doodlers

Link to comment
Share on other sites

So after reading this is what i come up to :

Creating asset for 1x for iphone and android. Then scaling it up.

Is these values accurate for 1x of android and iphone. I got these values from different articles but i am not sure about the DPI. I chose 72 because it was default for web before the changes.

 

  1. iOS iPhone 6: 375 x 667
  2. Android Nexus 5: 360 x 640 (mdpi)

 

DPI : 72

Follow me: Instagram | Dribbble

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.