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!
(more…)
