What should be file sharing in the instant messenger?
We live in a time when the convenience of using a program often outweighs all its disadvantages, and sometimes decides the fate. It is good that there is no limit to perfection and even very popular programs are not without flaws.
Take for example QIP. It seems that everyone is good, sends and receives messages, works with different networks, can send multicast messages, but this is not enough. People besides messaging are actively sharing files. So QIP files can send, you say, and you will be absolutely right. But does he do it well? Let's see.
To begin, click on the button to send the file in the message box. A dialog to open files from the default QIP program directory will open. Why the developers have done so, I do not understand. After restarting the program, this directory opens again instead of displaying the last one from which the user sent the files. Every time, you have to perform non-trivial manipulations for a person to go to the correct directory and select a file there, although it is known that many and many users often work with only a few directories where they put files as they themselves are comfortable. Someone has a “My Documents” folder, someone has “WORK” or “Dump”, it doesn't matter. Last opened directory should be saved.
')
And so, we chose the file to send. A completely incomprehensible window has opened, displaying various sending options. Not only is it unnecessary, it still does not close after clicking the Cancel button (to do this, click the Close button). And if you decide to send several files at the same time, the window tends to grow vertically, cloning incomprehensible gray rectangles with letters.
Instead of an extra form that hangs and blisters the eye, it would be more logical to display the file being sent directly to the chat with the recipient user. For example:
The sender sees an icon familiar to him from the file manager, by which he unconsciously determines the type of file. If it does not, it is shown the corresponding explanations of the file from the registry, as well as the file name, its volume and the sending status. And all this without any unnecessary windows.
Of course, when sending multiple files, you need to display several such “widgets” with corresponding statuses. For example, "waiting to be sent", "sent" or "sending failed". Sent file icons can be displayed as translucent.
Has this been the case?
Of course not! After all, everything is also bad on the receiving side: the same non-obvious window for receiving files opens, for which a separate button has been created. And the received files (oh, horror!) Are saved somewhere in the depths of the “Application Data” directory instead of the notorious “My Documents” folder or specified by the user. Remember how they sent you a file once and now you needed it, but QIP is not running and you have to wade into the jungle of “Application Data” or launch QIP and select “Send file - Received files” in the message window to open the folder with received good. Awful. The save folder must be configured or located in a publicly accessible location.
Of course, the receiving party must receive the file with the same convenience with which it is sent. The “widget” of the reception may look like this:
In addition to the obvious data, the “Open” button is available to the receiving user after downloading the file, with which the received file is opened by an application assigned to a particular type of file in the OS. This is a very necessary function, since Now, to open a received file, you have to open the explorer and launch the received files in the traditional way (double click), spitting at the will of the developer to the delights of the Shell API Windows.
Can I do something else?
Of course you can, because the ultimate dream has not been reached.
Working with files of one type or another is transparent to most developers at the expense of WinAPI or third-party library tools. For example, when sending images, you can display thumbnails and sizes in pixels, and when sending an mp3 file, a mini player or at least the “Listen” button:
Take for example QIP. It seems that everyone is good, sends and receives messages, works with different networks, can send multicast messages, but this is not enough. People besides messaging are actively sharing files. So QIP files can send, you say, and you will be absolutely right. But does he do it well? Let's see.
To begin, click on the button to send the file in the message box. A dialog to open files from the default QIP program directory will open. Why the developers have done so, I do not understand. After restarting the program, this directory opens again instead of displaying the last one from which the user sent the files. Every time, you have to perform non-trivial manipulations for a person to go to the correct directory and select a file there, although it is known that many and many users often work with only a few directories where they put files as they themselves are comfortable. Someone has a “My Documents” folder, someone has “WORK” or “Dump”, it doesn't matter. Last opened directory should be saved.
')
And so, we chose the file to send. A completely incomprehensible window has opened, displaying various sending options. Not only is it unnecessary, it still does not close after clicking the Cancel button (to do this, click the Close button). And if you decide to send several files at the same time, the window tends to grow vertically, cloning incomprehensible gray rectangles with letters.
Instead of an extra form that hangs and blisters the eye, it would be more logical to display the file being sent directly to the chat with the recipient user. For example:
The sender sees an icon familiar to him from the file manager, by which he unconsciously determines the type of file. If it does not, it is shown the corresponding explanations of the file from the registry, as well as the file name, its volume and the sending status. And all this without any unnecessary windows.
Of course, when sending multiple files, you need to display several such “widgets” with corresponding statuses. For example, "waiting to be sent", "sent" or "sending failed". Sent file icons can be displayed as translucent.
Has this been the case?
Of course not! After all, everything is also bad on the receiving side: the same non-obvious window for receiving files opens, for which a separate button has been created. And the received files (oh, horror!) Are saved somewhere in the depths of the “Application Data” directory instead of the notorious “My Documents” folder or specified by the user. Remember how they sent you a file once and now you needed it, but QIP is not running and you have to wade into the jungle of “Application Data” or launch QIP and select “Send file - Received files” in the message window to open the folder with received good. Awful. The save folder must be configured or located in a publicly accessible location.
Of course, the receiving party must receive the file with the same convenience with which it is sent. The “widget” of the reception may look like this:
In addition to the obvious data, the “Open” button is available to the receiving user after downloading the file, with which the received file is opened by an application assigned to a particular type of file in the OS. This is a very necessary function, since Now, to open a received file, you have to open the explorer and launch the received files in the traditional way (double click), spitting at the will of the developer to the delights of the Shell API Windows.
Can I do something else?
Of course you can, because the ultimate dream has not been reached.
Working with files of one type or another is transparent to most developers at the expense of WinAPI or third-party library tools. For example, when sending images, you can display thumbnails and sizes in pixels, and when sending an mp3 file, a mini player or at least the “Listen” button:
Source: https://habr.com/ru/post/63375/
All Articles