When the ’80/20′ rule is applied to software development, it usually manifests itself thus: developers spend 20% of resources to meet the needs of 80% of users and refuse to meet the needs of the remaining 20% at the cost of saving 80% of resources. This model works well when different categories of users use different products, but for the reasons discussed above, this is not always possible.
Messenger developers often organize the contact list in such a way that it is intuitive and convenient for the vast majority of users. For example, Skype stopped supporting categories in its 8th version; as a result, all related information was lost. At the same time, the official app is often the only messenger that supports a specific protocol, or the choice of alternatives is very limited.
Browser interfaces have undergone significant changes over the past fifteen years. There are fewer and fewer solutions available to those preferring the traditional style of window applications (title bar, menu bar, etc.). In many browsers and messengers, the choice of the destination for the downloaded file is hidden deep in menus or is unavailable, since a default folder is used in all cases. This may be convenient for most users, but definitely not for users who prefer to organize their own file storage structure on their devices.
Video communication programs are often developed under the assumption that all video streams should be represented in a single window. This suits most use cases, but creates problems for users who are used to working with multiple screens. For example, on Skype there is no way of viewing the user’s desktop on one screen and the stream from the other person’s web camera on the other.
In Sivelkiria, this problem can be solved by moving different features into different modules. For example, the module supporting the contact list structure can work with any messenger, regardless of whether it is supported by the protocol. If the protocol does not support it, category information can be stored locally or synchronized between devices. On the other hand, the target audience of a complicated, but feature-rich messenger interface would comprise 20% of all users of messengers, rather than 20% of a particular messenger’s users, which is a much bigger number. It also makes it possible for the messenger’s developers to provide an alternative interface without the risk of losing users; instead, it can attract new users.