4 Tips in Designing a Retail Inventory Management App

4 Tips in Designing a Retail Inventory Management App

When designing a retail inventory management application, it’s crucial to do a lot of heavy lifting in the preliminary stages of design to ensure that the transition from the client’s old system to their new app is seamless, intuitive, and incorporates just what they need to get the job done right.

From concept to delivery, the retail inventory app design process requires research, attention to detail, inspiration, testing, and refining. By keeping the following tips in mind during the design process, you can be sure to deliver a quality app that your client and their employees will love.

Tip 1.) Do Your Homework on the Client’s Needs

Prior to diving into a design project, it’s important to ask the right questions in order to understand 1) why the business prioritized this project, 2) the process/tasks employees are being asked to do, and which parts are the most challenging, and 3) how the system (including APIs) works in order to design around limitations or suggest changes accordingly.

These questions are crucial, along with other obvious questions, like what equipment/device does the client foresee using, how many stores do they have, how many employees will be using this solution, who has admin privileges, and how will admin use differ from that of general employees?

This initial info-gathering stage is key in the design process because having the team and the stakeholders “in the know” is necessary when making a polished, efficient, and effective app that everyone is proud of.  

design_agile_shockoe

Tip 2.) Find out What the App Users Need 

Once you’re confident with the client-provided requirements data, the interview process should transition from the stakeholders to their employees. Sitting behind a screen, it can be easy to gloss over seemingly minor details, but those minor details can impact the people on the other end and affect their job performance daily.

By focusing on details such as how the user will input data to the app and how they will maneuver around in it, you will be able to design a new system that will be effective and intuitive for all users and will replace outdated systems that might require quirky shortcuts and workarounds.

Vital to this step is gathering client data, studying the data, and researching and implementing said research, all the while incorporating your interview results with the employees/users. If you don’t understand their procedures, keep the dialogue going until you understand their daily routine, in order to provide them with the solutions they’re looking for.

app-user-needs

Tip 3.) Create an Inspired, Intuitive Design

Once you have all the details worked out, start working out the app flow. Put the pen to the paper, the markers on the whiteboard, and let the heavy brainstorms pour inspired innovative ideas.

This process will require multiple iterations and failures so you can reach the holy grail of design solutions for your client. In order to achieve this level of design fruition, you will need to research design trends (Pinterest, Dribbble, Behance), your client’s app (if they have one), and their competitors’ apps (if they have them).

Expand your design horizon outside of your comfort zone. Don’t be satisfied with safe designs; mediocre designs don’t break any new ground or impress clients.

That being said, try not to reinvent the wheel either. It’s great to have inspiration, but it’s up to you to be innovative while also staying intuitive.

intuitive-design

Tip 4.) Test Your Design, and Redesign as Necessary

Now that you have shiny, impressive, and modern designs, it’s time to test. Your design has to exceed expectations. So, even though you’ve interviewed a variety of people, researched every corner of Google, and spent countless hours in Sketch, Xd, or your design app of choice, you still need to test the app out.

The testing results will likely incur some redesigns, as any good test would. It’s important to ensure that the user flow makes sense, which is why you’ll test your prototypes with the client’s employees.

Remember, these employees are the experts in their job field. They know what they need to complete their job successfully and what will make their day-to-day work routine more efficient. Listen to their every complaint, concern, and compliment.

Redesigns can be fun. They often make us rethink what we thought we knew or understood. This could be a eureka moment for a designer, their team, and possibly the client. At most, it should only require some simple, but effective, design tweaks in order for the user to know what’s what.

So tweak away, tighten it up, and bust out of your design bubble. Find the sweet spot everyone’s looking for and apply your groundbreaking ideas to your designs. Finally, make sure any, and I mean any, users will know how your designs work—intuitively.

test-your-design

Key Points to Remember

Be sure to keep these points in mind when designing an app for retail inventory solutions:

  • Listen: The stakeholders typically have a good idea of what they’re looking for.
  • Answer these essential questions:
    • Why does the business (client) want this app? Know their KPI (Very important!)
    • How does the system currently work? (APIs and integration)
    • What are the client’s current pain points? (This is where we can REALLY help, by improving on what doesn’t currently work.)
    • What works? (What do employees like about the current system?)
    • What type of equipment are you designing the app for? (What type of device will employees use to access the app? Will they need a sling or a harness if they’re unloading a truck?)
    • What is the client’s budget? (A necessary evil.)
  • Follow up. Have constant communication and keep everyone in the loop. Interview the client’s employees to make sure you’re including everything they need to do their job well.
  • Prototype your designs, and see what works and what might need to be tweaked or rethought to make the app intuitive and easy to use.
  • There’s always room for improving the design until you get it right.

Look Towards the Future

Once your super-powered retail inventory app is developed, there will be updates, which require continued communication between you and the client. It’s your job (and ours) to help clients succeed. When our clients are successful, so are we. Together, we can conquer the world—one app at a time.

Editor’s Note: 

If you’re interested in reading about our most recent work for a retailer, check out A.C. Moore Case Study and the Inventory Management App our team has created for this retailer’s team.

Watch the full Case Study Video for A.C. Moore below.

ac-moore-inventory-management-app-video

The Warehouse Management System of Tomorrow: Faster, Leaner, and Mobile

The Warehouse Management System of Tomorrow: Faster, Leaner, and Mobile

Imagine this: you show up at your place of work, look out onto the warehouse floor, and see all your employees hard at work making sure inventory is being stocked and orders are being fulfilled. But these are not your normal employees, instead, they are robots automatically and seamlessly performing the work previously assigned to countless humans.

Some warehouses are already adopting these technologies, and it won’t be long before others do as well. With the ubiquity of mobile and greater access to the latest technology, it’s not surprising to see more manufacturers incorporating emerging devices into their processes.

Warehouses once relied exclusively on paper for production orders, dispatch notifications, and as a means of managing asset and inventory. Fast forward to today and you’ll see an increasingly paperless industry. Warehouse Management System software, scanning solutions, and other applications are now in place to enable data to be entered directly into digital or cloud storage. This has reduced the number of errors caused by readability issues or lost paperwork, while also reducing the operating costs of the companies.

So how do warehouses become more efficient between the world of today and the future world of automation? Well, the transition is becoming increasingly achievable with all the evolving technology. The key is evaluating the current infrastructure and technology, coming up with a strategy based on key objectives, and starting to make the investment.

Over the last couple of years, we have been working with Arrow Electronics to do just that – improve efficiency through mobile solutions. When we first started working with Arrow, they had a WMS system in place but were using older technology that limited the efficiency of their employees. Shockoe created an overhauled WMS using mobile tablets, wireless handheld scanners, and a revamped user interface. The new process and interface allow operators greater flexibility and maneuverability, increasing pick speed efficiency. Supervisors can now make necessary decisions away from their desk through the mobile interface allowing them to review reports, manage inventory and processes, and communicate directly with the operators.

As we continue to grow our relationship with Arrow, we are exploring means to provide further functionality to operators and immersing them in the mobile experience. This will include wearable technology which enables operators to work hands-free and eliminate the need to bring a cart down an aisle.

As we move forward, other technology will be considered to improve the efficiency of the warehouse operations. For example:

Truly hands-free with Smart Glasses

How about integrating the core functionality of a smartphone into a pair of glasses? The main difference is the display technology: images are projected directly in front of the field of vision, freeing-up user’s hands for other tasks. When working in a warehouse, having free hands and ready access to information is hugely progressive for both ergonomics and efficiency. Using this kind of device in the picking process will ease the work for operators and can help increase picking performance. It is also a flexible solution to implement since it doesn’t need any other specific equipment in the warehouse.

Voice as a guide

Adding voice-guidance to different WMS functionalities can also increase the efficiency of warehouse operations. Instructions can now be heard rather than cumbersomely viewed. This can be integrated into both smart glasses or a traditional mobile app, further allowing the operators to function hands-free and increase focus on their tasks.

MR/AR: Layer instruction & Complete more Processes

Augmented and mixed reality ‘picking’ uses smart glasses to merge virtual images and information with an operator’s surrounding environment. The operator would wear the glasses, follow any on-screen instructions, and scan product barcodes all within the glasses’ display. The combination of real-world and virtual information provides speed and accuracy beyond previous warehouse picking technologies.

VR/AR: Immersive Training

Did you know only 40% of information is retained when people observe versus 90% when they experience it themselves? So, how about leveraging VR or AR to train employees so they can become productive quickly, while also improving quality of the work and reducing training costs? Using smart glasses, VR headsets, or other simulators allows both new and current employees to get immersed in the work to learn without having to shadow other employees. This keeps productivity high across the board as you don’t need to pull someone away from current work to train someone.

The state of warehouse management has evolved over time as companies continue to evolve to keep up with consumer demands. Fully automating systems will take time and money. Yet, with the ubiquity of mobile and existing WMS software, an affordable cutting-edge solution might not be so distant. By employing a combination of mobile solutions, smart glasses, AR/VR/MR, or voice, warehouses can become exponentially more productive — improving not just cost, but also overall quality and safety.

Note from Editor: 
With mobile technology, employees are no longer confined to their static cubicles, bulky PCs, and disorganized file cabinets. If you’d like to learn more about what it means to have a truly mobile workforce, check out this page.

Also, you can read about “A Mobile Workforce: What Customers Want” in our previous post.

Mobile Apps for the Supply Chain

Mobile Apps for the Supply Chain

Don’t Limit Yourself

While computing in the supply chain is nothing new, many of the existing systems and platforms are typically running on bulky and dated equipment, limiting the flexibility and efficiency of employees. This issue isn’t confined to one segment of the supply chain. Everyone from suppliers to retailers is often conducting day-to-day operations with outdated supply chain applications and hardware. With the ubiquity of mobile technology, introducing apps into the supply chain can be beneficial and seamless. Mobile supply chain apps can lead to improvements at every step, often in similar ways across segments. For example, inventory management apps allow suppliers to track their raw materials, manufacturers to decrease the time to manufacture and ship, and retailers to more effectively track their stock.

Companies frequently focus the majority of their mobile technology investment on consumer-facing apps, often at the expense of mobilizing their supply chain operations. Shockoe has partnered with several big box retailers, as their supply chain app developer, to create apps that support supply chain workforce and processes. The infographic, below, outlines examples of how these supply chain apps can support desired customer experiences by improving processes such as inventory management, production planning, material management, and resource planning processes, to name a few.

See The Potential

As a supply chain app developer, we work with our clients to help them gain insight into points along the supply chain that will benefit from mobile app investment in order to get customers their product faster, more efficiently, and more effectively. This leads to a better customer experience, which maximizes their existing investment in consumer-facing solutions and increases customer loyalty.

How Suppliers Benefit:

  • Accurate sourcing: track and distribute raw materials anytime, anywhere. Mobile apps connect manufacturers to the first step of the supply chain, the raw materials supplier.
  • Easier inventory control: inventory management with the tap of a finger. Warehouse management apps give you 24/7 control of inventory
  • Simplified logistics: order fulfillment that’s simple, intuitive, and on the go. Track the transit of materials from anywhere in the field.

How Manufacturers Benefit:

  • Faster production times: supply chain apps integrate with legacy systems to cut down on the overall production process, decreasing the time to manufacture and ship.
  • Recall/damage control: simplify field assessments and integrate data captured in the field from mobile apps with back office applications. The faster a customer complaint is resolved, the more likely customers are to become repeat customers.
  • Better final product: tighter quality control means better oversight. All of this amounts to a higher quality product.

How Distributors Benefit:

  • Improved warehouse management
  • Smarter communication
  • Increased “on-time” delivery

How Retailers Benefit:

  • Better stock management
  • More efficient front-line employees
  • Less shrinkage

How Consumers Benefit:

  • Faster shipments
  • Accurate order tracking
  • Great customer experience

Increase Your Bottom Line

Partnering with an experienced supply chain app developer to digitize the supply chain means organizations can have the best of both worlds by increasing efficiency to decrease costs and making sure customers become ambassadors for the brand, leading to repeat business and long-term revenue growth.

 

Apps for the Supply Chain

 

Asset/Inventory Management Apps in Record Time with Flutter

Asset/Inventory Management Apps in Record Time with Flutter

Shockoe specializes in utilizing tools which can most efficiently provide a beautiful experience for a given project. We have a history with cross-platform frameworks, as they can often quicken the development period for a mobile app considerably. Many of our projects were historically built on Titanium, and a few more recently were undertaken with React-Native.

When Flutter was announced, we knew we had to keep a close eye on it, and we were eager for it to reach the point where it was mature enough to build a robust production app. The results were astounding. Not only does it ease many of development pains present in other cross-platform frameworks, it also gives you beautiful UI out of the box, and extraordinary speed as it is blazingly fast to develop. In fact, the entirety of the development you will see later in this post was completed single-handedly in a matter of hours!

Flutter for Inventory Management Apps

At Shockoe, we have a point of creating great inventory/asset apps the help manage resources, assets, and inventory at a number of large-scale companies. A few reasons why Flutter has been a particularly great fit for developing these kinds of apps include:

  • List Convenience: Turning a raw data list of assets and inventory into an actual list laid out on screen couldn’t be easier. It can be accomplished in a handful of lines of code.
  • Beautiful by Default: Apps in this category have a heavy focus on functionality. A framework which looks good in its most basic state lets you focus on the utility and devote as much time as you decide to enhance UI and delivering the right content.
  • List Performance: Flutter renders every pixel on the screen itself, allowing for a performance unparalleled by other frameworks. It touts its ability to maintain 60fps, and scrolling is buttery-smooth even on massive lists.
  • Empty/Loading State Simplicity: Most screens will be heavily data-driven. In some environments, displaying states like waiting for an API response or failing to connect can become extremely cumbersome. Flutter makes it easy to build a UI which reacts to these in-between moments gracefully.
  • Object-Oriented: Unlike Titanium and React-Native, which use Javascript, Flutter apps are written in Dart. This offers a number of benefits, like the lessened runtime error rate of strongly typed languages. The reason why it is perfect for this case is that Object-Oriented design allows for easy 1:1 mappings between real objects and their representations in code. Are you a retailer which specializes in shoes? Well, chances are your app is going to have a class Shoe and an instance of it is going to tell you everything you need to know about that specific shoe.

In this post, we’re going to take a look at building an inventory management app and not just the Flutter bit. This post includes a fully functioning Node.js backend as well — ensuring you successfully deliver your message and content to your users.

Note: This will not be a step-by-step guide, as that would be difficult to digest at a high level. Instead, we will look at each piece and break down the important components.

Inventory App Features We’ll be Building

Below is everything entailed in going from an unstarted project to a functioning application pulling real data. Here is what we will end up with:

inventory app example pulling real data

Let’s dive in!

Basis

We will use the example of a library — yes, the variety filled with a book! A library is essentially a warehouse filled with inventory (in this case, books). For many businesses an inventory application, at its core, would support browsing and tracking items. In the context of a library, those functionalities manifest themselves in the following ways:

  • Browsing
    • view the full catalog
    • search for a specific title
    • view information about a specific title
  • Tracking
    • see a title’s availability
    • check out a copy
    • return a copy

Our app will handle all of the above.

Setup

Database
MongoDB will be used to store the data. There is no special setup required, we just load all the items into a collection and later run the Node.js server on the same machine to leverage Mongo’s already exposed localhost connection.

Most likely, when building an app of this type, it will be used to access an existing dataset. The data in this example will be a subset of the most popular titles on Project Gutenberg supplemented with Wikipedia details.

Backend (API)
For our server, we will be using hapi with a few smaller dependencies like the official Node.js MongoDB drive and boom for error handling.

Once hapi is installed, we must create our startup file. This will get the server up and running to fulfill requests. Let’s use index.js.

'use strict';

const Hapi = require('hapi');
const routes = require('./routes');

const server = Hapi.server({
port: 3000
});

server.route(routes.allRoutes);

const init = async () => {

await server.start();
console.log(`Server running at: ${server.info.uri}`);
};

process.on('unhandledRejection', (err) => {

console.log(err);
process.exit(1);
});

init();

Tiny, right? Hapi requires very little boilerplate. The majority of this is ripped right from hapi’s Getting Started guide. Besides removing the host property on the server configuration object in order to fall-back to the machines hostname, the only custom line is as follows:

server.route(routes.allRoutes);

 

This line imports and registers all of the endpoints we define in our second, and final, file: routes.js. We separate these so that the server configuration doesn’t get drowned out by the much larger endpoint definitions. In a more complex app, we would likely want multiple files which logically group endpoints into smaller buckets. Here is routes.js with an example endpoint. Its only job is to export an array of configuration objects.

const Boom = require('boom');

exports.allRoutes = [
  {
    method: 'GET',
    path: '/',
    handler: async (request, h) => {
      return 'Hello world';
    }
  }
];

 

Flutter
Enter Flutter! When creating a new Flutter project through IntelliJ, a main.dart file is created for a basic sample app which implements a counter. This is helpful when learning, but we need to rip out some of that starter code. Here is a single page app which we can use as a starting point.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Library',
      theme: ThemeData(
        primarySwatch: Colors.deepOrange,
      ),
      home: CatalogPage(),
    );
  }
}

class CatalogPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Catalog'),
      ),
      body: Center(
        child: Text('List of books'),
      ),
    );
  }
}

 

flutterSetup

 

 

 

 

 

 

 

 

 

 

 

 

 

Catalog

Backend
Now that we’re set up, let’s start serving up data. We replace the example endpoint we defined before with one which returns the full list of books in the database.

const MongoClient = require('mongodb').MongoClient;
const Boom = require('boom');

exports.allRoutes = [
  {
    method: 'GET',
    path: '/bookList',
    handler: async (request, h) => {
      let client;
      try {
        client = await MongoClient.connect('mongodb://localhost:27017');
        let books = client.db('inventory').collection('books');

        // fetch all books
        return await books.find({},
          {
            projection : {
              _id: 0,
              id: 1,
              title: 1,
              authors : 1,
            }
          }
        ).toArray();
      } catch (e) {
        console.error(e.message);
        return Boom.internal(e);
      } finally {
        if (client && client.close){
          client.close();
        }
      }
    }
  }
];

 

You may notice async/await syntax. As it is available in both recent Node.js versions and Dart, we will use it throughout the backend and the app.

There isn’t too much going on here. We connect to MongoDB, specifically the collection books in the database inventory, and run a find query with an empty filter object (first argument) so that all records are pulled. For cleanliness of data, we project only the properties of a book which we would be interested in when listing them en masse.

Flutter
The first thing we need to define is the representation of a book. We will go ahead and include all fields we need to be known for a book, even though only a few of them will be populated from the results of the /bookList endpoint.

class Book {
  final String id;
  final String title;
  final List<String> authors;
  final String releaseDate;
  final String description;
  final int totalCopies;
  final int availableCopies;

  /// Creates a Book instance out of JSON received from the API.
  Book.fromJson(Map<String, dynamic> json)
      : id = json['id'],
        title = json['title'],
        releaseDate = json['releaseDate'],
        description = json['description'],
        totalCopies = json['totalCopies'],
        availableCopies = json['availableCopies'],
        authors = json['authors'].retype<String>();
}

 

We will use the “Serializing JSON inside model classes” strategy shown in Flutter’s JSON and serialization guide.

CatalogPage is a Stateless widget, because the full screen including the appbar doesn’t need to be re-rendered in the future, just the content. For that, we create a Stateful Widget, called CatalogList, which we will place in the body of CatalogPage. To keep this example concise, network requests will be made directly from widgets. It is better to practice to split them out into a non-UI library. Here is Catalog with basic display functionality complete followed by a breakdown below.

/// The list of books.
class CatalogList extends StatefulWidget {
  @override
  _CatalogListState createState() => _CatalogListState();
}

class _CatalogListState extends State<CatalogList> {
  /// All books in the catalog.
  List<Book> books;

  /// Books currently being displayed in the list.
  List<Book> displayedBooks;

  /// Kicks off API fetch on creation.
  _CatalogListState() {
    _fetchBookList();
  }

  /// Fetches the list of books and updates state.
  void _fetchBookList() async {
    http.Response response = await http.get('http://<API location>/bookList');
    List<Map<String, dynamic>> newBooksRaw =
        json.decode(response.body).retype<Map<String, dynamic>>();
    List<Book> newBooks =
        newBooksRaw.map((bookData) => Book.fromJson(bookData)).toList();
    setState(() {
      books = newBooks;
      displayedBooks = books;
    });
  }

  @override
  Widget build(BuildContext context) {
    return displayedBooks != null
        ? Column(
            children: <Widget>[
              new Expanded(
                child: Padding(
                  padding: const EdgeInsets.all(8.0),
                  child: ListView.builder(
                    itemBuilder: (BuildContext context, int index) => Card(
                          elevation: 2.0,
                          child: ListTile(
                            title: Text(
                              displayedBooks[index].title,
                              maxLines: 2,
                              overflow: TextOverflow.ellipsis,
                            ),
                            subtitle:
                                Text(displayedBooks[index].authors.join(' | ')),
                          ),
                        ),
                    itemCount: displayedBooks.length,
                  ),
                ),
              ),
            ],
          )
        : Center(child: CircularProgressIndicator());
  }
}

 

basicCatalog

 

 

 

 

 

 

 

 

 

 

 

 

 

Fetch Data
When the CatalogList widget is created, we immediately want to fetch the data on all books from the backend. We go ahead and create two list references, one for all the data downloaded and one for data currently displayed, as we know search functionality is coming and we won’t always be displaying the full catalog on screen. When data is first downloaded, though, these will be the same. We take advantage of the fromJSON serialization constructor we created to convert the backend’s JSON response into a list of formed Book objects in one list mapping call.

/// All books in the catalog.
List<Book> books;

/// Books currently being displayed in the list.
List<Book> displayedBooks;

/// Kicks off API fetch on creation.
_CatalogListState() {
  _fetchBookList();
}

/// Fetches the list of books and updates state.
void _fetchBookList() async {
  http.Response response = await http.get('http://<API location>/bookList');
  List<Map<String, dynamic>> newBooksRaw =
      json.decode(response.body).retype<Map<String, dynamic>>();
  List<Book> newBooks =
      newBooksRaw.map((bookData) => Book.fromJson(bookData)).toList();
  setState(() {
    books = newBooks;
    displayedBooks = books;
  });
}

 

Try/catch around the async body of _fetchBookList is omitted for readability. Make sure to catch possible exceptions/errors in production.

Build a List
Here is where we see Flutter start to shine. To convert this list of Book data into a rendered list on the screen, all we have to do is write an itemBuilder function which returns what a given item in the list will look like, then pass in the list of data and it’s length. We use a Material Design Card containing a ListTile- a prebuilt widget which displays a title and subtitle (and optionally additional inner widgets).

child: ListView.builder(
  itemBuilder: (BuildContext context, int index) => Card(
        elevation: 2.0,
        child: ListTile(
          title: Text(
            displayedBooks[index].title,
            maxLines: 2,
            overflow: TextOverflow.ellipsis,
          ),
          subtitle:
              Text(displayedBooks[index].authors.join(' | ')),
        ),
      ),
  itemCount: displayedBooks.length,
),

 

styledListItems

 

 

 

 

 

 

 

That’s all it takes to build a ListView which is ready for production. It will lazily render new rows as they are scrolled into view, gracefully handle changes to the list of Books, adapt scrolling behavior to OS, and perform fantastically.

Much of the above is styling as well. We could get something functional in half as many lines.

child: ListView.builder(
  itemBuilder: (BuildContext context, int index) => ListTile(
        title: Text(displayedBooks[index].title),
        subtitle:
            Text(displayedBooks[index].authors.join(' | ')),
      ),
  itemCount: displayedBooks.length,
),

 

unstyledListItems

 

 

 

 

 

Handle Loading State
When the Catalog List is created, the data list which our ListView is populated from, displayedBooks, is null.

List<Book> displayedBooks;

 

Once the data fetch is complete, that variable will point to a valid List.

setState(() {
  books = newBooks;
  displayedBooks = books;
});

 

Once this occurs, the ListView can start rendering rows. In the meantime, we need to render something different. If handling moments like these require a lot of development effort, it can feel counterproductive to tackle them right out of the gate while true functionality is still being worked out. This can lead to polish/UX tasks being put on the afterburner. With Flutter, it’s easy to handle loading during our first pass at the screen. We just use a ternary expression in the build function to describe an alternate visual while displayedBooks is still null.

@override
Widget build(BuildContext context) {
  return displayedBooks != null
      ? Column(
          // ...rest of widget hierarchy for loaded state
        )
      : Center(child: CircularProgressIndicator());
}

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Search
Supporting search requires two main changes.

  1. Add a search input field which fires an event when it changes
  2. Add a search function to filter the displayed list when the search event is fired

An input field which fires an event is achieved with the combination of TextField and TextEditingController

/// The controller to keep track of search field content and changes.
final TextEditingController searchController = TextEditingController();
child: TextField(
  decoration: InputDecoration(hintText: 'Search for titles...'),
  controller: searchController,
),

 

With the search bar in place, we can register a listener when the CatalogList is created to fire the function which will filter the full book list down to results to be displayed and update state. If the search text becomes empty, the list is set back to the full catalog.

/// Kicks off API fetch on creation.
_CatalogListState() {
  _fetchBookList();
  searchController.addListener(_search);
}
/// Performs a case insensitive search.
void _search() {
  if (searchController.text == '') {
    setState(() {
      displayedBooks = books;
    });
  } else {
    List<Book> filteredBooks = books
        .where((book) => book.title
            .toLowerCase()
            .contains(searchController.text.toLowerCase()))
        .toList();
    setState(() {
      displayedBooks = filteredBooks;
    });
  }
}

 

 

Navigation
The Catalog page is complete, and now we need to be able to take a deeper look at an individual item. The next page will be called DetailPage, so we’ll rig up each item in the list to move forward to the respective book’s details. Conveniently, ListTile has builtin touch handling, so we can just add a single property

onTap: () {
  Navigator.of(context).push(MaterialPageRoute(
      builder: (BuildContext context) {
    return DetailPage(displayedBooks[index].id);
  }));
}),

 

We only pass the id instead of the Book instance, since we will be fetching the book’s most up-to-date full data from the backend when loading DetailPage anyways.

Details

Backend
We add a new endpoint configuration object onto allRoutes to return full details of a title. It is nearly identical to the full listing except we switch to findOne, add a filter for an id passed from the app, and project additional fields. We also call out to a function to calculate the number of copies available, but we will wait to see that in the Tracking section.

{
  method: 'GET',
  path: '/book',
  handler: async (request, h) => {
    let client;
    try {
      client = await MongoClient.connect('mongodb://localhost:27017');
      let books = client.db('inventory').collection('books');

      // fetch matching book
      let book = await books.findOne(
        {
          id: request.query.id
        },
        {
          projection : {
            _id: 0,
            id: 1,
            title: 1,
            authors : 1,
            releaseDate : 1,
            description: 1,
            totalCopies: 1,
            checkedOutTo: 1
          }
        }
      );
      setAvailableCopies(book);
      return book;
    } catch (e) {
      console.error(e.message);
      return Boom.internal(e);
    } finally {
      if (client && client.close){
        client.close();
      }
    }
  }
},

 

 

Flutter
The basic DetailPage widget is a bit larger, but most of the functionality will look familiar from CatalogList. This time we make DetailPage itself the Stateful Widget, since we want to allow the AppBar to update with the book’s title once data is loaded.

/// The screen which displays the full details of a given book.
class DetailPage extends StatefulWidget {
  final String bookId;

  DetailPage(this.bookId);

  @override
  _DetailPageState createState() => _DetailPageState();
}

class _DetailPageState extends State<DetailPage> {
  /// The full book data.
  Book book;

  /// Kicks off API fetch on creation.
  _DetailPageState() {
    _fetchBookDetails();
  }

  /// Fetches the books details and updates state.
  void _fetchBookDetails() async {
    http.Response response =
        await http.get('http://<API location>/book?id=${widget.bookId}');
    Map<String, dynamic> newBookRaw = json.decode(response.body);
    Book newBook = Book.fromJson(newBookRaw);
    setState(() {
      book = newBook;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(book?.title ?? ''),
      ),
      body: book != null
          ? new Center(
              child: new SingleChildScrollView(
                child: Padding(
                  padding: const EdgeInsets.all(20.0),
                  child: Card(
                    elevation: 5.0,
                    child: Center(
                        child: Padding(
                      padding: const EdgeInsets.fromLTRB(24.0, 0.0, 24.0, 24.0),
                      child: Column(
                        mainAxisAlignment: MainAxisAlignment.spaceEvenly,
                        crossAxisAlignment: CrossAxisAlignment.center,
                        children: <Widget>[
                          _BodySection('Author', book.authors.join('\n')),
                          _BodySection(
                              'Release Data', book.releaseDate ?? 'N/A'),
                          _BodySection('Description', book.description),
                        ],
                      ),
                    )),
                  ),
                ),
              ),
            )
          : Center(child: CircularProgressIndicator()),
    );
  }
}

class _BodySection extends StatelessWidget {
  final String title;
  final String content;

  _BodySection(this.title, this.content);

  @override
  Widget build(BuildContext context) {
    return new Padding(
      padding: const EdgeInsets.only(top: 24.0),
      child: Column(
        crossAxisAlignment: CrossAxisAlignment.center,
        children: <Widget>[
          Text(title, style: Theme.of(context).textTheme.title),
          Text(content, style: TextStyle(color: Colors.grey[700]))
        ],
      ),
    );
  }
}

 

We could have fetched all these details back on the CatalogPage and simply passed them through the be displayed on the DetailPage. The reason we opt for pulling the data fresh is to ensure we have the very latest details on an item when we view it. In this example, it’s unlikely that any of the fields we are displaying would change frequently. In other industries, however, a DetailPage might be displaying volatile data. These considerations especially come into play when we add our next section.

Tracking

We will support two operations on books: checking out and returning. These operations will drive the number of copies available to be checked out by other users as well. When a user checks a book out, they are grabbing it from the library and marking one of the copies as taken by them. When they return a copy, they are again providing their name and stating that they have placed the copy back into the library. In this example, no unique identifiers are used for individual copies, however, it would be a small change to add an additional field to the app and modify the backend to accept a copy identifier (potentially a barcode).

The three fields in the database driving these interactions will be:

  • totalCopies – total number of copies of a title which the library has in circulation
  • checkedOutTo – array of names to which copies are checked out
    along with one virtual field calculated at request time
  • availableCopies – number of copies in the library available for checkout (total copies – checked out copies)

 

Backend

We add two endpoint configuration objects. /checkOutBook will push a name onto the checkedOutTo array, and /returnBook will splice a name out of it.

{
  method: 'POST',
  path: '/checkOutBook',
  handler: async (request, h) => {
    let client;
    try {
      client = await MongoClient.connect('mongodb://localhost:27017');
      let books = client.db('inventory').collection('books');

      // update book data with name added to check out list
      let bookResult = await books.findOneAndUpdate(
        {
          id: request.payload.id
        },
        {
          $push : { checkedOutTo : request.payload.name }
        },
        {
          projection : {
            _id: 0,
            id: 1,
            title: 1,
            authors : 1,
            releaseDate : 1,
            description: 1,
            totalCopies: 1,
            checkedOutTo: 1
          },
          returnOriginal : false
        }
      );
      let book = bookResult.value;
      setAvailableCopies(book);
      return book;
    } catch (e) {
      console.error(e.message);
      return Boom.internal(e);
    } finally {
      if (client && client.close){
        client.close();
      }
    }
  }
},
{
  method: 'POST',
  path: '/returnBook',
  handler: async (request, h) => {
    let client;
    try {
      client = await MongoClient.connect('mongodb://localhost:27017');
      let books = client.db('inventory').collection('books');

      // get current list of checked out copies
      let currentBookData = await books.findOne(
        {
          id: request.payload.id
        }
      );
      let nameIndex = currentBookData.checkedOutTo.indexOf(request.payload.name);
      if (nameIndex !== -1){
        currentBookData.checkedOutTo.splice(nameIndex, 1);
      }

      // update book data with name removed from check out list
      let bookResult = await books.findOneAndUpdate(
        {
          id: request.payload.id
        },
        {
          $set : { checkedOutTo : currentBookData.checkedOutTo }
        },
        {
          projection : {
            _id: 0,
            id: 1,
            title: 1,
            authors : 1,
            releaseDate : 1,
            description: 1,
            totalCopies: 1,
            checkedOutTo: 1
          },
          returnOriginal : false
        }
      );
      let book = bookResult.value;
      setAvailableCopies(book);
      return book;
    } catch (e) {
      console.error(e.message);
      return Boom.internal(e);
    } finally {
      if (client && client.close){
        client.close();
      }
    }
  }
}

 

We also add a quick helper method to routes.js to calculate available copies.

function setAvailableCopies(book){
  book.availableCopies = book.totalCopies - (book.checkedOutTo ? book.checkedOutTo.length : 0);
}

 

 

Flutter
Beneath the other body sections, we add availability details and a small form for checkout/return. Since both actions require the same info, they can share an input box.

_BodySection('Available Copies',
    '${book.availableCopies} / ${book.totalCopies}'),
Column(
  children: <Widget>[
    TextField(
      decoration:
          InputDecoration(hintText: 'Enter name'),
      controller: nameController,
    ),
    new Padding(
      padding: const EdgeInsets.only(top: 16.0),
      child: new Row(
        mainAxisAlignment:
            MainAxisAlignment.spaceEvenly,
        children: <Widget>[
          RaisedButton(
            child: Text('Check Out!'),
            onPressed: fieldHasContent &&
                    book.availableCopies > 0
                ? _checkOut
                : null,
          ),
          RaisedButton(
            child: Text('Return'),
            onPressed:
                fieldHasContent ? _return : null,
          ),
        ],
      ),
    )
  ],
)

 

 

detailsDisableddetailsEnabled

 

These buttons call functions to pass the current book id and entered a name to the backend, and will update state with the new version of book details returned. This ensures that the available copy count will stay in sync with actions performed.

Each button is conditionally disabled by passing null to its onPressed property. Both buttons are disabled by the fieldHasContent flag which is set when the name input field is empty, and the check out button is additionally disabled when there are no available copies.

We have a functional, performant, aesthetically pleasing app with associated backend all in ~500 lines of code. Creating a solution for Asset/Inventory Management has never been easier, and Flutter continues to improve daily. Don’t let it’s “beta” tag fool you, Flutter is production ready. In fact, we just built a production Inventory Management application for Belden Brick, so that the brick distributors they work with can access browse their inventory, search products, view product images, order samples, and more!

Below you will find the full files from this demo.

Flutter: https://bitbucket.org/snippets/shockoe/7eMxEq
Hapi: https://bitbucket.org/snippets/shockoe/ne8jR6

 

 

Related post:

Three Reasons FLutter is a Viable Cross-Platform Framework
Google Flutter goes Beta at #MWC18

Event Recap: Southeastern Credit Union Conference

Event Recap: Southeastern Credit Union Conference

 

Mobile Apps at SCUCE

Last week we had the pleasure of attending the Southeast CU Conference & Expo. SCUCE is one of the largest credit union conferences in the country and is a great opportunity to interact with and exchange innovative ideas with credit union leaders from across the country. One of the main goals of this annual conference is to discuss the latest technologies, applications, and resources available to credit unions to improve their operations and efficiencies and better serve their members. At Shockoe, we are committed to innovation through mobile technology and customer-centric solutions, so we were excited to participate in this event and share our experience developing the mobile app for Virginia Credit Union.

 

Why is mobile technology for credit unions now more important than ever?

There is no question: mobile technology has become as ubiquitous as the wallet in one’s pocket or purse. With 95% of Americans carrying a cell phone (77% of which are smartphones), credit unions should be feeling the pressure to deliver great app experiences to their customers.

According to the BBC, in 2011, 22 million UK adults turned to their cell phones to manage their finances, and this number is expected to rise to as many as 35 million by 2023 — a whopping total of 73% of the country’s population.

Here in 2018, Gen-X is increasingly impacting the direction of the U.S. workforce. More dollars are being invested with financial institutions, and younger users are looking to maintain greater oversight of their finances in the way they know best — mobile interfaces. In fact, The CACI estimates that by 2019 mobile will overtake traditional online banking. A shockingly rapid change since 2013 when approximately only 50% of online users opted for mobile as their platform of choice versus web.

 

On the side of change

In addition to rethinking their IT strategies, Credit Unions need to prepare for a shift operational strategies as well. Branches will play a decreasingly relevant role in money management for the active workforce — money that could be shifted to embracing security, IT infrastructure, and mobile strategy that keeps banking operations lean and effective.

It’s clear that today’s digital-centric credit union consumers have higher expectations of their institutional providers. To appeal to these consumers, businesses will need to find innovative approaches to digital customer engagement. Custom mobile apps allow for a tailored, personalized, customer-centric experience that is unique to the brand. Pair this with customized employee productivity apps, and the entire operation works seamlessly to meet customer needs and build brand loyalty. The credit unions that are able to adopt this “outside-the-box” thinking will be more likely to succeed in this new, highly competitive consumer landscape.

 

How can Shockoe help your credit union?

In working with a local credit union, Virginia Credit Union, (one of the 55 largest Credit Unions in the country), we’ve conducted significant discovery to determine what members expect out of their banking app. VACU approached us to help their customers integrate a credit card management option and improve their overall mobile application. VACU was using Fiserv as their core banking system and quickly realized that they were limited in what they could do with their mobile technology. We learned at SCUCE that this is a very common theme at most credit unions. As credit unions outgrow the “out of the box” solution, they search for a more tailored way to connect with their members to uphold customer loyalty and provide a seamless mobile banking experience. That’s where Shockoe comes in. We augment your development teams and partner together with your core banking system to provide you with a custom app carefully designed to fit your members’ needs.

Our connections at SCUCE confirmed our assertions about the importance of custom mobile apps, and we’d love to continue to share our knowledge and expertise with the greater credit union community. Whether it’s helping with API strategy, development, security, or UX/UI design – we’re here to help find innovative approaches to attracting and retaining customers and improving the day-to-day employee experience. At Shockoe, we strongly believe that the credit unions that embrace custom mobile apps will have customers that are more engaged and more loyal, allowing these credit unions to thrive in a highly competitive environment. If you’re interested in exploring how custom apps might be able to help your credit union, give us a call to chat about how we can help!

4 Creative Ways Mobile can Keep Your Supply Chain on Track

4 Creative Ways Mobile can Keep Your Supply Chain on Track

Mobile devices are everywhere. Every aspect of the supply chain, from the supplier to the consumer, has been impacted by mobile technology. There is a good chance that you are already using some type of mobile supply chain application, but is your mobile strategy keeping up with the needs of your operation?

Not only is mobile hardware changing quickly, with new phones being released constantly, but the software that runs on these devices is also changing. Device manufacturers are continuing to add more and more features into the operating system of mobile devices as well as giving developers the ability to quickly take advantage of these new features in their mobile apps. In addition to the devices and software improvements, manufacturers have also been producing rugged cases for mobile devices that add superior durability while still being able to take advantage of the latest mobile technology and features.

Barcode Scanners Increase App Adoptability 

While barcode scanners have been used with mobile apps for a very long time, there have also been many hardware and software improvements that have increased both reliability and ease of use. A good scanner can make the difference in the adoptability of your app and can make your business more efficient from source to customer. Reducing the time it takes to actually scan an item and adding support for many more barcode types can make tasks like inventory and asset management much more efficient. It complements voice features well by allowing identification of products in environments where speech recognition might not work well.

Related: See how we added product scanning to improve warehouse inventory count and identify packages at delivery checkpoints for AC Moore

Speech Recognition Tailored To Your Product Lines

Voice and speech recognition have probably have made very rapid advancements in the past few years. All the major players including Apple, Google, Amazon, Microsoft, and Samsung, have worked on optimizing and perfecting the ability to recognize and process speech. Not only will you find it on mobile devices, but this past year has seen a large adoption of devices such as Amazon’s stand-alone Echo and Dot products. What used to be a novelty years ago has now transformed into a valuable feature available on almost all modern mobile devices. Speech recognition is able to easily complement technologies like barcode scanning in areas such as inventory management. It also has the flexibility of being as adjustable and powerful as you need by tying a recognized vocabulary with data from suppliers, transportation, sales, and consumers.

  • Using voice to document quality control inspections
  • Improving safety by not requiring workers to take eyes off equipment and instead use voice to enter/read data

GPS

GPS technology has also improved over the years giving mobile devices much quicker and more precise location information. While traditional mobile uses of GPS like navigation are quite mainstream, features such as geofencing are not as widespread. Geofencing creates a virtual geographic boundary that mobile software can react to. It can trigger a check in when a truck arrives with a shipment or optimize and adjust workflows based on estimated times of arrival. When combined with a smart mobile app, it can also give receiving terminals detailed information about drivers and shipments (eliminating possible paperwork) as well as giving feedback back to drivers about possible gate changes or wait times.

Supply Chain Case Study: See how changes to truck routing and package tracking improved routing and fuel efficiency for JB Hunt.

Beacons

With the introduction of Bluetooth® Low Energy (BLE) beacons, companies have been able to improve the logistics of their business in a much more efficient (and affordable) way than what was delivered with RFID. Early adoption of beacons was often used for indoor navigation, where GPS signal was unreliable. Shockoe has tackled this through a great personalized tour experience app with Anheuser-Busch. Uses have expanded to allow workers to efficiently navigate and locate items in storage, as well as being able to give a customer the ability to find the product they are looking for in a retail store. In addition to location proximity, beacons can also be fitted with additional sensors for light, humidity, and temperature; which expands their many uses to areas such as storage and transportation. A beacons low cost, enhanced battery lifetime, and the fact that they can be used with mobile devices (bypassing the need for specialized equipment), makes them particularly ideal for supply chain operations.

  • Alert personnel that humidity levels for monitored goods are above acceptable range and direct them to the location using their mobile device
  • Navigate grocery customers looking for a certain product to the correct aisle for the store

Mobile technologies are being used in all aspects of supply chain management from manufacturing to the consumer. At Shockoe, we are building smart mobile apps that leverage the latest features available. We work to give suppliers, truck drivers, dispatchers, receivers, retail stores, and customers real-time insights and collaboration using an app they love. 

Related post: 4 Tips in Designing a Retail Inventory Management App 

 

Why We’re Rebranding: a Letter from Our CEO

Why We’re Rebranding: a Letter from Our CEO

Hello from the world of Shockoe!

As some of you might have noticed over the last few days, Shockoe is sporting a brand new logo. It’s an exciting era for our company — our steady growth has brought new clients, new teammates, and pushed us into our larger digs in Scott’s Addition. It’s a great time for Shockoe!

You’ll see it’s not just our logo that is changing. We’ve changed our website, our social media, our messaging, and our focus to better reflect the way we help our clients succeed. What we’re saying should not sound unfamiliar to those who have worked with us. Our mission is only a refined version of what we have always known well about ourselves: we make quality apps that make users lives measurably better. In short, we’re Shockoe: we’re mobile by design.

So what’s changed?
Actually, not much. We’re bigger and better — our consulting-focused approach to developing apps remains, but is now a thriving team of developers, strategist, and designers. We have 35+ talented individuals and a growing client portfolio that we can be proud of. It’s truly our growth that has helped us realize our focus and expand the breadth of expertise that Shockoe truly represents.

From grocery store apps in the southeast to managing herd health in Canada — it’s felt like we do a bit of almost everything. That said, we have seen a few trends surface, and began to recognize we are particularly fantastic in a few different areas of mobile development. It’s what we’re calling our “pillars,” and what is ultimately the driving force behind the utility apps we create. What are these pillars? I’m glad you asked!

If you want to learn more about what each one means, I encourage you to visit our new website where you can read more on each pillar and read supporting case studies. Additionally, our latest three blog posts take a leap into the various pillars as we aim to push thought leadership that helps companies bring mobile apps to more processes, internal operations, and customer loyalty strategies. I encourage you to hop in and check things out.

We’re incredibly proud of the work that we do at Shockoe and thankful for the employees, the partnerships, and clients that have accompanied us in our growth. We owe this rebrand to all of you.

As always, if you have any questions, please don’t hesitate to reach out! Until then, keep an eye on Shockoe as we continue our growth and continue our campaign to be the best damn mobile shop around.

Sincerely,

edwin huertas signature

 

Edwin Huertas, CEO

A Mobile Workforce: What Customers Want

A Mobile Workforce: What Customers Want

Preface with a confession

Full disclosure: I am not a developer nor a designer — I’ve been in business ops for most of my professional career. That said, I’ll give myself a dose of credit: I’ve been in tech for years, start-ups and well-established alike. During that time I’ve seen that when it comes to mobile, one thing is consistently fueling a successful app — whether aimed at mobilizing a workforce or driving loyal customers back, apps must always be ready to provide utility in a moment of need. No exceptions.

When I truly needed mobile

This morning I woke up at 5 to the sound of torrential rain. While usually, I would dig myself deeper into my blankets, today it forced me out of bed at a much earlier hour. As it turns out, the night before, my wife detected some water coming into the basement, and I had a feeling it was not going to be a pretty sight downstairs.

I grabbed my phone to kick the lights on around the house. That’s when I noticed my phone was at 75% charge. Strange. It was vexing enough at such an early hour, that after swiping around for a few tired seconds, I forgot to turn the lights on.

I stubbornly walked in the dark and guided myself through the house by carefully feeling out the usual milestones — edge of the bed, door frame, banister, and finally the kitchen light switch. “Damn!” The power was out, and now I had a soaked basement and no light to resolve it.

Be the tool customers want when things fall apart

When things start failing at home, people like myself try to find help in the quickest, cheapest, and most accessible solution possible. For the water, it took shovels, mops, and wheelbarrows. As for the power outage, I had to go through a web-portal, find a billing statement to get an account number, and finally after going through some more personal identification prompts, five minutes later, I was reassured to see a team had been dispatched to fix the problem.

Keeping demanding customers like myself pleased takes some finesse. While I have to give props to my utility company for giving me a five-minute solution, the rising water was not exactly being resolved as I was searching for web-access.

Going mobile is tricky but very doable

Deploying the kinds of mobile management tools that customers crave sometimes go hand-and-hand with the tools that can enable a workforce to act faster, give prompter updates, and resolve more issues in less time. Yet, if these tools don’t exist, it’s alright. Rome wasn’t built in a day after all.

At Shockoe, we’ve done everything from overhauling pen & paper methods and building mobile ecosystems from scratch, all the way to optimizing legacy systems and tapping into API’s to deploy better user experiences. That said, we believe there is a right way to move from antiquated systems, and a measured means of building out tools that can improve your overall service, empower your workforce, and ultimately give customers with flooded basements, the 30-second solution they truly needed.

Step one: Low Investment High Return

If you’re starting from scratch, start internally. Typically your team will be more forgiving than your customers. Figure out what information has been missing as technicians work in the field to complete tickets, receive orders, or communicate with HQ. Regardless of what it is, keep your vision clear, uncomplicated, and unobstructed. Most importantly, keep your metrics measurable and your data visible in a way to demonstrates efficacy to your deployment.

Here are a few things we’ve seen as a valuable step one for Mobile Workforce applications:

  1. Route Mapping: Optimize the travel path between stops by providing real-time directions and automatically tracking time at each stop.
  2. Messaging and Feedback systems: Enable technicians to send notes, photos, and videos back to supervisors or other technicians for feedback, advice, and training.
  3. Repair/Service Supplies: Enable technicians to keep track of inventory and supplies riding with them on the truck. When technicians use items, build an app that keeps track of how much. And when supplies, run low, have the system push a notification (I encourage reading our node.js blog post on how to best do this) to restock the next time they’re parked at HQ.

The key to step one is to make sure you get buy-in from your team by delivering a product that truly saves time and delivers the utility that encourages them to use it time and time again.

Step two: Build on success, Invite your Customers Along

Necessity drives innovation. A tool that is simple will eventually reach a threshold where it must either be built out further or run the risk of feeling limiting to your team. Build on what works, and start giving access to your customers to tap into the data that is relevant to them. I can’t stress this enough — keep utility front and center. Flash, gimmicks, shameless marketing will be evident in a heartbeat. If you want your customers to stay loyal, give them genuine utility and a true reason to pull their phone out when the house is slowly flooding.

A few stage two deployments we encourage:

For driving a mobile workforce

  1. Gamification: create dashboards and performance metrics that show customer satisfaction, ticket time to resolution, accuracy, and safety performance.
  2. AR & VR Training: In some industries, training can entail a safety risk. By incorporating emerging visual technology into your training program, a technician can learn a new skill in a safe, controlled environment.

For customers with midnight woes

  1. Deliver utility first: payments, statements, reporting outages, leaks, and other common service hiccups. The time for your company to shine is when things go awry for your customers
  2. Deliver details: The same system powering technicians can now give a more granular view of when things will be repaired. If you really want to go the extra mile, add an option for customers to opt-in to push notifications giving regular updates to when crews are dispatched, assessing damage, in repair mode, and of course, when repairs are completed.

I get it, it can be daunting to jump into mobile. People are often held back by clunky systems, outdated back-ends, lack of expertise, or general fears of delivering a poor application. But just like the flood, what started with a pushbroom and a lot of cursing, turned into a full scale operation with flashlights, shovels, ladders, and a lot of elbow grease that ultimately cleared out the basement, and fixed the issue at the root — I’ll listen next time my wife tells me to clean the gutters before the spring-time truly rolls in. I would encourage companies to listen to their customers in the same way.

It takes a clear vision and a well-constructed roadmap to take a company from antiquated systems to cutting edge — but don’t fear, it’s doable! If you ever need a hand, you know where to find us.

— Jaime De La Ree is the Business Development Lead at Shockoe with five years of experience in mobile technology sales

Mobile Utility: Powering the Next Generation of Brand and Employee Engagement Apps

Mobile Utility: Powering the Next Generation of Brand and Employee Engagement Apps

It’s been well over a decade since the release of the first true smartphone. Apple promised to revolutionize the computing world with the iPhone, and true to their word, they did. Since then, companies like Shockoe have worked diligently to harness the full potential of such hardware. From Fortune 500 to start-ups, mobile shops have helped companies create workforce and customer-loyalty apps that measurably improve the daily lives of users. What is a Utility App? Let’s jump in.

Understanding Utility Apps

App downloads have been on a steep decline. This is unsurprising — bloatware, marketing gimmicks, usability issues, and ad-riddled pages make it unappealing to download an app and keep it on your phone. Even the greatest of intentions can backfire when apps lack focus or miss the mark on execution. Enter “Utility Apps.”

Utility is the concept of providing functionality and measurably demonstrating value – this idea is the fundamental key to any successful app. Was it built specifically for doing focused work, for producing clear results, or supplying a common need? The way we currently see it, there are three types of Utility Apps:

  • Customer and Brand Loyalty
  • Workforce Mobility
  • Resource & Inventory Management

Whether improving a brand or buying experience or alternatively, providing mobility to employees, the ingredients behind a successful app deployment are always the same. Does the application provide the best means to resolve a need?

Why Mobile Utility?

understanding-utility-appsWe’re often approached by customers who think of mobile as an alternative or add-on channel. This notion still surprises us. With 77% of US adults carrying around a smartphone, and furthermore, many checking it over a 100 times per day, mobile is a must for 2018.

With this in mind, it’s quite simple. Users will engage more with companies that remove barriers to products and resources and grant access through phones. As far as we see it, the writing is on the wall. Growing enterprises should feel obligated to improve mobile transactions and embrace innovative technology. Voice recognition, biometric access, Augment and Virtual Reality (AR/VR) are the new status quo behind today’s competitive apps.

Brand & Customer Loyalty Apps

Today’s most successful companies are investing heavily in their digital strategy to provide utility beyond shameless advertising. Home Depot, Nike, Delta, Amazon, Starbucks, all share a common thread — their apps aim to serve their customers. Furthermore, they provide functionality to the point that users rely on the application to improve their daily lives. A tall order, but a necessary one for companies aiming to lead the pack.

If you’re part of a B2C company that is still thinking of mobile as a secondary digital strategy, it’s time to go back to the drawing board. Mobility provides customers access to your brand and products on their schedule — not the other way around. E-commerce has been quickest to adopt, but other retailers, whether brick and mortar, restaurants, coffee shops, airlines, clothing lines should feel equally pressured to make the investment.

How Caribou Coffee Brewed Up App-Driven Business

Caribou Coffee, like many B2C companies, exists in a competitive business environment. In 2016, their low-rated app and poor user feedback proved users wanted to engage on mobile but were failing to do so. Sometimes it takes rethinking a good idea and executing in a different manner to get the desired business result.

caribou-coffee-brand

By keeping utility front and center, Caribou with Shockoe’s help overhauled everything from the back-end architecture to the user-interface. Despite major strategy and technology changes, Shockoe never steered away from the fundamental mobile goal: providing measurable utility. Loyalty systems were built to keep users coming back, login bugs were teased out to reduce access frustration, and in the end, all user testing kicked back positive. The result was a 4.9-star rating app backed by a loyal and satisfied customer pool.

The Modern Mobile Workforce

Loyalty is not a trait reserved for customers. Employers are now on the hook for providing work tools that facilitate work-life, and equally, boost management oversight.

Certain job-types nestle right into mobile as a solution. Utility technicians, outside sales representatives, high volume retailers simply operate better when they toss out antiquated hardware/software. Being able to review next appointments, manage tasks, report progress, generate reports, all while on the move, is the new business norm. Companies electing to keep their processes tethered to clunky portals and pen & paper will not only lose time but in time will also see employees grow frustrated.

Management Apps: Right Tool, Wrong Execution

Oracle, Microsoft Insight, Salesforce, or other CRM/ERP software are sometimes built with the right intention, but with misaligned execution that forgoes utility.

Even the most brilliant backend architecture can flop if the tool itself feels unusable. For the people managing resources, submitting expense reports, or counting inventory, designers must consider everything from strategy, information architecture, UX/UI, design, and innovation (biometric log-in, document scanning, etc.). It’s only once all these ingredients align that a mobile app can begin to make headway. Think of how the app is used and what limitations exist (and resolve them), and then and only then will you produce a tool as powerful as the system behind it.

Build App That Fit and Scale

Because companies come in different shapes and sizes, every process and deployment should be equally unique. Whether it’s an IT service team’s ability to service employees through mobile or tracking travel expenses through custom payroll app, it’s key to deliver tools that help employees feel heard and managed as a company grows.

Shockoe did just this when internal stakeholders at American Express were requesting greater numbers of custom productivity apps. With a growing backlog, a mobile roadmap became a necessity, as did a way of prioritizing and deploying the right mobile applications. Together, our teams conceived an application for employees to suggest, track, and manage the mobile tools rolled out by the company. The result has been better managed digital growth with greater employee access to digital tools. Everybody wins.

The Single Thread

Regardless if an app aims to bring more customers through the door or is attempting to streamline a supply chain, if it does not provide utility, you can count on a short shelf-life. All apps should be built upon solid strategy, sound data architecture, and clear UX/UI. This is the secret formula to any app that will ultimately end up as a front-page tool that your users count upon on a daily basis.

 

Page 1 of 2012345...1020...Last »