Dev

Avoiding sucking: How to make an app people actually want to use

These days, users require intuitive, responsive, and interactive apps that scale to high volumes of data (and users!). While developers work overtime to keep up, they are often locked into programming models that result in lackluster apps.

Here are five ways developers can break the cycle of simply meeting user demand and get ahead of the game to create apps that users actually want to use.

Single-page applications

In traditional web applications, every click or interaction causes a page refresh. This is not an effective way for a user to move through an application.

The single-page architecture is shifting the paradigm and allowing developers to build more fluid and interactive applications. To validate user input, traditional web applications send the user input to the server, validate the input, then return results to the user. Single-page applications validate most content on the client, providing a vastly more interactive and responsive user experience.

Web browsers and mobile devices provide powerful environments that allow for rich user interaction. For example, single-page application can leverage the capabilities of a mobile device to deliver a rich user experience, utilizing the camera, accelerometer, and/or GPS to specific and contextual experiences.

Single-page applications can use powerful visual components to present information in the format selected by the user. For example, a user may want to see data in a chart or in a table; a single page application can switch between these representations without any interaction with the server.

The plethora of devices with varying sizes has catalyzed the concept of responsive design, where applications adjust how information is displayed and which content is displayed for the size and characteristics of the device. Single-page applications are far better suited for creating responsive applications because the client can make independent decisions based on the device capabilities.

Separating client and server

Most Java applications look terrible because the application architecture does not allow UI developers to collaborate effectively with server-side developers. By exposing services and creating a clear separation between the client-side and the back-end services, developers can create much richer applications.

A client application, written with HTML or HTML and Java Script, execute server-side functionality. Client developers, with skills in graphic design and user interaction, leverage the efforts of server developers, whose expertise are in scalability and reliability, which provides a powerful combination and results in superior applications. A clear separation between client and server, often using a REST interface and/or JSON payloads, allows both sets of developers to focus efforts in their areas of expertise.

Realtime push

Historically, web apps are updated only when the user refreshes or moves to a new page. While the user views the page, the data may have changed on the server, thus the user is often seeing outdated information. JVM-based apps can solve this issue using real-time push, which updates the data in real time. In the case of apps like Google Docs this means instant collaboration.

Rich user experiences are created with instant content updates. Instant messaging and text messaging are two solutions founded on push notification that have changed how we communicate. Map applications are much more useful when merged with realtime traffic data. Vital business applications require notification to key decision makers, whose business successes require timely information.

Data is being collected with growing frequency and volume, providing new opportunities to provide consolidated results that can impact our immediate decisions. For example, the Waze mobile maps application collects the current speed and location of other drivers and adjusts your route based on that information.

Scale predictably

Web applications must scale to meet demand. The “Oprah Effect,” where an application or website is brought to its knees by an onslaught of traffic after being mentioned by a prominent source, has crashed more than one web application. The solution must be implemented so the application can scale to meet increased user demand, increased data volume, or other increases in activity.

Most developers build their applications on top of low-level concurrency models like threads. In order to manage concurrency, they rely on locks, which block threads and are particularly difficult to compose, leading to incredibly difficult and unpredictable issues such as deadlocks and live locks.

Using high-level concurrency models like Akka’s Actors enables developers to build high volume systems that scale as needed. Developers can write applications that block threads only where they absolutely must, and instead rely on asynchronous execution to maximize the utilization of the physical resources on a single machine or many.

Create a stateless architecture

Since the advent of CORBA, the idea of being able to create clusters of servers that replicate state across them has been the holy grail of distributed architectures. JEE specified entity beans that would fulfill a similar role. For performance and complexity reasons, we have since given up on such architectures and instead focused on using external, denormalized stores to cache our data for multiple servers, but even that comes with the cost of eventual consistency and manual arbitration of colliding updates across nodes.

Have we have finally reached the point where it is okay to say that stateless sessions is the only way to go for high-performance, distributed architectures?

Stateless web applications have become really important for building fault-tolerant and scalable systems. This allows web requests to be transparently load-balanced across a number of servers. Without any state contained in those servers the web tier becomes elastic and can easily deal with failures. Additional servers can be added as demand increases.

Ultimately, the world is witnessing a fundamental phase shift in the way applications are built and designed. Keeping these new basics in mind will enable the creation and deployment of truly scalable and robust applications; furthermore, you’ll be able to leverage new open source tools to build these systems on the JVM.

Get ready for a new era of reactive applications, and happy hacking!

Derek Henninger is vice president, engineering, at Typesafe, a developer tools company focused on Scala, Java, Akka, and the Play Framework.

Image credit Shutterstock/leedsn


Mobile developer or publisher? VentureBeat is studying mobile marketing automation. Fill out our 5-minute survey, and we'll share the data with you.
0 comments