Development Agency & Digital Product Superheroes
Apps | Software | Hardware

Let's work together

Rhabit

Live Video Coaching Sessions with top tennis coaches

Learn more

Product Super Powers

Product Design

We’ll help you refine your idea and roadmap it into a real solution.

Native Mobile Apps

Your mobile app will be ridiculously fast and extremely reliable.

Web Apps & Software

Everything we build for you will run seamlessly across different platforms.

Hardware Development

We’ll apply technology to your hardware and make it way cooler.

See All Services

Genevieve Theirs
CEO, NewFounders

SO MANY THANKS to 20Spokes, our amazing tech firm here in Chicago. We literally cannot say enough good things about 20Spokes.

Why 20spokes

Passion

We live and breathe design and development, and put that passion into every product we produce.

Transparency

You’ll know everything that goes into your product with status updates on a consistent basis.

Quality

Quality is top of mind. We work through a tailored approach to ensure that quality is consistent.

Fun

Turning your idea into a reality will not only be a rewarding experience that results in a high-quality product, but we guarantee you’ll have some fun.

From the Blog

Technology

5/17/18

When to Put Data in Redux

Lots of internet ink has been spilled over when to keep data in an application state management system (like Redux) versus in a React component's internal state. While I've mentioned benefits to Redux on this blog before, it's important to understand the tradeoffs.

Keeping state in components has pros and cons:

Pro: your data is cleared when the component unmounts!

Con: your data is cleared when the component unmounts.

Likewise, keeping data in app state has pros and cons:

Pro: your data persists between components!

Con: your data persists between components.

Personally, I err on the side of keeping data out of app state. If I'm creating a new component and I'm unsure where to store my data, I'll use internal state, then port to Redux when it becomes necessary.

It's helpful to conceive of your app state as a collection of global variables. Normally, global variables are to be avoided. You wouldn't add global variables willy-nilly in a Rails or Python app. Have the same precaution when adding globals client-side.

Like any other global variable, when you make the decision to move your data into the global app state, it is now up to you to manage it. For instance, you'll probably need to clear your app state when a user logs out. When a user exits a multi-step form, you may need to clear any data that user entered.

Constructing your React container components thoughtfully can help you avoid manually managing state like this. With multi-step forms, I typically create a wrapper component that's responsible for rendering each step of the form, keeping all user-entered data in its own state. From this container, I can pass any of its state and functionality down to each step as props. It's a simple solution, but an often overlooked one, especially when Redux is already in your app and you see other components using it.

When an app uses Redux, it's impossible to prevent future maintainers from simply adding everything to app state. You can mitigate this by stressing in your documentation how keeping state in Redux can be dangerous. You can also practice predictable state patterns in your own components (like the form wrapper), setting good examples for future developers. But ultimately it's a hard thing to enforce, and this should be considered when deciding to add Redux to your application.

Design

12/15/17

UX is in the Details: Better Empty States

Empty states are the in-between spaces in any app. They’re what happens when the inbox is empty, when the special offer has expired, when you haven’t selected any favorites, or when you’ve cleared the to-do list out. And potentially they are the first screens to be seen upon signing up.

hendrix empty state

Hendrix

While empty states may seem like small flourishes, they are actually a powerful design pattern.

Anticipating empty states, understanding when and where empty states occur, requires extensive knowledge of a user’s pathway through the product. By developing good empty states, the landscape of the product can be clearer - a user can know what to expect from your app and even be guided on how to use the app before they have invested time in it.

On top of improving the user experience of an app, empty states inform your users on what information will be displayed on the screen. To put it nicely, without good empty states your product will feel not just empty, but broken!

dovetail empty state

Dovetail

So now that we have our empty states accounted for, how do we make them better?

Empty states are an incredible opportunity to build brand affinity. You can introduce branded characters and animations and set the tone of the brand’s identity through empty states. It is one of the most powerful ways to set the “tone” of your product - is it silly and loose, or purposeful and stylish? We probably wouldn’t want a dog digging for a bone in a financial product, but it’s perfect for a pet adoption app.

Hoang Nguyen Empty State

Dribbble: Hoang Nguyen

Humanizing your product with enjoyable empty states can produce familiarity and build an emotional connection. Twitter didn’t just tell you they’re down with a message - they showed you the iconic Fail Whale: cute birds cheerfully lifting a huge and grinning whale.

We may be down, but here’s an awesome cartoon.

While the endearing whale is no more, the reach of that simple empty state shows how powerful a tool they can be for a brand. Instead of a cold error message, there’s a colorful little diversion from frustration. Taking the edge off of bad news with an empty state illustration is a widely-used design pattern.

Ivy Mukherjee Empty State

Dribbble: Ivy Mukherjee

So, beyond your servers crashing - what else could we use empty states for?

They can show crucial information, acting as an onboarding agent for new users.

AirBnb Itinerary Empty State

AirBnb Itinerary Empty State

They can act as a tutorial, showing a slightly more in-depth way to use a feature.

Dropbox Empty State

Dropbox Paper Empty State

They can reveal product goals, or the power of a product.

Waze Alerts Empty State

Waze Alerts Empty State

The empty states are the chance to give the product a voice and let it speak. It’s nearly an advertisement for itself!

The most common empty state is the upload screen. The drag-here box that’s unmistakable because of its design - you just want to put your latest pic there. These “contribution” empty states are vital because they’re one of the user’s direct interaction points. It must not only look like something the user wants to use, of course - it has to work perfectly, too!

Empty states are a nudge that call us to action in our apps. Without them, users aren’t just lost - they think something is wrong. If there’s no particular place for a user to go, or if they don’t like where you’re trying to take them, then they’re going to bounce!

Blank screens hide features, but empty states reveal them

As a product designer, empty states are one of my favorite chances to be creative and really get to know a product. I get to shape how a user approaches a product’s features. What should this app feel like? What will they use it for? How will they want to use it? What will signal to them: this product is secure, safe, but also simple enough to use?

Now that we’ve explored why emtpy states are so crucial - did you notice an empty state you’d never thought about? Do you have a favorite empty state? Let me know in the comments!

Technology

12/8/17

What I’ve learned from a few large-scale React and Redux projects

A friend of mine recently started a new job where he’ll be working a lot in React and Redux, and asked me if I had any strategies or best practices, particularly with large-scale projects.

I wish I could tell him that I do. But honestly, every time I make a framework-specific rule, I quickly come across a situation where the best solution is to break it.

What I have come up with are a few benchmarks that guide me to making sure my React code is understandable to other developers, and to Future-Me.

1. All of my logic is tested

When I ensure that all of my logic is tested, whether it’s component/view logic or action-related logic, I naturally fall into healthier coding patterns. I extract unnecessary responsibilities from my components. I write more helper functions and utility modules. I can better determine when state should be kept locally or remotely.

This also helps me determine what packages I want to introduce to my app. For example, people often debate whether Redux is an appropriate tool for their project. The co-author of Redux has even said that for many cases, local state is just fine. In my view, if Redux helps you test your logic, then you are gaining a big advantage by using it. Since reducers are supposed to be pure functions, testing them is incredibly straightforward. Action creators can be tested in isolation outside of your components. If you use any middleware to perform asynchronous requests, these can be tested in isolation as well.

Testing view logic should not be ignored either. If testing your components becomes cumbersome, or if you’re stubbing too many functions in order to test them, that’s a good sign your component is doing too much.

2. My Redux actions tell a story

Redux Dev Tools is indispensable to me when I’m building an app, and when I’m debugging one. These tools allow you to view all of your actions in real time, rewind and replay actions, and dig into the current state for each action.

The list of action names that Redux Dev Tools gives you should tell the story of your user. They should give you a crystal clear understanding what what your user is doing at any given time. An action like SEND_API_REQUESTED is way less understandable to a new developer than an action like USER_LOG_IN_REQUESTED, because it lacks the context of the user experience. Giving your actions this context helps a lot when debugging.

Redux actions should also show you the result of any asynchronous requests you make. So if I see a USER_LOG_IN_REQUESTED in my list of actions, I should know to expect a USER_LOG_IN_SUCCEEDED or USER_LOG_IN_FAILED action shortly afterward.
Using a redux middleware like redux-saga helps me keep track of asynchronous requests and their effects. With dev tools I can clearly see the order of these requests and the effects of their responses.

3. I know how to use a React component without looking up a working example of it in the codebase

If I’m looking at a component definition, I should be able to:

  1. determine whether this component is for global use or context-specific use. Often this is achieved by defining the component within certain directories, like components/elements/forms/textInput.js.

  2. know exactly what props this component receives. This can be done by using React’s prop-types package, which now allows you to more accurately define the shape of your props. So instead of doing this:

user: PropTypes.object.isRequired  

I can do this:

user: PropTypes.shape({  
  id: PropTypes.number.isRequired,
  first_name: PropTypes.string,
  state: PropTypes.oneOf(['pending', 'active', 'archived'])
}).isRequired

I feel like I’ve only scratched the surface here, but it’s a start. Happy coding!

View More Work

PupJoy

We automated PupJoy’s operation and gave back hundreds of man hours. (So we could all spend more time with our best friends)

Rhabit

Want to watch a video of player mechanics while streaming a video chat with your tennis coach? We made it possible with Rhabit.