How to make an application that users will like

In this habratopic, I would like to describe several points that, in my opinion, will help novice (and not only) programmers to write applications that users will love and use with great pleasure.

Foreword

Unfortunately, as elsewhere, really good and convenient programs can be found quite rarely, which, personally, as a programmer, is usually very frustrating for me. Therefore, I decided to write this article in the hope that at least among Habrahabr readers who are engaged in software development, the quality of their applications will increase. I do not consider the creation of software in terms of obtaining commercial benefits, I am not very strong in this :). Therefore, perhaps, some of the tips voiced here may be harmful when applied to commercial software. However, if you are developing Open Source or free software, the voiced tips can help you to improve the quality of your products and improve your own qualifications as a programmer.

Characteristics of a “good” program:

1. The application solves some very specific tasks and problems of the user, and allows you to achieve greater efficiency than solving the same problems and tasks without this program.
2. Easy installation - the user should have a minimum of obstacles in installing your application, the program should not depend on any third-party libraries / utilities that are not included
3. A simple, responsive and fast-running interface - users really dislike when programs hang, they barely load new windows, and so on. They have the right to do this: today's computers have truly impressive computing resources and allow us, with proper design of the application, to completely eliminate any “brakes” of the program’s graphical interface, even when using complex visual effects
4. The correctness of the work - the program must perform exactly the actions that the user expects from them, no more and no less! If some operation cannot be completed, the program should try to explain the cause of the problem and ways to fix it in human language, without having to go into the documentation
5. The high speed of the program - this applies to everything: it should load quickly, quickly perform its duties and should not resist its closure (as some applications like uTorrent do, although uTorrent does it for quite good reasons)

Examples

Examples of "good" programs can give a lot. Many years ago I was very impressed with the program “ Hieroglyph ”, which, in addition to its flawless work, could, for example, switch the language of its interface “on the fly” (not sure if it will run under Windows Vista / 7, but under older Windows) works). Such a seemingly trifle (for the uninitiated :)), saves the user from having to perform extra actions, albeit by complicating the program itself. To guarantee the fulfillment of the task, edit the Russian text, Hieroglyph even had the opportunity to use its own font rendering engine to completely eliminate problems with the "crackers" that still sometimes haunt Windows users.

From Mac OS X programs, I really like TextMate : in contrast to modern very heavy IDE and text editors like Komodo , Eclipse , NetBeans , etc., TextMate has the necessary functionality and ease of expansion, while taking up little space (10 MB in the distribution) , loads very quickly and does not require a lot of system resources.
')
From purely Linux applications, you can probably call Enlightenment a good window environment - it also professes minimalism and simplicity of work.

Development Approaches

It is obvious that it is easy to write an application that works poorly . If you are a programmer (otherwise why are you reading this article :)?), Then you know perfectly well because you have written many such programs yourself, and you write every day. And I also write them, because there is nowhere to go, especially if the programs are written “for myself”, I don’t want to spend more time on them than is required to get a result. However, if you are writing a program not for yourself, but for other users , then both the development approaches and the quality requirements should also be different :

1. At the very beginning of development, if you are faced with a choice, for example, to use or not any “fancy” library / framework / paradigm, try to understand how much you need it and how fully you are going to use its capabilities, and also try to evaluate it impact on application size, download speed and ease of installation. Practice shows that for small programs the use of large frameworks or any purely closed technologies does not justify itself in terms of user-friendliness. (I can cite as an example the CodeCraft program published on Habré recently , which, with a weight of a couple of megabytes (of which the background image takes most of it :)) requires under the most popular Windows XP operating system to download and install frameworks with a total weight of over 100 MB , and for writing your robots - again, self-installation of VisualStudio and at least Microsoft Word / OpenOffice for reading the instructions))
2. If your application contains a graphical interface, then try at least briefly to get acquainted with the GUI-guidelines for the corresponding OS or DE. If you are developing a web application, then try not to replace the standard controls with your own ones, do not use non-standard fonts, and try not to abuse features that are not available in all browsers. Following established standards will make communication with software users easier and more “intuitive”.
3. To ensure the responsiveness of the interface, try not to perform resource-intensive operations in event handlers, especially mouse clicks and window resizing. Event handlers should only have a minimum code that will run the same operations in the background, so that the main thread of the application that processes all events does not have large queues, otherwise the user will feel that the program is “frozen” . A very good example of ignoring this recommendation is Explorer in older versions of Windows when working with the network: he often used blocking calls in the event processing thread, which led to consequences well known to you :). If you are writing a web application, then try not to perform resource-intensive operations on the client, at least for a long time, because Javascript still does not have a single standard for creating multithreading, and all code is executed in single-threaded mode, which can also cause significant delay in event processing
4. Do not forget about the goal that was set when writing the application - the program must perform exactly what was originally intended, and nothing else! In addition, keep in mind that the program should not give incorrect results with correct initial data. I mean, if there are several ways to solve a subtask, choose the one that will give the correct answer for any source data, even if you have to sacrifice performance for this (agree, if you don’t require the program to work, you can write the function of calculating the root as double sqrt (double x) {return 0.0;} - this will be the fastest function to calculate the root of a number, but there is no sense from it :))
5. Despite the fact that a good program should work quickly, it does not mean that you need to optimize the program from the very beginning, before writing it, or right in the process - as Donald Knut said, “Premature optimization is the root of all evil” ( en.wikipedia .org / wiki / Program_optimization # Quotes ). However, do not forget that your application is likely to be tested on a more powerful hardware than the person who will use your program, and therefore, with the slightest “brakes” on your machine, try to figure out what's wrong and speed up the corresponding a piece. It is also useful to try to “feed” to your application data volumes that significantly exceed the volumes that are expected by the user on average - to make sure that the application never “freezes” or “slows down” even if the expected data volume is exceeded by orders of magnitude (the user most likely will sometimes want to use his hardware to the fullest, and your application should allow it if it is doing any kind of data processing)
6. If you are writing a web application, then try to make it so that even users with a narrow or unstable channel can use it without any inconvenience, and they do not have to wait 5 minutes to just see the list of documents and their contents (yes, this stone in the garden google docs!). We all used to use dial-up for Internet access, and personally I had a 64 kbit / s channel not so long ago, and I do not live in the outback at all
7. And finally, do not forget about thorough testing of those releases (and intermediate versions too) of your products in various situations. Worse than a program that “slows down” only a program that also works unstable at the same time!

Perhaps, for the first time, everything, although I have touched on only a small part of the problems that usually arise when developing software products, I still hope that you still found something useful for yourself in this article, and that we will soon see more quality programs. and web services, and in Russian, written by our, domestic programmers :)!

Literature

I can not fail to mention a few books, which I consider to be either mandatory for reading, or at least very useful and help you learn how to write programs.

1. Brian Kernigan, Dennis Ritchie " ANSI C " - a guide to the C language, very sensible, helps not only learn the C language, but also teaches programming (in any language)
2. Brian Kernigan, Rob Pike " The Practice of Programming " - a book that is only 10 years old (compared to the previous book, the first version of which was published in 1978), describes not only C programming, but also contains examples in C ++, AWK, Perl, Java, and affects almost all areas of programming in a purely practical aspect, applied to solving real problems
3. Marc J. Rochkind “ Advanced UNIX programming ” (translated as simply “ Programming for UNIX ” in the Russian version) is an excellent book that talks in great detail about programming for UNIX, and also contains a huge number of general recommendations for writing applications that, like me It seems to be no less valuable than the description of the system calls of different versions of UNIX and UNIX-like systems and associated pitfalls