アカウント名:
パスワード:
つまり、機能(を呼び出すボタンなど)の位置は、 ユーザが100%自由に変更/設定できるべき、なのです。
できるのが良いか悪いかといったら良いだろうけど、それとは別に初期配置の問題と教育の問題、そして「ほとんどの人はデフォルトのまま使う」という点が挙げられます。 その結果、「変えられることよりも初期配置がどうなっているか」「再教育は不要で済むか」の二点がクローズアップされることとなります。
普通の人は鋏で紙を切りたいのであって、鋏のグリップを自分好みに改造する手間なんてどうでもいいんですよ。 より細かい言い方をするなら、普通の人は mv の現存する使い方を覚えて使うだけで、mv のコマンドラインパラメータを独自改造するのは極めてこだわりがある人だけです。
さらに言えば、教育環境/利用環境の標準化という点を考えると、逆に「変更できないようにすること」も重要になりますね。
「ボタンになってるものをメニューにしてほしい」など、 種類まで乗り換えることを許しているものは、あまり見かけません。
つまり Visual Studio 位なら大満足ってことですね。
# import/export を含め、挙がってるものが全部可能ですね。
ということは、GUI部品を $ mv hoge/fugaButton foo/bar/ とするだけでGUI構成(少なくとも位置)を変更できる、ってことでしょうかね？ だとすれば画期的。
設定ファイル上にあるデータを fs 上に出しているだけですから、項目群とは別に位置、表示順序などの情報を別途管理するファイルなどが必要になりませんか? 結局全部を fs 上に置くことは難しいように思います。
ファイル名を元に項目を決定している、と考えると各 GUI 部品の位置情報をそのファイルに持たせることができるようになり、ファイル名を変更するだけで機能を変更できるようになりますが、やはり位置情報の整合性などを取るという点では問題が出そうです。また、ディレクトリによりメニューやツールバーなどの GUI 部品を表す形にすると、やはりディレクトリレベルでの位置や表示順序の情報が必要になりますね。
その辺りをまとめて、全部 XML とかに突っ込んだ方がセンスがいいように感じますが、どうでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
個人的には何故かまったく興味が沸かないのだった (スコア:1, 参考になる)
業務で必要になるならいじくりますが今の所その気配もないし……
＃やはり７からUIが大幅に変更され、それに自分が拒否反応おこしてるのかなあ？
Re: (スコア:1, 興味深い)
と云ったものが感じられなくなっています。
その典型例がＶｉｓｔａ。
しかし、それらにしがみついてプリインストールを続けている
パソコン「組み立て」メーカにも責任の一端があるのではないでしょうか？
”じゃぁ、後継は何だ？！”って聞かれそうですが、それを考えるんは私の役目ではありません。
もちろん、個人的には既に結論を出して実践していますが．．．。
＃「ＫＴとＲＯがテレビに現れると景気は悪くなる。」ほら当たったジャァン。
Re: (スコア:-1, フレームのもと)
Re: (スコア:0)
Vista以外にもOfficeやそのMac版などいろいろありますよ
Re: (スコア:0)
UI変えられて困るのはむしろ 非エンジニアのおっさんが多い企業のほう
あの機能はどこ?俺にだまって勝手に変えるな とか普通に文句言われる
移動して非ITの仕事をしているのでAC
Re:個人的には何故かまったく興味が沸かないのだった (スコア:3, 興味深い)
しゃれぬきに、今主流のGUIのスタイルの問題点のひとつは、ここにあると思います。
つまり、機能(を呼び出すボタンなど)の位置は、
ユーザが100%自由に変更/設定できるべき、なのです。
(そして設定をImport/Exportできる機能もね。)
が、なかなかそうなっていない。
位置の移動だけなら出来る奴も多いですが、
「ボタンになってるものをメニューにしてほしい」など、
種類まで乗り換えることを許しているものは、あまり見かけません。
仮にも次世代というならば、
単に固定的に位置の変更をする(つまり変更の決定権を相変わらずメーカーが持ち続ける)
のではなく、
そのへんの自由をユーザーにいかに委譲するか、を工夫してほしいものだと思います。
脱線になりますが、
昨日「Java Expoert #03」を読んで少しだけ感心したのが、NetBeansのアーキテクチャ。
いわくGUI構造などがことごとく「ファイルシステム」のように見えるようになってるのだそうな。
ということは、GUI部品を
$ mv hoge/fugaButton foo/bar/
とするだけでGUI構成(少なくとも位置)を変更できる、ってことでしょうかね？
だとすれば画期的。
＃Eclipseは…EclipseMonkeyを使ってもDOMで事前に苦労する必要は相変わらず必要なので、かなりいまいちかも。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1)
できるのが良いか悪いかといったら良いだろうけど、それとは別に初期配置の問題と教育の問題、そして「ほとんどの人はデフォルトのまま使う」という点が挙げられます。
その結果、「変えられることよりも初期配置がどうなっているか」「再教育は不要で済むか」の二点がクローズアップされることとなります。
普通の人は鋏で紙を切りたいのであって、鋏のグリップを自分好みに改造する手間なんてどうでもいいんですよ。
より細かい言い方をするなら、普通の人は mv の現存する使い方を覚えて使うだけで、mv のコマンドラインパラメータを独自改造するのは極めてこだわりがある人だけです。
さらに言えば、教育環境/利用環境の標準化という点を考えると、逆に「変更できないようにすること」も重要になりますね。
つまり Visual Studio 位なら大満足ってことですね。
# import/export を含め、挙がってるものが全部可能ですね。
設定ファイル上にあるデータを fs 上に出しているだけですから、項目群とは別に位置、表示順序などの情報を別途管理するファイルなどが必要になりませんか? 結局全部を fs 上に置くことは難しいように思います。
ファイル名を元に項目を決定している、と考えると各 GUI 部品の位置情報をそのファイルに持たせることができるようになり、ファイル名を変更するだけで機能を変更できるようになりますが、やはり位置情報の整合性などを取るという点では問題が出そうです。また、ディレクトリによりメニューやツールバーなどの GUI 部品を表す形にすると、やはりディレクトリレベルでの位置や表示順序の情報が必要になりますね。
その辺りをまとめて、全部 XML とかに突っ込んだ方がセンスがいいように感じますが、どうでしょうか。
Re: (スコア:0)
>(そして設定をImport/Exportできる機能もね。)
>が、なかなかそうなっていない。
あなたのいう主流というのがどの辺を指しているのか知りませんが、ここにあることならOfficeやIEなどの「主流製品」ではかなり前のバージョンから実現されてますよ。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1, 興味深い)
IE7で、「戻る」「進む」「アドレスバー」「更新」「中止」「検索バー」の順に並んでいる段を変えたいのですが…。
具体的には「戻る」「進む」「更新」「中止」「アドレスバー」の順番にして、検索バーはコマンドバーと同じ位置に置きたいのです。
素のIE7では私のスキルでは出来ませんでしたから、現在はIEコンポーネント系のブラウザ（フリーソフト）を使用しています。