Cave technology of the future
Never paid attention, how often old interfaces, old code and generally old solutions look strange and ugly? And all this can become old in a few years. When you have to run very fast just to stay in place, there is a desire to somehow cut off, look a little into the future, jump over a couple of points.
Let's try. To do this, we need to understand the principles for the development: to carefully consider the cave technologies that we used a couple of years ago and how they turned into “technologies of the future” that we use today.
A few years ago, building an admin panel for a photo gallery on one site, I realized that the usual layout approach at the time in the form of several inputs is not so good, especially considering the need to download a previously unknown and relatively large number of photos. The solution was the creation of five fields and the “add more” link, which dynamically created another additional field. With the help of a colleague, I attached the link “add another 5”, and the “technology of the future” was ready.
And she was really good, for a while, after which in another project, I used to download pictures in the archive. The new method had its advantage - there is no need to choose a lot of files, and its shortcomings - a person needs to pre-pack their images (normal for admin panel, unacceptable for frontend) and there is no possibility to manage the order of images.
')
As time went on, and just over a year ago, the same task arose again, as usual, on the next new project. There were differences, firstly, this time the form was “for people”, and, secondly, the maximum number of photos per form was small (the photos really grew up, gained weight in the past tense). The implemented solution in the end was this - one field, with the filling immediately sent via the iframe, the processing results (URL and statistics) are slipped into a hidden field in the original form and are shown as a miniature. There are many advantages, but the main thing for us was the possibility of separate loading of images and forms (you can fill out the form while the images are loaded, thus reducing the waiting time) and the ability to download images to a separate server, bypassing the application server. By wrapping the whole thing in a widget, we saved ourselves from any need to process image downloads in this project. Due to this, this method has become for us the next “technology of the future” for a year.
As you can imagine, after a year the old decision did not satisfy us and we decided to upgrade it. Firstly, in all browsers that are able (all but IE), the file upload field was made multiple. Secondly, again, where possible (everywhere except IE and Opera) instead of iframe, AJAX 2 with its cross-domain file downloads was used, while using the File API, the multiple file set was broken up into separate files, which accelerated the download and simplified the server part (no need to parallelize the pin, no need to aggregate errors into one result). Well, that sounds pretty cool bye.
In my short story about downloading images, I mentioned various reasons and advantages of separate steps, both interface and technical. Now let's drop everything that doesn't apply to the interface, and try to figure out where it all goes.
To separate the interface from everything else, you need to clearly understand what it is. What is the interface? Okay, this is too complicated a question to warm up, let's ask another, simpler one. When do we encounter an interface? The general answer could be this: when we are dealing with a system (program, service) and we want it to do something for us. It sounds reasonable, we will dance from this, with a small amendment: the system is usually an intermediary between us and other people (or between us and physical reality), so it should be discarded from the wording, i.e. we encounter the interface when we want something. In this way:
The interface is an obstacle between a person and what he wants.
So that this conclusion and the last few phrases do not seem muddy and excessive generalization, let us return to the example with loading photos. What does a person want when he accesses this interface? Upload images to the site? Not quite, more precisely, this is only partly true, in fact, he wants to show others what he sees / sees himself. The second formulation is more general and it gives its advantages - it becomes obvious that both the “site” and the “pictures” are additional entities not contained in the original task, if it were possible to fulfill the desire to “show what I see to others” without this and the other. would be a win in terms of the interface.
It immediately follows from the definition that the ideal interface is one where the user's desire is executed immediately without additional steps. And these very additional steps and entities not contained in the task itself, but used in the interface, constitute the complexity of the interface.
Well, having gained all this wisdom, we will try to apply it to the story with pictures. For clarity, let us write out all the elements of interface complexity for each case.
0. What was before. Steps - selecting a file for each image in a separate field; if there are not enough fields, you need to repeat everything. Additional entity - the maximum number of pictures at a time.
1. Add fields dynamically. Steps - the choice of each picture in a separate field, with a lack of fields, add them using one and special links. Additional entities - add field references.
2. Download archive. Steps - creating an archive with the desired images, selecting the archive file in the field. An additional entity is an archive.
3. Iframe. Steps - select photo files one by one in a single field.
4. multiple + Files API + AJAX 2. Steps - select all the necessary photo files in the download field.
It can be seen that with each iteration of steps and additional concepts it becomes less and less, the last option seems to be generally excellent - just one step and not a single superfluous entity!
As if not so. Let us recall the most general formulation of what the user wants: “show others what he sees himself” and immediately notice the additional steps and entities common to all the above options. Steps - taking photos, transferring them to a computer, launching a browser, entering a site, authorizing, filling out a form, sending a form. Entities - downloading files, files, photos, camera, computer, browser, website, form, Internet.
Damn it, there is room to grow! And it looks like our future technology will become the same artifact as all previous ones, too many possible improvements. Let's see how you can eliminate these additional steps and concepts.
One effective way to eliminate a step is to make it automatic, if the user does not need to think about something, then it ceases to be an interface element.
Uploading files can be replaced with automatic synchronization, this is what Dropbox already does and, in part, Google Docs. The Dropbox example is indicative of the fact that it solves one but a very common problem and builds its entire business on this.
Transferring files to a computer, launching the browser replace mobile applications. The Dropbox client on the phone effectively eliminates these steps, just like any other mobile application for working with the site. There is even a whole ChromeOS operating system that eliminates the need to launch a browser (in addition, of course, it greatly simplifies the installation of applications and the synchronization of the working environment).
You can even eliminate such fundamental concepts as files or the Internet. The concept of files is quite successfully hidden in iOS, where the user deals with images, videos, music, books or contacts, with anything, but not with files. The Internet disappears (from the user's worries, and therefore from the interface) if it simply is always and everywhere, a free universal connection for Amazon Kindle 3G, in this sense, is not just free traffic, it is a qualitative improvement in the interface.
We see that someone somehow overcomes the many remaining fragments of the interface. The question was what would come up with to improve our interface. Let's go back to the example with the pictures again.
You can go on the synchronization path. All the pictures on a computer, stored in a specific folder, can appear on the site (you can add a special step of publishing them, although it is better, for example, to publish everything in “unsorted”, giving the user the opportunity to put everything in order at his convenience. Synchronization will be even more convenient in the case of a mobile application - all the pictures taken can simply appear on the site.
All this is great for large resources (if I were Flickr, I would seriously think about how to shove my client into cameras), but what should the author of a small site do? The answer is to integrate with external services. If we need to get a photo from the user, this does not mean that we need to organize the download of files, in fact, this does not even mean that the user needs to upload something (for example, because he has already done it). We need to think where we can get these photos. And such places are not so few: avatar can be tied off with Gravatar, various photos from social networks and services like Flickr, any files from Dropbox.
Using third-party services gives great advantages:
- at some point you can simply refuse to implement and support this site functionality on your own,
- you automatically receive (provide your users) all the amenities that appear in the services with which you integrate. Dropbox releases client for PS 3 - you can upload screenshots from there, Flickr makes the notorious client for cameras - you are again in the win.
Such outsourcing not only allows you to get a better interface, it allows you to focus on what exactly your service does. For example, if you conceived to create an online editor for creating collages, then using traditional methods you need to implement user registration / authorization, image uploading, a comment system (where to go without them?) And your application itself is a specially sharpened photo editor. Instead of doing all this yourself, you can use social networks for authorization, theirs, Flick and Dropbox as a source of photos and Disqus as a commenting system. In addition, third-party services (social networks, mostly) will also serve as an excellent publishing environment, and therefore word of mouth advertising for your application. All you have to do is to create what you actually did — the online collage editor (plus put it all together, of course).
The chances are great that if you don’t spend time on developing and supporting all non-core functionality, then the essence, your creation - the collage editor, in this case - will be better. Your application will do one simple thing well. And to complete the Unix-way analogy, teach your application to work with others - provide an API.
You decide what you are doing - another (possibly good) service or another stone in the foundation of the future network.
Let's try. To do this, we need to understand the principles for the development: to carefully consider the cave technologies that we used a couple of years ago and how they turned into “technologies of the future” that we use today.
One extensive example
A few years ago, building an admin panel for a photo gallery on one site, I realized that the usual layout approach at the time in the form of several inputs is not so good, especially considering the need to download a previously unknown and relatively large number of photos. The solution was the creation of five fields and the “add more” link, which dynamically created another additional field. With the help of a colleague, I attached the link “add another 5”, and the “technology of the future” was ready.
And she was really good, for a while, after which in another project, I used to download pictures in the archive. The new method had its advantage - there is no need to choose a lot of files, and its shortcomings - a person needs to pre-pack their images (normal for admin panel, unacceptable for frontend) and there is no possibility to manage the order of images.
')
As time went on, and just over a year ago, the same task arose again, as usual, on the next new project. There were differences, firstly, this time the form was “for people”, and, secondly, the maximum number of photos per form was small (the photos really grew up, gained weight in the past tense). The implemented solution in the end was this - one field, with the filling immediately sent via the iframe, the processing results (URL and statistics) are slipped into a hidden field in the original form and are shown as a miniature. There are many advantages, but the main thing for us was the possibility of separate loading of images and forms (you can fill out the form while the images are loaded, thus reducing the waiting time) and the ability to download images to a separate server, bypassing the application server. By wrapping the whole thing in a widget, we saved ourselves from any need to process image downloads in this project. Due to this, this method has become for us the next “technology of the future” for a year.
As you can imagine, after a year the old decision did not satisfy us and we decided to upgrade it. Firstly, in all browsers that are able (all but IE), the file upload field was made multiple. Secondly, again, where possible (everywhere except IE and Opera) instead of iframe, AJAX 2 with its cross-domain file downloads was used, while using the File API, the multiple file set was broken up into separate files, which accelerated the download and simplified the server part (no need to parallelize the pin, no need to aggregate errors into one result). Well, that sounds pretty cool bye.
Interface
In my short story about downloading images, I mentioned various reasons and advantages of separate steps, both interface and technical. Now let's drop everything that doesn't apply to the interface, and try to figure out where it all goes.
To separate the interface from everything else, you need to clearly understand what it is. What is the interface? Okay, this is too complicated a question to warm up, let's ask another, simpler one. When do we encounter an interface? The general answer could be this: when we are dealing with a system (program, service) and we want it to do something for us. It sounds reasonable, we will dance from this, with a small amendment: the system is usually an intermediary between us and other people (or between us and physical reality), so it should be discarded from the wording, i.e. we encounter the interface when we want something. In this way:
The interface is an obstacle between a person and what he wants.
So that this conclusion and the last few phrases do not seem muddy and excessive generalization, let us return to the example with loading photos. What does a person want when he accesses this interface? Upload images to the site? Not quite, more precisely, this is only partly true, in fact, he wants to show others what he sees / sees himself. The second formulation is more general and it gives its advantages - it becomes obvious that both the “site” and the “pictures” are additional entities not contained in the original task, if it were possible to fulfill the desire to “show what I see to others” without this and the other. would be a win in terms of the interface.
It immediately follows from the definition that the ideal interface is one where the user's desire is executed immediately without additional steps. And these very additional steps and entities not contained in the task itself, but used in the interface, constitute the complexity of the interface.
Learn lessons
Well, having gained all this wisdom, we will try to apply it to the story with pictures. For clarity, let us write out all the elements of interface complexity for each case.
0. What was before. Steps - selecting a file for each image in a separate field; if there are not enough fields, you need to repeat everything. Additional entity - the maximum number of pictures at a time.
1. Add fields dynamically. Steps - the choice of each picture in a separate field, with a lack of fields, add them using one and special links. Additional entities - add field references.
2. Download archive. Steps - creating an archive with the desired images, selecting the archive file in the field. An additional entity is an archive.
3. Iframe. Steps - select photo files one by one in a single field.
4. multiple + Files API + AJAX 2. Steps - select all the necessary photo files in the download field.
It can be seen that with each iteration of steps and additional concepts it becomes less and less, the last option seems to be generally excellent - just one step and not a single superfluous entity!
As if not so. Let us recall the most general formulation of what the user wants: “show others what he sees himself” and immediately notice the additional steps and entities common to all the above options. Steps - taking photos, transferring them to a computer, launching a browser, entering a site, authorizing, filling out a form, sending a form. Entities - downloading files, files, photos, camera, computer, browser, website, form, Internet.
Damn it, there is room to grow! And it looks like our future technology will become the same artifact as all previous ones, too many possible improvements. Let's see how you can eliminate these additional steps and concepts.
One effective way to eliminate a step is to make it automatic, if the user does not need to think about something, then it ceases to be an interface element.
Uploading files can be replaced with automatic synchronization, this is what Dropbox already does and, in part, Google Docs. The Dropbox example is indicative of the fact that it solves one but a very common problem and builds its entire business on this.
Transferring files to a computer, launching the browser replace mobile applications. The Dropbox client on the phone effectively eliminates these steps, just like any other mobile application for working with the site. There is even a whole ChromeOS operating system that eliminates the need to launch a browser (in addition, of course, it greatly simplifies the installation of applications and the synchronization of the working environment).
You can even eliminate such fundamental concepts as files or the Internet. The concept of files is quite successfully hidden in iOS, where the user deals with images, videos, music, books or contacts, with anything, but not with files. The Internet disappears (from the user's worries, and therefore from the interface) if it simply is always and everywhere, a free universal connection for Amazon Kindle 3G, in this sense, is not just free traffic, it is a qualitative improvement in the interface.
Closer to life
We see that someone somehow overcomes the many remaining fragments of the interface. The question was what would come up with to improve our interface. Let's go back to the example with the pictures again.
You can go on the synchronization path. All the pictures on a computer, stored in a specific folder, can appear on the site (you can add a special step of publishing them, although it is better, for example, to publish everything in “unsorted”, giving the user the opportunity to put everything in order at his convenience. Synchronization will be even more convenient in the case of a mobile application - all the pictures taken can simply appear on the site.
All this is great for large resources (if I were Flickr, I would seriously think about how to shove my client into cameras), but what should the author of a small site do? The answer is to integrate with external services. If we need to get a photo from the user, this does not mean that we need to organize the download of files, in fact, this does not even mean that the user needs to upload something (for example, because he has already done it). We need to think where we can get these photos. And such places are not so few: avatar can be tied off with Gravatar, various photos from social networks and services like Flickr, any files from Dropbox.
Using third-party services gives great advantages:
- at some point you can simply refuse to implement and support this site functionality on your own,
- you automatically receive (provide your users) all the amenities that appear in the services with which you integrate. Dropbox releases client for PS 3 - you can upload screenshots from there, Flickr makes the notorious client for cameras - you are again in the win.
Such outsourcing not only allows you to get a better interface, it allows you to focus on what exactly your service does. For example, if you conceived to create an online editor for creating collages, then using traditional methods you need to implement user registration / authorization, image uploading, a comment system (where to go without them?) And your application itself is a specially sharpened photo editor. Instead of doing all this yourself, you can use social networks for authorization, theirs, Flick and Dropbox as a source of photos and Disqus as a commenting system. In addition, third-party services (social networks, mostly) will also serve as an excellent publishing environment, and therefore word of mouth advertising for your application. All you have to do is to create what you actually did — the online collage editor (plus put it all together, of course).
The chances are great that if you don’t spend time on developing and supporting all non-core functionality, then the essence, your creation - the collage editor, in this case - will be better. Your application will do one simple thing well. And to complete the Unix-way analogy, teach your application to work with others - provide an API.
You decide what you are doing - another (possibly good) service or another stone in the foundation of the future network.
Source: https://habr.com/ru/post/130011/
All Articles