Tag Archives: products

Thumbnail

Building Mobile Apps Using React Native And WordPress




Building Mobile Apps Using React Native And WordPress

Muhammad Muhsin



As web developers, you might have thought that mobile app development calls for a fresh learning curve with another programming language. Perhaps Java and Swift need to be added to your skill set to hit the ground running with both iOS and Android, and that might bog you down.

But this article has you in for a surprise! We will look at building an e-commerce application for iOS and Android using the WooCommerce platform as our backend. This would be an ideal starting point for anyone willing to get into native cross-platform development.

A Brief History Of Cross-Platform Development

It’s 2011, and we see the beginning of hybrid mobile app development. Frameworks like Apache Cordova, PhoneGap, and Ionic Framework slowly emerge. Everything looks good, and web developers are eagerly coding away mobile apps with their existing knowledge.

However, mobile apps still looked like mobile versions of websites. No native designs like Android’s material design or iOS’s flat look. Navigation worked similar to the web and transitions were not buttery smooth. Users were not satisfied with apps built using the hybrid approach and dreamt of the native experience.

Fast forward to March 2015, and React Native appears on the scene. Developers are able to build truly native cross-platform applications using React, a favorite JavaScript library for many developers. They are now easily able to learn a small library on top of what they know with JavaScript. With this knowledge, developers are now targeting the web, iOS and Android.

Furthermore, changes done to the code during development are loaded onto the testing devices almost instantly! This used to take several minutes when we had native development through other approaches. Developers are able to enjoy the instant feedback they used to love with web development.

React developers are more than happy to be able to use existing patterns they have followed into a new platform altogether. In fact, they are targeting two more platforms with what they already know very well.

This is all good for front-end development. But what choices do we have for back-end technology? Do we still have to learn a new language or framework?

The WordPress REST API

In late 2016, WordPress released the much awaited REST API to its core, and opened the doors for solutions with decoupled backends.

So, if you already have a WordPress and WooCommerce website and wish to retain exactly the same offerings and user profiles across your website and native app, this article is for you!

Assumptions Made In This Article

I will walk you through using your WordPress skill to build a mobile app with a WooCommerce store using React Native. The article assumes:

  • You are familiar with the different WordPress APIs, at least at a beginner level.
  • You are familiar with the basics of React.
  • You have a WordPress development server ready. I use Ubuntu with Apache.
  • You have an Android or an iOS device to test with Expo.

What We Will Build In This Tutorial

The project we are going to build through this article is a fashion store app. The app will have the following functionalities:

  • Shop page listing all products,
  • Single product page with details of the selected item,
  • ‘Add to cart’ feature,
  • ‘Show items in cart’ feature,
  • ‘Remove item from cart’ feature.

This article aims to inspire you to use this project as a starting point to build complex mobile apps using React Native.

Note: For the full application, you can visit my project on Github and clone it.

Getting Started With Our Project

We will begin building the app as per the official React Native documentation. Having installed Node on your development environment, open up the command prompt and type in the following command to install the Create React Native App globally.

npm install -g create-react-native-app

Next, we can create our project

create-react-native-app react-native-woocommerce-store

This will create a new React Native project which we can test with Expo.

Next, we will need to install the Expo app on our mobile device which we want to test. It is available for both iOS and Android.

On having installed the Expo app, we can run npm start on our development machine.

cd react-native-woocommerce-store

npm start


Starting a React Native project through the command line via Expo. (Large preview)

After that, you can scan the QR code through the Expo app or enter the given URL in the app’s search bar. This will run the basic ‘Hello World’ app in the mobile. We can now edit App.js to make instant changes to the app running on the phone.

Alternatively, you can run the app on an emulator. But for brevity and accuracy, we will cover running it on an actual device.

Next, let’s install all the required packages for the app using this command:

npm install -s axios react-native-htmlview react-navigation react-redux redux redux-thunk

Setting Up A WordPress Site

Since this article is about creating a React Native app, we will not go into details about creating a WordPress site. Please refer to this article on how to install WordPress on Ubuntu. As WooCommerce REST API requires HTTPS, please make sure it is set up using Let’s Encrypt. Please refer to this article for a how-to guide.

We are not creating a WordPress installation on localhost since we will be running the app on a mobile device, and also since HTTPS is needed.

Once WordPress and HTTPS are successfully set up, we can install the WooCommerce plugin on the site.


Installing the WooCommerce plugin to our WordPress installation. (Large preview)

After installing and activating the plugin, continue with the WooCommerce store setup by following the wizard. After the wizard is complete, click on ‘Return to dashboard.’

You will be greeted by another prompt.


Adding example products to WooCommerce. (Large preview)

Click on ‘Let’s go‘ to ‘Add example products’. This will save us the time to create our own products to display in the app.

Constants File

To load our store’s products from the WooCommerce REST API, we need the relevant keys in place inside our app. For this purpose, we can have a constans.js file.

First create a folder called ‘src’ and create subfolders inside as follows:


Create the file ‘Constants.js’ within the constans folder. (Large preview)

Now, let’s generate the keys for WooCommerce. In the WordPress dashboard, navigate to WooCommerce → Settings → API → Keys/Apps and click on ‘Add Key.’

Next create a Read Only key with name React Native. Copy over the Consumer Key and Consumer Secret to the constants.js file as follows:

const Constants = 
   URL: 
wc: 'https://woocommerce-store.on-its-way.com/wp-json/wc/v2/'
   ,
   Keys: 
ConsumerKey: 'CONSUMER_KEY_HERE',
ConsumerSecret: 'CONSUMER_SECRET_HERE'
   
}
export default Constants;

Starting With React Navigation

React Navigation is a community solution to navigating between the different screens and is a standalone library. It allows developers to set up the screens of the React Native app with just a few lines of code.

There are different navigation methods within React Navigation:

  • Stack,
  • Switch,
  • Tabs,
  • Drawer,
  • and more.

For our Application we will use a combination of StackNavigation and DrawerNavigation to navigate between the different screens. StackNavigation is similar to how browser history works on the web. We are using this since it provides an interface for the header and the header navigation icons. It has push and pop similar to stacks in data structures. Push means we add a new screen to the top of the Navigation Stack. Pop removes a screen from the stack.

The code shows that the StackNavigation, in fact, houses the DrawerNavigation within itself. It also takes properties for the header style and header buttons. We are placing the navigation drawer button to the left and the shopping cart button to the right. The drawer button switches the drawer on and off whereas the cart button takes the user to the shopping cart screen.

const StackNavigation = StackNavigator(
 DrawerNavigation:  screen: DrawerNavigation 
}, 
   headerMode: 'float',
   navigationOptions: ( navigation, screenProps ) => (
     headerStyle:  backgroundColor: '#4C3E54' ,
     headerTintColor: 'white',
     headerLeft: drawerButton(navigation),
     headerRight: cartButton(navigation, screenProps)
   })
 });

const drawerButton = (navigation) => (
 <Text
   style= padding: 15, color: 'white' }
   onPress=() => 
     if (navigation.state.index === 0) 
       navigation.navigate('DrawerOpen')
      else 
       navigation.navigate('DrawerClose')
     
   }
   }> (
 <Text style= padding: 15, color: 'white' }
   onPress=() =>  navigation.navigate('CartPage') }
 >
   <EvilIcons name="cart" size=30 />
   screenProps.cartCount
 </Text>
);

DrawerNavigation on the other hands provides for the side drawer which will allow us to navigate between Home, Shop, and Cart. The DrawerNavigator lists the different screens that the user can visit, namely Home page, Products page, Product page, and Cart page. It also has a property which will take the Drawer container: the sliding menu which opens up when clicking the hamburger menu.

const DrawerNavigation = DrawerNavigator(
 Home: 
   screen: HomePage,
   navigationOptions: 
     title: "RN WC Store"
   
 },
 Products: 
   screen: Products,
   navigationOptions: 
     title: "Shop"
   
 },
 Product: 
   screen: Product,
   navigationOptions: ( navigation ) => (
     title: navigation.state.params.product.name
   ),
 },
 CartPage: 
   screen: CartPage,
   navigationOptions: 
     title: "Cart"
   
 }
}, 
   contentComponent: DrawerContainer
 );

#


Left: The Home page (homepage.js). Right: The open drawer (DrawerContainer.js).

Injecting The Redux Store To App.js

Since we are using Redux in this app, we have to inject the store into our app. We do this with the help of the Provider component.

const store = configureStore();

class App extends React.Component 
 render() 
   return (
     <Provider store=store>    
       <ConnectedApp />    
     </Provider>    
   )
 }
}

We will then have a ConnectedApp component so that we can have the cart count in the header.

class CA extends React.Component 
 render() 
   const cart = 
     cartCount: this.props.cart.length
   
   return (
     <StackNavigation screenProps=cart />
   );
 }
}

function mapStateToProps(state) 
 return 
   cart: state.cart
 ;
}

const ConnectedApp = connect(mapStateToProps, null)(CA);

Redux Store, Actions, And Reducers

In Redux, we have three different parts:

  1. Store
    Holds the whole state of your entire application. The only way to change state is to dispatch an action to it.
  2. Actions
    A plain object that represents an intention to change the state.
  3. Reducers
    A function that accepts a state and an action type and returns a new state.

These three components of Redux help us achieve a predictable state for the entire app. For simplicity, we will look at how the products are fetched and saved in the Redux store.

First of all, let’s look at the code for creating the store:

let middleware = [thunk];

export default function configureStore() 
    return createStore(
        RootReducer,
        applyMiddleware(...middleware)
    );

Next, the products action is responsible for fetching the products from the remote website.

export function getProducts() 
   return (dispatch) => 
       const url = `$Constants.URL.wcproducts?per_page=100&consumer_key=$Constants.Keys.ConsumerKey&consumer_secret=$Constants.Keys.ConsumerSecret`
      
       return axios.get(url).then(response => 
           dispatch(
               type: types.GET_PRODUCTS_SUCCESS,
               products: response.data
           
       )}).catch(err => 
           console.log(err.error);
       )
   };
}

The products reducer is responsible for returning the payload of data and whether it needs to be modified.

export default function (state = InitialState.products, action) 
    switch (action.type) 
        case types.GET_PRODUCTS_SUCCESS:
            return action.products;
        default:
            return state;
    
}

Displaying The WooCommerce Shop

The products.js file is our Shop page. It basically displays the list of products from WooCommerce.

class ProductsList extends Component 

 componentDidMount() 
   this.props.ProductAction.getProducts(); 
 

 _keyExtractor = (item, index) => item.id;

 render() 
   const  navigate  = this.props.navigation;
   const Items = (
     <FlatList contentContainerStyle=styles.list numColumns=2
       data=this.props.products  
       keyExtractor=this._keyExtractor
       renderItem=
         ( item ) => (
           <TouchableHighlight style= width: '50%' } onPress=() => navigate("Product",  product: item )} underlayColor="white">
             <View style=styles.view >
               <Image style=styles.image source= uri: item.images[0].src } />
               <Text style=styles.text>item.name</Text>
             </View>
           </TouchableHighlight>
         )
       }
     />
   );
   return (
     <ScrollView>
       this.props.products.length ? Items :
         <View style= alignItems: 'center', justifyContent: 'center' }>
           <Image style=styles.loader source=LoadingAnimation />
         </View>
       }
     </ScrollView>
   );
 }
}

this.props.ProductAction.getProducts() and this.props.products are possible because of mapStateToProps and mapDispatchToProps.


Products listing screen. (Large preview)

mapStateToProps and mapDispatchToProps

State is the Redux store and Dispatch is the actions we fire. Both of these will be exposed as props in the component.

function mapStateToProps(state) 
 return 
   products: state.products
 ;
}
function mapDispatchToProps(dispatch) 
 return 
   ProductAction: bindActionCreators(ProductAction, dispatch)
 ;
}
export default connect(mapStateToProps, mapDispatchToProps)(ProductsList);

Styles

In React, Native styles are generally defined on the same page. It’s similar to CSS, but we use camelCase properties instead of hyphenated properties.

const styles = StyleSheet.create(
 list: 
   flexDirection: 'column'
 ,
 view: 
   padding: 10
 ,
 loader: 
   width: 200,
   height: 200,
   alignItems: 'center',
   justifyContent: 'center',
 ,
 image: 
   width: 150,
   height: 150
 ,
 text: 
   textAlign: 'center',
   fontSize: 20,
   padding: 5
 
});

Single Product Page

This page contains details of a selected product. It shows the user the name, price, and description of the product. It also has the ‘Add to cart’ function.


Single product page. (Large preview)

Cart Page

This screen shows the list of items in the cart. The action has the functions getCart, addToCart, and removeFromCart. The reducer handles the actions likewise. Identification of actions is done through actionTypes — constants which describe the action that are stored in a separate file.

export const GET_PRODUCTS_SUCCESS = 'GET_PRODUCTS_SUCCESS'
export const GET_PRODUCTS_FAILED = 'GET_PRODUCTS_FAILED';

export const GET_CART_SUCCESS = 'GET_CART_SUCCESS';
export const ADD_TO_CART_SUCCESS = 'ADD_TO_CART_SUCCESS';
export const REMOVE_FROM_CART_SUCCESS = 'REMOVE_FROM_CART_SUCCESS';

This is the code for the CartPage component:

class CartPage extends React.Component 

 componentDidMount() 
   this.props.CartAction.getCart();
 

 _keyExtractor = (item, index) => item.id;

 removeItem(item) 
   this.props.CartAction.removeFromCart(item);
 

 render() 
   const  cart  = this.props;
   console.log('render cart', cart)

   if (cart && cart.length > 0) {
     const Items = <FlatList contentContainerStyle=styles.list
       data=cart
       keyExtractor=this._keyExtractor
       renderItem=( item ) =>
         <View style=styles.lineItem >
           <Image style=styles.image source= uri: item.image } />
           <Text style=styles.text>item.name</Text>
           <Text style=styles.text>item.quantity</Text>
           <TouchableOpacity style= marginLeft: 'auto' } onPress=() => this.removeItem(item)><Entypo name="cross" size=30 /></TouchableOpacity>
         </View>
       }
     />;
     return (
       <View style=styles.container>
         Items
       </View>
     )
   } else {
     return (
       <View style=styles.container>
         <Text>Cart is empty!</Text>
       </View>
     )
   }
 }
}

As you can see, we are using a FlatList to iterate through the cart items. It takes in an array and creates a list of items to be displayed on the screen.


#


Left: The cart page when it has items in it. Right: The cart page when it is empty.

Conclusion

You can configure information about the app such as name and icon in the app.json file. The app can be published after npm installing exp.

To sum up:

  • We now have a decent e-commerce application with React Native;
  • Expo can be used to run the project on a smartphone;
  • Existing backend technologies such as WordPress can be used;
  • Redux can be used for managing the state of the entire app;
  • Web developers, especially React developers can leverage this knowledge to build bigger apps.

For the full application, you can visit my project on Github and clone it. Feel free to fork it and improve it further. As an exercise, you can continue building more features into the project such as:

  • Checkout page,
  • Authentication,
  • Storing the cart data in AsyncStorage so that closing the app does not clear the cart.
Smashing Editorial
(da, lf, ra, yk, il)


More here: 

Building Mobile Apps Using React Native And WordPress

Product Awareness Month: Why I’m Writing 30 Blog Posts in 30 Days

alt : https://unbounce.com/photos/30-in-30.mp4https://unbounce.com/photos/30-in-30.mp4

We Have 1.06 Products.

I wrote that statement on a whiteboard at the start of a website brainstorm session.

What does 1.06 products mean?

1.06 sums up my frustration at the adoption rate of our new products. Yup, Unbounce is now more than just a landing page builder. We released two new products, namely “overlays” and “sticky bars”, and we grouped them together under an umbrella term “Convertables”.

The number 1 represents our flagship industry-leading landing page product (100% of our customers have adopted it), and the .06 represents the tragic adoption rate of our new products (6%).

And yes, you’d be correct if you noted that “Convertables” isn’t a real word, but then neither is Unbounce, so we went with it after a notable amount of company-wide polling, and general corporate groupthink. More on that later.

So, how does this scenario result in me writing 30 blog posts about our products?

Rewind to October 5th: I was in a meeting with fellow co-founders Rick, Carl, and Carter, openly expressing my frustration with the adoption numbers, and Carter interrupted me to ask, “Okay, fine, but what are you going to do about it?”.

Then this video happened…

Awesome, right?! Yeah, it is, until the moment I realized it’s been exactly 301 days since I last wrote a blog post (I’ve been focusing on public speaking), making this level of bravado a tad audacious at best. Aaand, yes I realize I was a little intoxicated in the video.

But, I’ve learned over the years, that being a bit ridiculous in my promises is the only way I really know how to get shit done. When I tell everyone that I’m doing something big, the self-imposed peer pressure is what motivates me to make sure I complete my mission.

Enter Product Awareness Month (PAM)

This brings me to our blog. We’ve never written much about our products on the blog, in fact, we’ve actively avoided it to let the content speak for itself as an educational pillar of the community, and to remain non-salesy.

I’ve realized though, that it doesn’t make much business sense to be that overtly humble in all marketing communications. There has to be a way to balance exposing people to your product without it detracting from the experience.

It’s my fault in many ways. When I started our blog back in 2009, I had a mission to be different from our competitors, to not come across as a salesperson, and just to provide value and entertaining content that stood out.

We dominated the realm of conversion content for many years, but in an increasingly competitive SaaS martech space, our content is no longer number one, and it’s time that we change our approach.

Which is why we’re doing a blog takeover for the whole of January.

Our goal is to explore a blog topic we’ve not covered before, but also to expose a transparent window – transparency is one of our six core values at Unbounce – into our journey as a company, as a marketing team, and myself personally, to become better at marketing our new products.

For me, it’s the first time I’ve ever been involved in product marketing, which will make it a fascinating personal journey reinventing myself as a different kind of marketer.

I’m also cutting the number of speaking gigs I do in 2018 in half, because let’s be honest, in this moment, the success of Unbounce can be more rapidly impacted by me staying home than being on the road.

Transparency

Along the way, I’ll be opening up the Unbounce vault to share our core metrics with you. This will include our churn and product adoption metrics, which we hope to be able to lift in a big way throughout this 30-day experiment. There will be data check-ins throughout, with a halfway report, and then a full “Results Show” at the end.

I’ll also be digging into our analytics to see what the engagement and attribution looks like for every one of the 30 blog posts.

Some of the content will revolve around the learnings and experiences of becoming a better product marketer, and the rest will be an exploration of the ways we’re trying to rethink what our products are, what they mean to our customers, and how we can do a better job communicating their benefits (with some case studies and new ways of thinking – I hope).

I say “I hope” because I’m writing this as you read it. That’s what tends to happen when you commit to something as absurd as 30-in-30.

Follow Along << Mid-Post CTA

I encourage you to follow along by subscribing to our weekly update emails at the bottom of the page. I’m really keen to have our community (that’s you) help us explore how to do this properly, and hopefully, we’ll all learn how to do a better job of marketing our products.

This is a screenshot of the subscribe form at the bottom of the post. Thought you should know.

You can also subscribe by clicking here to launch a popup (using the on-click trigger feature) which contains the subscribe form. << product marketing much?

Aaand I’ve configured it so you’ll see an exit popup when you leave this page. Note, that I’m doing this to show the product in a relevant and hopefully useful manner.

Unbounce Product Adoption Metrics

How do we measure adoption at Unbounce? To understand, it helps to explain a little about how we define a customer. In the old days, a customer was any signup, someone who started a 30-day trial. Over time we learned we should be measuring a little deeper into the customer lifecycle, and decided a customer was someone who paid us twice; once after the 30-day trial, and again after sixty days.

In 2017 we modified this further to someone who pays us three times, giving us a much better sense of true churn numbers.

To be considered a customer who has adopted our products, we have an additional set of app usage criteria:

For landing pages adoption means: a customer who has built and published one or more pages, has set up a custom domain, configured an integration with another tool, and has paid us three times.

For “Convertables” (Overlays & Sticky Bars) adoption means: a customer who has built and published a popup or sticky bar, installed our one-line global Javascript on their website, received at least 10 conversions, and has paid us three times.

Full transparency: 6% adoption for a new product sucks.

So what went wrong? Why was adoption so low?

Well, first, and most importantly, product marketing is really hard.

We also made a few (well intended) mistakes, namely…

Mistake #1: We called a popup an overlay.
Mistake #2: We created a fictitious umbrella term “Convertables” for only two child products, and for a few months, only one child product.
Mistake #3: We assumed that people would find and use these two products, hidden behind said umbrella term in the app.
Mistake #4: We assumed that the functional user of our landing page product would be the same person who needs to use popups and sticky bars.

How do we un-f*** this problem?

The first thing we’re doing is removing public-facing mentions of the term “Convertables”. This has excited the marketing team because it’s much easier to market something when you know how to describe it, and a multi-product value prop is much harder than a single-product value prop.

Beyond that, the approach I’m taking is a combination of four primary tenets:

  1. First, is a concept I call “Productizing Our Technology” or POT for short. This is about discovering new and novel ways that our platform can be used, that people either haven’t imagined or simply didn’t know was possible.
  2. Second, is exploring the entire Unbounce ecosystem, from the app, to the website, our content channels, and our community, to see how we could do a better job of exposing the benefits of our products to those who can benefit from them.
  3. Third, is using the Product Awareness Month blog takeover to create interactive demonstrations right here on the blog – the goal of which is to reduce the Time to Value (TTV) by creating more obvious ah-ha moments.
  4. Fourth, understanding who the various target personas and functional users of the different products are, and adjusting our targeting and marketing communications to find and speak to those potentially different users.

In regards to #3 the blog takeover, if you take a look at the top of the screen, you’ll see a header bar like this:

Or this one, if you have scrolled down the page:

If you look at the hierarchy of information from left to right, you see: 1) Who we are: logo, 2) What we do: value prop, 3) How to take action: the three big orange buttons.

This is hugely different to the rest of the blog, which retains the navigation of the whole site (I’ve thought that was incongruent for a long time).

My hope is that the new header bar helps more people know what we do, and how our products can help. I’ll be tracking engagement with the 3 CTAs and comparing these 30 posts against our other blog content in terms of its ability to get people to sign up.

Productizing Our Technology: Landing Pages, Popups, & Sticky Bars

I had my own ah-ha moment when I started imagining all the ways that I could hack/modify/extend the ways the Unbounce conversion platform can be used. We have 3 core pieces of product technology (not including our AI/Machine Learning efforts that will power our technology in the future): landing pages, popups, and sticky bars.

By taking our core tech, combining the available features, with new jQuery scripts, CSS, and some 3rd-party integrations, it’s possible to create a plethora of new “mini-products” that if embraced by the community, might inform future product direction.

Take a look at the spreadsheet below. This is my POT matrix. The complete sheet currently houses over 120 new product ideas.

Productizing Unbounce Technology
(Click image for full-size view)

Across the top (in yellow) are the core products, their features (such as targeting, triggers, display frequency), and the different hacks, data sources, and integrations, that can be combined to produce the new products listed in green in the first column.

Each product is flagged as being in one of three states:

NOW: These products are possible now with our existing feature set.
MVP: These products are possible by adding some simple scripts/CSS to extend the core.
NEW: These products would require a much deeper level of product or website development to make them possible. These are the examples that came from “blue sky” ideation, and are a useful upper anchor for what could be done.

I’ll be explaining these use cases in greater detail as the month progresses, and I’ll be building some of them directly into these blog posts as I write them. << FTR this will involve me reverting to my long-extinct coding background to hack the shit out of the blog to show you what I’m talking about.

Please Follow Along

That’s the intro, that’s what happened, and what we’re going to do to try and fix it. Subscribe to the weekly email updates, join the discussion in the comments, and chat directly with me on Twitter.

There is also a calendar at the bottom of every post that will link to all 30 PMM topics as they roll out.

What’s coming on day 2 of PMM?

Tomorrow’s post is called “50 Creative Ideas Your Marketing Team Can Use to Improve SaaS Product Adoption & Awareness”. It’s based on the results of rapid-fire brainstorms which exposed quick-win tactics all product marketers can use to expose your products in small and simple ways, to build to a critical mass of awareness.

This should be very relevant to anyone in marketing, and doubly so to those working for a SaaS business.

Here’s to kicking off 2018 in a blaze of product marketing glory.

Cheers,
Oli Gardner

p.s. Please jump into the comments below to let me know what products you’re currently trying to take to market.

Original article: 

Product Awareness Month: Why I’m Writing 30 Blog Posts in 30 Days

Building Accessible Menu Systems

Editor’s Note: This article originally appeared on Inclusive Components. If you’d like to know more about similar inclusive component articles, follow @inclusicomps on Twitter or subscribe to the RSS feed. By supporting inclusive-components.design on Patreon, you can help to make it the most comprehensive database of robust interface components available.
Classification is hard. Take crabs, for example. Hermit crabs, porcelain crabs, and horseshoe crabs are not — taxonomically speaking — true crabs.

Read article here:

Building Accessible Menu Systems

9 Customer Re-Engagement Emails You Need to Steal

emails you should steal

If you had one shot at a 100% guarantee that your customers will open every email you send, how would you do it? Will you tempt them with massive discounts on your products and services? Will you extend their free trial period? Will you add a free upgrade to their account? Whatever method you choose; one thing remains true: Forever does not exist. Your customers will get tired of you eventually. Acceptance Is Key Once you have come to terms with the fact that not all your email subscribers will be with you for the rest of your marketing career,…

The post 9 Customer Re-Engagement Emails You Need to Steal appeared first on The Daily Egg.

Read original article:  

9 Customer Re-Engagement Emails You Need to Steal

Giving Your Product A Soul

After a few years of designing products for clients, I began to feel fatigued. I wondered why. Turns out, I’d been chasing metric after metric. “Increase those page views!” “Help people spend more time in the app!” And it kept coming. Still, something was missing. I knew that meeting goals was part of what a designer does, but I could see how my work could easily become commoditized and less fulfilling unless something changed.

This article:

Giving Your Product A Soul

The one segment you probably aren’t (but should be) looking at

Reading Time: 4 minutes

Let’s say you’re segmenting traffic to your website.

You’re segmenting traffic because, in a digital world brimming over with messages, you want to make sure that the messaging on your site is Relevant to the right user at the right time.

And segmentation allows for personalization.

You believe that a more customized user experience will lead to more orders, demo requests, phone calls etc. So, you have structures in place to deliver appropriate messages to your different audiences, each with distinct needs and expectations.

But I must ask, how are you segmenting your visitors?

You might be grouping them by device, by traffic source, by demographic data.

General_Segments
People often segment general visitors by device, by traffic source, and by demographic data.

And these buckets are all viable:

  • Your desktop visitors may behave differently than your mobile visitors
  • Visitors coming from a Facebook ad may respond better to social proof triggers than those coming from organic search
  • Older visitors may browse your products differently than younger visitors

But the ultimate goal of segmentation, like conversion optimization, is to increase conversions. With that in mind, this post is all about that one segment you probably aren’t looking at: converters versus non-converters.

To clarify, your converter segment is not necessarily the same thing as your repeat-customer or Loyalty segment. Your converter segment includes anyone who converts, whether or not they’ve converted before.

Rather than focusing on different general visitor segments, you should turn your attention to the behaviors that differentiate visitors who convert from visitors who don’t.

When you focus on general visitor segments, you’re working from the top of the funnel to the bottom. Why not work from the bottom of the funnel, up? After all, that’s where the money is!

Correlation vs. Causation

First things first: when you’re looking at differences between converters and non-converters on your site, you must be wary of correlation versus causation.

It’s almost impossible to know whether converters are behaving in a distinct way because they’re already motivated to buy (correlation) or because the elements on the page have enabled those distinct behaviors (causation).

For example, does a converter browse more products than a non-converter because they’re already motivated to buy before arriving on-site? Or does an on-site UI that emphasizes browsability encourage converters to browse (and therefore convert)?

It’s similar to the search bar quandary: typically, visitors who search convert at a higher rate. But do they convert because they search (causation) or do the search because they’re already more motivated to buy (correlation)?

It’s a bit of a “the chicken or the egg” situation.

Fortunately, at WiderFunnel, we’re able to test on many retailers’ websites and take note of certain patterns. On multiple instances with different clients, we have observed clear and drastic differences in key user behavior metrics between visitors who convert and visitors who don’t convert.

These differences paint a picture of how your visitors shop. You can use this information to improve your UX and add features that’ll help your general visitors behave more like converters than non-converters. The hope is that encouraging non-converters to mimic the behavior of converters will lead to them actually becoming converters.

Moral of the story: If you observe impactful differences between converters and non-converters on your site, you should create a hypothesis that targets these differences.

WiderFunnel Optimization Strategist, Nick So, recently ran a test that did just that.

Let’s buy some shoes

One of our biggest clients is a global shoe retailer. Over the past 6 months, Nick noticed some patterns in their analytics:

  1. A high percentage of visitors that convert (like 60%) are returning visitors
  2. Converters visited 186% more pages per session on average and spent more time on page per session than non-converters
Converter_Stats
Converter vs. Non-Converter behavior on this client’s site.

Meaning, the majority of converters on this site have already been to the site at least once before and they seem to spend much more time browsing than their non-converting counterparts.

Nick So

It’s common sense that visitors who convert behave differently than those who don’t. But it wasn’t until we pulled the report and saw how big the difference was in their shopping behavior that we really thought to go down this path.

Nick So, Optimization Strategist, WiderFunnel

In previous testing, Nick had also observed that visitors to this site are responsive to features that increase the browsability of multiple products. He’d noticed the same sensitivity with some of our other retailer clients, where features that made it easier to compare products helped conversions.

We decided to run with this data. Our hypothesis was based on the idea that visitors who convert are most likely returning visitors, therefore, pointing them toward products they’ve already viewed will guide them back into the funnel.

The hypothesis: Increasing the browsability of the site by displaying recently viewed products to increase relevance for the visitor will encourage higher engagement and increased return visits, which will increase conversions.

Nick and the team tested a single variation against the Control homepage. The Control featured a “Recommended Products” section just below the hero section, displaying four of the client’s most popular product categories.

In our variation, we replaced this with a “Your Recently Viewed Products” section. We wanted to target those visitors who were returning to the site, presumably to continue in the purchasing process. The products displayed in this section were unique to each returning visitor.

Converter_Test
The Control (left-hand) versus our variation (right-hand), which highlighted “Your Recently Viewed Products”.

Our variation won, consistently outperforming the Control during this test. This client saw a 6.9% increase in order completions.

Bottom to top

When you’re segmenting your audience, don’t forget about the segment that floats at the bottom of the funnel. Instead of identifying the differences that characterize visitors coming to your site, why not work backwards?

Look at the behavioral differences that distinguish converters from non-converters and test ways to help non-converters mimic the behaviors of converters.

Have you noticed drastic behavioral differences between your visitors who convert and those who don’t convert? Do you tap into this particular segment when you plan tests? Tell us all about it in the comments!

The post The one segment you probably aren’t (but should be) looking at appeared first on WiderFunnel Conversion Optimization.

Continue reading: 

The one segment you probably aren’t (but should be) looking at

A Never-Ending Story On Ad-Blockers

Desperate times call for desperate measures. In attempts to fight back against the growing adoption of ad-blockers, many publishers and ad-dependent websites adopt all kinds of techniques from introducing “light” paywalls to limiting access to the site to fully blocking ad-blocker users from accessing the content altogether.
It seems a bit ironic that a website would send away potential customers that are taking measures to actually access the site faster, and read the content published on the site without annoying distractions.

More here:  

A Never-Ending Story On Ad-Blockers

Nobody Wants To Use Your Product


Every morning, designers wake up to happily work on their products, be they digital or physical, with an inner belief that people will want to use their products and will have a blast doing so. Perhaps that is a slight generalization; however, as designers, we tend to have a natural desire for each project we work on to be the best it can be, to be innovative and, most importantly, to make a difference.

Nobody Wants To Use Your Product

Here is a little revelation. People are not really into using products. Any time spent by a user operating an interface, twisting knobs, pulling levers or tapping buttons is time wasted. Rather, people are more interested in the end result and in obtaining that result in the quickest, least intrusive and most efficient manner possible. And these are two fundamentally different concepts — usage versus results — which, at the very least, differentiate good product design from poor product design or, on a smaller scale, a good feature from a bad one.

The post Nobody Wants To Use Your Product appeared first on Smashing Magazine.

Read More: 

Nobody Wants To Use Your Product

Decoupling HTML From CSS

For years, the Web standards community has talked about the separation of concerns. Separate your CSS from your JavaScript from your HTML. We all do that, right? CSS goes into its own file; JavaScript goes in another; HTML is left by itself, nice and clean.
CSS Zen Garden proved that we can alter a design into a myriad of permutations simply by changing the CSS. However, we’ve rarely seen the flip side of this — the side that is more likely to occur in a project: the HTML changes.

View original post here – 

Decoupling HTML From CSS

The Elements Of Navigation + 6 Design Guidelines

When users look for information, they have a goal and are on a mission. Even before you started to read this article, chances are you did because you either had the implicit goal of checking what’s new on Smashing Magazine, or had the explicit goal of finding information about “Navigation Design”. [Links checked February/11/2017]
After a couple of seconds of scanning this article, and maybe reading parts of the introduction, you may have started to ask yourself whether the information that you’re consuming at the moment is actually relevant to you—the user.

Read this article: 

The Elements Of Navigation + 6 Design Guidelines

Just another WordPress site