| 20 | | Try to imagine how many different environments and different ways to work can exist, for example if you are beta-testing Enlightenment 17, and you want to see if some window minimizes correctly, think about all the possibilities, you can do it by using the mouse to click the minimize button, or you can also press ''ctrl + alt + i'' on the keyboard to do the same thing, also think in other things related to minimizing an application, for example engage or taskbar can trigger the minimization too. |
| | 20 | Try to imagine how many different environments and work methods can exist. For example, if you are beta-testing Enlightenment 17 and want to see if a window minimizes correctly, consider all the possibilities. You can use the mouse to click the minimize button, or you can press ''Ctrl + Alt + I'' on the keyboard to achieve the same result. Additionally, think of other factors related to minimizing an application, for example from ibar/engage it can also be triggered the minimization. |
| | 21 | |
| 24 | | Are you creative ? you need to be... think about it, in the previous example we have seen different ways to trigger the same thing, but all the possibilities are not listed here, you need to be creative (or at least get familiarized with the application/code) to imagine how much different things can happen, for example: |
| 25 | | * can the window be minimized when is in maximized mode ? |
| 26 | | * if another window is on top of another one, we can still minimize it ? |
| 27 | | * what happens if I try to minimize during an e17 restart ? |
| 28 | | * which window is minimized by default if I switch to a different desktop and don't manually focus in any ? |
| 29 | | * what happens if the minimizer module is not loaded ? |
| | 25 | Are you creative? You need to be. Think about it: in the previous example, we have seen different ways to trigger the same action, but not all the possibilities are listed here. You need to be creative (or at least familiarize yourself with the application/code) to imagine how many different outcomes can occur. For example: |
| | 26 | * Can the window be minimized when it is in maximized mode? |
| | 27 | * If another window is on top of one, can we still minimize it? |
| | 28 | * What happens if I try to minimize during an e17 restart? |
| | 29 | * Which window is minimized by default if I switch to a different desktop and don't manually focus on any? |
| | 30 | * What happens if the minimizer module is not loaded? |
| 38 | | If you have the biggest headaches trying to catch a bug and you still don't found it, may be because you are not looking at the correct place. |
| 39 | | There's a few examples: |
| 40 | | * Warning with ''async, threads, and parallel tasks'': If you have things that runs in paralel, nothing ensures you that A would happen before B even if in the code its declared on this way. For example: You have a code that generates a temporal html file with statistics, then you open it with a browser in background to visualize it, then you copy it to a backup directory and finally since this is a temporal file you simply delete it, on this example you could experience that the browser fails, why this could happen? I used the example of a browser because is a bloated ton of crap and so it takes some time to open, in the meantime the script has continued and removed the file, when the browser is ready to print it the file is gone. |
| | 41 | If you are having the biggest headaches trying to catch a bug and still haven't found it, it may be because you are not looking in the correct place. |
| | 42 | Here are a few examples: |
| | 43 | * Warning with ''async, threads, and parallel tasks'': If you have things that run in parallel, nothing ensures that A will happen before B, even if it is declared that way in the code. For example: You have a code that generates a temporary HTML file with statistics, then you open it in a browser in the background to visualize it. After that, you copy it to a backup directory, and finally, since this is a temporary file, you simply delete it. In this example, you could experience a failure with the browser. Why could this happen? I used the example of a browser because it is bloated with unnecessary features, causing it to take some time to open. In the meantime, the script has continued and removed the file, so when the browser is ready to display it, the file is gone. |
| 45 | | You can more easily find bugs if you try to combine things, for example: |
| 46 | | * what happens if you run the application multiple times ? |
| 47 | | * is the performance affected by running it multiple times ? |
| 48 | | * try A while you are doing B |
| 49 | | * do the same tests with different settings |
| 50 | | * combine parameters/features at the same time |
| | 48 | You can more easily find bugs by trying to combine different elements. For example: |
| | 49 | * What happens if you run the application multiple times? |
| | 50 | * Is the performance affected by running it multiple times? |
| | 51 | * Try A while you are doing B. |
| | 52 | * Conduct the same tests with different settings. |
| | 53 | * Combine parameters/features simultaneously. |
| 52 | | === Frequent Problems in applications === |
| 53 | | This is more like a list of ''common noobish programming issues'', so if you find them, you can spank the author of the application ;) |
| 54 | | |
| 55 | | * Your system is multiuser, there's a lot of applications that uses /tmp to store temporary data (like /tmp/app1), but if another user runs the same application, it will use the same location, and this can result in really big, annoying and even hard to find problems, the most common ones are ''permission denied'' reports |
| 56 | | * Multiple instances: sometimes an application is not ready to be run multiple times, this needs to be correctly managed by the programmer in order to not conflict with different instances of the same application, if the application is made to only be able to run one instance, then it needs to avoid another run with a message like ''application is already running'' |
| | 55 | === Frequent Problems in Applications === |
| | 56 | This is more like a list of ''common novice programming issues''. If you encounter them, you can hold the author of the application accountable. ;) |
| | 57 | * Your system is multi-user, and many applications use /tmp to store temporary data (like /tmp/app1). If another user runs the same application, it will use the same location, which can lead to significant, annoying, and even hard-to-diagnose problems. The most common issues are ''permission denied'' reports. |
| | 58 | * Multiple instances: Sometimes an application is not designed to be run multiple times. This needs to be managed correctly by the programmer to avoid conflicts between different instances of the same application. If the application is intended to run only one instance, it should prevent another run with a message like ''application is already running''. |
| 60 | | It is very common that we report not correct bugs, this happens when the cause of the problem is not what you think but just a side effect of another thing, a similar problem occurs when you report that the cause is A but in fact is in another place. Just make sure the real cause of the problem before to report it. |
| | 62 | It is very common for us to report incorrect bugs. This happens when the cause of the problem is not what you think, but rather a side effect of something else. A similar issue occurs when you report that the cause is A, but in fact, it lies elsewhere. Just make sure to identify the real cause of the problem before reporting it. |
| | 63 | |
| | 64 | |
| | 65 | === Other different types of bugs === |
| | 66 | |
| | 67 | ==== Pebkac ==== |
| | 68 | ''(Problem Exists Between Keyboard And Chair)'': After reprimanding the user of your application for being foolish, you must also reflect on your own shortcomings. Pebkac issues are '''really''' bugs that '''you''' need to fix... yes, you, the developer :), this is known as an ''usability issue''. You may think that users are foolish, but that won't change anything; what can change is your application. Make it more user-friendly, lazy dev! |
| | 69 | |
| | 70 | ==== Wording ==== |
| | 71 | A grammar error is also an error worth reporting. If you encounter incorrect messages, such as those written by the tarzanic of ''Thanatermesis'', you must report them as well. '''Update''': Since version Topaz, Elive's translation tool includes the option to translate into English, meaning you can translate from tarzanic (the application's original language) to English! |
| | 72 | |
| | 73 | The process of beta-testing wording doesn't end here. An interface must use optimal messages. In short, this means: |
| | 74 | * avoid overwhelming users with excessive information (they don't read it, and they realize it) |
| | 75 | * provide clear and direct messages, without potential for misinterpretation |
| | 76 | * keep messages concise |
| | 77 | * ensure messages are easy to understand, but not so simplistic that they alter the logic and meaning |
| 64 | | === Other different types of bugs === |
| 65 | | ==== Pebkac ==== |
| 66 | | ''(Problem Exist Between Keyboard And Chair)'': after to spank the user of your application because he/she is stupid, you must give yourself some spankies too, because pebkac's are '''really''' bugs that '''you''' need to fix... yes, you, the developer :), that's called an ''usability issue'', you may think that the users are stupid but this won't change anything, what can change is your application, make it more evident, lazy dev! |
| 67 | | |
| 68 | | ==== Wording ==== |
| 69 | | A grammar error is also an error to report, if you find some wrong messages like for example the ones written by the illiterate ''Thanatermesis'', you must report it too... '''Update''': Since version Topaz, the translation tool of Elive also includes the possibility to translate to english, this means, from tarzanic (application orginal) to english! |
| 70 | | |
| 71 | | The wording beta-testing doesn't finish here, an interface must use the optimal messages, in short this means: |
| 72 | | * avoid flood of boring information (users don't read, realize it) |
| 73 | | * clear and direct messages, without possible different interpretations |
| 74 | | * short messages |
| 75 | | * easy to understand, but not for dumbs changing the logic and sense |
| 76 | | |
| 77 | | ==== User Experience (UX) ==== |
| 78 | | This is an entire science, so it requires some knowledge about what is and what is not a good interface, lots of knowledge exist about it... but by other side, you can still check these things, because you are a '''logic and coherent''' person, the interfaces of the applications needs to be coherent and logic, easy to use, handy, userfriendly, etc... so if you think that the interface can be better made in a different way, just report it with the details of how it should be made. |
| | 81 | ==== User Experience (UX) ==== |
| | 82 | This is an entire science that requires knowledge of what constitutes a good interface. While much information exists on this topic, you can still evaluate these aspects because you are a '''logical and coherent''' person. The interfaces of applications need to be coherent and logical, easy to use, handy, and user-friendly. If you believe that the interface could be improved in a different way, please report it with details on how it should be designed. |
| 81 | | * User interface Design (UI) |
| 82 | | * Optimal Positioning of elements (buttons, text, etc) |
| 83 | | * Feelings that gives the interface, the use of it, the actions, etc |
| 84 | | * Usability to use |
| 85 | | * Information architecture (IA) |
| 86 | | * Handy application, obtaining efficient and desired results |
| 87 | | * Helping tips (way's to help the user if some element is difficult) |
| 88 | | * Avoiding overload of elements/text/images/tips/messages/etc |
| 89 | | * Interaction design (IxD) |
| | 85 | * User Interface Design (UI) |
| | 86 | * Optimal Positioning of Elements (buttons, text, etc.) |
| | 87 | * Feelings Evoked by the Interface, Its Use, and Actions |
| | 88 | * Usability |
| | 89 | * Information Architecture (IA) |
| | 90 | * Handy Application, Achieving Efficient and Desired Results |
| | 91 | * Helpful Tips (ways to assist the user if an element is difficult) |
| | 92 | * Avoiding Overload of Elements/Text/Images/Tips/Messages/etc. |
| | 93 | * Interaction Design (IxD) |
