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…
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!
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:
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.
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:
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.