The meaning of software life
Nowadays, the techniques of architecture, design and organization of the software development process multiply like rabbits on steroids. Framework, components and libraries are not far behind. Many solutions are based on experience, intuition, or a series of trial and error. With the increasing complexity of systems, the risks of choosing unsuitable products are only increasing. I would like to discuss one of the possible ways to assess the adequacy of the tools for the task.
The text will be long. If you are not in a hurry and are comfortably settled in a chair, then let's try to substantiate this statement.
In software engineering, developers seek to hide repetitive steps and details of operations behind interfaces, in components, modules, services, or controls, to separate the implementation of a solution to a problem from its formulation / interface.
')
How well a component or program fits the user's task can be judged by the number of trivial steps that the program allowed to avoid and how many new ones it added. Also, the plus is how much less the user should now go into the details of the task, and the minus is how much extra effort to study the program to start using it effectively and to solve the technical problems introduced by it.
Software design often provides high-quality answers to the “what” and “how” questions, even if we go down to the smallest details:
- What transparency do the shadow for this button?
- How to send these 2 bytes to the server?
On the contrary, the answer to the question “why” is often given at the level of the entire program and large parts of the functionality or architectural solutions, but for smaller details it becomes too expensive to think over and justify each decision. Accordingly, it becomes difficult to substantiate why “decision A” is better than “decision B” within the framework of task “C”.
The choice of non-optimal means and solutions can be quite destructive, leading to a chain reaction effect, when the attention of designers and developers shifts from the organization of ideal user interaction to the struggle against technical problems in adapting the chosen tools to an existing task. The project requires more work, and the enthusiasm of developers falls, threatening the quality of the final result.
How to evaluate the quality of such decisions? One of the good options is to analyze the routine steps and compare the solutions after splitting the task in two parts: repetitive / boring / auxiliary / mechanical and creative / interesting / important / functional.
Identification routine shows
- Where and how the program can be improved.
- Do we use the right tools to do the job.
- Can we increase the creative part in the work of programmers and end users.
Take a couple of scenarios and see how you can use routine analysis to improve user interaction with the program. For more illustrative purposes, the examples will be based on the end-user interaction with the software, but the final principles can also be applied to components or frameworks. The problems of users and programmers are in many ways similar, especially if measured by WTFs / minute
Most users worked with Word. The document saving dialog, especially for the first time, can be seriously puzzling:
- Have I chosen the right file type?
- Do I need to fill in all the tags, enter the title and the topic, or just a part of these fields?
- What is the difference between the title and the topic?
- Do I have to specify the encoding? I remember I had problems with the wrong encoding before, so this should be important.
- Where to save the file? I have my articles on a shared disk, entries in My Documents, corporate files on a network resource, project documentation in a project folder, etc. Can you just save the file to any temporary folder and decide later?
- Why is the file now called on the first line of text, and the title of the window was “Document 1”; Is this a bug or a feature?
Over time, you are accustomed to this dialogue and know which parameters you need to enter and which ones to ignore. The only question that remains is whether all these parameters are necessary.
What the user needs is to “set the name of the text and make sure that I can find it the next time I want to work with it.” The task does not include determining the folder to save the file or choosing the correct encoding. In fact, even saving a file is not included: all the user wants is to make sure that he can find his text next time and do something with it: print it, continue working or send it to someone by mail.
Is it possible to save the file differently? For example, some people are happy to use drafts of Gmail letters to prepare texts with simple formatting. Gmail doesn’t bother the user with questions about when and how to save a document - this is done automatically. You can enter a topic, but even this is optional.
Looking at how GMail managed to remove all the routine actions and to make the saving of documents completely transparent for the user, was it possible to do the same in MS Word? Of course:
- Define a standard place to save new documents.
- Name and save the document automatically
- Give the user the ability to rename and move documents
As a result, the user is no longer distracted by the technical details:
- The user gives the file a name when it needs it, and not when the application needs it.
- The user does not need to decide when the file is copied from memory to the hard disk.
- The technical parameters associated with the save dialog can either be removed or moved to the less commonly used export dialog, so the user no longer needs to study them for everyday use of the application.
It's just great when you have the opportunity to focus on your work, without being distracted by extraneous things.
Of course, Word is a large and complex program that can be customized. You can even write a VBA script to do “save as in Gmail”. But you have to pay for it to study and go into technical details that are completely uninteresting to the author who writes a novel or to the cook who makes out his own recipes. Yes, and the programmer ... I don’t know about you, but for me, for example, the periodic click Ctrl + S reflex developed much earlier than I learned about autosaving in Word.
I need to not forget the umbrella if it is going to rain, for which I use the weather forecast gadget on the iGoogle page.
Step by step the process is as follows:
1. Check iGoogle in the morning
2. Click on the detailed forecast link, see what time it is expected to rain.
3. Compare with the plan for the day and decide whether to take an umbrella or not
4. Do not forget the umbrella when I go out
Each step takes some time, requires a little attention and provides an opportunity to make a mistake. If it rained early in the morning, but now it’s clear and the umbrella is no longer needed, I may not notice that it is going to rain again after 6 pm. I can get distracted for breakfast and not check the weather information, or check everything as it should, decide that I need an umbrella, and then forget about it, in half an hour, leaving the house.
Since the task literally stands as “not to forget the umbrella, leaving the house if there is a chance to get under the rain”, close to the ideal would be to hang an inexpensive tablet from the inside with a program that will check the hourly forecast, compare it with my schedule and say something like: "Take an umbrella if you're on the street after 6 pm".
I do not need a cool application with the ability to compare the current weather with the average annual statistics in Tahiti, but only a reminder "today will be shedding like a bucket" and only when necessary. You can, of course, force your wife or girlfriend to do the same, but this is no longer a solution, but cheating, so let's return to the solution with the tablet.
All risks are now left in a single step - look at the tablet before leaving the house.
If there is no tablet, you can use a smartphone. The difference will be in determining the moment when to turn on the reminder. The ideal time is “just before leaving the house”, but in my case it will be suitable “when the charger is turned off,” since this also happens right before leaving.
What is interesting is that by removing unnecessary steps and risks, we, as developers, have not only made the user's life easier, but we ourselves can focus more on further improving the functionality.
These examples can be used to create “control questions” to assess the usability of the program.
- What is the real task of the user, if we eliminate all the technical elements introduced by the program?
- Are there repeated steps in the task; Did you manage to fully or partially automate them?
- Are there purely technical steps introduced by the program; Can I hide them from the user?
- Are there any optional steps distracting the user's attention?
- Does the program require making decisions not directly related to the user's task?
- Does the program require making decisions “out of context” when the user does not have the necessary information to make a decision?
- Does the user have to make related decisions separated by large periods of time?
Such questions are useful in their own right, but they are based on one basic question:
- What part of the work (when using the program) is characterized as repetitive, boring, optional and mechanical, and which remains creative, interesting and important?
In the absence of a better term, I call the first part “routine”. “Routine” is the part of the work that can be automated, eliminated or hidden.
The rest of this, in fact, is the real work - an important and / or creative part of it. This is the part that requires the user to make the necessary decisions and the task of software to remove all the boring, routine elements from it.
The meaning of life everyone finds for himself. Physicists can say that the meaning of life in the fight against entropy: the transformation of chaos into order.
In this case, the meaning of the software is to eliminate the routine in order to make the creation of order more efficient and interesting.
The text will be long. If you are not in a hurry and are comfortably settled in a chair, then let's try to substantiate this statement.
In software engineering, developers seek to hide repetitive steps and details of operations behind interfaces, in components, modules, services, or controls, to separate the implementation of a solution to a problem from its formulation / interface.')
How well a component or program fits the user's task can be judged by the number of trivial steps that the program allowed to avoid and how many new ones it added. Also, the plus is how much less the user should now go into the details of the task, and the minus is how much extra effort to study the program to start using it effectively and to solve the technical problems introduced by it.
The basic element in program design is the separation of functionality and its implementation. Like many other things in life, this raises 3 major questions:
1. What do we want to do?
2. How do we want to do this?
3. Why do we want to do this?
The first is a question for functional specification. The second is the technical implementation of a specific functionality. But the last question, why we do it and why we need it, determines the general direction within a broader task and guides our choice among possible answers to the “what” and “how” questions.
Software design often provides high-quality answers to the “what” and “how” questions, even if we go down to the smallest details:
- What transparency do the shadow for this button?
- How to send these 2 bytes to the server?
On the contrary, the answer to the question “why” is often given at the level of the entire program and large parts of the functionality or architectural solutions, but for smaller details it becomes too expensive to think over and justify each decision. Accordingly, it becomes difficult to substantiate why “decision A” is better than “decision B” within the framework of task “C”.
The choice of non-optimal means and solutions can be quite destructive, leading to a chain reaction effect, when the attention of designers and developers shifts from the organization of ideal user interaction to the struggle against technical problems in adapting the chosen tools to an existing task. The project requires more work, and the enthusiasm of developers falls, threatening the quality of the final result.
How to evaluate the quality of such decisions? One of the good options is to analyze the routine steps and compare the solutions after splitting the task in two parts: repetitive / boring / auxiliary / mechanical and creative / interesting / important / functional.
Identification routine shows
- Where and how the program can be improved.
- Do we use the right tools to do the job.
- Can we increase the creative part in the work of programmers and end users.
Take a couple of scenarios and see how you can use routine analysis to improve user interaction with the program. For more illustrative purposes, the examples will be based on the end-user interaction with the software, but the final principles can also be applied to components or frameworks. The problems of users and programmers are in many ways similar, especially if measured by WTFs / minute
Picture
Example one: saving a file in MS Word
Most users worked with Word. The document saving dialog, especially for the first time, can be seriously puzzling:- Have I chosen the right file type?
- Do I need to fill in all the tags, enter the title and the topic, or just a part of these fields?
- What is the difference between the title and the topic?
- Do I have to specify the encoding? I remember I had problems with the wrong encoding before, so this should be important.
- Where to save the file? I have my articles on a shared disk, entries in My Documents, corporate files on a network resource, project documentation in a project folder, etc. Can you just save the file to any temporary folder and decide later?
- Why is the file now called on the first line of text, and the title of the window was “Document 1”; Is this a bug or a feature?
Over time, you are accustomed to this dialogue and know which parameters you need to enter and which ones to ignore. The only question that remains is whether all these parameters are necessary.
What the user needs is to “set the name of the text and make sure that I can find it the next time I want to work with it.” The task does not include determining the folder to save the file or choosing the correct encoding. In fact, even saving a file is not included: all the user wants is to make sure that he can find his text next time and do something with it: print it, continue working or send it to someone by mail.
Is it possible to save the file differently? For example, some people are happy to use drafts of Gmail letters to prepare texts with simple formatting. Gmail doesn’t bother the user with questions about when and how to save a document - this is done automatically. You can enter a topic, but even this is optional.
Looking at how GMail managed to remove all the routine actions and to make the saving of documents completely transparent for the user, was it possible to do the same in MS Word? Of course:
- Define a standard place to save new documents.
- Name and save the document automatically
- Give the user the ability to rename and move documents
As a result, the user is no longer distracted by the technical details:
- The user gives the file a name when it needs it, and not when the application needs it.
- The user does not need to decide when the file is copied from memory to the hard disk.
- The technical parameters associated with the save dialog can either be removed or moved to the less commonly used export dialog, so the user no longer needs to study them for everyday use of the application.
It's just great when you have the opportunity to focus on your work, without being distracted by extraneous things.
Of course, Word is a large and complex program that can be customized. You can even write a VBA script to do “save as in Gmail”. But you have to pay for it to study and go into technical details that are completely uninteresting to the author who writes a novel or to the cook who makes out his own recipes. Yes, and the programmer ... I don’t know about you, but for me, for example, the periodic click Ctrl + S reflex developed much earlier than I learned about autosaving in Word.
Second example: rainy day
I need to not forget the umbrella if it is going to rain, for which I use the weather forecast gadget on the iGoogle page.Step by step the process is as follows:
1. Check iGoogle in the morning
2. Click on the detailed forecast link, see what time it is expected to rain.
3. Compare with the plan for the day and decide whether to take an umbrella or not
4. Do not forget the umbrella when I go out
Each step takes some time, requires a little attention and provides an opportunity to make a mistake. If it rained early in the morning, but now it’s clear and the umbrella is no longer needed, I may not notice that it is going to rain again after 6 pm. I can get distracted for breakfast and not check the weather information, or check everything as it should, decide that I need an umbrella, and then forget about it, in half an hour, leaving the house.
Since the task literally stands as “not to forget the umbrella, leaving the house if there is a chance to get under the rain”, close to the ideal would be to hang an inexpensive tablet from the inside with a program that will check the hourly forecast, compare it with my schedule and say something like: "Take an umbrella if you're on the street after 6 pm".
I do not need a cool application with the ability to compare the current weather with the average annual statistics in Tahiti, but only a reminder "today will be shedding like a bucket" and only when necessary. You can, of course, force your wife or girlfriend to do the same, but this is no longer a solution, but cheating, so let's return to the solution with the tablet.
All risks are now left in a single step - look at the tablet before leaving the house.
If there is no tablet, you can use a smartphone. The difference will be in determining the moment when to turn on the reminder. The ideal time is “just before leaving the house”, but in my case it will be suitable “when the charger is turned off,” since this also happens right before leaving.
What is interesting is that by removing unnecessary steps and risks, we, as developers, have not only made the user's life easier, but we ourselves can focus more on further improving the functionality.
Conclusion
These examples can be used to create “control questions” to assess the usability of the program.
- What is the real task of the user, if we eliminate all the technical elements introduced by the program?
- Are there repeated steps in the task; Did you manage to fully or partially automate them?
- Are there purely technical steps introduced by the program; Can I hide them from the user?
- Are there any optional steps distracting the user's attention?
- Does the program require making decisions not directly related to the user's task?
- Does the program require making decisions “out of context” when the user does not have the necessary information to make a decision?
- Does the user have to make related decisions separated by large periods of time?
Such questions are useful in their own right, but they are based on one basic question:
- What part of the work (when using the program) is characterized as repetitive, boring, optional and mechanical, and which remains creative, interesting and important?
In the absence of a better term, I call the first part “routine”. “Routine” is the part of the work that can be automated, eliminated or hidden.
The rest of this, in fact, is the real work - an important and / or creative part of it. This is the part that requires the user to make the necessary decisions and the task of software to remove all the boring, routine elements from it.
Source: https://habr.com/ru/post/151754/
All Articles