The designers and developers at Arc90 will become the core of the SFX Platform Team. We will work with the other groups at SFX to create a completely new digital platform to connect and serve the legions of fans and artists that make up electronic music culture.

I will oversee this effort as Chief Product Officer. Everyone who works at Arc90 will be part of the new product team. We will also be adding developers and growing the team. We are gearing up to do great engineering at a world-changing scale.

We are incredibly excited.

At our founding in 2004 we decided to make Arc90 a company focused on building world-class digital platforms for a very small number of clients. Our client engagements typically lasted years. We became known as a developer-first company that did innovative work, and as active contributors to the open-source community. We also became known for the products that came out of Arc90 Labs, such as Kindling and Readability.

SFX originally came to Arc90 as a client. As the relationship grew, we were incredibly impressed by the scope of SFX’s vision: a vision of one digital framework that connects together every aspect of Electronic Music Culture (EMC). It was clear to us that SFX had plans to build something entirely new and unprecedented: a global, API-driven platform that delivers content, connects people to events (and to each other), connects artists to their fans, integrates with the largest social networks, and works across devices. And those are just the aspects of the system that we can publicly disclose.

We knew we wanted this challenge. We wanted to build and support this system, and we knew we’d need to grow to do that. That’s why an acquisition made perfect sense.

I’m proud of the family we’ve built. But I also know that this is a wonderful way forward. It’s a chance to watch our culture grow and adapt. Arc90’s commitment to great design and rigorous approach to engineering will become the core of SFX’s platform strategy. Our engineers will have more opportunities, more challenges, more opportunities to scale, and more chances to attend awesome dance festivals than any other engineers on earth.

We see incredibly exciting days ahead. If you’d like to join us on this next journey, we’re hiring and we’d love to hear from you.

Finally, to the employees, clients, and supporters who helped us get here: thank you.

People love working with their iPads because the interface is radically simpler than a traditional WIMP system: only a single app is on the screen at any moment; many apps show only one view at a time; and most or all relevant actions/commands are immediately visible right on the screen at all times. This makes the system highly accessible and a pleasure to use — but there’s a downside. There are some workflows which require a lot of navigation; this navigation interrupts the user’s flow and forces them to pay attention to what is essentially irrelevant interstitial work, “computer administrative debris” (à la Tufte). Interestingly, iOS supports certain “advanced gestures” which circumvent these problems — but those gestures are not easily discoverable. I’ll describe some examples and then a way that iOS could make these gestures unobtrusively and easily discoverable.

This proposal is equally applicable to any touch interface; I’m only using iOS for these examples and illustrations because it’s the platform with which I’m most familiar.

Some Examples of Advanced Gestures

Switching Between Apps

Let’s say you’re composing a brilliant tweet in Tweetbot. To do so, however, you need to refer to a web page loaded in Safari. So you’re switching back and forth between Tweetbot and Safari, over and over again.

Most people would do this by pressing the home button to return to the home screen, then tapping the icon of the app they’re switching to — unless the two apps are on different pages of the home screen, in which case they’d press the home button, swipe N times to get to the right page, and then tap on the icon of the other app.

Fortunately, iOS includes a faster, simpler, more direct, and less distracting way to switch apps — two ways, if you’re using an iPad.

The approach that works on all iOS devices is to double-click the home button to display the multitasking bar. This raises the current app to show a bar at the bottom of the screen that displays recently used apps. The apps are sorted by the order in which they were most recently used, so it’s quick and easy to switch back and forth between two apps: you simply double-click on the home button and then tap the left-most app in the multitasking bar.

If you have an iPad (any model except the original iPad), you can turn on a feature named “Multitasking Gestures” in the Settings app. Once this setting is active, you can switch between apps quickly and fluidly by simply swiping left and right on the screen with four or five fingers. This is radically better than either of the other two methods — it makes multitasking on the iPad more of a pleasure than a chore.

Switching Between a Reference Email and a Draft Email

Another common case is needing to refer to an email while writing another one. This is similar to the prior example, in that you’re switching back and forth between two views, except this time both views are in the same app.

The only obvious way to do this requires a lot of navigation, and it’s quite a drag. To switch from writing a message to reviewing a message and back to writing a message, one needs to:

1. Tap the “Cancel” button
2. Tap “Save Draft”
3. In the ideal case, the email to which you wish to refer is right there
4. To return to your draft, you need to:
   1. Navigate out of the email you’re viewing, out of the mailbox you’re viewing, and into the “Drafts” mailbox
   2. Tap the draft email

1. Tap the “Cancel” button
2. Tap “Save Draft”
3. Navigate out of the “Drafts” mailbox and to the mailbox containing the reference email
4. Tap the reference email

Thankfully, iOS includes a great gesture for avoiding all that navigation. When you’re viewing a message and want to resume writing a draft email, all you need to do is tap-and-hold on the ever-present “Compose” button, and a list of your drafts pops up right there. Just tap on the draft you wish to resume writing, and it opens right up. When you want to refer to the reference email again, just close the draft and the reference email is right there — no navigation required.

Jumping Multiple Steps in Safari’s History

Let’s say you’ve tapped 5 or 6 links while browsing, and want to go back to where you started. Sure, you could just tap the back button over and over again, causing each intermediate page to load — and use unnecessary battery life and bandwidth. But if you tap-and-hold the back button, you’ll get a popover containing a list of the pages you’ve navigated through within that tab. Just tap the page you want and Safari will jump directly to it. (This also works with the forward button, if you’ve jumped back and then want to jump forward.)

Re-opening an Accidentally Closed Browser Tab

It’s all too easy to accidentally close a browser tab in Safari on iPad. And it can be a pain to reopen the tab, if you don’t know the URL — you need to tap “+” to create a new tab, then navigate around in your history until you find the page, then tap it. And your browsing history from that tab is lost.

A better way to reopen that tab is to tap-and-hold “+” — you’ll see a popover containing a list of all recently closed tabs. Tap the tab you want and it’s reopened instantly — and not only does it reload the page you were last using, it also reloads the browsing history for that tab, so you can use the tap-and-hold technique on the back button to jump back in your session.

Currently, this example applies only to iPad, as Safari in iOS 6 on iPhone doesn’t use tabs, but rather “pages” (an unfortunate overloaded name). I’m not sure whether this will change with iOS 7.

There are plenty of other examples in plenty of other apps — especially sophisticated productivity apps such as Apple’s iWork suite, or the Omni Group’s impressive apps — but hopefully these are sufficient to illustrate my point: that iOS and many iOS apps support powerful advanced gestures which enable a much easier, more fluid, and more efficient experience, but that none of them are easily discoverable. On to the proposed solution!

The Proposal

In a nutshell: the OS and apps should monitor the user’s behavior, and if they observe the user performing a task “the long way” for which an advanced gesture exists, they should display an unobtrusive notification to inform the user that there’s a faster, easier way to do what they’re doing. If the user taps on the notification, they should see a simple, direct, and visual popup which teaches the gesture.

Some Examples

Switching Between Apps

If the OS observes the user switching between apps by using the home button to go to the home screen, then it should display an unobtrusive notification at the top of the screen, like so:

If the user taps the notification, the OS would display a view which would teach the shortcut in a simple, direct, and visual way. Maybe it’d be some illustrations, maybe some animations — I’m not an expert in this sort of thing, and I’ll leave this up to those who are.

Jumping Multiple Steps in Safari’s History

If Safari observes the user tapping the “Back” button repeatedly, it should display an unobtrusive notification at the top of the screen, like so:

If the user taps the notification, the app would display a view… well, you get the idea.

I’d love to see Apple or Google implement this idea at the OS level and in their apps, and provide APIs for this approach, but in the meantime any app developer can add this to their apps right now.

Finally, my colleague Timothy Meaney has pointed out that this idea assumes that touch apps have already crossed the threshold of making powerful functionality accessible to a broad audience, and that the next challenge is for app developers to provide more thoughtful interactions to their users — to create apps which anticipate their users’ needs, support them towards their goals, and generally strive to delight their users by constantly helping and supporting them. This rings true for me and I appreciate Tim pointing it out.

Thanks for reading! I’d love to hear what you think of this idea, and especially if you try implementing it! Feel free to contact me via email or Twitter.

On July 31, we’re hosting a panel discussion featuring special guests Karen McGrane, Paul Ford and our own Richard Ziade. Moderated by Code Meet Print’s Glenn Nano, the panel will discuss anything and everything about technology, culture, the web and publishing.

Want to join us? We’re opening up a few invites, first-come, first-serve, to our blog readers. Shoot us an email at events@arc90.com and we’ll give you the access code.

It’s easy to forget about maintenance. It’s easy to buy plants because they’re beautiful and let them die because it’s more work to maintain things than to buy something new.

I’m not a gardener. I work in technology. Every day start-ups are born and every day some of them die. A mission is only as good as the people who are available to realize it, but in an industry with nearly 0% unemployment, competition for these people is fierce. How should we approach the people whose shiny resumes and varied experiences promise to move your organization forward? How can we be thoughtful about retention in a way that feels challenging and productive for everyone involved?

Let me back up here.

Two years ago I got an opportunity to evolve my job here at Arc90 when I took on the role of Director of Employee Development. When I began that role, I stepped into the wilderness. Sure, we were doing basic Human Resources. We hired people, we got them health insurance and we staffed them on teams. Sometimes we even switched their teams or gave them a new role. We weren’t doing badly, but we weren’t managing anyone’s development with intention either.

I sussed out what needed attention most and slowly started to instill processes and practices. I’ve written before about the way we cultivate candidates and the way we think about career path. But what I do is more than onboarding and it’s more than HR; my job is about finding and retaining the people who will make Arc90 successful.

After much thought, I believe that the name for what I do is Sustainable Resourcing. Sustainable Resourcing is an approach to managing the development of every person at the company. It relies on the fact that resourcing decisions are made not only in the company’s best interest, but in the interest of the individual as well. It happens through incremental change with regard to roles, teams, focus and skill sets. It hinges on the fact that both the company and the individual are headed in the same direction.

There are five main tenets of Sustainable Resourcing:

1. In almost every case, what’s right for the individual is what’s right for the company.
2. Building relationships with potential candidates (irrespective of current job openings) leads to solid hires.
3. Paying hiring managers commission per hire confuses the process. (Referral bonuses, for other employees, is totally different, though.)
4. Skillsets are just a starting point. A Python developer is not always a Python developer.
5. Maintenance is different than resuscitation. Keep a consistent pulse on how employees and teams are functioning; only addressing problems when they’re life-or-death is untenable.

Resourcing and retention cannot live in a small office with the HR person and they can’t happen off the edge of the CEO’s desk because they have big stakes. The best products and visions can only happen through steady building. Success is nearly impossible (and definitely slower) if there’s a revolving door of people driving things forward.

Are you nurturing this process? Are you taking care of the people you work alongside 40+ hours per week? I have much more to share in the future on this blog about the ways we grow here at Arc90 and the ways that Sustainable Resourcing has been shaping who we are and who we want to be. Stay tuned.

The Contest

Write an implementation of Fizz Buzz using Fibonacci numbers- up to 50 terms – as the sequence. Drop your implementation in a Gist. Bonus points for elegance, using recursion, compactness and sheer creativity. We need to be able to run any answer.

To submit, tweet at @arc90 with a link to your Gist. We’ll pick the top three and send you an invite. Good luck!

About 4 years ago we introduced TBUZZ, a Web browser add-on which makes it super-easy and super-fast to tweet about any web page and to see what people are saying on Twitter about that page. We were big fans of the tool and enjoyed using it ourselves, and it developed a small but passionate group of users out there in the world.

Unfortunately, after a few years Twitter changed their API and TBUZZ stopped working. Many of us here at Arc missed it and we heard from some vocal fans as well, but we were busy and just didn’t have the time to look into updating it. We mourned its passing and learned to live with slow tweeting and manual searching. We never forgot it, though. It would inevitably come up over drinks at one of our happy hours or over tacos at weekly lunch, or in ideas in our Kindling instance.

Today I’m excited to say that we have updated TBUZZ and it’s now 100% functional! We eventually found a little time to scratch this particular itch, and we’re very happy with how it’s come out. If you’d like to check it out, just head over to tbuzz.arc90.com!

For those of you interested in the sausage-making, here’s a quick recap of what it took to resurrect TBUZZ:

All interactions with the Twitter API are handled by the TBUZZ server, which was written in PHP and used a hodgepodge of various OAuth and Twitter libraries which targeted Twitter’s no-longer-in-service 1.0 API.

At first I tried to update the server by replacing the various OAuth and Twitter libraries with the Zend Framework’s OAuth and Twitter services, which have been updated to work with Twitter’s current API. The server already used an older version of the framework, so this seemed like it should be a simple matter of upgrading the framework, then rewiring the code to use it. Unfortunately this didn’t go well. I simply couldn’t get Twitter authentication working properly, and the Zend Framework’s OAuth service proved too difficult to debug.

After being stymied by PHP and the Zend Framework for a few hours too many, I scrapped the entire server codebase and rewrote it in Python using Flask, Flask-OAuth, and Python Twitter Tools. This took only a few hours, and the resulting codebase was a breath of fresh air. To illustrate, the app went from 22 PHP files containing 996 lines of code to 1 Python file containing 92 lines. (To be fair, TBUZZ today doesn’t need to work as hard as it used to, since Twitter now uses its own URL shortener and its search engine dereferences shortened URLs.)

Working with Flask and Flask-OAuth was a joy — until I found that one of the decorators in Flask-OAuth may raise an exception in certain cases, and there’s no way to catch exceptions raised in a decorator when the decorator is applied in the usual way using @-syntax. A bug report was created for this 2 years ago, so I wasn’t going to hold my breath waiting for it to be fixed. I ended up having to apply the decorator manually, which is not easy — thanks to Chris Schomaker for helping out with that! We concluded that functions and methods which are intended to be used as decorators should not raise exceptions; rather, they should call the wrapped function and pass the exception as an argument, à la Node callbacks.

Once we had all the features working properly, we realized that we couldn’t relaunch TBUZZ with its dated look-and-feel — it deserved better. So Robert Petro stepped up and redesigned the app and its installation page, making both feel thoroughly sleek and modern.

Thanks for reading, and I hope you enjoy TBUZZ!

Do not accept a job. Accept an opportunity.

Here’s what a job looks like: you’re hired as the third-wireframer-from-the-left, hired to fill a spot in the long assembly line of software production, possibly for a large and well-known company. Or you’re hired because the role requires someone who knows one specific language or framework. Or maybe you’re hired because a recruiter showed up at a career fair when you were a sophomore and offered you a huge chunk of money to sign on the dotted line so you could sleep easy for a few years, knowing you were safe and sound in someone else’s pipeline.

Here’s what an opportunity looks like: the person interviewing you listens to what you’re interested in. The prospective colleagues you meet come from a variety of backgrounds, colleges and universities. The hiring manager promises that you’ll wear a number of hats, that the lines are slightly blurry around your role, that your evolution at the company depends on things like your initiative and curiosity and hard work.

When people string jobs together like beads on their career path, they find themselves job searching every couple of years, constantly persuaded by a bigger office or a more famous logo. But when people string together opportunities, there’s a flow underneath it all. They organically find new opportunities because people can see that they’re someone who values working with smart and motivated people above all – and that they’re ready to pitch in. The most interesting (and rewarding?) career paths out there are not straight lines, but go through dips and crests and maybe a few double-backs.

They don’t teach this in college, at least they didn’t ten years ago when I was there. Nonetheless, I have found it to be true. And perhaps more importantly, my work at Arc90 is to underscore this truth, to seek out and hire people who want opportunities over jobs.

Looking for an internship? Work after graduation? A new opportunity after several (or many!) years in the field? Visit our openings and get in touch.

We’ve got opportunities to talk about.

• A day or two each week where I stayed at home
• Working evenings and weekends from home
• Working in airports or hotels when travelling
• Working in the local office with teams in 3 countries
• Working at home full-time

You might notice that one of those is not like the others. How can I be telecommuting from an office? Well, in this case, even though I had an office with a test lab and a local co-worker, the majority of my communication was with people in remote locations. Frequently, my coworker and I, despite sitting back-to-back, would opt to chat with each other electronically, rather than remove our headphones. As many remote workers have experienced, the generally asynchronous nature of online communication makes it easier to block off time to focus on a particular issue.

There are plenty of guides out there about how to be a good remote worker, so I won’t go into too much detail here. But from the perspective of being an employee and co-worker, the essential thing is that you establish and maintain a virtual presence, to make up for your missing physical one. This takes the form of email, chat, bug reporting, commit messages, video conferencing, wiki editing, etc. Be prolific.

What I’ve come to realize as I work with a variety of people in different situations is that those who put effort into this virtual presence are more successful in general. They experience fewer mis-communications and generally happier relationships. They gain respect from their co-workers for their more obvious contributions. Making their contributions transparent allows more opportunities for feedback, and over time, reduces the anxiety associated with peer review. Maintenance of their virtual presence will also establish discipline, which is another essential skills for successful developers.

That’s why I advocate for these practices as general development best practices, and in my current leadership role, try to cultivate them in those around me. I think they are beneficial for the reasons described above, but it’s also important to consider that very few of us do exclusively local development any more. With more and more development infrastructure moving to the cloud, chances are that you will end up working with people outside of your office.

The Marksy team coding.

Just before the Christmas break, we shut down our company for two days. It had been a few months since our last lab experiment and the group of creative technologists here at Arc90 were getting a bit restless. We needed some time to put our “normal” work on hold, team up with a different group of people, and think about solving new problems for a while. Our friends at Kindling and Readability agreed to join, too.

This was the first Hackathon we’ve attempted at Arc90. Because we weren’t sure exactly what to expect, we only put forth one guiding principle: aim to ship in two days. That’s it. No other ground rules. Want to work with others? Great, form a small team. You’re a coder with a cool idea but need a designer? See if you can recruit somebody. Have an itch to hole up by yourself and get something out in two days? Grab a desk and do exactly that.

Leading up to the Hackathon, we regularly shared the ideas that were brewing. We had pitches during our weekly lunches. From polished Keynote decks to the trusty whiteboard, ideas were laid bare and scrutinized. By the time we were ready to hack, the teams had (more or less) been formed.

And then… it happened. Two days of designin’, codin’, testin’, and lots and lots of coffee. We woke up early, stayed late, covered whiteboards with sketches. We debated features over lunch and built them over dinner.

The Hackathon wasn’t only about the work. It was about attacking the routine day-to-day for most of the designers and engineers at Arc90. For just about everyone, it was a breath of fresh air to change their scenery and work with others.

The contrast with the experience of working on a brand-new project is immense. It felt terrific, and I know I will be very disappointed if I’m not able to bring some of that experience to our day-to-day work.

Over the next nine weeks, we’ll be releasing one project each week over on the Arc90 Lab’s Hackathon 2012 page. The first is Must Read. It’s a web app that serves one simple purpose: share that one must-read article you’ve found this week with your friends. It uses Readability and it’s really slick. Go check it out, it’s available today.

We hope you’ll enjoy the fruits of our frenzied labor. We’re incredibly excited to showcase the creative energy that constantly brews inside our walls.

See you next week!

If you’d like to talk to us about how our unique blend of design and technology talent could help your organization, be sure to get in touch. We’d love to hear from you.

As a born and bred New York City agency, we couldn’t be happier to announce that Cornell NYC Tech has selected Arc90 to design and build out their web strategy.

A rendering of the future Cornell Tech campus on Roosevelt Island.

As soon as we began discussions with Cornell Tech, we knew that this wasn’t going to be just another graduate program. Their vision of blending the incredible entrepreneurial spirit of New York with a world class educational program strongly resonates with us. We’re incredibly excited to be joining Cornell Tech on the ground floor.

In the months ahead, we look forward to unveiling the fruits of this partnership. Collectively, our goal is to go well beyond the digital university brochure. Stay tuned!

If you’d like to learn more about how Arc90 can help your company or organization, we’d love to hear more. Get in touch.