In the past year, I shifted interested from the desktop to the web. I’m really drawn to apps that can be accessed from any device with a browser. I have a history with HTML, CSS, Flash and PHP, so I’m familiar with the space, but only in a presentation sense—I’ve made websites, but not web apps. I dove head-first into Rails and instantly fell in love, but the immediate response I knew with Flash was replaced with page loads. Because of this, I turned to Javascript.
Like the new kid at school, I didn’t know who was who in regard to frameworks. I looked around and saw mentions of Backbone.js everywhere, so I assumed it was the standard. After several months, however, I realized it’s not for me—Backbone.js lacks a clear direction of use. Every tutorial I read used a different structure, and it almost seemed too easy to disregard proven design patterns.
Enter Spine.js. I spent a night just reading through its guides and examining its demo apps. Everything I saw just looked right. That night, I wore a big smile and even had trouble sleeping because I couldn’t wait to start using it. What made me so excited?—these 10 things:
-
A Clear Architecture
Spine.js follows MVC (model-view-controller, for those who should take a moment to learn MVC). All the apps I’ve written follow the MVC architecture, so I immediately know how to structure my app using Spine.js. I also feel a sense of familiarity off the bat. There’s no question of which class does what or where each class lives.
-
Models are Models
Backbone.js has models, but it’s awkward because there are also collections—essentially an array of models that can also query an API and populate itself with the results. Spine.js models are very similar to Rails models. A model can be instantiated to represent a record, but it also has class-level methods for retrieving records from the API. These methods return the results instead of populating an array, so we don’t have to contemplate where the class lives, as one would with collections. And because collections are instances, many of the examples I’ve seen treat them as singletons. As a result, those learning Backbone.js and following these examples are also learning how to write untestable code.
-
Spine.app
While using Backbone.js, I found myself copy/pasting code every time I created a new class. I missed the generators I grew accustomed to in Rails. With a single command, I could generate the new class along with its spec, based on a template—this adds years to a dev’s life. “Write Backbone.js generators” was on my todo list for weeks, but I never got around to it.
Spine.app generates files. With a single line, I can create a class and its spec, just like in Rails. Hell, I can even generate a new app with one command.
-
Dynamic Records
This one is just crazy black magic, but it solves a problem I faced with Backbone.js. Let’s say you fetched a record in one view of the app. Then you fetch and update that same record in a different view. In Spine.js, both records will update. You don’t have to worry about keeping them in sync. The moment I read about this, a single tear rolled down my cheek.
-
Elements Hash
With Backbone.js, I constantly found myself manually assigning variables to nested elements in every view’s render method, repeating the same code for each element—that’s a lot of boilerplate. In Spine.js, there’s an ‘elements’ hash. The keys are selectors and the values are variable names. Just like the ‘events’ hash in Backbone.js, all your elements are mapped—clearly and easily.
-
The Release Method
In my Flash days, optimization was a key to survival. If ever I forgot to remove a single event listener, my app would leak memory like… a poorly maintained app. Because of this, every class I wrote included a method to nullify all references and remove all event listeners. Spine.js has this built in. Sold.
-
Routing Lives in the Controller
There is no Router class in Spine.js. This functionality is part of the Controller class where it belongs. In any controller, I can navigate to a new location and react to this new location. Other controllers can react to this new location as well. Now there’s no temptation to create a router singleton.
-
Model Adapters
By default, Spine.js saves models in memory, but there are two adapters that can be applied to any model class—Ajax and Local. By simply extending either of these adapters, your data can live in a remote database or even locally using HTML5’s local storage API. All this functionality is a matter of one line of code.
-
Get a Model from its HTML Element
This is another issue I faced with Backbone.js. I could instantiate a view and tie a model to it, but if I would ever need to reference that data without access to the view instance, I’d be out of luck. Spine.js provides access to an element’s model through a jQuery plugin. Just call the ‘data’ method on the element and you have your model.
-
Logging
Spine.js comes equipped with a nice little convenience module for logging. In any controller, you can call the log method and it will write to the console with a set prefix. You can then toggle whether or not to trace the logs without removing them.
In Conclusion
Now, this list is why I switched to Spine.js. Some apps might be better suited for Backbone.js, or any other JS framework. If you’re researching different frameworks, definitely take a look at all of them. Do your due dilligence. Make sure whichever framework you choose has a clear example and is free from gotchas. You don’t want to find yourself halfway through development and questioning the framework.
Resources
By default, Spine.app generates an app with Jasmine as its testing framework. I much prefer Mocha.js, so I forked Spine.app to add Mocha.js support. It also includes a HAML compiler and I have plans to include SASS as well as other helpers.
Here are all my javascript bookmarks from my recent high-dive into the language. They consist of links to articles, libraries, and answered StackOverflow questions. Hopefully, they will get a few of you out of a pickle.
I plan to write more about my Spine.js discoveries over the coming months, so keep an eye out if you’re interested.
thumbnail from OrthoIndy
When I left Adobe, I returned my company laptop. Since then, I’ve been test-driving a borrowed Macbook Air from fellow Studiomate Skylar Challand (Canadians are so nice!). While using the laptop, I realized something strange—even though it lacks a disc drive, it still has an eject key. This is understandable because of the optional USB superdrive, but the last time I actually used a disc drive was to burn the MP3s I downloaded from Limewire.
Half-joking, I tweeted this:
Before the tweet could load, I knew I had to follow through. And within 15 minutes, I had a solution.
Disclaimer: There are probably dozens of easier ways to do this, but this is the first way that came to mind.
-
Download KeyRemap4MacBook
KeyRemap4MacBook is a free preference pane app. I would describe it, but it’s one of those apps that skips all the cutesy names and tells you exactly what it does.
-
Map the eject key to F13
Go to the KeyRemap4MacBook preference pane, search for ‘eject f13’ and check its box. I use F13 because, on my computer at least, it isn’t mapped to anything. 
-
Download rimshot MP3 from instantrimshot.com
If you haven’t been to instantrimshot.com, you aren’t telling enough jokes in the workplace. I ended up scrubbing the HTML to find the MP3 file, but you can just download it here.
-
Create Alfred extension to play MP3 using afplay
I skipped writing a step for downloading Alfred and purchasing the Powerpack because I assume you already have them. If not, 5 points taken from Gryffindor! Open the preferences and under ‘Extensions’, create a shell script as seen below. Ever since Leopard, OSX comes bundled with a binary called ‘afplay’ that lets you play audio files from the command line. Incredibly useful in this case. 
-
Create global hotkey for extension
Lastly, go to the ‘Hotkeys’ tab and create a global hotkey for your shell script and map it to F13. 
Try it out and let me know how it goes!
Early this year, my brother Ben interviewed me as part of a series he’s working on. I talk about design, why I build, and my thoughts on collaboration. Ben recently started his own company as well, Hallman Productions, providing services for video recording and editing.
In case you were wondering about the birdhouse and plant, Ben interviewed me at our parents’ house in PA while I was home for a visit. And no, a tiny bird does not live in that birdhouse. I wish.
As mentioned in my previous post, I recently left Adobe. I won’t go into detail about why I left—I just knew it was time. Leading up to my last day, I met with several companies. I figured my next steps would be to join a new company and see where it leads me.
All of them seemed like great opportunities. It was enlightening to talk to people about their future while I was trying to figure out mine. When asked for input on what they should do next, I surprisingly had no problem sharing my thoughts. This on-the-spot kind of thinking allowed me to come up with ideas I never considered, looking years into the future instead of just months.
I showed them my work, speaking thoroughly about the process and sharing the many stories tied to each app. When asked about specific UX innovations in my apps, I turned to DestroyFlickr. I recalled it having a handful of unique features I was really proud of.
Revisiting the app left me a bit nostalgic. I could remember everything about the time I wrote it. I remembered being so excited to work on it I couldn’t sleep. I remembered knowing nothing about designing an app besides what felt right. I remembered celebrating each time I got a new user—reaching 30 was a huge deal.
At that moment, I fell in love with my side projects all over again. I realized I would still work on them no matter where I ended up—they are a part of me. Without a doubt, these side projects are my best work. They are what I’m best known for. They are my passion in life.
Then why are they just side projects?
The decision has never been more clear. It’s time to destroy today, every day. I will work for myself, spending every waking moment just building. I will collaborate with other builders, creating partnerships out of the want to make our ideas real. I will share everything I learn—writing articles and teaching workshops. Whether I’m designing, developing, or both, I will ship quality products. This is what I need to do. I’m ready.
After almost three years with Adobe, it’s time for me to move on. I was first a developer, then a designer, and now I need to be both. I wish the best for my fellow Adobe-ans and look forward to their future work. As for me, that’s for another post. Stay tuned.
A few weeks ago, I had the pleasure of meeting Carter Cleveland, founder and CEO of Art.sy. He demo’d the site at Studiomates and left us all with our jaws on the floor—literally, I blacked out and missed half of the demo. Not really, but still. Art.sy is a serious game-changer in a world where there are no serious players.
Art.sy has a handful of use-cases. For galleries, it’s a tool for selling. For collectors, it’s a tool for buying. And for art admirers of all levels, it’s an incredible tool for browsing and discovering art of any age. The site is several years in the making and destined to shake things up.
Today, I received several Art.sy invites to hand out. If you know me, you know I can’t just give them away without a good competition. So here’s the deal: Photoshop yourself into your favorite piece of art. Link to your image in the comments and I’ll pick my top 15.
Update
Carter liked the competition idea so much, he decided to give me ten more invites. Keep the submissions coming, and per Daniel Howells’ request, below is mine to get the ball rolling:
I know, I know. Instagram again? Yes. I originally intended to pick a different app each time, but I find myself wanting this feature on a regular basis, so I just have to get it off my chest.
Instagram has a feature that’s pretty common among photo apps—tilt-shift. Now, tilt-shift is an advanced feature in the SLR world. TS lenses are typically used for architecture or interior photography to even the perspective and a good one will run you a solid $2 grand. Somewhat recently, tilt-shift became the hot new thing because it can make a landscape look like an HO-scale train set. As a result, every photo app added linear blur to fake the effect of tilt-shift.
The problem here is that every app has this advanced feature, but they all lack a pretty basic one—depth of field. Sure, you could do what I do and use the tilt-shift tool to emphasize the depth of field, but if you shoot any organically shaped subjects, it’s tough. That’s why I call for ‘depth of field drawing.’ The concept is simple. Using your finger, draw the area you want to blur. This way, you can produce a stronger depth of field around any shaped subject or subjects.
pointing hand courtesy of Gesturecons
This post is the beginning of a series I referenced a few weeks back—UX I Want. Instead of just hoping or requesting the makers behind an app introduce a specific UX I want, I’m going to design and mock it for them. This way, they almost have to implement it, right?
I’m going to start things off easy and target Instagram. Here lies an app that lacks more features than I can shake a Wacom pen at. That said, Instagram has a very nice shorcut for liking a photo—just double tap it. The problem is that a second double tap does the unexpected and ‘likes’ the photo again. Since you can only ‘like’ a photo once, this means nothing—it’s a waste of a gesture.
For instances when you fumble your phone or scroll too fast, an accidental double tap might occur. Maybe you even have a change of heart. Sure, tapping the toggled ‘like’ button to unlike the photo would suffice, but to maintain a sense of consistency, the double tap gesture itself should be a toggle as well.
I love tools that improve the designer/developer workflow—GuideGuide does just that. Instead of wasting (probably valuable) time manually dragging each guide into place, you can enter your grid specs and GuideGuide will place each guide for you. You can also clear everything with a single click and create a grid in a specific area using the marquee tool. It’s clear that creator, Cameron McEfee, found Photoshop’s guide management lacking and decided to fix it on his own—a true maker mentality.
GuideGuide is completely free, but you should definitely donate. This tool is too good to give away.
Last week, Jen and I flew to New York in the hunt for an apartment before visiting family in PA. I received a tip of an available apartment the day before we left. Immediately, I scheduled a walkthrough with the landlord and nabbed the place. It is located in Carroll Gardens, a wonderful neighborhood on the west side of Brooklyn. We head back to NYC tomorrow to sign the lease and visit a few friends before returning to SF. After that, all we have to do is move.
When we moved from Baltimore to SF, we used Adobe’s moving company. This time, we’re trying something new by selling all our furniture and shipping everything else via USPS and Fedex. I’ve read quite a bit about this ‘strategy’ and most find it to be a much cheaper option. Shipping little by little throughout the month leading up to our flight sounds less stressful than an all-at-once plan of attack. USPS offers a service called Media Mail, which is a dirt-cheap way to ship books. All the rest will go with Fedex. I know they’ve been in the news lately for all the wrong reasons, but I’ve never had any issues, so fingers-crossed. Next stop, New York!
-
1
-
2
-
3
-
4
-
5
