For anyone who does not like automatically closing behavior of YaST Software Management module (or sw_single) in openSUSE 11.1, I have made a modified package (yast2-packager) which does not close automatically. Get it from my build service home project repository here.
I do not like the self closing behavior myself. No other package manager in any distribution does this. Even add/remove programs in Windows does not do this either. In 10.3, YaST used to ask if we want to install more packages or not, using a popup window. But as people find this popup irritating, the developers removed it. But I don't think whoever who wanted this also wanted the module to automatically close either. In terms of the user, I think the user will find both these things irritating: 1) Popups and 2) Windows which abruptly close without warning. A proper design would be where the number of clicks a user has to perform is least without experiencing the two behaviors described above. Now consider three use cases: 1) Popup removed and window closes automatically 2) Popup removed but the module does not quit. 3) Popup present.
For the first case, if a user does not want to do any futher software changes -> 0 clicks, or if YaST is open too, 1 click to close YaST. Let's give an average of 0.5 clicks.
If user want to make software changes -> if YaST is open, click software module (1 click); or go to openSUSE kickoff menu and click 'Install Software' (1 click); or go to openSUSE menu and click YaST, then click Software Management (2 clicks); All these can increase by one click if the user has the traditional KDE menu or the 'open on hover' feature does not work correctly for the buttons in the kickoff menu. Lets give this case an average of 1.25 clicks. (Note that making the user go through the menu again is not good design).
For the second use case, if a user does not want to do any further software changes-> 1 click to close the module, 2 clicks to close both the module and YaST if open. Let's give this one an average of 1.5 clicks.
If user wants to make software changes-> 0 clicks (module is already open).
For the third use case, if a user wants to make any software changes, click yes when popup is displayed (1 click).
If user does not want to make any changes, click no when popup is displayed (1 click).
Now, lets assign a fixed number of clicks (say 1 click each) to both popup and a self-closing window. So the first case will now have 1 click contribution from the abruptly closing window, the second case will have no contribution and the third case will have 1 click contribution from the popup (Here we are not counting the window closing as the user should be expecting the window to close when he says no).
On tabulating and averaging the clicks for the three cases, you can see that the second case has the lowest number of clicks.
I do not like the self closing behavior myself. No other package manager in any distribution does this. Even add/remove programs in Windows does not do this either. In 10.3, YaST used to ask if we want to install more packages or not, using a popup window. But as people find this popup irritating, the developers removed it. But I don't think whoever who wanted this also wanted the module to automatically close either. In terms of the user, I think the user will find both these things irritating: 1) Popups and 2) Windows which abruptly close without warning. A proper design would be where the number of clicks a user has to perform is least without experiencing the two behaviors described above. Now consider three use cases: 1) Popup removed and window closes automatically 2) Popup removed but the module does not quit. 3) Popup present.
For the first case, if a user does not want to do any futher software changes -> 0 clicks, or if YaST is open too, 1 click to close YaST. Let's give an average of 0.5 clicks.
If user want to make software changes -> if YaST is open, click software module (1 click); or go to openSUSE kickoff menu and click 'Install Software' (1 click); or go to openSUSE menu and click YaST, then click Software Management (2 clicks); All these can increase by one click if the user has the traditional KDE menu or the 'open on hover' feature does not work correctly for the buttons in the kickoff menu. Lets give this case an average of 1.25 clicks. (Note that making the user go through the menu again is not good design).
For the second use case, if a user does not want to do any further software changes-> 1 click to close the module, 2 clicks to close both the module and YaST if open. Let's give this one an average of 1.5 clicks.
If user wants to make software changes-> 0 clicks (module is already open).
For the third use case, if a user wants to make any software changes, click yes when popup is displayed (1 click).
If user does not want to make any changes, click no when popup is displayed (1 click).
Now, lets assign a fixed number of clicks (say 1 click each) to both popup and a self-closing window. So the first case will now have 1 click contribution from the abruptly closing window, the second case will have no contribution and the third case will have 1 click contribution from the popup (Here we are not counting the window closing as the user should be expecting the window to close when he says no).
On tabulating and averaging the clicks for the three cases, you can see that the second case has the lowest number of clicks.
| Case 1 | Case 2 | Case 3 | |
| No software changes | 0.5 | 1.5 | 1 |
| Software changes | 1.25 | 0 | 1 |
| Popups/closing window | 1 | 0 | 1 |
| Average | 0.92 | 0.5 | 1 |
Some more observations: If for the first case, we reduce the clicks for 'more software changes' condition to 1, the average no of clicks will be 0.83 which is still larger than 0.5 for the second case. Further, if we reduce the number of clicks for software changes for the first case and then assume that the user gets accustomed to the window closing on its own, then making the contribution from it zero, the average number of clicks then matches the second case.
Some people may argue that they need something to tell them that software installation was successful or not at the end of the installation process. But then, if something does go wrong, the module does pop up more notifications/warnings than needed already!
In any case, I feel that its best to trust the developers to make the appropriate decision. Since openSUSE is open source free software, we can always make our own customized packages. Feel free to use the package in my repository but remember that its at your own risk!
Some people may argue that they need something to tell them that software installation was successful or not at the end of the installation process. But then, if something does go wrong, the module does pop up more notifications/warnings than needed already!
In any case, I feel that its best to trust the developers to make the appropriate decision. Since openSUSE is open source free software, we can always make our own customized packages. Feel free to use the package in my repository but remember that its at your own risk!
4 comments:
Thanks! That irritated me also, since I constantly install some soft.
Welcome! Btw, the next release of openSUSE, i.e. 11.2, will have a configurable closing behavior for this module. Unfortunately, 11.2 will be out in November 09 and till that time we are stuck with the older version of this module. The backport may be available in this repository though, I haven't checked. The repository will probably be unstable as it's a SVN repo.
Beleive you or not, but I have already reinstalled 11.1 three times. I wonder if such a feature like Revert Pakages Installation were implemented :( So I'd better wait till stable release :)
P.S. Where from you know that it's backported? :)
Work on a feature like Revert Package installation is progressing. The initial steps in this direction have already been implemented using the package history feature in libzypp. Hopefully, we should see the results of this work in 11.2. About the backport, I do not know if the feature has been committed to svn yet, but if it has, then it should be available in the repository, since it is the YaST svn repo rebuilt for 11.1.
Post a Comment