File Uploader. Features of the component and what we came to

In this article I would like to share with you our best practices and tell you what we came up with when assembling the File Uploader mobile component. However, many of the settings are also applicable to the web.

A file uploader is an interface element that allows users to select and upload files. It typically consists of a “Choose File” button or a drag-and-drop field for files that the user can select to upload.

In our service, the process of uploading files is one of the main actions performed by the user, so it should be as convenient as possible. And, it would seem, the component is familiar to everyone and used everywhere, take a template and go. But there is no limit to perfection, and even tuning of inconspicuous details makes the user experience more pleasant, which directly affects the conversion and loyalty of the user 🙂

In this article, we will omit the description of the analysis process (gathering needs, studying the experience of other companies, studying all possible limitations and data), and will focus only on the important points that will help to qualitatively approach the assembly of the component.

Introductory

The previous version of our design system already had a File uploader, but:

• it didn't cover many scenarios;

• was not adapted for mobile : ));

• morally tired and visually outdated. In short, it didn't match our new cool redesign.

Research, scenarios, practices, and just my own user experience have taught me that the most important moments in the file upload process for users are:

1. Displays the progress of file download. You should show the user a loading indicator so that the user can see how much time is left until completion. This will show users what is happening and make it easier to wait.

2. Checking files. It is necessary to be able to see the required type and size of files being uploaded to prevent incorrect or overly large files from being uploaded. This will help avoid errors and improve the overall experience.

3. Ability to drag and drop files into the upload area (for web). Adding this feature can greatly simplify the process. Dragging and dropping files into the specified area is easier than searching for them through a dialog box.

4. Preview files. The ability to preview uploaded files using a thumbnail will allow the user to ensure that they have selected the correct file before sending it to the service.

5. Download status notifications. After the file upload is complete, you need to show the user that the file has been uploaded successfully. In case of an error, it would be great to immediately show what the problem is (no network, too large file, etc.) and how it can be solved. This will save the person from searching for the cause and further errors during upload.

6. Clean and clear visuals. Do not overload such a small element, while maintaining the ability to obtain sufficiently complete information about the file.

7. Ability to perform an action during the loading process. Provide the ability to cancel the download or reload the file if an error occurs.

Limitations and features in the mobile version

If everything is more or less clear with the desktop version of the component, then mobile file upload has several features and limitations:

1. Size restrictions. Many mobile devices have file size limits for downloads. A user may encounter this if they try to download a file that is too large, which can result in errors or failure to complete the download.

2. File type restrictions. Some mobile devices may have restrictions on the types of files that can be downloaded. For example, some file formats may not be supported.

3. Internet speed on mobile devices may not be as fast as on desktop computers. This may affect the speed of file downloads, especially if the file is large.

4. Operating system and applications. Different operating systems may have different ways of loading files.

5. Limits on the number of characters in a file name. More compact display of the name without loss of information content.

6. Taking into account the features of touch screensmobile interfaces and interaction with the file system on mobile devices. For example, taking into account the click zone and adaptation to screen sizes.

7. Device size limitation. Mobile components are generally limited in width.

We impose on this the features of requests for our service:

1. Photos and videos. It is necessary to provide high-quality uploading of files such as photos or videos. This helps landlords attract more potential tenants by showing all the advantages of their property.

2. Documents and contracts. The ability to upload various documents to the housing rental service, such as lease agreements, inventory lists, receipts and other important papers. To simplify the process of exchanging information between parties, for example, on a mortgage transaction.

3. Multidisciplinary scenarios. Variations of the component for different scenarios, without loss of consistency.

4. The Importance of File Names. Documents uploaded by the user must be identified by name, so it is necessary to provide a fairly long file name and its correct display.

5. Status of the file being downloaded already outside the process of loading itself. After completion, it is important for the user to see the status of the document sending process, for example, whether the bank has approved the contract, etc.

So, we have all the input about the component. We studied the scenarios of other companies, collected the needs from designers, studied the limitations of platforms, devices and, what is important, the limitations from developers and the legacy of the previous version of the component. We took all this and went to assemble the component.

Below I will present screenshots of the component itself and its settings. And then I will split and explain why it is so and how it works.

Assembly

In total, we have three types of components in both mobile and desktop:

• File row. The line displaying the uploaded files is mainly intended for situations where only documents are uploaded, where only the file type is important (pdf, jpg, etc.), and it is also important to see the files in a list.

  

• File photoWhen we upload photos, it is important for us to control what we want to upload to the system, so preview is important so that we can easily identify the object in the photo before it gets into the system 🙂

  

  

• File card. This option is designed for those cases when the user uploads mixed file types (both documents and photos). Here, it is important to preview the uploaded image so that the appearance of the uploaded document and the image is uniform.

  

  

Component composition

Each component type provides a certain set of elements that are mandatory and situational:

• Preview (full or compressed). An important element of the component, which is primarily read by the user at the level of the file name. It is a permanent filling.

  

• File name and extensionIn our component, the name is limited by the number of lines, namely, the maximum length of the name is two lines, then the text is hidden in three dots. It is a permanent filling in two types of components

  

• Subtitle. To indicate the share of the download or, subsequently, to describe the file weight, the date of download, etc. That is, any useful information that is entered depending on the needs of the team of designers who take the component into work. It is a permanent filling in one type of component.

  

• Ability to select a file. This function can be enabled or disabled depending on the embedded process. It is an impermanent filling.

  

• Buttons for performing actions with a file. The actions embedded in the component can be changed depending on the needs. In the mobile version, only one button is used to save space, and the actions are displayed by pressing through BottomSheetOn the desktop, it is permissible to use up to three buttons. It is a permanent filling in one type of component.

  

• Badge. To display a particular document status. This function can be enabled or disabled, depending on the embedded process. It is an impermanent filling.

  

• Swap zone. For placement of oversized additional elements that are not provided by the component. Some highly specialized scenarios at the discretion of designers. It is an impermanent filling.

  

Badge and swap zone are separated into a single group, which can be completely disabled.

Documentation and technical aspects

For each component we have documentation in which we describe the rules of use, features and limitations depending on the platform and media.

In addition to the description of the component's operation, the features of the carrier, platform, etc. are also pulled here. For example, the “more” button, also known as the three dots, will have a different display on iOS and Android. This is due to the different behavior of this element within the system itself. In the mobile version of the component, we can pull up a preview of the photo during the loading process, but on the desktop, this is impossible for technical reasons.

Application

For such a component as a loader, we have provided for displaying its behavior at all stages of working with it. In this way, we make the component and its behavior consistent across all platforms where it is used.

Visual

Visuals play a big role in component assembly, but it is important to rely on the following factors:

• Coherence and conformity all other elements in your library. For example, if you want to make a component's rounding 20px, but your library is based on rounding 12px, then you shouldn't single out your component from the others. This will only create disharmony when designers use the component in their layouts.

• Consistent behavior across different states. If your component provides for many different states, try to make them identical in the distribution of elements and the presentation of information inside. This way, the cognitive load on the user will be less, the behavior of the component will be expected at all stages, it will be easy to track changes in mass actions, and in general you will keep a clean visual.

  

• It is important to consider all of a component's states at the design stage. And reactionscompare it with all possible scenarios in the product. This will prevent further errors when assembling the layout and reduce the number of requests from designers to you to “fix the layout” 🙂

• Provide a compact and extended version of the component. In the case of the file loader, we adopted the shortened version (min) of the card without indents, and the extended version (max) of the card with indents.

When the layout is very dense in content and every pixel is important, the designer will want to reduce the visual load by reducing the volume of the component. Or, when the layout already provides for indents in the block where the loader component is placed, there is no need to duplicate and complicate the visual nesting.

Conclusion

Well, that seems to be it!

To summarize:

• Spend enough time analyzing, collecting information and needs from all sources to avoid future mistakes and blind spots when creating a component.

• Make the component flexible enough, but don't overload it with settings.

• Listen carefully to feedback from designers on other teams, they may give you a solution that is already quite ready and tested. However, do not follow them blindly, pass them through your own prism of analysis.

And remember that when assembling a component, even the simplest one, there is always room for improvement.