Designing Your First Android App? 3 Things Not To Do
- Exploring the Design Workflow
Hey all UI/UX Designers out there! This post is probably not the guide for designing the android app interfaces rather this is a extract of what I learned while working on my first app design project. But, I am sure this will definitely help you choose a better design workflow for your own projects.
As a designers, we strive hard tweaking pixels to perfect each and every aspect of the design. But when the UI renders in the actual app, the results are quite vague. I also faced the similar problem during my first design gig and pretty much got an understanding of why this happened. I won’t go too deep into behind the scenes, rather jump straight into the discussion:
1) Don’t Design @1x
Apparently there are lots of advantages of designing @1x resolution . But still the tools, the most of the designers use (particularly the Windows users) are probably not the best to design @1x.
Listed here are some of the tools that I considered for my own design process. And their pros and cons as well.
1. Adobe Photoshop
Adobe Photoshop is a powerful image editing program. It is best for modifying already created images or graphics, like photographs. And over time its functionality has improved and designers have started using it to create mobile and web interface. It also offers the feature to mirror (live preview) the photoshop documents on the real devices. This feature comes very handy if you are designing the mobile apps, as the desktop screen displays the scaled up version of the design and thus making it difficult to predict the size of tap targets and font sizes in context of the actual device.
But despite of so many functionalities, photoshop is probably not the best tool for designing app interfaces (especially @1x resolution). The problem being a pixel based tool, the 1x resolution (i.e 360 x 640 px) appers too blurred and pixelated to work on. Let’s see the next consideration.
2. Adobe Illustrator
Adobe Illustrator is an advanced vector-based software. Unlike Photoshop’s pixel-based format, it uses mathematical equations to create vector graphics. The best thing about vectors is that they are scalable images that can be sized as small or as large as you need them to be, and still maintaining their resolution and clarity.
Thus illustrator appears to be the best tool for designing app interfaces @1x resolution. But the one major reason why I didn’t choose Illustrator for my design is that it doesn’t support any mirroring app. And this feature was very important for me, so I looked for others tool.
3. Adobe XD
Adobe XD is the latest addition in the adobe family. It is the vector based tool and specifically designed for the UI/UX Designers. It offers lot of handy features like artboards, symbols, native prototyping etc.
But for windows, this software is still in beta and awaiting lots of improvements. But the one main reason why I dropped it out of my consideration is, the complexities involved in mirroring the design on the real devices on the windows platform.
Realtime preview with the USB is only available for the mac users, and if you are a windows user you need to upload the XD documents into the creative cloud file folder and then open them from your mobile device. The major flaw in this process is that, every-time you make any change into the document you need to reload the files from the creative cloud, and that sucks!
4. Sketch
Sketch is probably the best tool as far as I have read. But it is mac exclusive and I was working on Windows, so couldn’t consider it into my list. Though some people have found the way of running sketch on their pc via virtual desktop. But I don’t want so much complications.
So, designing @1x on windows platform may require a lot of compromises. But if you are aware of the above limitations, you can select the tool that best suits your needs and workflow. Or even define your own workflow (as I did).
2) Don’t pick any random device to preview your designs
From the above mentioned programs, I chose photoshop for my designing, as I was pretty much used to it and the mirroring feature was very important. And I selected Moto G4+, which is my primary phone, to test the screen mockups as well as the actual app, so that I can compare them side by side.
After a lot of iterations, we finalised some screens for the development. All the font sizes and icons were looking perfect on the photoshop mockup, but those in the actual app were quite smaller. Here’s the side by side comparison of two for your reference:
So after some research and mind tickling I found that, my photoshop document was created @3x resolution i.e, 1080 x 1920 px. Thus I was assuming that every measure of 3 px on photoshop would be equivalent to 1 dp (or 1 sp for font sizes) on android.
Therefore, the font size of heading text which is 56 px in photoshop must be equivalent to 18 sp. But, when we were using the same 18 sp unit in our code, the heading was looking too small.
So the problem here was either we were making mistake in reading the font size from the photoshop document or we were expecting the 18 sp font size to be big enough to look good, as seen on the preview app.
But, if we take a closer look to the mobile’s screen specification, following things will come into picture:
At first instance it appears that the mobile screen has standard resolution i.e, 1080 x 1920 px, but if we check the other specifications the case is quite different.
The screen size in terms of dp, is 423.53 x 752.94 dp
This means that every 1080 px on my screen equals to 423.53 dp, thus applying some elementary math here:
Therefore my screen was scaling everything to 2.5x of the base size (point to be noted). This number is called the Scaling Factor. This factor is different for different devices and is based upon the pixel density of the screen.
Now lets quickly jump back to the previous step, where we were making the design iteration and tweaking the font sizes. At that stage, I was designing the screen mockups @3x resolution (1080 x 1920 px) and mirroring these mockups on the device. The font sizes were looking big enough in the mockups but they were quite small in the actual app. So, the problem is that, the mirroring apps just takes the image from the photoshop document and displays it on the mobile’s screen, scaling or descaling as per the available screen area. It doesn’t take into consideration the device’s screen density.
But this is not what happens in the actual app. Basically the app renders each UI element individually, reading the XML code line by line. Thus the shape and size of each element (the fonts, icons etc.) depends entirely upon the screen density and scale factor.
So, we were making a mistake in predicting the physical size of the elements by mirroring them on the device.
Thus there can be two solution to this problem:
- Use a standard resolution device to preview the design mockups. By standard resolution we mean the devices whose scaling factor is a whole no (like 1x, 2x or 3x) and resolution is 360 x 640 dp. Here’s a list of few devices for your reference or you can see the whole list on Google’s Device Metrics website.
2) Or the other solution could be to read the design specifications manually and test it on whatever device available to you (Moto G4+ in our case). But then have to read the specifications manually and it may involve a lot of calculations.
For example- the 56 px font size in mockup that was looking perfect on my phone may look the same in the actual app if we use the following text size in the code:
56/2.5 = 21 sp
I opted for the second options since I was almost done with all screen designs. And resizing designs again for the new device was too hectic. The only hard work involved here was to take the measurement of each elements from photoshop manually and dividing them by 2.5 (i.e the scale factor of the device as we calculated above).
Though, I could have automated the handoff process but that was the next pain point.
3) Don’t Automate Your Design Handoff Process
Finally after a lot of back and forth, we have defined our design workflow and completed the first phase of design process. Now its time to handoff the style guides to the developer.
I heard a lot about the design handoff tools like zeplin, craft by invision etc. So gave it a consideration for my own workflow. These tools are very useful if you are following a standard workflow but since I was working differently, they didn’t helped me a lot.
The first problem being, they allow to upload the designs at the standard scaling factors ( the whole no’s as we talked above like @1x, @2x, @3x etc) . Thus they make the calculations on the basis of these scaling factors only and gives the measurements. But since I was designing the screens at scaling factor of 2.5x I couldn’t use them anyway.
The second problem I found was, these tools are not very accurate in measuring the distances between text views and other elements.
For example: If we try to measure the distance between the article heading and date published (see the fig below), the distance measured by zeplin is greater than we actually used in the code to achieve the same result.
The reason behind this problem is that the text views in android have some amount of default padding above and below the text. But zeplin doesn’t take into account these paddings and you always have to subtract these default paddings from the measurements taken to achieve the best results. However I am still figuring out what’s the value of this padding. But we were able to achieve the best results with few hit and trials.
Finally after a lot of experimentation, we were able to define our workflow and achieve the desired results. The method that we opt was probably not the best method in terms of productivity but our priority was to deliver the best experience to our users. Gladly the effort went well and we were able to get more than 10k downloads in a month. Here’s the link of our app.
Have any questions or want to share your experience?
Please write in the responses below.
