One day a few of my peers on the creative team came to me with a request/challenge – could I build a Sketch plugin that streamlines keeping image assets up-to-date in their comps? After a few iterations, I believe I settled on a solution for them, see the [narrated] video below for details.
assign local/remote URLs to image layers
data is saved at the document level and persists (see sketch file format for more info about this)
upon menu item click, or document open, grab layer object via saved layer ids and update image data with associated URL
no need to iterate through layer hierarchies (slow/wasteful), no need to rename layers, no need to keep directories in a specific structure
To make a better guest experience I was asked create some new html templates to be used in our app’s message center (powered by Urban Airship). Although this used technologies I already knew, there was a ton of specialized learning to understand how all the pieces fit together.
Some key callouts were: understanding how the html entities needed to be prepared/attributed in the template creation process so that the UA CMS sees them as editable fields, exploring how the UA webview creates a JS bridge and passes a UA object to be used by template at run-time, and how the template itself reaches out to UA for user specific data with the help of data passed in the CMS process.
In partnership with Apple and CPS, Ulta hosted a Day of Code at our downtown Chicago office. Students from LakeView High School and Michele Clark were walked through the development lifecycle of a feature, from requirements to development, to getting the app on the app store. We also spent some time introducing the students to the Ulta Beauty brand and high level stats about our company.
We also built an app just for this day so the students could have something tangible to correlate some of our coding topics as we provide the students with the GitHub repo for the app. We did our best to represent all common iOS app view patterns, as well as latest Swift syntax.
Another cool feature in the app is we did a little of the school branding and let students choose their school – doing so updates the app icon and provides with school specific details.
In our latest release we added support for iOS11 and the iPhone X, a major milestone for our development team. With that release I thought it was important to take a look back and see just how much the app [and team] has changed in my time at Ulta.
Cleaned up, simplified, and modernized the codebase. Established a cadence for structuring code aimed for readability and understanding with emphasis on in-line comments explaining business logic. In most cases I tell my developers to structure their code linearly so that it mirrors what’s being displayed.
Identified redundancy in models/views and consolidated
Removed all non-essential third party code (that isn’t mandated by business partners)
Banned the use of cocoa pods and dependency managers.
Removed all unused and old assets / converted new assets to PDF (vector)
Created a “Core” which handles all our application/session/configuration management, as well as contains our own web services client
Established rules on native first UI/UX patterns with creative partners and an understanding of maintaining code over time e.g. I don’t want to be fixing custom controls with each OS release.
Compartmentalized storyboards based on features [performance/readability]
*It’s important to note that the above initiatives reflect my viewpoint on how a large enterprise project with multiple [sometimes fluid] team members should be treated. When creating my own apps I have similar from different goals and I can take certain liberties knowing only I will be maintaining the code.
The screenshots below are a few examples of said changes. On the left is version 4.0.1, the app I inherited when I started, and on the right, 5.2, our latest release.
Search bar changing height is iOS11 revealed some skeletons in our closet, primarily around trying to maintain opaque navigation and tab bars which led to layout issues. I also explored moving the search bar to the new searchController property on navigation controller, but the business ultimately wanted to maintain the title view approach/look. Search controller is nice though because it has support for large title, hiding when scrolling, etc.
Supporting iPhone X wasn’t too much effort because of my previous enforcement of using native views/controls and auto layout.
For P3 colors we changed obvious things at first: launch screen, app icon and primary brand colors. We also made a conscious choice to not make every brand color P3, like the typography saying “If everything is bold, nothing is bold” – and we wanted certain color to stand out. P3 conversion from a code perspective is simple, but from a conversion standpoint I still am not sure the proper method.
Converting Brand colors to P3 (view image below on P3 screen for accurate reproduction)