Add Presence to Your Conversations

Presence Has Shipped

Presence is now generally available for Layer customers; and ready to tell you when your customers and contacts are:

Add Presence to Your Conversations

Presence can facilitate a number of tasks within the communications process:

  • Identifying users who are active within your application, and may need help from your staff
  • Identifying users who are available to chat
  • Providing tools for users to flag their availability to chat

Presence addresses three questions:

  1. Is a user online?
  2. Is the user available, busy or away?
  3. When was the user last online?

How does it work?

Presence takes two inputs:

  1. Connection: Is the app connected to Layer’s Services
  2. Status: A string sent by a client indicating the user’s status

Any change to these values should be quickly reflected in any application that is listening for changes to presence data.  This data is currently available only through the Client APIs (iOS, Android and Web clients). The status has the following values:

  • Available: The user is connected and their status is set to available.  This is the default status.
  • Busy: The user is connected and their status is set to busy
  • Away: The user is connected and their status is set to away
  • Invisible: The user is connected and have set their status to Invisible (Shows to this user as Invisible, and to all other users as being Offline)
  • Offline: The user is not connected

Who can see Presence

Layer provides a model and APIs for controlling which users follow which other users.  Any user that you follow is a user for whom you will receive updates that change their Identity object.  As status is a part of Identity, any changes to status can be seen by all users who follow that identity.  If the person you follow wants to see your status back, they can follow you back.  Layer currently assumes that any users in a conversation together are implicitly following one another, allowing them to each see one another’s status.

Understanding Status

Status values of “away” and “busy” at this time has no defined meaning to Layer.  There is no automated detection that sets your status to “away” or “busy”; each app can decide for itself what sort of patterns of activity/lack of activity justify setting these status values.  For example, your client might automatically set the user to “busy” before starting a phone call.

Any solution for automatically setting a user to “away” is typically only needed for web, and not for mobile clients. Why is that? Most mobile devices change apps or go to sleep after sufficient time has passed, and in so doing, will update the user to no longer being online.

Web browsers and mobile apps have fundamental differences in what it means to be put into the background.  Best practice for a typical mobile app developer whose app has been put into the background is to minimize the system resources used in the background.  Depending on the mobile client, a backgrounded app may flag you as offline within a few minutes of being moved to the background.  On the web however, a tab that is in the background may still visible, and even if hidden may still be generating desktop notifications to announce new messages.  What this means for presence is that a web user who leaves a tab open remains available, and can remain available for weeks to come.  

Presence is a tool; and how best to use that tool for your business will depend a great deal on what you want presence to mean for your application.  As such, Layer Clients do not have a hard coded concept of when to flag a user as Away.  Are you away if the app is in the background? If the app hasn’t seen any user interface events in a while?  If the app has desktop notifications perhaps the user never needs to be flagged as being away as they are always a popup and a click away from seeing new messages.

For your first iteration with presence, you may simplify things by limiting your application to using Available and Offline as the only statuses.  Evolution of how you use presence will need to start factoring in what you want to achieve; “busy”, “away” and “invisible” are status values that you can set within your client to help achieve those goals.

Learn More

Take a look at our documentation for more information on how to integrate Presence into your Layer application. We can’t wait to see what you build with it.

iOS | Android | Web

Introducing Layer UI for Web

We are pleased to announce that Layer UI for Web is now generally available. Layer UI for Web extends the Layer Web SDK to include a library of customizable, commonly used widgets to be used for creating web-based messaging experiences.

These widgets are intended to allow developers to focus on the look, feel and use-case specific functionality of their web messaging interface rather than building basics from scratch.

This post will serve as an overview of our approach and an introduction to Layer UI for Web. You can view the full documentation here.

 

Our UI Framework Philosophy

React is popular, so there was a lot of temptation to use it to build a UI framework that would primarily satisfy React developers and call it good enough.

We didn’t.

Our philosophy on JavaScript Frameworks is as follows:

  • Your framework is your choice
  • We’re not going to force you to also use React, or Angular, or any other common framework
  • The ability to easily customize or even replace any single widget or behavior is critical to you building your application the way you want it.

To achieve these goals, we’ve used Web Components. Web Components will work with almost any UI framework (or with plain JavaScript) without requiring dependencies beyond an optional Web Components polyfill. They are also remarkably easy to work with.

To illustrate how Web Components are used, the code below uses no framework to generate the picture above, and depends upon two widgets:

  1. layer-conversations-list: A widget for loading, scrolling through and selecting Conversations that your user is participating in
  2. layer-conversation-panel: A widget for viewing messages in a conversation, sending messages in reply, typing indicators, marking messages as read, paging, etc…
<body>  
  <layer-conversations-list id='mylist'>
  </layer-conversations-list>
  <layer-conversation-panel listen-to='mylist'>
  </layer-conversation-panel>
</body> 

Web Components provides the capability of telling the browser that the DOM nodes described above exist, as well as the ability to associate rendering and behaviors with those nodes.

We add an optional header row as used in the picture above:


<div class='header'>  
  <div class='layer-conversations-list-header'>
    User <span class='user-name'></span>'s Conversations
  </div>
  <div class='layer-conversation-header'></div>
</div>

The listen-to attribute tells the conversation panel to listen to the conversations list and to show any conversation selected by the user.

Alternatively, instead of using listen-to, we could build this ourselves with a little JavaScript:


// Initialize the Layer UI Framework
layerUI.init({  
    appId: "layer:///apps/staging/UUID"
});

// Get the dom nodes
var conversationList = document.querySelector('layer-conversations-list');
var conversationPanel = document.querySelector('layer-conversation-panel');
var conversationHeader = document.querySelector('.layer-conversation-header');

// Whenever the user selects a conversation:
conversationList.onConversationSelected = function(evt) {  
    var conversation = evt.detail.item;

    // Tell the Conversation Panel what conversation to show
    conversationPanel.conversation = conversation;

    // Update the label above the Conversation Panel
    conversationHeader.innerHTML = conversation.metadata.conversationName;
};

Isn’t Web Components just another UI framework?

Well… ok… yes. But it’s also:

  • A Web Standard
  • Natively supported in many browsers and is supported via polyfill in all other supported browsers
  • Can be written using a number of open-source frameworks or with raw JavaScript.

How much coding is really required?

There are products where you just drop an entire chat experience as a widget into your app and you declare done. This is great for certain use cases and providing such a starting point is a goal we are working towards.

But ultimately, as any application evolves, it requires custom UI behaviors that differentiate your app and help focus on your core business goals.

To accomplish this, Layer is making available a library of UI widgets that you can integrate into your application and customize as you see fit. In the above example, the <layer-conversations-list /> provides an event when the user selects a conversation, and you use that event to tell the <layer-conversation-panel /> what the selected conversation is.

Is that all the coding that is needed for a basic, un-customized application? Yes that is all the UI code needed (there is still authentication which is handled separately via Layer’s WebSDK).

Ultimately, more code will always be added:

  • Do you want a dialog to show a list of users to create a new conversation?
  • Do you want to support custom message types?
  • Do you want to allow for deletion of messages or conversations?
  • Do you want to modify messages before they are sent?

As you depart from the plainest possible application and head toward customizing an experience, more coding will be needed. But configurability is core to our UI philosophy. Relatively small amounts of code are typically needed to customize behaviors.

Configurability

A message list is just the beginning of your messaging experience. Being able to send textual messages back and forth provides you with a basic shippable product. But interactive content is where your app stops feeling like an SMS integration and starts feeling like a rich, interactive conversation between participants.

Being able to render content like credit card forms, purchase approvals, work orders, shopping cards, and other resources in the messaging list will help you shape your UX to fit your business needs beyond plain text.

Using any Web Component framework you like, you can implement a message handler capable of rendering the custom resources your application needs. This functionality, available across the Layer platform, allows for the creation of arbitrarily rich, interactive message elements. Examples below will include some basic utilities Layer UI uses to define its own Web Components, but this is not a constraint on your own implementation.

The first step is to tell Layer UI how to handle a custom/credit-card message:

layerUI.registerMessageHandler({  
  tagName: 'custom-credit-card-form',
  label: 'Credit Card Form received',
  handlesMessage: function(message) {
    return message.parts[0].mimeType === 'custom/credit-card';
  }
});

This code includes:

  • tagName: Identifies the DOM node that will be generated to render this message. The example above tells Layer UI to generate a <custom-credit-card-form />.
  • handlesMessage: Tests against each Message to determine if the specified tagName should be generated for this Message.

The second step is to build a Web Components custom-credit-card-form:


var MessageHandler = layerUI.mixins.MessageHandler;  
layerUI.registerComponent('custom-credit-card-form', {  
  mixins: [MessageHandler],
  template: `<form><fieldset>
    <legend>Enter Credit Card</legend>
    <div><label>Card Number</label><input type="text" /></div>
    <div><label>Expiration Date</label><input type="date" /></div>
    <input type='submit'>Setup Payment</input>
  </fieldset></form>`,
  methods: {
    onCreate: function() {          
        this.querySelector('form').addEventListener('submit',
            this.validateAndSendCardInfo.bind(this));
    },
    validateAndSendCardInfo: function() {
       // custom code for validating the card and sending it to your server
    }
  }
});

On filling out the credit card form and hitting send, the card information can be sent to your server securely, and then your card could then send a message to other participants indicating that payment was received.

More Customizability

Our documentation is full of examples for how to customize a variety of aspects of your application.

  • Defining new message handlers
  • Changing the layout and template of a message item in the message list
  • Adding, enhancing, and replacing behaviors of widgets using Mixins
  • Changing default behaviors such as what happens when the user hits the SEND button after typing a message
  • Replacing widgets such as the avatar widgets with your own widget definitions

These are all written up in more detail in the Layer UI Customization Documentation.

What’s Next?

World-Class Messaging in Minutes

Guide to World-Class Messaging

We know that messaging increases customer engagement and improves conversion. No matter what industry you’re in, a 1:1 customer conversation strategy can lead to business success. However, creating your own branded messaging experience might sound easier said than done.

But did you know you can achieve world-class messaging in just a few minutes? It’s possible when you build on top of the Layer platform.

3 Components of Layer that Streamline Messaging Go-to-Market

Our goal at Layer is to enable you to build your own world-class messaging experience with minimal effort by using our customer conversation platform. To help, we’ve designed a new workflow in our dashboard that allows anyone (including non-engineers) to get started on Layer.

There are three main components in this workflow—an identity provider, sample apps, and a web wizard.

Rather than forcing you to register with Layer itself, the platform offers a simple identity provider. This eliminates the typical engineering hurdle platforms require when you have to migrate existing users or integrate your user management system. We’ve developed a simple 1-click deploy to Heroku that allows anyone to start experimenting with messaging through Layer quickly.

After you’ve had the chance to experience Layer, you can integrate your actual user management system for full-scale production deployment.

This streamlined access is also useful for existing applications that have already been built on Layer. By downloading the sample apps that are available for iOS, Android, and web, you can integrate your user management system and compare application behavior with Layer’s best practices. Validating against the best practices can help ensure you’re releasing an optimal messaging experience.

All of these processes can be completed through the web wizard available in the Layer dashboard. It guides you through the whole process of setting up your branded messaging experience.

This 3-phase workflow can be completed in just a few minutes and help you get well on your way to releasing your own customer conversation channel.

Want to see how it works in real time? Check out the quick 3-minute demo below.

by Amar Srinivasan

Sending Your First Layer Message from Ivy Montgomery on Vimeo.

Learning with teams

Editor’s note: This is a cross-post from Udacity‘s Dhruv Parthasarathy. Dhruv shares how, with the collaboration with Layer, they were able to successfully implement their classroom chatroom feature, Teams.

Despite all the advancements made to date, online education still has one glaring shortcoming — it is lonely. Learning online today is largely done on your own, at your computer, cut off from those around you. In essence, we’ve lost the human element of education that brings so much joy and richness to the experience. Here at Udacity, our goal is to create an educational experience that is better than any other, online or offline, and so long as our experience lacks this human element, we know we will continue to fall short of our goal.

Seeing this, we’ve been focused on bringing real, human relationships to the core of our product. The manifestation of these efforts is Teams: a new experience in Udacity where you join 10 other fellow students from around the world in a small, tight-knit community focused on learning. Students on teams answer each others questions, collaborate on projects, and help each other achieve their goals. Beyond that, they also get to participate in a real community with students who share similar career and learning goals. In order to create such a community, we knew that we would need to provide a simple way for teams to communicate with one another as without communication, there can’t be community! As such, at the very core of Teams are Rooms — persistent, Slack-like, chat rooms where students can communicate with one another. The first iteration of Teams and Rooms shipped in June 2015, a through the rest of this post, we’ll explore the engineering and product decisions we made in creating this product and how we’ve seen it improve the learning experience for students.

Teams — A Technical Perspective

One of the key elements of Teams is the web client where students log in to chat with one another. You can see what it looks like below.

In developing the web client for Team Rooms, we had a few specific engineering goals:

  1. The application had to be reactive. The view had to be able to update itself without a refresh in response to new events that occurred during the session (new messages, changes in status, new members joining etc).
  2. The application had to be simple to work on and extend as there would only be one to two engineers working on it (both frontend and backend).

Regarding our first goal, current practices in an MVC frontend (we use AngularJS), make creating a reactive application difficult. Let’s take a look at why this is the case. In a reactive application, controllers need to have a way of discovering when the model changes so that they can update the view. In the current paradigm, you have two main ways of achieving this:

1. Eventing + Callbacks

The first way you could approach this is by using a combination of eventing and callbacks to send out an event to controllers whenever you update the model and have the controllers run some callback in response. In practice, this is difficult to implement. A fine-grained eventing system requires a different event type for every property. Assuming you remember to emit those events on every change, the number of listeners also increases dramatically. In essence, the number of events and the number of listeners scales linearly with the number of model properties.

2. Watching Models

Alternatively, you could instead have your controllers check your model directly for changes by diffing the new from the old. But in practice, looking through a large nested object for changes is extremely slow and as more controllers attempt to do it, performance degrades significantly. If you have an object with let’s say a constant branching factor of m at each depth, and a depth of n, you will be watching m^n different properties which quickly becomes infeasible.

Our Solution: Store models in Immutable datastructures

Unsatisfied with the options we saw, we looked to solve this in a different way. Our goal was to create a system where controllers would just be able to say “I care about this part of the model only!”, and the model would update the controllers when it changed in a simple, performant manner.

Of course, checking if a standard Javascript object has changed is extremely expensive. But what if the object were immutable? Then, whenever the object changed, it would be trivial to know: you just see if oldObject === newObject and you’re done! In seeing this, we decided to store our state in an Immutable object, and we did so by using Facebook’s wonderful Immutable.js library. Now, we had a simple way of checking when the model changed — we just check the reference to the underlying immutable object! We then needed a way to communicate updates between the model and the controllers. Instead of using an eventing system, we chose to use Netflix’s ReactiveX library for javascript (RxJS). With Rxjs, we treat our model as a stream of states rather than a single, unchanging, state. Whenever we update the chat state model, we added a new value on a stream.
To understand this better, let’s walk through how a controller might subscribe to model changes. Let’s say we’re interested in showing a list of users in the chat room and want that list to update whenever the list of users changes. Let’s also say our users model has the following schema:

{'users':
    {
       userId: //user object,
       ...
    }
}

Here’s how the controller would do it:

  1. Get a stream of updates to the users model.
  2. // create a stream of user updates
    var userMaterializedView = chatState.createMaterializedView( // this is the main stream of updates the chat state chatState.chatStateUpdateObservable, // this is a function that returns the part of the chat state we care about function (newDB) { return chatState.getUsers(newDB); }
    );
  3. Subscribe to the stream and update the view whenever a new value comes on the stream.
  4. userMaterializedView.subscribe(function (users) { $scope.users = users;
    });

The diagram below visualizes what’s going on behind the scenes to help us create this stream.

The bottom stream of triangles, the ones that are all different from one another, is what the controller in this case gets. In this way, we created a simple API that allowed controllers to subscribe to updates on any transformation of the model they cared about.

The Backend: Powered By Layer

With a small team, we had the luxury to create this architecture on the frontend partly because we didn’t have to worry about the backend — Layer took care of most of that for us. As someone who’s configured and deployed a chat server from scratch before, using Ejabberd (an open source XMPP server), I can confidently say this saved us a lot of time. Managing an Ejabberd deployment on your own is challenging,and clustering the setup is quite difficult due to fairly opaque documentation that hasn’t been updated for a while. Additionally, Ejabberd isn’t particularly user friendly from a client perspective either. Being an XMPP server, it communicates over XML instead of JSON that your client can actually use. Moreover, it doesn’t support Websockets out of the box and you have to instead use the fairly ancient HTTP BOSH technology. As such, standard XMPP servers were not at all a great fit for our use case and came in the way of development.
On the other hand, Layer was a comparative joy. Layer gave us access to a simple Websocket API with extremely well documented json packets. This made communicating with the server very simple (see the documentation here). We didn’t have to worry about deployment, maintenance, or translating packets into something meaningful. What I personally loved most about Layer was that it was clearly designed to get development out of the way and allow you to focus on what’s most important — creating a wonderful experience for the user. My sentiments were shared by my colleagues working on the mobile clients — we were able to create a prototype android and iOS client in a matter of a weeks. I can’t think of another simple setup that would have provided us this kind of productivity. As a result, we were able to focus on our product and continuously iterate the user experience instead of debugging the server.

Improvements Since Launch

Since the basic product launched on July 6th, we’ve been able to improve it at a strong pace thanks to the productivity afforded us by Layer. Here are just a few of the enhancements we’ve made since launching less than two months ago.

Integration with Google Hangouts

While chat is good for communicating asynchronously, we found that nothing beats a live video chat for a realtime meeting. As such, we added in simple support for Google Hangouts which also gives our students the ability to screenshare with each other.

Udacity Guides

One of the most exciting things at Udacity is the growing community of intelligent, passionate alumni we have. We wanted to leverage this alumni network to help current students succeed even further. So we created the concept of guides — paid Udacity alumni who help teams learn, collaborate, and succeed.

We’ve been able to focus on improving the product in these ways largely thanks to the fact that we only had to worry about the client — Layer took care of the rest for us.

The Impact

As a result of this focus, we’ve seen metrics that lead us to believe that Teams are helping our students succeed in meaningful ways. For instance, the percent of students who submitted their first project, one of the key metrics of student engagement, increased by 25% — something we’ve never seen before. Not only this, we’ve seen groups connect, get to know one another, and create real bonds learning online. Layer’s tools and support have been an integral part of making this product happen and we are thrilled with our experience working with them. We are excited by the architecture we have put in place to create a truly reactive application for our students and know that the productivity afforded us by Layer was a key part in making this happen. We’ve still got a long way to go with Teams, but we’re confident that it can help us bring human connection to the forefront of online education.

Introducing the Layer Client API

Today we’re happy to announce the public availability of our new Client API—a REST and WebSocket API that lets anyone build browser-based messaging applications for web and desktop.

Its release comes at the end of several months of beta testing. Three hundred developers took part in our early access program, and a number of companies have already released applications that use the new API, most notably Udacity, who saw a 25% boost in goal achievement when they added group chat to their mobile and web applications.

Our Client API is available today, and documentation can be found here:
http://developer.layer.com/docs/client

What is the Client API?

The Layer Client API is a set of APIs for building messaging clients on any web-enabled platform, including browsers and desktop applications. It bundles together a REST API for authentication and interacting with Conversations and Messages, and a bidirectional WebSocket API for real-time updates. These APIs serve as the underpinnings of the forthcoming JavaScript SDK.

What can be built with it?

The most straightforward use for our Client API is to create a complementary browser-based version of your mobile app, offering the same functionality but on a different platform (mirroring the experiences your users may have had with web versions of WhatsApp, Telegram, or Facebook Messenger). Some applications package this as a native desktop app wrapped around a web view.

Alternatively businesses may require a two-sided, asymmetrical application, where different users have different application experiences. Examples of these asymmetrical interfaces include:

  • Logistics — a dispatcher is given a large administrative dashboard, while mobile users (drivers and riders) have application experiences that are specific to their needs
  • Customer support — one agent has dozens of tickets, but a user may only have one support ticket
  • Concierge shopping — a personal shopper is paired with several individual users, who each have only one shopper
  • Coaching — connecting personal trainers to clients, where trainers have different options from clients

Layer for Web: Client API, SDK, UI Kit

Today’s release of our Client API is the first step towards what will eventually become Layer for Web—a complete toolkit for building messaging applications on the web. Steps two and three, a JavaScript SDK and accompanying Web UI Kit, will be open sourced and released in the same fashion as the Client API; a small early access program followed by a public beta.

If you’d like to help test our JavaScript SDK in the coming weeks, please fill out this quick 2 minute form, and let us know your plans for developing with it.

As for the Client API, we can’t wait to see what you build with it.

Announcing webhooks early access

At Layer, we are on a mission to make communications better in all the products people love and use daily. The platform we offer enables developers to create compelling user-to-user and application-to-user rich messaging experiences.

Our philosophy is to launch new products gradually, in tight collaboration with the active community of Layer developers. This lets us build scalable, secure, reliable infrastructure, while incorporating direct feedback from the community. Our iOS and Android SDKs, UI Kits, Platform API, and Client API (get early access) have all benefitted this approach.

Following this process, we are now opening the Layer webhook service for early access.

What are webhooks?

While the Layer Platform API is used to input data into conversations, webhooks serve as an output. As a developer, you define which events you want to be notified of and Layer will trigger a request to a URL you define, along with a JSON payload containing additional event information.

What can webhooks be used for?

Webhooks can be used to monitor events in conversations, process them, and act accordingly.

Example use cases:

  • interoperability with legacy messaging systems
  • interoperability with external systems like SMS or e-mail
  • monitoring messages for keywords and commands (e.g. /help)
  • monitoring of messages for specific content filtering (e.g. profanity)
  • monitoring activity (such as new participant added), to trigger alerts or automated messages (e.g. “Welcome to the conversation Jane…”)
  • integration with machine learning and text processing services

When combined with the Layer Platform API, integrations like external services and AI bots become possible. This enables:

  • conversational onboarding (a bot that gets to know you)
  • automated responses from in-app customer support
  • hyperlink expansion and embedded content cards with images and metadata
  • text-based reminders of upcoming calendar appointments
  • hailing a car service from an in-app message

Apply for early access

If you’d like to start developing with Layer webhooks, or if you want to offer a service to Layer developers, please fill out this short form. We expect to release webhooks in general availability later this fall.

Introducing the Layer Platform API: build rich application-to-user messaging

Every app is a communications app. Whether it’s connecting two people in a marketplace, an on-demand service, a shared interest community, or a dating app, user-to-user communications is an integral layer of functionality. Layer already provides this with client-side SDKs for mobile and web.

But sometimes as a developer, you need special control over the communications within an app. There comes a time when you need to add participants to a conversation (customer support), create a conversation on behalf of two users who do not know each other (dating app), or act in an administrative function to block certain users (shared interest community). You and your application need to be in control. That’s where the Platform API comes in. It unlocks all of the functionality you would expect to enable control from your backend application, and adds support for your backend to send application-to-user messages. This opens up entirely new possibilities to broadcast updates to your users and enables service integrations, injecting content feeds, or offering rich in-line content.

Announcements: a new way to notify your users

alt

Fig 1. Surge pricing.

Application-to-user messaging comes in two flavors. The first is akin to a targeted notification. You may want to broadcast an update about surge pricing to select users in a geographic area, let someone know that they have a new follower, or that there’s a new deal based on their shopping preferences. You could use SMS for this, but you’d need the user’s phone number, the communication appears to the user to come from an anonymous source, and lands among the noise of a user’s already-busy text message inbox. Push notifications are better, but they are best-effort delivery and you don’t get in-depth analytics on receipt or open rate. With Announcements, you can send a persistent message to users that can be optionally accompanied by a push notification. It can also be silently synchronized among the user’s devices, to power an activity feed for example.

There are major benefits to message persistence, searchability, and receipt analytics. Announcements will work even when users have disabled notifications, or if they have uninstalled the app. You can tell what the exact delivery status is (e.g. sent, delivered, read), and which people have read the message. When your users log back in, you can display a stream of updates, or let them know how many activity items they missed since their last visit.

These capabilities provide you complete control to create the exact experience you want for your users. Bring the conversation into your app and re-engage your users with Announcements in ways that SMS or plain push notifications just can’t provide.

Send system messages into conversations

alt

Fig 2. Score update in group chat.

The second form of application-to-user messaging is a scenario many of us are familiar with: integrated services that interact right in the flow of conversation. Anyone who uses Slack or HipChat has probably set up a number of 3rd party integrations with services such as Twitter, Github, or Trello. When changes occur in these services, they broadcast updates directly into the appropriate channels in your messaging interface. With System Messages, anyone is able to build this rich functionality. Your backend application can relay 3rd party service updates, usually from a third-party Webhook, directly into the relevant conversational UI of your users.

For logistics and on-demand applications, where there are many different parties involved and frequent status updates about an order, all of the application-originated messages can be injected into a single in-app conversation across mobile devices and browsers. When the user has been matched with a shopper, or they need to change an order, or the order is out for delivery, all of this can be tracked in a single message thread. Accompany it with optional push notifications to keep everyone informed about the updates of the progress of the transaction. This means maps, order cards, chat, questions, and receipts can all be integrated together, and accompanied by notifications. All of the conversation flowing through the app also removes privacy concerns around personal identity and phone numbers. SMS quickly becomes second class to a consolidated, media-rich, in-app conversation.

This context is ultimately what makes a communications experience rich. Imagine a set of basketball fans discussing the NBA finals. One person in the chat may be watching at home with friends, another at the bar, and yet another is on the subway without access to a video stream. The three of them may already have a group chat going as their play-by-play commentary about what’s happening. However this conversation is missing one key thing: shared context. Now with System Messages, the basketball application can inject the score updates and notable events directly into the stream of conversation. For the member on the subway, she now has access to what’s going on without having to follow multiple sources of information at once; it’s all there in the conversation. The content and communications are integrated into a single place, and the experience for each person is made all the more relevant.

Create and edit conversations from your backend

alt

Fig 3. Start a new chat between matched users.

Let’s say you’re building a dating app, and a match was just made between two of your users. These two don’t know each other, and need to be connected in a conversation so the magic can happen. Using the Platform API, your backend application can create a conversation and invite the two of them to join. This allows you to set your own metadata on the conversation, and determine when to begin the conversation (e.g. optional time delay). On top of all this, with a System Message you could include an ice breaker question or prompt into the newly created conversation to trigger immediate engagement. In the future, this will also allow you to delete the conversation (e.g. a 24 hour window of opportunity). Application-controlled conversation creation also allows you to build invite mechanisms, automatic removal of inactive users, or automatically adding new users to a conversation upon sign-up.

Your backend is in control of Layer

alt

Fig 4. Block users based on community feedback.

The last important piece of functionality the Platform API opens up is control over your application, and eventually your Layer account, via REST. A common implementation of this might involve allowing users to flag each other as inappropriate, and when enough flags are accumulated on a user, to invoke a block policy on Layer. We’re expanding this area over the coming weeks and months to provide more granular control over your applications, and eventually over administrative function of your Layer account.

What’s next

At Layer, our aim is to provide easy-to-use, flexible, powerful APIs and SDKs for developers to build rich communications experiences. This means exposing controls where needed, and simplifying complexity where possible. We view the Platform API as a whole product, one that gives you more leverage and control over your application and the communication experiences within. We’ll be releasing administrative controls over your Layer account, enhanced control over user and notification policies, insights into all of your messaging activity, and all of the functions you are currently able to perform at a user-level.

 

What we learned building a Layer messaging app for Apple Watch

Push notifications are at the core of the Layer messaging service. Where some platforms provide push as a complementary offering, push is a fundamental pillar of our system. Every message that’s delivered to a device via Layer is optionally accompanied by a push notification, and this works across platforms and devices. Our fondness for the notification interface is one of the many reasons we’re so bullish on wearable devices and the possibilities they open up for application developers.

As we’ve written in the past, the Apple Watch provides a simple, convenient and discreet medium for delivering notifications. At Layer, our mission is to help developers build the very best messaging experiences, and we believe those experiences will undoubtedly involve Apple Watch applications. To learn more about what it’s like to build for this new medium, we started with a fully working iOS app and set out to make it work on the Apple Watch. Here’s what we learned.

Findings

This was the first time our iOS team had the opportunity to develop for Apple Watch, and we naturally experienced a small learning curve while getting started with the new platform. Here are a few areas that stood out.

Running and debugging

When developing for a new technology platform it can take a bit of time to become familiar with the tooling and workflow. Working with the WatchKitsimulator was no exception and produced a few unexpected surprises.

  1. Displaying the Apple Watch Simulator – We expected to have the Watch simulator pop up when running our app extension target for the first time. As we quickly found out, a bit of setup was required to enable this behavior.
    1. Navigate to Hardware > External Displays.
    2. Select either the 38mm or 42mm simulator.
  2. Debugging extension and app simultaneously – App extensions can make calls to their parent application via the openParentApplication:reply: API. This method calls the app delegate’s application:handleWatchKitExtensionRequest:reply: method. We expected to be able to add a breakpoint into our implementation of this method while running the extension in the simulator, but the break point was simply not tripped. In order to debug applications on the iPhone and Watch simulators simultaneously, perform the following:
    1. Launch the WatchKit app target in the simulator.
    2. Open on the corresponding parent application in the iPhone simulator.
    3. In Xcode, navigate to Debug > Attach to Process and select your iPhone application’s process.

Provisioning

Cocoa developers who have distributed iOS applications have undoubtedly run into issues that can arise from Provisioning Profiles and Signing Certificates. We weren’t surprised to encounter these issues when attempting to build our WatchKit app on an actual device for the first time.

The WatchKit Extension and Notification target both require their own unique Provisioning Profiles that must match their Bundle Identifiers. These will need to be generated in the Apple developer portal before building for an actual device.

Storyboards

We’re admittedly not the biggest Storyboard fans at Layer (and while the reasons for this are numerous, they’re probably best discussed in another blog post). Needless to say, we were somewhat disappointed to learn that Storyboards are mandatory for Apple Watch Apps and that layout shouldn’t be performed programmatically. This is a bit of a departure from the development philosophy of Atlas for iOS, where we try to perform as much layout as possible in code.

Push in the simulator

Lastly, one very pleasant surprise we encountered was the ability to simulate the delivery of a push notification to Apple Watch. Developers can define a push notification JSON payload in a .apns file and have it “Delivered” to the WatchKitNotification target. This provides very efficient notification debugging, especially when implementing push notification actions for the extension. Our hope is that Apple extends this functionality to the parent application targets in the near future!

The future with watchOS 2

We were excited to see Apple’s announcement yesterday of native application development for Apple Watch, and the new features in WatchKit. Apple made a number of improvements that benefit messaging applications, especially with regard to interactive notifications and new APIs for Siri and the microphone. We’re looking at experimenting with the following functionality in LayerKit and Atlas:

  • Reply directly from a Notification on Apple Watch using voice or text, not just from the Watch Extension.
  • Use Siri in the Layer-powered Watch app to reply directly to messages.
  • Reply to a message using the microphone to send an audio message.
  • View videos and GIF within message cells, adding to the current photo and map functionality.
  • Display the last message or message count as a Complication, with new high-priority push, to keep a running history of replies on Apple Watch.
  • Use custom Taptic vibrations depending on the sender of the message, or differentiated by 1:1 or group conversations.

We can’t wait to see what you’ll build for Apple Watch with Layer and Atlas. If you’re interested in getting early access, don’t hesitate to get in touch!

Helpful links

  1. WatchKit Programming Guide
  2. App Extension Programming Guide
  3. LayerKit
  4. Atlas

Building blocks for logistics: maps and notifications

Editor’s note: This is a cross-post from Mapbox‘s Peter Liu. It’s a sneak peek of a larger collaboration between Mapbox, the building block for maps, and Layer, the building block for communications. More to come!

Technology is reinventing on-demand services to include everything from shipping to laundry, and the central innovation is realtime logistics. Delivery-on-demand services like Postmates or Shyp work at the intersection of location, time, and economics. Assigning the right jobs to the right people – within seconds – is the challenge.

The dispatcher of the future is a stack built with Layer for communications and Mapbox for geo. Customers request a delivery at an address, which Mapbox’s geocoding API transforms into a latitude, longitude point. Turf.js assigns the nearest and oldest outstanding order to each available courier, sending them an instant push notification with Layer. When the courier accepts a task, Smart Directions generates a route specifically for their mode of transportation.

This is a full-featured logistical system in the browser (check out a preview).

  • Layer: realtime messaging layer that connects couriers to assignments.
  • Geocoding: converts addresses into geographical locations.
  • Turf: geospatial analysis fast enough to provide understanding of spatial relationships on the fly, as the foundation for more complex scheduling algorithms.
  • Smart Directions: instant routing from couriers to drop points.

Layer connects people with push notifications, text messages, and alerts – getting customers, couriers, and dispatchers on the same page, in realtime. Mapbox’s geographic technology provides analysis, visualization, and data. Mapbox and Layer are building modular components and APIs for developers, and it’s exciting to see that they can be assembled into real-world applications.

1 – Customer places order

Customer shares their location with the courier.

2 – Courier receives notice of new order

The customer’s location is visible on courier’s device.

3 – Courier plans route and begins trip

Given their two locations, courier is guided to the customer’s location.

4 – Customer is updated of courier’s progress

Trip updates can be sent automatically, so couriers can focus on getting to the destination.

5 – Customer is notified that their order has arrived

With Mapbox and Layer, we can build a great customer experience for any application. Real-time push notifications let customers and couriers stay on the same page without having to actually jump on a call.

The art of powering the Internet’s next messaging system

Last week hundreds of developers gathered in downtown San Francisco to attend Erlang Factory SF Bay, a two day tech conference focused on the Erlang programming language. The conference “brings together the rapidly growing community that uses Erlang in order to showcase the language and its various application to today’s distributed environments.”

Joining them were two of Layer’s senior software engineers, Juan Puig Martinez and Mubarak Seyed. Juan and Mubarak have designed and built much of Layer’s back-end messaging systems. Prior to joining Layer Juan built Erlang/OTP based solutions for Erlang Solutions and Linden Lab. Mubarak specialized in distributed systems (most recently at Apple where he built the Siri platform, and is a committer to Apache Flume).

Building Large Scale Messaging Systems

A question we sometimes get from developers is: What’s so hard about building communications? We usually respond:

In the talk below Juan and Mubarak share some insights into why we chose to power our backend with Erlang and the key components of our backend architecture. They also talk about some of the challenges we faced to maintain performance, how we addressed them, and of course, lessons learned.

Embedded iFrame

Building a powerful communications platform is hard – but for most developers, it doesn’t have to be. Layer provides a full-stack communications building block for developers, including UI components with Atlas.

We can’t wait to see what you build!