3 Key Lessons Learned Creating The New iOS Design Library

April 19th, 2012

A couple of weeks ago we released an extensive, new iOS Design Library.

This library has been created as an extension of the original iPhone Library and is intended to supersede that library for all new projects. Existing projects that use components in the iPhone Library should continue to link to it but may also link to this new library.

The iOS Library contains a collection of custom element widgets, components and icons for prototyping Apple iPad, iPhone and iPod Touch applications.

Creating libraries like this gives us a lot of ideas on how to improve GUI Design Studio itself, but also throws up some interesting learning experiences for library design.

Here’s three key lessons we learned that may be of use to you in creating your own design libraries for reusing widgets and components in your own projects…

1. Think ahead when planning the library structure

When we produced the original iPhone Library, we had always intended on producing a separate iPad Library.

But when we came to work on the iPad Library, we quickly realized that there’d be a lot of overlap with the same widgets appearing in both libraries. If Apple ever produce another type of iOS device with a similar UI then the overlap problem would worsen.

Not only that, but many iOS Apps need to be designed for both platforms so a single design project might contain screens for both targets. While it would still be easy to link to both iPhone and iPad libraries separately, it makes sense just to need the one library.


In the end, we maintained mostly the same folder structure and file names for iPhone components with and added “iPad” labels for the new additions aimed at the iPad. So if a design file or folder contains “iPad” then that’s what it’s for, otherwise it’s for the iPhone or generic.

For widgets, it’s not so bad. The structure is not important because, unlike components, widgets are copied into designs with no reference back to their original location.

Overall, with a bit of forward thinking and planning, we could have had a more consistent structure and naming convention and also avoided the problem of having an obsolete design library floating around!

2. Turn complex, static components into images to improve performance

Virtual keyboards are essential for application design because they take up a vast amount of screen real-estate when active. You need to design your application so that it works well when you only have half the screen to play with.

But rendering the 93 layers of elements that make up an iPad keyboard, complete with subtle gradient fills, take their toll on performance.


So what can be done?

Well, designs like this are used as static components only. There’s no real interaction with them in the prototype. In the case of a virtual keyboard, you’ll be using a real keyboard to enter the text (until the day when it runs on an actual iPad).

What we’ve learnt is that turning the design into an image produces a dramatic performance increase because all the separate layers are replaced by a single image blit.

And it only takes a few seconds to do this so it’s no big deal if you need to change the design and re-create the image:

  1. With the design open, use the “Edit | Copy Design Image” menu command (Ctrl+Shift+C hotkey).
  2. Select the target folder in the Project File Tree. We recommend using same folder as the original design.
  3. Click the “Paste Image to File” button or use the “Project | Paste Image to File…” menu command.
  4. Enter the image file name. We recommend using the same name as the design but with an image extension, of course, instead of “.gui”.

That’s it! Now you can drag and drop the image version of the design instead of the design file.

It’s tempting to have used an actual iPad keyboard screen grab from the start instead of having to go through all the effort to recreate it from elements and then turn it into an image. If you’re creating a library for private use then this is acceptable but copyright issues become a major consideration when a library is to be distributed.

3. Think about how custom element widgets can be more easily reused

Custom elements, also known as widgets, are the real heart of a design library. For all but the simplest of widgets, they’ll typically be made up of multiple element layers. But if they’re not created in the right way, they can be awkward to use in a design project.

The key to good widget design is to go that extra half mile and spend a minute or two checking how well it performs in reuse, especially when you want to move and resize it or edit the text or other content.

A custom button widget and exploded view showing its construction from 4 element layers and the top, text layer resize anchors


There are cases when some of the tips below don’t apply, such as when combining multiple controls in an entry form, but if you’re creating a single, self-contained widget, they all make sense in most cases:

  1. When it comes to moving the widget as a whole, when you’ve completed the widget design, the last action you should take is to select all the elements (Ctrl+A) and group them (Ctrl+G). This ensures that when a top-layer element is selected, all the widget elements will move together. While you’re editing the design you’ll probably want to do the reverse at some point (select all then ungroup with Ctrl+Shift+G) to make it easier to rearrange things.
  2. The ability to resize a widget is determined by the positional parent-child relationships controlled by Resize Anchors on the child. Use Shift+F8 to toggle these on and off in the graphical editor or access them from the Position tab of the properties editor. An advantage of using the graphical approach is that you can affect all selected elements at the same time.
  3. Content editing is simple. As a general rule, ensure that all editable content, like text and icons, is placed on the top layer so that it is directly click-able for editing.
  4. Sometimes you have to get creative to achieve the effect you want, by combining the available base elements in various layers. The last trick is to make sure the widget has a single background element encompassing the whole thing. When a widget is dragged onto a design, all background elements will be selected. If there is only one the operation is clean and that element can be resized to resize the entire widget, assuming the resize anchors have been properly set up.


Finally, it’s worth noting that whenever you use a layered widget in your designs and you want to select the background element for resizing, remember that the Tab key and the Shift+Tab combinations are your friends for switching between selected elements.

Please leave a comment below and share this article with your friends and colleagues if you found it useful.



Comments are closed.