What should be the file sharing in the Internet pager?
We live in a time when the convenience of using a particular program often outweighs all its disadvantages, and sometimes it decides fate. It’s good that there is no limit to perfection and even very popular programs are not without drawbacks.
Take for example QIP. It seems to be good for everyone, sends and receives messages, works with different networks, knows how to send multicast messages, but this is not enough. People, in addition to messaging, actively exchange files. And QIP can send files, you say, and you will be absolutely right. But does he do it well? Let's figure it out.
To begin, click on the send file button in the message box. A file open dialog will open with the default QIP program directory. Why the developers did this, I do not understand. After restarting the program, this directory opens again, instead of displaying the last one from where the user sent the files. Every time you have to do nontrivial manipulations for a person to go to the desired directory and select a file there, although it is known that many, many users often work with only a few directories where they arrange the files as they like. For some this is the “My Documents” folder, for someone it is “WORK” or “Dump”, it doesn’t matter. The last open directory should be saved.
And so, we selected the file to send. Some kind of completely incomprehensible window has opened, in which various sending parameters are displayed. Not only is this unnecessary, it still does not close after clicking the "Cancel" button (for this you need to click the "Close" button). And if you decide to send several files at the same time, the window has the ability to grow vertically, cloning obscure gray rectangles with letters.
Instead of an unnecessary form that hangs and corns the eye, it would be more logical to display the sent file directly in the chat with the recipient user. For example, like this:
The sender sees an icon familiar to him by the file manager, by which he subconsciously determines the type of file. If it doesn’t, it will be shown explanations from the registry corresponding to the file type, as well as the name of the file, its size and sending status. And all this without any unnecessary windows.
Of course, when sending multiple files, you need to display several such "widgets" with the corresponding statuses. For example, “Awaiting Submission,” “Sent,” or “Sending failed.” Icons of sent files can be displayed translucent.
Is this the case?
Of course not! Indeed, on the receiving side, everything is also bad: the same non-obvious file reception window opens, for which a separate button is created to close. And the received files (oh, horror!) Are stored somewhere in the bowels of the Application Data directory instead of the notorious My Documents folder or specified by the user. Remember how you were sent a file once and now, you need it, but QIP is not running and you have to wade into the jungle of “Application Data” or run QIP and select “Send file - Received files” in the message box to open the folder with the accepted good. Awful. The save folder must be configured or located in a public place.
Of course, the receiving side should receive the file with the same convenience with which it is sent. The “widget” of the reception may look, for example, like this:
In addition to the obvious data, the “Open” button is available to the receiver after downloading the file, with the help of which the received file is opened by the application assigned to one or another type of file in the OS. This is a very necessary function, because Now, to open the received file, you have to open the explorer and run the received files in the traditional way (double click), spitting on the charms of the Shell API of Windows by the will of the developer.
Is there anything else to do?
Of course you can, because the limit of dreams has not been reached.
Working with files of one type or another for most developers is transparent due to the power of WinAPI or third-party library tools. For example, when sending images, you can display their 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 to be good for everyone, sends and receives messages, works with different networks, knows how to send multicast messages, but this is not enough. People, in addition to messaging, actively exchange files. And QIP can send files, you say, and you will be absolutely right. But does he do it well? Let's figure it out.
To begin, click on the send file button in the message box. A file open dialog will open with the default QIP program directory. Why the developers did this, I do not understand. After restarting the program, this directory opens again, instead of displaying the last one from where the user sent the files. Every time you have to do nontrivial manipulations for a person to go to the desired directory and select a file there, although it is known that many, many users often work with only a few directories where they arrange the files as they like. For some this is the “My Documents” folder, for someone it is “WORK” or “Dump”, it doesn’t matter. The last open directory should be saved.
And so, we selected the file to send. Some kind of completely incomprehensible window has opened, in which various sending parameters are displayed. Not only is this unnecessary, it still does not close after clicking the "Cancel" button (for this you need to click the "Close" button). And if you decide to send several files at the same time, the window has the ability to grow vertically, cloning obscure gray rectangles with letters.
Instead of an unnecessary form that hangs and corns the eye, it would be more logical to display the sent file directly in the chat with the recipient user. For example, like this:
The sender sees an icon familiar to him by the file manager, by which he subconsciously determines the type of file. If it doesn’t, it will be shown explanations from the registry corresponding to the file type, as well as the name of the file, its size and sending status. And all this without any unnecessary windows.
Of course, when sending multiple files, you need to display several such "widgets" with the corresponding statuses. For example, “Awaiting Submission,” “Sent,” or “Sending failed.” Icons of sent files can be displayed translucent.
Is this the case?
Of course not! Indeed, on the receiving side, everything is also bad: the same non-obvious file reception window opens, for which a separate button is created to close. And the received files (oh, horror!) Are stored somewhere in the bowels of the Application Data directory instead of the notorious My Documents folder or specified by the user. Remember how you were sent a file once and now, you need it, but QIP is not running and you have to wade into the jungle of “Application Data” or run QIP and select “Send file - Received files” in the message box to open the folder with the accepted good. Awful. The save folder must be configured or located in a public place.
Of course, the receiving side should receive the file with the same convenience with which it is sent. The “widget” of the reception may look, for example, like this:
In addition to the obvious data, the “Open” button is available to the receiver after downloading the file, with the help of which the received file is opened by the application assigned to one or another type of file in the OS. This is a very necessary function, because Now, to open the received file, you have to open the explorer and run the received files in the traditional way (double click), spitting on the charms of the Shell API of Windows by the will of the developer.
Is there anything else to do?
Of course you can, because the limit of dreams has not been reached.
Working with files of one type or another for most developers is transparent due to the power of WinAPI or third-party library tools. For example, when sending images, you can display their thumbnails and sizes in pixels, and when sending an mp3 file, a mini-player, or at least the “Listen” button: