This post was written by Indy and Sam, on Bump’s client team.

Flock for Android was just a twinkle in the eye of the Android users at Bump until early October. So when it was time for another hackathon, a few of us got together and threw together an early version of the app you see today. Since then we’ve been iterating and hardening Flock for Android. In this essay we will go through what it took to bring Flock to Android.
 
An early decision we made was to initially build the app with ICS in mind rather than older versions of Android. We are big fans of UI direction Android has taken since ICS and knew of a lot of great APIs that were introduced with ICS that would make Flock faster and better, and easier to build. Once we had the app working like we wanted, only then did we go back and see how we could make the app work on Gingerbread. This meant that we had to cut out some of the things that make the app super slick, but kept it functional.

How exactly do you recycle the list view items correctly?  This is… crazy. - Diane Hackborn

Because of this we initially thought we were heading down the wrong path, but there were just too many things we got for free by using ViewPagers as ListView items that we decided to be a little crazy.

To get around the lack of view recycling we subclassed PagerAdapter and implemented recycling ourselves. The exposed methods are actually almost identical to a standard BaseAdapter (getView, getItemViewType etc.). We used a map of view type to queues of available pages to store recycled views. Whenever destroyItem is called for a particular view type, we add the corresponding view to the queue for that view type. Whenever instantiate item is called, before actually inflating a new view, we first check to see if we have a saved view in the corresponding queue in the map. While we got reasonable performance using this schema, it wasn’t sufficient. The order of the pages and the types of the pages in each row in Flock is determined by the number of photos in an event. Since most events have different numbers of photos, each row had a different sequence of view types. As the ViewPagers and PagerAdapters were reused during the user’s first few vertical swipes, the adapters were continually being asked to load new view types that other adapters had inflated, but the current one had not. Until every adapter had been asked to inflate a few of every view type we were inflating a lot of views, so there was a prolonged period of poor scrolling when users first opened the app. Since every adapter kept two or three views of each view type around, we were also using a fair amount of memory just keeping views around. The final step to help alleviate over inflating views and reduce memory usage was keep a single global map of view type to queue of views, rather than having each PagerAdapter have their own. Sharing views for pages across rows meant that we didn’t need to inflate as many views for each type and similarly didn’t need to keep as many views for each type around in memory.

This post was written by Andrew, a summer intern on Bump’s client team.

Deciding where to intern is a big decision, or at least it was for me. Having never interned at a company before, I didn’t really know what to expect but knew what I wanted. I wanted to work on interesting problems, have freedom to create, and work with great people. With these considerations in mind, I chose to intern at Bump.

Work
I came into Bump as an Android developer. Prior to Bump, I had some experience with the framework – I’d published an app. However, I still had much to learn (better realized after my internship).

One of the most integral skills to software development is being able to reason at multiple levels of abstraction, and this is a skill my experience at Bump helped me hone. The Bump Android app is complex, but necessarily so. The app makes use of many of Android’s facilities, including that for embedded native code. The app must take into account the interaction between UI actions and network events, and does so nicely. When working on the Bump app, the professionalism with which it was created is noticeable. Looking back, I think my appreciation for the app’s structure is a testament to what I learned over the summer regarding modularity and reusable code design. Sure, anybody learns in school how to write generic code inside a few source files, but what about writing a component composed of many source files which must interact with a much larger machine?

Another key skill I developed at Bump was working on a large codebase with other people. I am now infinitely more familiar with git than I was at the start of the summer, including managing projects with submodules. I think the day-to-day aspects of software development such as version control, setting up build environments, and team communication are under-emphasized in school and am glad for the experience I gained at Bump.

Freedom
An aspect of the work I did at Bump that I really enjoyed was the freedom I was given. The nature of the problems I solved at Bump was not “do this in O(whatever) runtime”. No, I was tasked with solving real problems the company faced – high level problems – and was given guidance in solving them. I found this freedom to be pervasive throughout my internship experience. For instance, I needed a lightweight way to log data from tests I was running and, even though I’m an Android developer, was able to play around with CherryPy to write a logging system. If I had questions, I was able to ask one of CherryPy’s lead developers – he works at Bump.

Freedom to do things the way you want is embedded into the culture of Bump. The Android developers use IntelliJ because they like its memory usage and code completion better than Eclipse. However, if you want to use Eclipse, you can. Want to run Eclipse inside an Ubuntu VM? Go for it. How about forgoing the whole thing and just using vim and a terminal? Your choice.

The openness and willingness to try new things as a company is one of my favorite aspects of Bump.

Life
As I’m still in college (Stanford ‘14), life at work was a major factor in deciding where to intern – Bump does not disappoint. I think it’s pretty cool when you can play Berlin-style ping pong and sing karaoke at work. The people at Bump are great and fun to be around. While people take their work seriously, they don’t take themselves too seriously.

Speaking of ‘seriously’, you may be wondering what the hours are like. Most people don’t show up until around 10 which was great for me. People generally leave around 7 but there is no set time. Personally, I’d usually leave around 8, but that was voluntary – I just figured that experiences like these don’t come too often and wanted to make the most of it. However, the culture is flexible – a few days I had to leave around 5:30 and would, no questions asked. The emphasis at Bump is on the actual work you do, not the time. That said, if you don’t want to work, don’t work at Bump. At Bump, you will work but you’ll have fun doing it.

Food
Food was great – would eat again.

At Bump, you’re surrounded by food. The company has a snack bar and refrigerator of drinks which get replenished weekly. You can have as many snacks/drinks as you want whenever you want. The company provides two catered lunches per week. Lunches range from Indian food to Pakistani to Jamaican. There were times when I would have preferred a burger or pizza, but I took the opportunity as a great time to expand my palate. Most importantly, when Bump gets food catered, there is a lot of it. There are usually leftovers which is awesome for the days following catered lunch days. Bump’s also really close to Castro Street which has more food than you can eat in a summer (I tried) and there is almost always a group willing to go grab something. For the company I’m not sure how the unlimited food model works – my productivity definitely went down during the post-lunch food coma, but for me it was great.

Should I Work There?
If you’re reading this, you’re probably asking yourself that question (otherwise, you have a lot of free time and/or enjoy reading intern blogs).While we both know there’s no definitive answer, Bump has my recommendation. I had a great time interning at Bump and the rest of the interns my year seemed to have very positive experiences as well. Ultimately, you’re going to have to go with your gut. I did, and it was one of the best decisions I’ve made.

This post was written by Seth, Bump’s resident iOS Magician.

Martin Gardner was a math and science writer, who also was a magician. In one of his books, he teaches a magic trick that bears some similarities to a more recent technique for stealing passwords from systems that are using an insecure HMAC checking algorithm.

So, let’s bring together HMAC security, mathematician Martin Gardner, magic, and a timing attack on your brain (and throw in app virality at the end). Do I have your attention yet, Hacker News?

What is a Timing Attack?

A timing attack uses information leaked by a computer system based on the amount of time it takes for something to happen. For example, let’s imagine I want to compare two strings for equality (say to check a password (which you would never want to do!)): “Hello World!” and “¡Hola Mundo!”. A simple algorithm could compare letter by letter, and return false as soon as one character doesn’t match. In this case, no characters match, so it would return pretty fast. If I were comparing “Hello World!” to “Hello Wormy!”, the algorithm would have to compare 10 characters, and so would take 10 times as long (factoring out the parts of the function that are run on every call). Using this timing information (on a sufficiently slow machine), you could uncover the password, one letter a time by simply iterating over each possible letter until the algorithm took a little longer, and then proceed to do the next character in the password.

This overly-simplified timing attack is similar to a real potential attack to using HMACs.

Magic Trick?

Martin Gardner described a timing attack on your mind in his book ‘Mathematics, Magic and Mystery’ in 1956. It is a magic trick called “Divining a Number” which involves discovering the number that your spectator is merely thinking of.

You may have heard of simpler magic tricks where you ask someone to think of a number, perform some math, and then can tell them the number they end up on. This magic trick is different. You tell them the number they originally thought of, and they never tell you any of the results of their mental math.

You ask them to think of a number, have them do some mental math, without saying anything, and then you know which number they thought of.

You discover the thought-of-number by using a timing-attack like process on their mental math. A simple example:

Think a number: 8 or 9 (a simple choice of two numbers).

Now, divide that number by 2.

To be fair, you are probably better at mental math than the average person by virtue of the fact that you are reading this article, but it is signifcantly easier for most people to divide an even number by 2 than an odd number. So, by watching your face as you did this mental math, I could tell you which number you were thinking of. If you were really fast, you were thinking of 8, slow means 9.

If you add a few more mental math timings, you can expand the original range of choices from 2, up to 10. Martin Gardner describes the whole (rather complicated) procedure in his book.

Martin Gardner didn’t invent the technique (he heard about it from Edmund Balducci), and it is based on several tricks found in “The Magician’s Own Book” published in 1862! Timing attacks go way back!

App Virality?

I’m a magician, and also a software engineer at Bump. Part of my job is to explore using the theory behind magic tricks (including mental timing attacks) to improve our app’s virality. If you want to learn how, or if you want instructions for the full magic trick, e-mail seth@bu.mp !

This post was written by Greg, a summer intern on Bump’s server team.

Internships are such a fantastic opportunity to explore different companies, work cultures, and cities that I sometimes wish I could forever do internships, trying and learning a little bit of everything, everywhere. Alas, there are only a couple summers as an undergraduate to be an intern, so I wanted to pack in as much learning and fun as possible.

After a solid first internship with Amazon’s Kindle division in Seattle last summer, I wanted to explore the opposite end of the tech company spectrum for my second internship, so I could make more well-informed career decisions after graduation. Bump caught my attention very early in the internship search. It was a small company working with open source software developing a truly one-of-a-kind product that makes life easier for tens of millions of users. A userbase of that size provides a great opportunity for machine learning, exposure to real-world architectural and scaling challenges, and a guarantee that my work would have a big impact.

My interest in Bump only grew during the interview process. Bump’s programming challenge and interview questions were practical and engaging, which was a refreshing change from the slew of linked-list manipulation, string-integer conversion, and fizzbuzz questions I had been answering in other interviews at the time. Before I knew it, I was on my way to California for the first time, and to the heart of Silicon Valley at that!

The first week was a bit overwhelming; it took a while to get used to the unstructured start-up environment and to learn who to ask for help. Once past these initial roadbumps however, I’ve gotten the chance to explore a variety of cool projects with the server and data teams and am still learning a ton everyday. In reflecting on my time here, I’m very grateful for a few qualities of this internship that exceed my experiences from last summer, especially these three things:

• Important work. While the project I worked on at Amazon was a neat idea that would have improved the Kindle experience for tens of thousands of people, it was more of a nice-to-have feature than anything else. I found out later that, unfortunately, it was shelved after I left because there were more valuable things to work on. This is not an issue with Bump. Because the company is so small and the userbase is so large, everyone’s work is critical (even interns’) and there is no shortage of important work to take on. The effort of a single person here can have a very visible impact on the product, and consequently, on the lives of millions of people. It’s exciting that my work on debugging tools and analytics will directly improve the service and experience for all of Bump’s users.

• Speed. I feel like I’ve accomplished more at Bump already than I did all of last summer. The pace throughout the company is very fast, and it works because everyone has a “get things done” mindset. There aren’t any obligations to distant departments or chains of managers to go through, and everyone in the company is within a 10 second walk of my desk, making it easy to ask questions and clear obstacles. The speed is a great motivator, as well, because progress is evident and exciting as we rapidly approach our goals.  

• Fun culture. Amazon had very cool weekly tech talks by senior engineers and also brought in various performers and artists (I even got to meet my favorite author, GRRM!). Aside from these events though, the majority of my work culture experience at Amazon was dominated by the company policy of frugality. I have a lot of respect for that policy and all the work Amazon puts into lowering prices and improving service for consumers, but I feel that having a much brighter, more open office with a few games and snacks has greatly improved my mood while at the office. I appreciate that — when I get stuck on a problem — I can get up, be active, and talk through the problem with a coworker over a game of ping pong. By the time I return to my desk, I can see the solution to the problem or I will at least have a new perspective or approach for tackling it. Little things like this, plus organized company events such as trivia night and ultimate frisbee matches against other startups have made the entire internship experience more enjoyable.

I’ve found that qualities such as these are very important to me not only today as an intern, but also as an eventual career-seeker. Bump has been successful at not only attracting smart, like-minded people, but also cultivating a positive and playful work culture where everyone motivates each other to build the best product they can imagine. Needless to say, I’m excited to be a part of this team and to continue building and learning here for the rest of the summer!

This post was written by Greg, a summer intern on Bump’s server team.

Internships are such a fantastic opportunity to explore different companies, work cultures, and cities that I sometimes wish I could forever do internships, trying and learning a little bit of everything, everywhere. Alas, there are only a couple summers as an undergraduate to be an intern, so I wanted to pack in as much learning and fun as possible.
 
After a solid first internship with Amazon’s Kindle division in Seattle last summer, I wanted to explore the opposite end of the tech company spectrum for my second internship, so I could make more well-informed career decisions after graduation. Bump caught my attention very early in the internship search. It was a small company working with open source software developing a truly one-of-a-kind product that makes life easier for tens of millions of users. A userbase of that size provides a great opportunity for machine learning, exposure to real-world architectural and scaling challenges, and a guarantee that my work would have a big impact.My interest in Bump only grew during the interview process. Bump’s programming challenge and interview questions were practical and engaging, which was a refreshing change from the slew of linked-list manipulation, string-integer conversion, and fizzbuzz questions I had been answering in other interviews at the time. Before I knew it, I was on my way to California for the first time, and to the heart of Silicon Valley at that!

• Important work. While the project I worked on at Amazon was a neat idea that would have improved the Kindle experience for tens of thousands of people, it was more of a nice-to-have feature than anything else. I found out later that, unfortunately, it was shelved after I left because there were more valuable things to work on. This is not an issue with Bump. Because the company is so small and the userbase is so large, everyone’s work is critical (even interns’) and there is no shortage of important work to take on. The effort of a single person here can have a very visible impact on the product, and consequently, on the lives of millions of people. It’s exciting that my work on debugging tools and analytics will directly improve the service and experience for all of Bump’s users.
   
• Speed. I feel like I’ve accomplished more at Bump already than I did all of last summer. The pace throughout the company is very fast, and it works because everyone has a “get things done” mindset. There aren’t any obligations to distant departments or chains of managers to go through, and everyone in the company is within a 10 second walk of my desk, making it easy to ask questions and clear obstacles. The speed is a great motivator, as well, because progress is evident and exciting as we rapidly approach our goals.  
   
• Fun culture. Amazon had very cool weekly tech talks by senior engineers and also brought in various performers and artists (I even got to meet my favorite author, GRRM!). Aside from these events though, the majority of my work culture experience at Amazon was dominated by the company policy of frugality. I have a lot of respect for that policy and all the work Amazon puts into lowering prices and improving service for consumers, but I feel that having a much brighter, more open office with a few games and snacks has greatly improved my mood while at the office. I appreciate that — when I get stuck on a problem — I can get up, be active, and talk through the problem with a coworker over a game of ping pong. By the time I return to my desk, I can see the solution to the problem or I will at least have a new perspective or approach for tackling it. Little things like this, plus organized company events such as trivia night and ultimate frisbee matches against other startups have made the entire internship experience more enjoyable.

I’ve found that qualities such as these are very important to me not only today as an intern, but also as an eventual career-seeker. Bump has been successful at not only attracting smart, like-minded people, but also cultivating a positive and playful work culture where everyone motivates each other to build the best product they can imagine. Needless to say, I’m excited to be a part of this team and to continue building and learning here for the rest of the summer!

This post is written by Tim on Bump’s server team

At Bump Technologies, we recently completed a significant database migration from MongoDB to Riak. Almost all of our users’ data — the lists of people they’ve bumped, communications sent and received, handset information, social network OAuth tokens, etc. — had been stored in MongoDB, but if you open the app today all of these interactions will be backed by Riak.

git is awesome

We use git at Bump for all sorts of things. Recently, we’ve started converting our designers and product managers. You can think about git like Dropbox: it takes files on your computer, puts them in the cloud, and lets other people work on them too. But it has some pretty rocking advantages:

Collaboration

Like Dropbox, git lets multiple people work on the same files at the same time. This is great when many people are working on a document together, or a group of people are creating assets for a website. Everyone can be contributing to the same folder and files, without fear of overwriting eachother’s work, something Dropbox can scew up.

Time Machine

Even if you don’t have a team of people, git has some awesome-sauce. It can act like a time machine, allowing you go and see what you did last week, or even last year, help you recover files you deleted, and keep track of progress over time. It has powerful tools to let you see what you’ve changed over time.

And More

git is also great for backing things up, so you don’t lose them. It can let you learn about how you work: when do you do your best work? How often do you change everything? There are tools to show you visual differences between versions of images, and all sorts of things.

but

git is awesome… but conceptually it’s a leap from most people’s mental models of what a file is.

There are so many wonderful reasons for non-programmers to use git when working with other people (especially programmers) and I’d like to convince you that there are even more awesome rewards down the way of git, but I won’t do that today.

My goal today:

Provide an analogy to Dropbox to help designers and product managers understand the mental model of how git works.

It might help you to think about git like Dropbox to start. It’s like Dropbox but with a whole lot more steps. Have faith (for the moment) that the more steps are worth it, and I’ll talk you through the differences.

First, a quick overview of how Dropbox works: many people can be working on the same file on their own computers, and magically they all get each other’s changes. Behind the scenes Dropbox is doing all sorts of things to make this work. With git, you end up helping do some of the behind the scenes work, and git thanks you.

As easy as 4… 5… 6!

Here is a more explicit model of how Dropbox works.

1. You install Dropbox.
2. Someone shares a folder with you.
3. Your computer downloads the contents of that folder from the “Cloud”
4. You make some changes to a file in the folder and save it.
5. Your changes get sent up to the Dropbox “Cloud” immediately
6. Everyone else gets your changes downloaded to their computers immediately.

Yay. This is just like git! Only git lacks some of the “immediately” magic. Steps 4, 5, and 6 don’t happen automatically: you have to tell git when you want it to do each step. Let me break it down for you.

4) Saving… are you sure?

The first difference is that git doesn’t assume that you want to send every saved change to the cloud. It makes you be explicit about what you want to send to the cloud.

Whereas Dropbox automatically uploads everything when you save it, git adds a new step: commitment. After you save a file, you must tell git that you are “committed” to this change.

To do this, you do what is called “staging.” This is really just telling git which changes you were sure about. This way, git doesn’t waste other people’s time if you make a draft you don’t like.

5) Uploading

Second difference: Dropbox uploads your files immediately. (It tries to anyway). git isn’t quite as eager to get things into the cloud.

In git, uploading to the cloud is called “pushing.” You are literally pushing the changes from your computer up in to the cloud. Only then will other people be able to download them.

6) Downloading

The next difference is downloading. Can you spot the difference? Why, that’s right! While Dropbox downloads the new changes automatically, git waits for you to tell it too.

You must ask git explicitly to “pull” the changes down from the cloud to your computer. This gives you the latest greatest copy of the documents, including everyone else’s changes

Stay strong! Keep faith that even though there is seemingly less magic, and more work, there are reasons for all this mortal toil [sic]!

Ordering, or 6… 4… 6… 5…???

git requires you to operate with a slightly different order of operations because it is more manual (slightly less magic).

Before you start changing things, you want to make sure you have the latest and greatest version with everyone else’s changes. That means the first thing you want to do is download the latest stuff from the cloud (i.e. do a pull).

Now that you have the latest, you can change it and edit it to your heart’s content. When you are happy with your changes you are ready to tell git you’re happy (i.e. commit).

You can also rinse lather and repeat step 4 many times, committing small changes before going to the next step.

But wait a second! What if Brian in marketing changed the document WHILE you were working on it? Because git doesn’t automatically download the changes, your computer (and you, by extension) doesn’t know about the new changes. So this adds another step, redownloading (i.e. doing another pull!)

Okay, now git knows about your changes, it knows about Brian’s changes, and the only thing left to do is… Push! Finally we can upload our changes to the cloud for everyone else to see and look at.

That’s the gist of git.

It’s like Dropbox, but you have to tell it to download, save, download, and upload each time. (Pull, stage & commit, pull, and push)

If you are digging it so far, let’s tackle some Advanced differences.

Advanced Differences

There are some other model differences between git and dropbox. The first are conflicts: what happens when two people change the same file. Another big one is the fact that git is “distributed,” i.e. there is no company holding the cloud for you… there can even be multiple clouds.

Here are some quick overviews of salient differences.

Time Travel

Every commit makes a little tick on a timeline. git keeps track of EVERY little tick. That means you can zoom back in time, and watch as your document changes from day 0 to present. You can see every change, along with who made it, and what there “commit message” was. Pretty cool.

git has multi-player undo You can find out exactly who made the typo, and when and then fix it really easily. (git has really awesome tools for this too).

Conflict

What happens when Brian changed that file in the cloud, while you were working on it on your computer? Dropbox takes care of it magically in the cloud, now… it’s your job. The second step 6 (re-pulling changes from the cloud) in your work flow is when you are most likely to have “merge conflicts”.

Usually git is pretty magical and figures out what to do if both you and Brian were editing the same file. For example if he changed the title of the document, and you added some foot notes, git will figure it out. However, if you change your salary to $350,000, and Brian changes it to $40, git isn’t going to know what to do.

If Brian pushed his change first, git will make you fix it. It will say: “Brian said you make $40 an hour, but you said you make $350,000, who’s right”. Your call. Fix it, save it (commit it) and push it it! (but do pull it in case Brian caught his error and changed it to $400,000 while you were typing)

Meta Comments

Every time you save (commit really) some changes, git asks you for a “commit message”. This is couple of sentences that describe the changes you made: a brief overview so that someone could review the list of changes to this document, without having to read the whole thing.

Style

Because git is a little more manual, there are a few stylistic changes suggested to make everyone happy. First of all, small changes. You should commit every time you finish changing a coherent piece. I.e. if you are changing your salary, and Brian’s, first make one commit with your increase and a commit message like “merit based salary adjustments”, then adjust Brian’s with a commit message of “balance the budget”. Good (informative) commit messages are very appreciated in git land.

Due to the nature of fixing conflicts, git also prefers text. Images are much harder for it (and you) to merge if both people change at once. So whenever possible use a text format (like html or markdown).

Fin

Well, I don’t know if I convinced you that you HAVE to use git, but hopefully you understand it a little better now. If you are already using it, hopefully now it makes a little more sense. At the very least, you are a step closer to being a friend and co-conspirator of git.

This post was written by Indy from Bump’s Android team.

Today we are releasing Bump 2.4 or what we have been calling the Visual Refresh. Earlier this year we hired our first (and so far only, we’re hiring) badass visual designer, Shona Dutta. Since then she’s been on a crusade to make our apps and everything else we present (including the recent infographic) look as awesome as our technology.

So when it was time for the Android app to get it’s much needed facelift we wanted to jump on it right away. Unfortunately we were still finishing up some other major features in the app, so our team’s summer intern Will Whitney, cut a branch and started churning away (If you’re an awesome Android dev, this is why we need you, there are too many things to get done and we are currently only two people). He left about a month ago, and finally in the last two weeks we had the time to finish up the work he started.

In the last 10 months we’ve learned a lot about the ins and outs and how to build a great app on Android. One of the things we learned quickly was people rightfully bagged on Android apps not looking as good as their iOS counterparts. But the reasons they pointed to were just plain wrong.

It’s a common misunderstanding that Android apps are harder to program than iOS. People say it’s because the lifecycle behind Activities (Android’s rough equivalents of iOS UIViewControllers) are hard to work with. Not true, I think reading through the documentation on that once should clear up a lot of confusion. People say it’s because the UI code is a bunch of messy xml. Not true, yes it’s xml, but it’s xml used in the way it should: declaratively and in a DRY manner. The xml based layouts are what make UI programming quite a lot nicer: one because it forces view code to be purely view code; two because simple parameter tweaking can produce great results.

In fact I joke with our iOS team that android UI is ridiculously fast to iterate on. Case and point is the global network status bar we have on top of the new app. Whenever the network goes down or is unavailable on any screen of the app a thin black bar rolls down above the whole UI (squeezing the content area below it) letting the user know what went wrong. This simple squeezing of the UI and adding a view on top of every screen took less than two hours to put together.

The real reason Android Apps historically haven’t looked good is because people haven’t put in the same care in building those apps. From a business sense that made sense in the past. Android has never been the primary platform for app users. But the rate of growth of the platform is phenomenal, and even if you believe that in general an Android user is less likely to use apps than an iOS user, the raw numbers should shock you into putting the same care into your Android app as your iOS app.

So it’s finally here: Bump 2.4 for Android. An App that finally looks as good as it works.

See the full gallery on Posterous

This post was written by Shona from Bump’s design team.

Bump is simple. Right? You bump, and data is transferred from one phone to another. It can be anything from your contact info to photos to apps, but the premise is basic and totally functional. This was what I figured back when I started working on the visual redesign of the app.

Three months later, my opinion has changed (kind of a lot). Bump is an incredibly complex, nuanced app that calls for a whole lot of visual interplay between screens, between elements on those screens, and across the whole application. It’s got hundreds of permutations and possibilities in what can be on the screen at any time. Fortunately I had the help of Abby, our UX designer here at Bump, when I undertook the work of giving Bump a visual “refresh.”

Our choice was to make Bump more tactile. The app is based on the physical bumping of two phones, and there’s something really magical about highlighting a physical interaction in a world where you can talk with someone without ever seeing them, and show them photos without standing next to them. We love the fact that people get a kick out of making real contact when bumping. To carry that further, I decided to explore textures, shadows, and layering in the new design. These are things we see in real life and that make the app look touchable.

Our homescreen background is paper-like; the buttons & graphics are tending toward a letter-pressed style; both of these are enormously tactile in appearance. Subtle dropshadows and glows give buttons, notes and bars the impression of popping up and out of the screen. This is all stuff we see everyday (just look at the pages of a book or the buttons on a TV). These details come from things we interact with and that we know how to use.

At Bump we’re trying to capitalize on the intuitive understanding that people have of objects, buttons,  and icons, and use them in the app to help our users get where they want to go. In the end it’s all about making Bump easy, and a pleasure, to use.

As with any large undertaking this project takes time. We’re only part-way finished with the redesign and we’re already looking ahead to a larger overhaul. But in the meantime I’m enjoying the new look we’ve injected into the app. It’s a huge step forward in making Bump even more a pleasure to use.

Want to work with Shona and the rest of the Bump team? We are hiring: http://bu.mp/jobs.