When I input bare text, I usually use Hidemaru text editor. Hidemaru's operability is so simple that there has not been any trouble around its usability so far, but a strange behavior of the application was observed the other day. At that time, after starting up Hidemaru text editor, I noticed that menu bar style was different from the usual familiar one. I had not conducted any customization operation related to Hidemaru before then. In fact, I've never felt the necessity of customizing Hidemaru, of which the basic mode contains enough functions at least for me. I tried to reverse-customize back to usual state but in vain. To be honest, even the discrimination between two possibilities, Windows' side setting matter or Hidemaru's side setting matter was not clear. Perhaps, other application's setting changes might have caused the Windows' side setting change and it eventually affected the Hidemaru's side setting, I guessed.
After spending some time for various operations, however, when I decided to uninstall and reinstall from the clean start, the state of the menu bar style returned to the usual familiar one without any specific manipulation. After all, the reason of the appearance and disappearance of unfamiliar menu bar remained unclear.
After summing up this small trouble, I concluded that at least four points should be remarked, which I hope would contribute to the theoretical generalization approach in the field of software operability.
1. The pathway into Customize mode should be assembled into one unified gate. If customization entrances are dispersed on various tail ends on menu trees, the process of finding right pathway brings an irritating time to us. Of course, major softwares have already concentrated customization switches onto the 'Tool-Option-' menu-trees. But some customization switches don't exist there and were dispersed on various places.
2. Windows' applications software had better include the menu items about the status change caused by Windows' side setting change and display the description on it even though the setting change can't be attained by commands contained in the application.
3. The entrance gate to customize mode should be independent of menu-bar's optional style change. The entrance gate should not disappear under any user-interface state. Furthermore, this matter should be discussed with the problem of returning path from full-screen mode. In case key-input to return from full-screen mode is complicated and forgettable, I tend to reset PC before finding documents describing the returning procedure from full-screen mode.
4. Unintentional shifting into Customize mode should not be allowed. It may not be such a serious problem that users in need of customization have to pass through the pathway with confirmation process presented by the application. In the end, this means that basic mode should be designed following the statistical evaluation derived from research on average users, as the least requirements for customization may occur.
