Three rules for designing interfaces with high-speed user interaction
This post is about how to increase the speed of navigation and user interaction with the interface, without resorting to optimization of calculations and rendering. Recommendations relate to applications where the server is used only for receiving data, and all interface logic is in the application itself. This entry is about the advantage of client applications over applications with poorly divided logic, representation, and data.
Recommendations may be especially valuable for those who have to develop or design an interface, when data from the server do not arrive too quickly, and it is often not possible to access it.
The rules for organizing high-speed user interaction with the application can be formulated as follows:
')
The information presented in this note is my practical experience in designing and developing the interface of my application for searching and listening to music seesu.me . Applications that harmoniously combine huge layers of data from disparate services, such as last.fm, VKontakte, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com
Recommendations related to improving feedback without improving performance were published about the instagram application. But the recommendations did not concern either navigation or receiving data, but, rather, on the contrary, they were related to sending.
speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design
I have not met applications that use similar principles. However, having implemented the requirements of these rules in the system level system, taking them into account when designing interaction with new parts of the application, I can safely say that by adhering to these rules you can drastically improve the user's experience of the speed of interaction with your application.
I came to these rules, as a result of consistent adherence to the principle of "instant feedback", operating under the conditions of technical constraints that stand in the way, and the experiments I have implemented.
Instant feedback is only one of several basic principles that I adhere to. Designing the interface of my application for listening to music, I am guided by the principles and ideas set forth in Jeff Raskin's book "Interface: New Directions in Computer Systems Design". And also conclusions and consequences from his ideas.
Jeff Raskin is a computer interface specialist, author of usability articles and The Humane Interface, employee No. 31 from Apple Computer, best known as the initiator of the Macintosh project at the end of the 70s.
Briefly, I can formulate the basic theses I use from the book as follows:
So, guided by the principle of instant feedback from a book published for the first time in 2000, I launched habrahabr.ru/post/88494 instant search half a year before google launched instant search. en.wikipedia.org/wiki/Google_Search#Instant_Search
More details about each of the rules necessary to ensure quick user interaction with the interface:
When you go to the artist's page, the entire page structure is immediately displayed.
Without waiting for the full download of information about the artist, the user can immediately go to the best compositions of the artist. After the specified transition, the list of the best compositions will be loaded first of all, and only then information about the artist will be obtained.
In order to fully display the artist's page, observing the requirement of issuing the highest possible structured information with a minimum of entered data, seesu fulfills 3 requests in last.fm, 3 at hypem.com, 2 at discogs.com, 2 at soundcloud.com.
And to go to any part of the artist's page, there is no need to wait for the data to be loaded on any of the requests.
You can go to seesu.me/o#/catalog/Pixelord/_ yourself and try to quickly switch between different compositions in order to make sure that the data for the last selected composition will be loaded as soon as possible. And only then the data for the next song and some data for the previous one will be loaded.
Also (as an experiment) you can try to open the list of lists of tracks of last.fm user http://seesu.me/o#/users/lfm:yodapunk/tracks , where elements are loaded from top to bottom. Select the last item you’ve downloaded and make sure it’s loaded, then you can instantly go back to find out that your selected list is loaded out of turn.
The combination of these three approaches and the relatively fixed location, the height and width of the visual blocks allow for comfortable and extremely fast movement within the application, forming a habit. Accelerating rendering, computing and reducing the time to receive a response from the server will make the application lightning fast, and the unobtrusive animation of page transitions will smooth out the impression of a delay in performing network requests (in Seesu, I use 120 ms animation).
When I mentioned technical difficulties, I meant both the restrictions on network requests for services that I use and the restrictions and load on browsers.
For example, VKontakte forbade sending more than one request per second.
Having implemented the queue with sending requests (for searching files for songs) every second, I found that the execution of the entire queue was delayed for a very long time. The queue is formed quickly enough: cost only to click on several different compositions. Waiting for the playback of the last selected song to begin becomes unpleasant, especially when you see that the files are not searched for the selected song, but for those whose playback you refused. It became clear that the files should be found first of all for the currently selected composition.
I began to display the structure of the pages after some reflections on the principle of displaying the maximum of structured information with minimal input. On the client side, I have a template - information about the visual structure of the page, its skeleton. Why not display it? Instant display of the template and the data that I received not for the page, but which can be used on it - is a direct adherence to one of those principles that I formulated for myself by reading the book
- the principle of instant feedback, displaying the maximum of structured information with a minimum of data entered from the user.
The last.fm service api has no restrictions on the number of requests, however, if you quickly move from page to page, the number of simultaneously executed requests could in some cases exceed 6 (six). No browser opens more than 6 connections to a single domain. With a large number of requests becomes noticeable load on it. I noticed that the user may change his mind and move to another page before data is received on request. This observation makes it obvious that the instant sending of requests does not reduce the wait for the user to receive the necessary information, but, on the contrary, increases. Having understood this, I made the decision to discharge and suspend all network requests.
Prioritization of requests at the initial stage was implemented exclusively for pages with a list of tracks. Later, when I became much more active in using last.fm api, connecting new data sources, I implemented the prioritization and discharge of requests for all pages, for all api. Now, when moving from page to page, when adding a new request to an existing queue, priorities are automatically recalculated, changed, taking into account the current page and the requests it needs. The remaining requests are executed (not completed) in the reverse order of addition.
Discharging requests can help a lot when there is no opportunity to influence the server side, as well as in cases where the server side needs to be handled with care.
Have you ever heard?
- “THERE WILL BE A BIG LOAD ON A SERVER!”
With the help of delayed dispatch, discharge of requests and instant feedback in September 2010, rossomachin and I made the coolest form of domain check shop.masterhost.ru/templates/default/domains . Despite the technical limitations and limited implementation of our wishes from the server developers.
If we want to be surrounded by modern interfaces, then we must have the tools, ways of describing interfaces, programming languages that take into account at least the requirements for interfaces formulated 14 years ago. The efficiency of creating interfaces should greatly increase.
Someone is still not obvious benefit from instant feedback. Someone is inspired by this principle and the possible productivity of interacting with interfaces that respect it. For example, with interfaces that provide instant interpretation of the entered data:
At the same time, according to the minimal existence of applications with instant feedback, it can be concluded that there are few people who have put their hands on the implementation of such applications. It is easy to find an explanation for this - the implementation of such principles is a truly labor-intensive process.
Consistent and systematic observance of the principle of instant feedback in the implementation in the system required me additional programming, time to design additional interface states.
In my case, all pages of the application should be designed with the ability to display them without loaded data; taking into account that the page should be filled, redrawn as data becomes available. From the point of view of technical implementation, such a requirement should have been done without a load on the browser - using atomic DOM changes. Or using the redrawing of huge visual blocks, which would cause a load on the browser. A loaded browser deprives the user of fast interaction. On the implementation of the partial redrawing of the display, time must first be spent first in a manual, semi-automatic way for each page. Later this time will be reduced to the minimum after the time spent on creating a system for automatic redrawing. The prioritization of requests, taking into account interconnections, should have been implemented, because there are many requests and they form uncontrollable queue loading the browser.
In addition to consistently adhering to this principle, I consistently implement other principles from the book of Jeff Raskin. For example, the absence of modal windows, the presentation of data in the form of a scalable structure. Principles determine not only how the application looks, but how the application code is written. Principles, of course, determine how much time will be spent on developing an application.
In order to organize the code that meets the complex requirements and not to get away with it, working alone with the application with huge layers of data, I use a self-written framework and a template engine. The code describes the complex interrelations of objects, the interrelations of their states, the structure of pages; meets the requirements of data mapping in a scalable structure, prioritization of objects, convenient templating, the principle of separation of MVC. I am sure that I can cope with the construction of any new interface that meets all the requirements listed above, using my own tools together in a bundle more efficiently than using other tools existing in the market. The effectiveness of my tools can be improved, but even after the improvements, none of this can become a tool that makes it possible to build modern interfaces for wide layers of developers. As well as other libraries are not such a tool. At the same time it is obvious to me that the existence of such tools is possible.
Recommendations may be especially valuable for those who have to develop or design an interface, when data from the server do not arrive too quickly, and it is often not possible to access it.
The rules for organizing high-speed user interaction with the application can be formulated as follows:
')
- Calculations should not block interaction with the interface and its rendering - the user should always be able to indicate the focus of their interests.
- The page of the object addressed by the user should be displayed instantly, without waiting for the data that the object needs to load.
- Requests to the network should not leave one large group, should not be sent immediately; should be postponed for a short time, folded and prioritized if necessary.
The information presented in this note is my practical experience in designing and developing the interface of my application for searching and listening to music seesu.me . Applications that harmoniously combine huge layers of data from disparate services, such as last.fm, VKontakte, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com
Recommendations related to improving feedback without improving performance were published about the instagram application. But the recommendations did not concern either navigation or receiving data, but, rather, on the contrary, they were related to sending.
speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design
I have not met applications that use similar principles. However, having implemented the requirements of these rules in the system level system, taking them into account when designing interaction with new parts of the application, I can safely say that by adhering to these rules you can drastically improve the user's experience of the speed of interaction with your application.
I came to these rules, as a result of consistent adherence to the principle of "instant feedback", operating under the conditions of technical constraints that stand in the way, and the experiments I have implemented.
Instant feedback is only one of several basic principles that I adhere to. Designing the interface of my application for listening to music, I am guided by the principles and ideas set forth in Jeff Raskin's book "Interface: New Directions in Computer Systems Design". And also conclusions and consequences from his ideas.
Jeff Raskin is a computer interface specialist, author of usability articles and The Humane Interface, employee No. 31 from Apple Computer, best known as the initiator of the Macintosh project at the end of the 70s.
Briefly, I can formulate the basic theses I use from the book as follows:
- The presentation of information should be implemented as a scalable structure;
- Instant feedback, the issuance of the highest possible structured information with a minimum of entered data;
- Only contextual requirement for additional user input. Only at the time of the immediate need for additional data.
- The rejection of "intuitiveness", "number of clicks", "number of clicks" as a measure of the effectiveness of the interface;
- Formation of new user habits;
- Complete rejection of modal windows.
So, guided by the principle of instant feedback from a book published for the first time in 2000, I launched habrahabr.ru/post/88494 instant search half a year before google launched instant search. en.wikipedia.org/wiki/Google_Search#Instant_Search
More details about each of the rules necessary to ensure quick user interaction with the interface:
- Whatever happens in the application, no matter how busy it is with calculations, the user can always indicate what he needs. In an application written in Java, I use setTimeout to unlock the interface (I also plan to use setImmediate, and requestAnimationFrame - rendering should not block the ability to click for a long time, etc.).
- Immediately, even before loading the data that fills the object, not just the object page itself is displayed, not the empty screen, but its entire structure. Its parts, visual blocks that somehow depend on data not yet received from the network are displayed. In addition, all blocks of objects nested in this object are displayed. When data arrives, the displayed blocks are filled. This allows the user to immediately analyze the structure of the page and make a decision about moving to another object, without waiting for the download to complete.
- When moving from object to object, the user clearly indicates the focus of their interests. First of all, data retrieval requests for the user's landing page should be executed. The remaining requests can be executed later or canceled altogether, for example, such as outstanding requests for pages that the user has left. Objects can be nested in other objects and have their own queries. Some of the queries may be needed to display data in the context of user interest, while others are not. The priorities of such requests should also be changed, and in the order in which the data is used on the page, and, accordingly, in the order in which the representations of nested objects are declared. (Ie, a page consisting of a set of elements and nested objects will be replenished as data is received from top to bottom).
When you go to the artist's page, the entire page structure is immediately displayed.
Without waiting for the full download of information about the artist, the user can immediately go to the best compositions of the artist. After the specified transition, the list of the best compositions will be loaded first of all, and only then information about the artist will be obtained.
In order to fully display the artist's page, observing the requirement of issuing the highest possible structured information with a minimum of entered data, seesu fulfills 3 requests in last.fm, 3 at hypem.com, 2 at discogs.com, 2 at soundcloud.com.
And to go to any part of the artist's page, there is no need to wait for the data to be loaded on any of the requests.
You can go to seesu.me/o#/catalog/Pixelord/_ yourself and try to quickly switch between different compositions in order to make sure that the data for the last selected composition will be loaded as soon as possible. And only then the data for the next song and some data for the previous one will be loaded.
Also (as an experiment) you can try to open the list of lists of tracks of last.fm user http://seesu.me/o#/users/lfm:yodapunk/tracks , where elements are loaded from top to bottom. Select the last item you’ve downloaded and make sure it’s loaded, then you can instantly go back to find out that your selected list is loaded out of turn.
The combination of these three approaches and the relatively fixed location, the height and width of the visual blocks allow for comfortable and extremely fast movement within the application, forming a habit. Accelerating rendering, computing and reducing the time to receive a response from the server will make the application lightning fast, and the unobtrusive animation of page transitions will smooth out the impression of a delay in performing network requests (in Seesu, I use 120 ms animation).
How I came to these rules
(you can not read)When I mentioned technical difficulties, I meant both the restrictions on network requests for services that I use and the restrictions and load on browsers.
For example, VKontakte forbade sending more than one request per second.
Having implemented the queue with sending requests (for searching files for songs) every second, I found that the execution of the entire queue was delayed for a very long time. The queue is formed quickly enough: cost only to click on several different compositions. Waiting for the playback of the last selected song to begin becomes unpleasant, especially when you see that the files are not searched for the selected song, but for those whose playback you refused. It became clear that the files should be found first of all for the currently selected composition.
I began to display the structure of the pages after some reflections on the principle of displaying the maximum of structured information with minimal input. On the client side, I have a template - information about the visual structure of the page, its skeleton. Why not display it? Instant display of the template and the data that I received not for the page, but which can be used on it - is a direct adherence to one of those principles that I formulated for myself by reading the book
- the principle of instant feedback, displaying the maximum of structured information with a minimum of data entered from the user.
The last.fm service api has no restrictions on the number of requests, however, if you quickly move from page to page, the number of simultaneously executed requests could in some cases exceed 6 (six). No browser opens more than 6 connections to a single domain. With a large number of requests becomes noticeable load on it. I noticed that the user may change his mind and move to another page before data is received on request. This observation makes it obvious that the instant sending of requests does not reduce the wait for the user to receive the necessary information, but, on the contrary, increases. Having understood this, I made the decision to discharge and suspend all network requests.
Prioritization of requests at the initial stage was implemented exclusively for pages with a list of tracks. Later, when I became much more active in using last.fm api, connecting new data sources, I implemented the prioritization and discharge of requests for all pages, for all api. Now, when moving from page to page, when adding a new request to an existing queue, priorities are automatically recalculated, changed, taking into account the current page and the requests it needs. The remaining requests are executed (not completed) in the reverse order of addition.
Discharging requests can help a lot when there is no opportunity to influence the server side, as well as in cases where the server side needs to be handled with care.
Have you ever heard?
- “THERE WILL BE A BIG LOAD ON A SERVER!”
With the help of delayed dispatch, discharge of requests and instant feedback in September 2010, rossomachin and I made the coolest form of domain check shop.masterhost.ru/templates/default/domains . Despite the technical limitations and limited implementation of our wishes from the server developers.
About the future of interface development
(you can not read)If we want to be surrounded by modern interfaces, then we must have the tools, ways of describing interfaces, programming languages that take into account at least the requirements for interfaces formulated 14 years ago. The efficiency of creating interfaces should greatly increase.
Someone is still not obvious benefit from instant feedback. Someone is inspired by this principle and the possible productivity of interacting with interfaces that respect it. For example, with interfaces that provide instant interpretation of the entered data:
At the same time, according to the minimal existence of applications with instant feedback, it can be concluded that there are few people who have put their hands on the implementation of such applications. It is easy to find an explanation for this - the implementation of such principles is a truly labor-intensive process.
Consistent and systematic observance of the principle of instant feedback in the implementation in the system required me additional programming, time to design additional interface states.
In my case, all pages of the application should be designed with the ability to display them without loaded data; taking into account that the page should be filled, redrawn as data becomes available. From the point of view of technical implementation, such a requirement should have been done without a load on the browser - using atomic DOM changes. Or using the redrawing of huge visual blocks, which would cause a load on the browser. A loaded browser deprives the user of fast interaction. On the implementation of the partial redrawing of the display, time must first be spent first in a manual, semi-automatic way for each page. Later this time will be reduced to the minimum after the time spent on creating a system for automatic redrawing. The prioritization of requests, taking into account interconnections, should have been implemented, because there are many requests and they form uncontrollable queue loading the browser.
In addition to consistently adhering to this principle, I consistently implement other principles from the book of Jeff Raskin. For example, the absence of modal windows, the presentation of data in the form of a scalable structure. Principles determine not only how the application looks, but how the application code is written. Principles, of course, determine how much time will be spent on developing an application.
In order to organize the code that meets the complex requirements and not to get away with it, working alone with the application with huge layers of data, I use a self-written framework and a template engine. The code describes the complex interrelations of objects, the interrelations of their states, the structure of pages; meets the requirements of data mapping in a scalable structure, prioritization of objects, convenient templating, the principle of separation of MVC. I am sure that I can cope with the construction of any new interface that meets all the requirements listed above, using my own tools together in a bundle more efficiently than using other tools existing in the market. The effectiveness of my tools can be improved, but even after the improvements, none of this can become a tool that makes it possible to build modern interfaces for wide layers of developers. As well as other libraries are not such a tool. At the same time it is obvious to me that the existence of such tools is possible.
Source: https://habr.com/ru/post/211659/
All Articles