Understand these Web apps first, you can go a lot less detours

In recent years, with the rise of front-end separation and single page application, Web pages are becoming more and more applied. The development of mobile Internet is fueling this trend--for interactive, performance-insensitive scenarios, Web apps have a clear advantage over development costs and cross-platform compatibility.

But behind this hot market, many times from product managers to design and even development, the characteristics of the Web platform does not have enough knowledge and vigilance, resulting in the final product is neither app nor Web Sibuxiang, not only drag the user experience, the development team is also easy to apply.

This article hopes to focus on the features of the web, explore the differences between Web apps and native apps, and help readers identify potential problems early in the project.

　　Web app is not app

The Web App also needs to follow the Basic Law

Web app or single page application, the name of an app, sounds quite niaoqianghuanpao taste, whether engineers or stakeholders (product manager, customer), will inevitably have a monk touch me, the app do I do not? The illusion. What's more, the original app's design draft p last browser address bar was dropped to the team, so as to make a web app out. If this is your situation, then congratulations, you're already on the way to the pit.

As the saying goes, since running on the browser, even if the web app to a large extent to provide close to the app experience, but there are a few, is fundamentally different from the app and must consider:

　　1. Application Portal and Access path

The app has almost absolute control over the user's access path: where the user enters the app (icon, notification bar, Share link) is limited and predictable. The sum of the operations portals provided on each page are the complete works of the sub-paths that the user currently has access to.

The Web Access path to the user control is almost 0: any page URL is visible to the user, users can add bookmarks, share to friends and relatives-any page may be directly accessed, must be considered at the design and architectural level.

Authentication and access are not contradictory: This article is accessed strictly by the user request, and authentication or redirection is the processing of the request

　　2. Refresh, rewind, Advance

These three actions are the standard configuration for all Web browser toolbars, and in most cases the app only needs to consider the return operation.

The most troublesome is the refresh: it empties the page memory, re-initiates the request, and re-executes the script. This means that the web-side cross-page memory data is not reliable, if a page depends on the B page in the memory of the data, the next refresh will only be undefined.

　　3. Context Isolation

A user may perform a series of cross-page operations on an app or site, which are called contexts, and the data that the operation produces, such as user selection or form input, is then referred to as contextual data.

Because the app has absolute control over the path right vote does not consider the refresh, in a way the app opens the new view and the cost of opening the modal window on the Web page is the same, the downstream page can assume that the upstream page generated memory data must exist, and that the data completely through the code access, there is no limit to the data structure, so The context data on the app side is complex and can be relied upon.

In view of the Web, since each page can be accessed directly, refreshed, or even replicated to another device, the data stored in memory and Localstorage becomes unreliable, and the only contextual information that can be reliably delivered is limited to the data that can be represented by the URL. In the absence of server Help, the Web-side context data is simple or non-dependent.

Modern mobile browsers provide an application mode that masks the browser toolbar and makes the page more like a native app. However, there are few cases of real application at this stage, and there are at least two problems:

Back cannot be completely masked: The system return key of the Android platform is equivalent to the browser's back.

Tight memory on the mobile side can cause the currently inactive page to be reclaimed by memory and reloaded the next time it is opened-equivalent to a refresh.

　　Why is URL important?

The above three points are all around the core--url, to some extent, the entire web world is identified and driven by the URL, each URL should be targeted to the corresponding resources

And the reality is: You may be doing a consumer (hereinafter referred to as 2C) project, but the demand party did not mention the URL and refresh things, or you can only do a back-end management system, no one cares about this thing, and even some of the URL of the location characteristics of the conflicting requirements.

This is the most horrible thing, and also the original intention of my writing this article: Before the real trouble, very few people (even the senior front-end engineer) will think about this kind of problem comprehensively, wait to fall into the pit to discover Humpty.

Understand these Web apps first, you can go a lot less detours