The pain and joy of designing app widgets

Ana Seler
Undabot
Published in
7 min readMay 7, 2020

Some people say widgets are a thing of the past, but recently we faced a market for which this was one of the main features users were asking for. A bit of googling showed there are not a lot of useful articles covering widget design (most information is found in human interface guidelines and material design), though development is more widely covered.

Because of that, this article will cover how to design a widget for both platforms. Let’s start with the basics, although I’m sure most of you know what a widget is. :)

What are widgets?

Widgets are mini application views that are embedded on the home or lock screen of smartphones. They allow users to interact with an app without opening the app itself. They usually receive periodic updates and are very useful for displaying small amounts of data or app-specific functionality information that’s important right now. For example, our widget is for a telecom and displays tariff name, current balance, remaining data…

Widget design

When we get to the topic of designing widgets, a lot of questions open up. Especially since we have two different platforms to design for, different screen sizes and options users want to have. Some users want to see just the basic info, for example, the amount left on their account, whereas others want to see more details, but the thing that connects them is that both want to see the information instantly. Another problem is that there is no strict definition of sizes or detailed info on how to design the widget. For most of us (designers) that is frustrating, since we want to create a mockup which will show how the widget is really going to look like before developing it.

The first step in designing the widget is to define what information your widget is going to show. It would be good to do some research and define which information your users would like to see.

Widgets can contain text, icons, buttons, images and more. They don’t contain input fields, checkboxes or radio buttons.

iOS widget

iOS widgets are a little bit easier to design, since there is a lot predefined. Usually there is only one widget per application and one configuration screen.

When you first start thinking about the iOS widget, go through the human interface guidelines on that topic: https://apple.co/3d9xVQI

There is a lot of info to be taken from them, these are the main points to keep in mind when designing the widget:

  • the width of a widget varies, depending on the device and orientation
  • there are two states: collapsed or expanded — keep in mind that not all widgets support expansion. On iOS 13 the “show more” and “show less” are replaced with just an arrow down / up
  • a collapsed widget is the height of roughly two and a half table rows — taking into consideration that one row is 44px we have a height of 110px for a collapsed widget. It shows essential information that can stand alone
  • an expanded widget is ideally no taller than the height of the screen. It shows additional information.
  • use system font San Francisco (SF) in black or dark grey
  • avoid customizing background and never use a photo as a background
  • avoid extending content to the edges of a widget, use the app icon at the top of your widget for alignment guidance. Provide a margin of at least a few pixels between each edge and the content
  • let people tap the content itself to see or edit it in your app. Never use your widget to open other apps
  • if your widget provides additional functionality when someone is logged into your app, make sure people know about this. For example, an app that shows your mobile subscription info will have a message like this: “Sign into the app to view your account status.” when you aren’t logged in.

Mocking up a widget on iOS

You can create a mockup of your widget in order to define the design or get the client’s approval.

Here is a list of elements you need to think about in order to create a high fidelity mockup:

  1. collapsed height - 110px including the header
  2. header height - 36px
  3. rounded corners - 13
  4. app icon size - 20x20px
  5. use system font San Francisco (SF) in black or dark grey
  6. app name - 13pt, regular, uppercase
  7. show more/less - 13pt, regular (or just arrows on iOS 13)
  8. margins and padding

Interesting bug

Although the widget normally works without unlocking the phone, we encountered an interesting bug while developing our iOS widget. Our application uses a token to access the data it needs and so does the widget, but this token is stored in the iPhone’s secure storage. While the screen was locked, the widget couldn’t access it and would display an error message, despite everything appearing to be OK. We solved this problem by using a simple message “please unlock your phone” in case the phone was locked and after that the widget would work OK.

Example

A mockup of the iOS widget

Android widget

On Android, users can have multiple widgets with different settings / content. Android widget is extremely flexible (although there is a limit on the number of views and layouts you can use to display the widget). While designing, you can use different colors, images, icons, buttons, text, size…

Since they can be of different sizes, your developers will play an important role here. Together you can define how the widget will look like and try and define all the possible sizes for your widget according to the content you want to display to your users.

When you first start thinking about the Android widget, go through the material guidelines on that topic: https://bit.ly/3d9FvLf

These are the main points to keep in mind when designing the widget for android:

  • the height or width of a widget can be adjusted and you can define how many cells on the home screen it will take up
  • default home screen positions widgets in its window, based on a grid of cells that have a defined height and width. These cells are roughly 40dp. The term “roughly” is used because different devices can have different cell sizes and layouts.
  • you can set up a minimum number of cells, but can’t define the maximum number
  • if the design doesn’t take up an entire cell, android will align it within the specified cells.
    The user will still be able to tap the whole cell, even if the design doesn’t cover it whole
  • widgets should not generally extend to screen edges and as of Android 4.0, widgets are automatically given margins between the widget frame and the app widget’s bounding box to provide better alignment with other widgets and icons on the user’s home screen
  • preview image — field — specifies a preview of what the app widget looks like. This preview is shown to the user from the widget picker. If this field is not supplied, the app widget’s icon is used for the preview.

Mocking up a widget on Android

You can also create a mockup of your widget on Android in order to define the design or get the client’s approval.

Here is a list of elements you need to think about in order to create a high fidelity mockup.

  1. different sizes of the widget - chosen in accordance with the data you want to show to your users - consult your developers when picking the sizes you want to use
  2. you can use any color you want
  3. margins and padding
  4. create a preview image

Example

A mockup of the Android widget

Conclusion

I hope these tips helped you understand how to create a high fidelity mockup of your widget which you can then share with your teammates or successfully present to a client. If you are looking for something easier, one option would be to create a screenshot of an existing widget and use it to create your mockup. Another option is to create a preview with the developers. The problem with this last option is that in case the client wants to change a lot, the developers have to work on it again and you spend more time on thing which you might not be able to charge.

In either case, my suggestion is: consult your developers before you start working on a widget, together you will be able to create a perfect solution.

A big thanks to our developers Jeton Fejza and Marko Iličić for reviewing this post. :)

--

--