Native American software designer tricks. Release 1
Hello. With this release, I want to open a series of articles that will contain various techniques and tricks that I use myself and which my colleagues in dangerous business practice. The materials are not structured and are scattered field notes, which may someday be developed into a system, but for now I will not guess anything.
And today I have the following thoughts for you:
Documenting variables
When developing really large and complex applications, you will certainly encounter the need to use variables. For example, to determine the type of user, if your interface is different for each of them, you can create a corresponding variable and bind the displayed functionality to its value.
')
It happens that there are a lot of variables and after opening the project you will have to remember again what they mean.
In order to avoid these painful memories, I use a simple trick. Every time I start a variable (of course, for the most part, global variables are 'Global Variables'), I write down its name and possible values to a separate master, which I usually call 'Variables'. Next, I write explanations for myself, what exactly a variable does, where I used it, and explanations of its values. It helps a lot when you need to quickly remember which variables are already involved and how they work. Yes, yes, in fact, banal commenting code.
Structuring the functional
If we are talking about developing complex applications, then as a rule we are talking about a huge amount of functionality. This functionality can be duplicated on different screens, displayed with small changes and without them. But in any case, regardless of the desire of the designer, it is almost always necessary to make corrections. And of course you want to make edits as quickly and easily as possible. To facilitate such work it is very convenient to use the master pages, but I consider them not only as masters but also as containers that help keep widgets in a structured form and, as a result, in quick access. I do the following: I do the maximum amount of functionality initially by wizards and organize a separate category in the wizard tree with a clear hierarchy.
This approach is very convenient for several reasons:
No need to dig deep into the prototype / dynamic panels and their states in order to change the inscription on the button. Simply find the master you want. (For example: the client card will be located in the Main \ Clients \ Tools folder).
Master is a master, you will not need to do the same thing several times on different screens.
The structure of the masters allows you to better control your project. You can immediately see what has been done, what is missing, quickly transfer widgets between screens and better control the uniformity of your decisions.
In general, this approach will take you a little more time at the prototype development stage, but opening your prototype in half a year you will thank yourself.
To do
Another move that I often use in my work is to document the upcoming work right on the screen on which to do this work. I just write with the text that I plan to do on this screen and delete it as it goes. If I don’t manage to do everything at once, I drive everything into one group and hide it (for example, if I need to show a prototype to someone), and when I return to this screen I don’t have to go into the requirements to see what I have not done. This saves a lot of time. Sometimes, when there is not enough text, pictures may appear in a group (for example, if I saw somewhere a solution that might fit me) or links, etc. It sounds quite simple and logical, but for some reason I have not yet met designers who act in this way. It's a pity.
Imitation of external factors
It often happens that the interface is influenced by external factors that do not depend on user actions or depend indirectly, but which, nevertheless, must be worked out and displayed in the prototype. I will give an example. It is necessary to design how the system will behave when the temperature of a physical component changes. You can draw a large guide with separate screens to reach each heating threshold, you can write explanations directly in the body of the prototype and make a pop-up window with all the icons and warnings, or you can take a slightly more logical way. You can simply take and prototype a widget that will contain triggers on which the interface will change. That is, right in the prototype, put the button "Imitation of temperature fluctuations" which will consist of the triggers "Reaching the first limit", "Reaching the second limit", etc. When testing you will say thank you. All in one place, everything changes, you can clearly see the behavior of the system.
We can do the same for scenario forks that are independent of the user. For example: we want to simulate sending a form to a server, but in one case independent of the user, the form will be sent, but not in the other. In such cases, I simply show the widget as excellent as possible in design (with the text that this is not a system window and is needed only to imitate the operation of the system, just in case) in which I give the opportunity to choose a path. Thus, the integrity of the prototype is preserved and the connections between the screens remain straightforward and understandable.
Behind this pilot issue I consider it possible to complete. I would be glad if the article turned out to be useful to you and I will be even more pleased if you also share your Native American tricks in the comments. And today I have everything. Until new meetings.
And today I have the following thoughts for you:
Documenting variables
When developing really large and complex applications, you will certainly encounter the need to use variables. For example, to determine the type of user, if your interface is different for each of them, you can create a corresponding variable and bind the displayed functionality to its value.
')
It happens that there are a lot of variables and after opening the project you will have to remember again what they mean.
In order to avoid these painful memories, I use a simple trick. Every time I start a variable (of course, for the most part, global variables are 'Global Variables'), I write down its name and possible values to a separate master, which I usually call 'Variables'. Next, I write explanations for myself, what exactly a variable does, where I used it, and explanations of its values. It helps a lot when you need to quickly remember which variables are already involved and how they work. Yes, yes, in fact, banal commenting code.
Structuring the functional
If we are talking about developing complex applications, then as a rule we are talking about a huge amount of functionality. This functionality can be duplicated on different screens, displayed with small changes and without them. But in any case, regardless of the desire of the designer, it is almost always necessary to make corrections. And of course you want to make edits as quickly and easily as possible. To facilitate such work it is very convenient to use the master pages, but I consider them not only as masters but also as containers that help keep widgets in a structured form and, as a result, in quick access. I do the following: I do the maximum amount of functionality initially by wizards and organize a separate category in the wizard tree with a clear hierarchy.
This approach is very convenient for several reasons:
No need to dig deep into the prototype / dynamic panels and their states in order to change the inscription on the button. Simply find the master you want. (For example: the client card will be located in the Main \ Clients \ Tools folder).
Master is a master, you will not need to do the same thing several times on different screens.
The structure of the masters allows you to better control your project. You can immediately see what has been done, what is missing, quickly transfer widgets between screens and better control the uniformity of your decisions.
In general, this approach will take you a little more time at the prototype development stage, but opening your prototype in half a year you will thank yourself.
To do
Another move that I often use in my work is to document the upcoming work right on the screen on which to do this work. I just write with the text that I plan to do on this screen and delete it as it goes. If I don’t manage to do everything at once, I drive everything into one group and hide it (for example, if I need to show a prototype to someone), and when I return to this screen I don’t have to go into the requirements to see what I have not done. This saves a lot of time. Sometimes, when there is not enough text, pictures may appear in a group (for example, if I saw somewhere a solution that might fit me) or links, etc. It sounds quite simple and logical, but for some reason I have not yet met designers who act in this way. It's a pity.
Imitation of external factors
It often happens that the interface is influenced by external factors that do not depend on user actions or depend indirectly, but which, nevertheless, must be worked out and displayed in the prototype. I will give an example. It is necessary to design how the system will behave when the temperature of a physical component changes. You can draw a large guide with separate screens to reach each heating threshold, you can write explanations directly in the body of the prototype and make a pop-up window with all the icons and warnings, or you can take a slightly more logical way. You can simply take and prototype a widget that will contain triggers on which the interface will change. That is, right in the prototype, put the button "Imitation of temperature fluctuations" which will consist of the triggers "Reaching the first limit", "Reaching the second limit", etc. When testing you will say thank you. All in one place, everything changes, you can clearly see the behavior of the system.
We can do the same for scenario forks that are independent of the user. For example: we want to simulate sending a form to a server, but in one case independent of the user, the form will be sent, but not in the other. In such cases, I simply show the widget as excellent as possible in design (with the text that this is not a system window and is needed only to imitate the operation of the system, just in case) in which I give the opportunity to choose a path. Thus, the integrity of the prototype is preserved and the connections between the screens remain straightforward and understandable.
Behind this pilot issue I consider it possible to complete. I would be glad if the article turned out to be useful to you and I will be even more pleased if you also share your Native American tricks in the comments. And today I have everything. Until new meetings.
Source: https://habr.com/ru/post/327064/
All Articles