Robustness of the entrance gate into Customize mode

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.

2D-nization of text character code: How we can insert virtual spaces or delimiters between not-separated Japanese phrases

After writing previous entry, my concern about word separation problem converged and focused into an image (Fig). This image is merely one of various possibilities. At any rate, I think information about word separation may have to be added to the files.

Word group theory (2). Front-end processor's paradigmatic change.

When writing in Japanese, I usually use ATOK front-end processor. As ATOK's usability is excellent for me, I still can't step out for using Google's Japanese front-end processor. Nevertheless, I usually feel that Japanese front-end processors are now facing a time for paradigmatic change.

When I write a Japanese phrase '検索する' by using ATOK, a set of the Kanji & Hiragana character codes corresponding to '検’索’す’る' are finally recorded on the document file. But the alphabetical keyboard-typing process of characters 'kennsakusuru' is not included in the file. It means that only the result of conversion, Kanji code (or Hiragana or Katakana code) translated from alphabetical characters has been the important information so far.

Conversely, in search engine's era, conversion process & its embedding into document files will become more important due to the fact that Japanese (Chinese) sentences are not separated by spaces between words.

Every word in English is separated by spaces. The power of Google-search, I guess, seems to be strongly supported by the existence of spaces between words, the structure of English language itself. Meanwhile, when analyzing Chinese language (or Japanese) sentences, computer algorithms have to tackle with the word-separation problem at first.

Let me take an example from a Chinese web.

A sentence '那麼胡錦濤你面臨了利用百度訴江案這件詭異的事情' was found on a Chinese web page.

As I can't understand Chinese language at all, I'm not able to separate above sentence into words correctly except for the well-known word '胡錦濤 (Hu Jintao)' and '百度(Baidu)'. A few other words like '利用' and '事情' seem to have the same meaning as those of Japanese, but this guessing is not conclusive level. Owing to these words, I can at least guess the meaning of the sentence roughly. 'Hu Jintao said something about peculiar situation related to using Baidu search engine.' If the spaces are deleted, this sentence become 'HuJintaosaidsomethingaboutpeculiarsituationrelatedtousingBaidusearchengine.' This expression contains the words like 'Ted' 'sing' 'use' 'arch'.

If Chinese language front-end processor can embed the alphabetical keyboard-typing processes of 'Hu Jintao', 'Baidu' and other words in the document file, it may help search engines to decide correct word separation.

Of course, corpus-based dictionary of Chinese language may be the basic approach to solve this problem in the Baidu era. But on another front, front-end processor's paradigmatic change also may become important in the Google-era.

Though Google has decided to leave China, the possibility of producing a new kind of Chinese language front-end processor based on a quite different approach still remains.