Announcing Walgreens Photo Printing on Android!

Written by   //   Leave a comment

Last month, Kicksend launched an integration with Walgreens that lets the Kicksend iPhone app print directly to any Walgreens store. Today, we’re announcing the same Walgreens photo printing integration on the Kicksend Android app!

 

Android users can now select up to thirty photos at a time from the Gallery or Kicksend app and send them to be printed any of the 8,000 Walgreens locations in the US and pick up high quality prints within an hour.

Our printing feature on Android and iPhone works great with the photos you receive on Kicksend from the people you love. For example, you could send photos from your iPhone to your mom’s Android phone. She can send her favorites to Walgreens and pick up the high quality prints in an hour. She can also print her own photos instantly through Kicksend.

Another feature we’re announcing is the ability to send photos to any phone number. Now Kicksend on Android users can send a high-resolution album of photos from their phone to any other phone number in their Address Book directly.

We built Kicksend to make it easy to keep in touch with the people we love. As of today, Android and iPhone users can send, receive and print photos through the easiest, most seamless private photo-sharing app made to date.

You can learn more about the new Kicksend Android app, and install it from the Google Play Store now.

 

P.S. Use the KICKSEND3 coupon code to get 25% off your order!*

Coupon code KICKSEND3 valid thru October 31, 2012 on the Walgreens Mobile Partner application only. Code must be entered in the mobile app quick prints checkout flow to apply discount. Timing will be determined by Walgreens server clock. Discount does not apply to previous purchases or taxes.  Cannot be combined with any other offer.  Walgreens reserve the right to expire the offer at any time.  In store sales associates reserve the right to monitor and prevent offer abuse.

Being a startup’s first product designer

Written by   //   6 Comments

There are few things more tantalizing than taking the reins at a growing startup in Silicon Valley as the first Product Designer. The entire visual and interactive experience is in your hands, and everything a user sees and does happens through the filter of your work. Product design is more important now than ever, so it has become a huge responsibility. Bad design and user experience can sink a small company just as fast as bad engineering, but great design can be the hallmark of a good product.

I’ve been fortunate enough to spend the last month and a half here at Kicksend as Product Designer. It’s been so much more intense than I could have imagined, and I’ve learned a lot about how working in a startup differs from leading a consulting team. These are a few of those things that stand out the most.

1. You are the creative product culture lead.

Just as important as good product design is good design culture. What does that mean exactly? It’s a way of thinking about product (and, I suppose, the world in general) with awareness of how things are designed, what about them constitutes good or bad design, and how it could be improved. It’s all subjective, and you don’t have to be ‘right’ – you don’t even need to be a designer or a ‘visual person.’ Engineers, biz ops, marketing, and whoever else on your small team should be thinking about design. If your team can get into the habit of noting usability and aesthetic problems (or successes) when critiquing another company’s product, they’ll be much more helpful when you ask them for critique on the work you’re doing with them. As the first designer, you can’t benefit from a strong team critique structure, so take advantage of  your great team by sharing your knowledge and passion for design, and ability to discern good design from bad design when observing the world around you.

Most small startups and early-stage companies are still figuring out the nuances of their culture. Company culture can’t be forced – it has to be discovered. It’s defined by the way product, business goals, and the team work together. If you exude design from the get-go, it will be forever ingrained in the company’s fundamental values and culture.

For example, I talk about design incessantly. Ask anyone on my team, ask my girlfriend, my parents, strangers… I just can’t seem to shut up about it. I see the world through this lens that makes badly set type literally impossible for me to read, and I instantly ragequit anything with bad usability. I can’t even use certain mobile OSes because the confirmation dialogues won’t make up their minds about which side the confirm button will be on.

I also bring design into the office…

(Amperbranch by Ryan Putnam and Ropersand print by Rogie)

(My baby baby grand)

Posters lying on the floor waiting to be hung. Can you believe we don’t have nails in our office?

Posters and letterpress prints aren’t the lynchpin to design culture success, but it gets me excited about design. By extension, it gets everyone else excited about design or, at least, exposed to it constantly. Culture is contagious… you just gotta start the fever.

2. Take religious and verbose notes before you dig too deep into the trenches.

This is something I wish I had done more of. For the first 72 hours you’re part of a new product team, write down everything. Think about how it works, what’s wrong with it, what stands out in a good or bad way, what you think the product can do for you, etc. The ‘newbie’ perspective is something you can never get back, and it’ll give Future You some great insight into how a new user feels stepping into your product for the first time. Think of it as doing user testing on someone with a great design vocabulary.

On my first day, I walked into the office and said “No one wants to send photos. No one wants to use Kicksend” and it’s the most valuable observation I could have ever made. It informs most of my design decisions, because I know people (especially our market of Average Joes and soccer moms) are adverse to using software. Their goal is for Grandma and Aunt Sue to see their vacation photos or Timmy’s first steps. How can I design Kicksend to help people achieve that goal? As we iterate on our product, you’re going to see it get more and more out of the way. There’s nothing revolutionary or shocking about that approach, but it’s informed by experience and observation, not jargon.

After your first week, present your notes and feelings to the team. It’ll give everyone a fresh perspective on something they’ve been looking at under a magnifying glass for (possibly) months or even years. Fresh perspective is crucial for any product to stay relevant and keep improving… ask any startup founder.

3. Never stop learning. You don’t know as much as you think.

Coming from a more traditional role as a design consultant, I thought I had a pretty good idea of how software / product design worked. It shouldn’t come as a surprise to anyone that I was pretty much completely wrong about that.

Rarely as a consultant did I ever have to ‘clean up’ an existing product, and I never had to stick around after the first release to maintain, iterate, and bugfix. Stepping into an existing product with thousands of manhours and four passionate engineers behind it is an entirely different experience. At first, it’s almost impossible to make sweeping design changes. In the first week, I felt paralyzed by it. As I eased in, I learned the ins and outs of Kicksend for iPhone, then ‘realized’ there was a webapp, Android app, Mac app, and an Air app for Windows. O M G.

It was overwhelming, and even today I’ve only made headway on three of those five. Even on those I’ve only scratched the surface but fortunately Brendan, one of our co-founders, has always held high design standards, and Mike Kus has done some great consulting work for Kicksend before I got here. If you’re used to a fast workflow through consulting or freelancing projects prepare to slow waaay down, while working faster and more intensely than ever before. That’s not to say I sit at my desk twiddling my thumbs, however. I spend 90% of my time on product, and the rest…

4. Wear many hats.

My business card says “Product Designer” only because “Design ALL THE THINGS” wouldn’t fit. I’ve helped with iOS, Android, and Mac App icon design, created marketing collateral, business cards, landing pages, giveaways… the list goes on.

I expected (and desired) these responsibilities upon joining the team, but the workload adds up. Make sure you know where to draw the line, how to design for re-use, and always work smart, not hard. When the design team grows from guy-in-the-corner to Design Team, you’ll have the insight and experience to lead others effectively.

So that’s it. I’m still learning, failing, iterating, and insert-important-sounding-gerunds-here-ing at Kicksend. I’ll keep you updated.

Kicksend for iPhone Now Lets You Print to Walgreens!

Written by   //   Leave a comment

You know Kicksend as the app that makes it easy to send tons of photos and videos privately to people you love.

Today, we’re making it easy to print tons of photos from the people you love, with a deep integration with Walgreens, the country’s largest pharmacy chain.

Kicksend for iPhone users can now select a stack of photos they either received from family or took themselves, and print them in full quality to their nearest Walgreens store, right from their phone. They can then pick up their shiny new prints in an hour.

We’re all about empowering everyday people to stay in touch with people they care about, and our brand new, incredibly seamless photo printing experience through Walgreens’ QuickPrints is a big step in that direction. There is no better way to share and keep your memories with the people you love.

Learn more or install the app from the App Store.

P.S. Android version coming soon!

Building a Rocket in 4 Days – A Kicksend Story

Written by   //   2 Comments

Kicksend lets you send tons of photos to people you love. A month ago, we released a revamped version of the awesome Kicksend web app. The relaunch was closely tied to making Kicksend a lot friendlier towards everyday people. To push that along a little further, we were brainstorming a new photo-sending flow for our users. Here’s how it all came together technically, and how this exercise helped influence Kicksend’s current branding.

Whiteboarding
At Kicksend, we whiteboard new product flows as a team. For this session, we were wondering what we could show users that would give them something interesting to look at while photos were sending. We decided that everytime someone sent photos from Kicksend on the web, we’d show them a subtle animation of a rocket blasting off, which was in line with Kicksend’s existing characteristics as a speedy photo delivery service. Here’s Derrick’s first attempt at fleshing it out on paper

First Draft
We had our illustrator, the mighty Mike Kus, come up with visual assets for the animation, which he created for us in a day. This included the actual rocket, flames, support structures for the rocket, a gauge that indicates photo sending progress and a beautiful moonlit background to set the stage. Here’s the result:

 

As photos send, we wanted the dial to fill up, and have the rocket blast off into the night sky, becoming smaller and receding into the distance.

To make the animation as close to reality as possible, we initially opted for HTML5 with an actual physics-based acceleration engine. Essentially, we would be animating the rocket using projectile motion and then scaling it to be smaller as it blasted off into the background. This involved setting up the HTML5 canvas with a coordinate system that made sense, and scaling/rotating/accelerating the rocket as a function of it’s position on the x-axis, while moving the rocket along the canvas using a projectile function tied again to the rocket’s position on the x-axis.

After a few experiments with Mathematica, we found a few custom projectile functions that worked well, and we had a pretty decent proof of concept. When we decided to test performance, however,  we ran into serious issues with every browser except Chrome. The problem seemed to lie less with doing math in the browser at a rapid execution rate and more towards browser compatibility of the HTML5 Canvas. Animations over a big Canvas were lagging most of the time, and we weren’t confident enough to move forward with it, even though animations on a smaller canvas object seemed to be consistent.

Second Draft
At this point, we were considering scrapping the rocket altogether when we realized we should probably give the new CSS3 animation functions a shot. A little digging showed wider compatibility on multiple browsers so we decided to spend a little time poking around.

20 minutes later – surprise! CSS3 animation support is actually quite powerful, and we wound up replacing most of the rocket animation with CSS3 properties. We scrapped the projectile motion equations completely and also moved off HTML5 Canvas for the most part.

The new way of animating the rocket was now a combination of the following CSS3 properties: transition and transform (for rotation) operating on a rocket image. The actual movement of the rocket (slow start, then speedup) is governed by a custom Cubic-Bezier path that the transition property supports.

 

This method was significantly smoother, was supported on many more browsers and essentially gave us a solid foundation on top of which we could build out more of the photo sending interface confidently.

Rocket Gauge
We still had some trouble with animating the rocket gauge. Since it was shaped like an arc, filling in backgrounds using transparent foregrounds didn’t really work cross-browser. This is when our realization that HTML5 Canvas actually works consistently with smaller canvas sizes helped.

The rocket gauge was then coded up as a simple canvas arc that gets drawn on the canvas as the photos send. We also used the aforementioned CSS3 properties to make the gauge’s needle move along with the arc drawing. For IE 8, we reverted to a simple progress bar since it didn’t support Canvas.

 

We pushed the rocket to production and were super happy with the response from our users. Time from whiteboarding to production push: 4 days.

Send some photos on Kicksend to see the animation in action.

And Then…
A few days later, we were wondering what to do about our email newsletter, nurture campaigns and notifications. At that point in time, the layouts were quite terrible, with very limited Kicksend branding. Worse, they looked unfriendly and unapproachable, which directly affected our conversion rates.

When we gave Mike Kus the mandate to redesign our email newsletters and notifications, he used the new rocket to guide his work, resulting in a fresh new look for all our email nurture campaigns, newsletters and notifications, and one that improved the overall cohesiveness and conversions of the app dramatically.

 

 

Looking back…
We’ve been working on Kicksend for over a year now and as a team we’ve gotten to know each other’s strengths very well. This web app relaunch was some of our best work together as a team, where every person on the team stepped up to make our product shine.

Thanks for reading!

PS: If you’re interesting in working on a tight product team, we’re always hiring stellar folk.

Kicksend Practices Part I – Backend and Web

Written by   //   3 Comments

Kicksend is a multiple platform application, we have clients on iOS, Android, OS X, Windows and the web. All of this is powered by a Rails backend, which we treat as an API server. Here are a couple of practices we have in play right now.

The Backend

(Taken by Tom Raferty)

Avoid to_json

Responses are the equivalent of views for your API; your presentation layer. Hence, you shouldn’t use to_json to generate your response, the same way you wouldn’t put presentation logic in your model. Use a templating system/builder like RABL (which we use) or Jbuilder.

Action cache

We use action caching, based on the principals of key based cache expiration. This keeps cache invalidation very simple for us as they auto-expire whenever an object or a collection is updated. We use a couple of helpers to simplify our cache key generation.

The Web App

The Kicksend web app is made with Backbone.js, Handlebars in Coffeescript. We treat it as a standalone entity, and it consumes our API the same way as our other apps do. There’s no special treatment.

Keep the UI responsive

As much as possible, keep your app responsive and don’t block the user. People have the expectation that rich clients are snappy. Some tips:

  1. Design your app such that you don’t have to use { wait: true }.
  2. Assume that the request will be a success, and have an error state with a retry otherwise.
  3. Load commonly used collections in the background, regardless of the page the user visits.
  4. Keep things asynchronous.

Modularize

Keep your models and collections independent from your views. This makes our views easily reusable (and even nestable). We instantiate individual models in our router and app wide collections on load, and never within the view. In the rare event you need to instantiate a model/collection from within a view, ensure that they are used only within the lifecycle of the view.

Have a single representation of each resource

For each resource (eg. api/lists/1), we maintain a single model representation of it as much as possible. This ensures that the right models are used by our views, so that the any model changes are appropriately reflected in the UI. We use our app wide collections to maintain the “gold” model representation of each resource. Here’s an example:

  1. You navigate to “kicksend.com/home#/lists/1/edit″ to edit your Family list.
  2. To reduce wait time, we make an API call to “/api/lists/1″, and instantiate a single List model – let’s called it Model 1. We then render the list edit page with Model 1.
  3. In the background, we load up our collection of all your lists (KS.lists), which will contain another model of your Family list – we’ll call this Model 2. The rest of the app operates off Model 2.
  4. Any changes to Model 1 is synced back to Model 2 within KS.lists.

Use a view manager

In a single page app, instantiating and destroying your view is important. Mismanagement can lead to a bloated DOM and stray event bindings. Taking a cue from Derick Bailey, we use a singleton to handle all view transitions and cleanups. The Kicksend app has two “containers” that we render views in – within the page or in a modal. With our View Manager, we can easily render any view in either container.

Over the next couple of months, we’ll be discussing more practices we use throughout the Kicksend ecosystem, so stay tuned. As always, we are always looking to improve and we love to hear any suggestions or improvements you may have!

Catch us on Twitter at @Kicksend and @derrickko. Sounds interesting? We’re hiring.