theonlylars

have you ever met another?

Rapid Content Prototyping With PlaceKit

Last week I open-sourced MMProgressHUD, a small work-project that I’ve been working on for what seems like an eternity. I alluded in my last post that I was also releasing a personal project later in the week. I went ahead and open-sourced that project which I’ve been calling “PlaceKit” for the Objective-C “Back On the Map” hackathon this past Saturday.

What is PlaceKit?

Think of PlaceKit as a central, lightweight, dependency-less library for all of your content, placeholder, test data and random numerical needs that you might run into during prototyping or in the early phases of production development.

Let’s go through a couple of scenarios that you might find yourself needing PlaceKit:

  1. You want to try something out fast, but need some content to show how it might look with real text or images
  2. You want to create a demo application for some particular widget you are working on, and need a set of fake data to display. Ditto for needing randomized data and geometry for creating random views or random offsets.
  3. You are working on a production app, but the server API is not ready yet, so you now have to come up with a large dataset of fake data to populate a fake database that you can use in your application until it is ready.

These are the primary scenarios I built PlaceKit to make easier. We all know about using lorem ipsum, but when we need it, we typically will open up our favorite browser, google “lorem ipsum generator” and then copy/paste the text into the appropriate place we would like it to show up. This is all well and great, but it really isn’t scalable, isn’t randomized and also won’t simulate fetching from the network. This scenario is also true for images.

MMProgressHUD

This morning I open-sourced a fun side-project I’ve been working on for the past (almost) two years - MMProgressHUD. “Wow, that looks a lot like MBProgressHUD!” Yes, astute pupil, not only is it in the same category of control, it shares 95% the same letters in the same order as MBProgressHUD. This was merely a coincidence since Mutual Mobile’s official Objective-C class prefix is MM:

From the Ground Up

MMProgressHUD was built from the ground up with a primary focus on animation, presentation and to cover the status bar. I also wanted a framework to easily add new animations and secondarily accept extremely basic user input.

Check It Out

If you’re looking for a new HUD interface, just curious or merely want to check out the bits and peek under the hood, feel free to check out the repository on GitHub. As always, if you find a bug or would like a new feature, feel free to fork the repo and submit a pull request!

iOS 7

I’ve also got some fun things planned for MMProgressHUD and iOS 7 that I can’t yet share publicly, but it will play very nicely and fit right in with the new styling iOS 7 will bring. I can’t wait.

Up Next

This is one of two things I’ve been working to open-source recently. If I weren’t on vacation right now, I’d be working on releasing the other. If you’ve ever been working on an early or prototype version of an app and needed to fill it with content, you’ll really be excited about the next project I’ll be releasing. It’s nothing too too exciting, but I hope others besides me find it really useful.

Building Twitter #music’s EQ Slider

Semi-recently, Twitter came out with a cool new music app to discovery new music on (get ready for it) Twitter. They aptly named their new chicklet “#music”. Visually, #music is a very, very cool app. Everything is custom: transitions, collection views, collection view selection animations, media player controls, and one very cool volume slider. If you don’t have an Rdio or Spotify subscription, you probably don’t see anything cool about the media player’s volume slider, but when you have one of the aforementioned subscriptions, the slider turns into a full-on 2-channel equalizer. It’s very cool.

So I had to build it - and now I’m going to show you how I built it so you can build something similar. This isn’t a full-on tutorial, but some generics behind building it with some code samples.

LARSBar

The final product I’ve created is available as LARSBar on GitHub under the MIT license. Ignore the name. Seriously, despite trying to move away from my name as a prefix, my friends at work penned the name for this control when I showed it to them, and I couldn’t come up with anything better.

Design

When I first start a new UI component. I take a step back and look at the big picture of what it is I’m going to be building. This is what we’re going to be building if you haven’t seen the app:

A Screenshot of Twitter’s EQ Volume Slider:

Before I begin, I ask myself a couple of questions to help me plan and not waste time (note this is just implementation, designing a component involves a whole different set of usability questions):

Abandoning the Consumer: Ignoring User Experience

Fair Warning: This post is relatively SimCity-centric.

The title includes some strong words, yes - but you do not want your users even feeling forgotten about. In my line of work, the user is a very central part of the development cycle. This is true in part to the intimate nature of the software I write. My software travels with the user. Everywhere the user goes - my software is living in their pocket. In fact, not only is it always with the user, but the user may also be using my software in a specific environment. How the user uses and interfaces with my software is what is known as the user experience. It has nothing to do with what the UI looks like, the shadow angle of the button when pressed or the ‘flat’ nature of the design.

The User’s Experience as a Requirement

In today’s market, the user is becoming ever more selective about the applications that they use and is raising the standards to which they will use when selecting their software using. Some of us have very specific quips about what they consider a “deal-breaker”. For me, this could be something like not making your app iPhone 5 enabled when it supports iOS 5.0+ or when you still don’t have retina assets for your app. This is inexcusable. I have heard others say that they hate when apps hijack the status bar for their own temporary in-app status. I personally love how that looks.

The above is said to emphasize that consumers care now more than ever about how their software both looks, feels, behaves, and how they can use it. If your users feel confused, nickel-and-dimed, or find using your software in any way difficult, they will most likely not use it anymore. Moreover, they will not tell their friends about it. If you screw up badly enough, they will actively tell their friends to avoid your software altogether.

Autolayout: To NIB or Not to NIB

A coworker recently asked me at the end of last week what I thought, based on my experience on my last iOS 6-only project, would be the best approach to starting to learn and work with autolayout. He was specifically asking if he should bother working with xib files, or simply layout everything in code. He then asked that if he were to go with a xib file, what the best approach would be to balance the time/effort workflow for autolayout.

All of the below is 100% based on my experience on my last project that was iOS 6-only, where autolayout was extensively utilized.

Autolayout Layout Construction Priority

Apple states in all of their documentation the following order you should begin implementing autolayout:

  1. Nib file
  2. Visual formatting language
  3. Individual constraints

To NIB

The priority above is, in my opinion, very dependent on what you are working on. If you have a pretty trivial layout that is simply being constrained based on something simple like an orientation change, then a xib file will probably be your best bet for a rapid layout that is unambiguous and doesn’t give you any issue during maintenance with very little effort.

Another very helpful feature of autolayout’s constraints is the fact that you can create an outlet to a single constraint. You can use this outlet to easily animate a change, change the constraints constant, or remove a constraint altogether without much additional effort. To animation a constraint change, simply update your constraint(s), call -setNeedsLayout, then call -layoutIfNeeded in an animation block. Very quick and easy.

No Touching

However, using xibs for autolayout starts to break down and become more time than it’s worth when you get into complex layouts that depend on cross-view constraints, constraints depending on a view’s content or complex constraint sets relating to many physically smaller views (the constraints simply become an absolute nightmare to physically click on and manage in the xib without screwing something else up).