Four ways to make a mobile site look like a native application

Building well-designed websites on mobile devices is becoming easier. No matter what method you use (responsive design, adaptive, etc.), if you know what you're doing, creating an aesthetically pleasing website is not an issue.

However, your users may still require the site to have a native app experience. Completing such an experience is a challenge.

Most of the time, when people talk about "app" or "native" feelings, they're not talking about the visual experience of a website. What they are talking about is how the user interface feeds their behavior and how that feedback is presented.

Native applications are "fast". The native app's animation renders smoothly, the button responds to the user's clicks in a timely manner, and when the app loads the data there is no problem.

Making your site like a native app means you need to improve the speed of your site's response and interactions as much as possible

Improving performance has been a hot and valuable topic. Until recently, the web was moving toward cumbersome and slow development. The industry has been arguing that achieving a high-performance webapp is impossible.

That's why Facebook is moving to native apps, at least under their development resources, without the speed and interaction they need to do.

Even if Facebook thinks so, it's not impossible to build a high-performance Web site. But it's not in our hands. We just have to work hard to make it happen. Technically speaking, we have the ability to make our website faster, more fashionable, and more perfect to experience.

Perceived performance vs. real-world performance

Real-world performance improvements are important, but it does not mean that these boosts can reach the user if they are not perceived as an improvement.

Earlier this year, Luke Wroblewski in Seattle mentioned his mobile app-polar. He explained that his team was trying to increase the speed at which the polls were loaded.

Polar is a very concise voting application--99

At the same time, they introduced a small icon to show the user that the vote was being loaded. And then, the user feels the vote loads very slowly and the feedback is immediately overwhelming, despite the fact. Loads much faster. Polar quickly released a patch to remove the loading icon, after which the user was impressed by the fast loading of the poll.

This is a good example of the importance of expressing perceived performance. When people "feel" a website is unhappy, then this site is no longer useless. Loading the icon just lets the user notice the fact that the data is loading and the user can only wait, not to draw attention.

As designers and developers, our goal should not be to build the fastest websites with some digital growth, and also to create the fastest website experience.

So the most important thing is how users perceive the speed of your website. Any real performance improvement is just a icing on the cake. I think the improvement in perceived performance is more important than the actual performance. But that doesn't mean you need to ignore real-world performance improvements.

Ok, explain enough, how can you immediately improve the perceived performance of the site?

Here are four tips that you can start immediately to try

Add touch State to a button

The simplest way to improve site-aware performance is to add "active" status to your site.

You see, whenever a visitor clicks on a button on the site, she has to wait 300 milliseconds before she knows what's going on.

The browser sets this time-out and then ensures that the user does not do something else (double-click). So after waiting 1/3 seconds, the browser knows the user's actions and performs the initial click. When this action occurs, the button is covered by a gray-colored thing.

This is a bad user experience. The Nielsen organization conducted a study that found that any delay above 100ms would make users think they were waiting. They may just want to do a jump.

However a lot of mobile sites, including those I do, do not consider this perception problem. The designer's usual design is to touch the button or link to keep it as it is.

To make your site feel faster, you need to have your button respond to the user's touch immediately, giving the user a clear visual indication that something is happening.

There is a great property for a button or link on the site; it is: Active pseudo class. We always use this pseudo-class on the desktop side.

Unfortunately, whether it's iOS or Android, when a button or link is clicked it ignores this attribute, in order to activate this state, you need to add a simple event bound to the page's javascript:

document.addEventListener("touchstart", function(){}, true)

You can then use CSS to define the style of the active state, and then remove the highlight when clicked:

-webkit-tap-highlight-color: rgba(0,0,0,0);

By setting these two properties on the button, the user immediately senses that the interface responds to the user's actions, even if the final response speed is the same. You just let your interface instantly feed back the user's actions, without letting users fool around and see what they're doing.

No touch Status (code)

Touch Status (code)

But if you want to respond to the user's actions immediately, you can use a different scenario.

With a JavaScript function such as Fasttap or Fastclick, you can completely remove the 300 millisecond delay after the click button. With the active state, you can make the website bright Blind your eyes.

For more information on FASTTAP, you can read Google search articles, which has a ready-made case that you can export from GitHub.

Use elastic scrolling

Have you ever tried to create a scrollable container and then be tortured by the default slow and unresponsive scrolling madness?

Now it's free, android3+ and the ios5+ version adds a new attribute: overflow-scrolling This property activates smooth scrolling and works well.

No scroll bar (code)

with scroll bar (code)

This elastic scrolling feels like a native application, because this is originally a native scroll. You only need to add one line of code to the scrollable area.

-webkit-overflow-scrolling: touch;

However, there is a problem with this property. This property will disable the ability to click on the iphone header status bar to get the page back to the top. This bug has been around for some time and seems to have not been fixed in the new iOS7 release.

There is a way to solve this problem by creating a class for the container and applying the attributes overflow-scrolling: touch . When and only if the container is displayed, use JavaScript to add the class to the container.

You do not need to use this property on Android4. Each scrollable container contains an elastic scroll.

You have two options on older versions of Android. My preferred solution is to use MODERNIZR to detect elastic scrolling and then to control the display of the containers in the layout. In addition, there are some JavaScript libraries you can try, such as OVERTHORW and Iscroll.

Create an efficient animation

One of the most obvious differences between apps and websites is the animation effect.

Now on the device, the application has been able to take full advantage of hardware graphics acceleration. On the web side, developers use JavaScript-based animations, which are slow to run on the mobile side of the CPU.

But now, with the constant support of mobile browsers, you can use hardware-accelerated CSS3 animations in your project.

In this way, we can add some visual effects that have been applied for many years by some of our favorite apps.

In fact, it's not that fast, shut up animation is close to the native experience, you need to avoid the animation slow and jitter, and this is difficult to deal with. Steamclock Software Allen Pike wrote a great article about the joy that animations bring to the user, and also about the low-performance animations that have a big impact on the user experience on the app.

Interestingly, he wrote this article about native application development. This makes this article quite useful, and we can follow the following tasks to create animations on the web.

In the article, he puts forward a so-called "timeline sense":

• The animation will run under 60fps . This means that each frame takes 16ms to run (1000ms/60=16). This is the most basic requirement to achieve a native, application-like, smooth experience. The FPS is the speed at which all iOS built-in animations run, which is why scrolling on the iphone feels better than Android devices (although Google has made great strides). You should try to get all the interactive animations that are directly related to the user running at this speed.
• Everything must be rendered within 100ms . It's a mental slow-down line. Any delay of less than 100ms will give the user a sense of instantaneous response.
• if it's definitely more than 100 milliseconds, it should definitely respond within 1000 milliseconds. Allen indicates that any operation that takes so long to complete should give the user some reaction that is occurring. For example, a rotating icon or a progress bar. But, as we've already done with the voting app example, focusing the user's attention on that little Daisy may actually do more harm than benefit. I'll show you a different way to deal with this problem.
• All response times of more than two seconds are bullying.

Well, you know that, so you probably want to take the keyboard as a hat and go for a career change. When do we need to take care of the animation time to create a website?

Don't worry, there are some great resources to make these things easier to achieve!

The first one is the effeckt.css in HTML5 boilerplate. Their goal is to achieve some of the common transitions and animations that run under 60fps. Although the library has not been completely completed, many of the results have been very well run. I highly recommend that you use this library in your project.

Another good library is the code written by the Topcoat,adobe network team, a library of CSS components built on performance considerations. The library is packed with excellent components that run smoothly. Because performance is their primary goal, each component has been tracked for performance, so you can clearly see the performance of the component.

The above two libraries are going hand in hand, and topcoat also contributed code to EFFECKT.CSS, both of which ran very well.

Then, I'm going to discuss what I mentioned earlier and try to get rid of the scenario of loading hints.

My tendency is that when the wait time is greater than 100ms and less than 250ms, using the load icon will do more harm than benefit, so it can be hidden away.

For example, if you use Ajax to request content, you can apply animations to the content's container, such as shrinking and expanding to accommodate the new content. This short animation distracts the user from waiting, rather than letting the user stare at a small, spinning daisy-they just wait for a short animation to finish, even unaware that the new content doesn't appear.

Of course, repetitive animations that take a long time to complete are very annoying, so we want to use these animations appropriately. This is the truth for most animations.

Provides a natural gesture experience

The app is a bit more than a web-side experience, and it's a natural gesture that can be provided on a touch device.

Mailbox and clear can be used as a good example of gestures. These apps use simple gestures to take advantage of the biggest features of a mobile device-you can touch objects on the screen directly.

Most Web sites, however, use only touch objects. Designers are wary of gestures, resulting in user perceptions of discrimination on the web side.

We need to consider developing a website directly for the device. If a user's device allows gesture manipulation, why not use them?

Of course, there is a small problem: the mobile operating system has a hateful feature, mobile browser will hijack gestures as their own.

For example, apps like Facebook Open the navigation by touching the left and right sides of the screen. However, in a browser segment, this interaction is not available. For Chrome, this action is used to toggle tabs. IOS 7 new version of Mobile Safari uses this operation to move forward, with the back.

All right. These gestures are outside our controllable range. So what gestures should you use? Here are four examples.

Gesture 1: Swipe left and right

Even if there is an edge problem, the left and right strokes are still a handy gesture. You just need to be careful not to get too close to the edge of the screen when triggered.

The best app for this gesture is to move a group of objects, such as a slide or list label.

Gesture 2: drop-down refresh

A drop-down refresh is also a gesture that the user touches. Here are some great JS libraries can easily implement this feature, I use hook.js to achieve.

Gesture 3: Long Press

There is a very useful property: -webkit-touch-callout: none . This disables the default long-press effect in the Mobile Safari browser. Disabling this effect on Android will require a bit of effort.

Long-press gestures can be used to pick up an item, such as reordering items in a list, or to show more options, such as social sharing.

Gesture 4: Two-finger zoom

Everyone knows two-finger scaling. Many people will try to zoom in on the image to see the details after seeing the web-side picture.

There is also the case of browser hijacking user gestures, but not very difficult.

When you lock or do not lock the viewport, you sometimes do not want users to zoom the entire page when the two-finger zoom. To replace this multi-fingered gesture, you can use this small and fine harmmer.js library. This library has a series of gestures that you can use, and you can create your own gestures.

A good example of two-finger scaling is Imgur.com's mobile station. You can swipe two to see what happens.

Just remember, if you're using a gesture, make sure it feels natural or meaningful to the user.

Conclusion

I hope someday, we won't need to differentiate between local and network. The road is a long way to repair, our job is to let users feel that the site is designed around them, this day will soon come.

I think the recent trend towards performance is great, but it must be remembered that our users are not machines.

They don't care how many requests your site has and how quickly the screen is redrawn. But they do care about something that affects their experience-their perceived performance.

Focus on making sure your site looks and behaves like a website as fast as possible. If the user is not aware of it is not eligible to be called "the fastest site."

If you have any suggestions for improving your perceived performance, please post them in the comments.

Four ways to make a mobile site look like a native application