東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

言うだけならタダ

ちんまいツールを頼まれまして、UI確認のためざくざくーっと張りボテこさえて使こうてもろたんですが。

「えーとね、このリストから一個選んで"削除"ボタン押すっしょ。
 リスト上でなんも選択してないときは"削除"ボタンを押せなく(グレイに)してよ

…やれっちゅーならやるけどさ。
なんも選択してないときに"削除"押しても"なにもしない/できない"んだから
わざわざグレイにせんでえぇやん。お望みなら「選べやゴルァ!」-Box出してあげるから。

僕のポリシーだと、たとえばリストが空になってはいけないって条件が
あるんなら、リストに残る最後の一個を選択した時点でグレイにするかな。
まー、こいつも押したときに「消すなやゴルァ!」-Boxで済ませてもいいんだが。

実装にさほどの手間がかかるわけじゃないんだけど、
"押してもかまわん"ように実装するんなら"押せなく"せんでもえぇやんか

 うーむ...UIに凝らない僕には無駄なことしてるように感じられてなりません。

投稿日時 : 2007年3月14日 11:27

コメントを追加

# re: 言うだけならタダ 2007/03/14 11:34 シャノン

俺はグレイ派。
Visible=false派っていう人もいる。

削除ロジックの方は「存在しないデータの削除依頼が来てもいい(誤動作しないこと。例外を投げるのも正解)」なように作っておくけど、UIでは「削除できない」のが個人的な好み。

でも仕事ではもっぱら「選ばれてねぇぞゴルァ!」が多い。

# re: 言うだけならタダ 2007/03/14 11:50 επιστημη

"見えなくする"てのはヤだなー。
一貫性を保つためそれをメニューに適用すると「ぬわんぢゃこりゃぁ!?」になりそう。

"やってはいけない"と"やっても意味ない"があるなら、
後者についてはあからさまにガードしないてーのが僕のスタンスでしょか。

# re: 言うだけならタダ 2007/03/14 11:56 Kazuki

出来ない事は出来ないと明示するということでグレイ派です。
押してみなけりゃわからないってのよりは、押す前にわかるほうが使いやすいかと。
実行時にわかるよりも、コンパイル時にわかるほうが傷が浅いみたいに…

# re: 言うだけならタダ 2007/03/14 12:00 nagise

>出来ない事は出来ないと明示する

場合によっては出来ない理由が分からなくて困ることも。
使用付加になる状況が素人さんが見ても把握できるような簡単な条件だとよいのですが、
論理演算をいくつか組み合わせると「どういうときに使えなくなるのか分からん」と言われてしまう…。

# re: 言うだけならタダ 2007/03/14 12:17 シャノン

ある程度は「マニュアルを読め」「あとは慣れろ」で。
それが不可能なほど複雑な条件ならば設計が悪い。

# re: 言うだけならタダ 2007/03/14 12:23 囚人

私もグレイ派ですね。
押す前に分かるというのは「押す前に管理者権限が必要かどうかが分かる Vista のシールドアイコン」に繋がるかと。
割とストレス軽減になります。

# re: 言うだけならタダ 2007/03/14 12:29 επιστημη

利用形態にも依りそうですねぃ。
不特定多数が触るなら丁寧に丁寧に作り込むけども、
ユーザが何度も使ってくれるんならじきに"押さなく"なるやろし。

# re: 言うだけならタダ 2007/03/14 12:37 ららら

ちょうど今日、リストになにもないときは
ボタンをDisableにするなんてのをやりました。
しかも(VC++6)
私は、リストが選択されていないときに
削除ボタン押したら、何も選択されてないよってメッセージだすかな。
そんで、リストに何もないときはボタンをDisableです。
あれ?グレイ派が多い?

# re: 言うだけならタダ 2007/03/14 12:57 επιστημη

"落としドコロ"ってやつなのかなー。

"やつてはいけない"はもちろん、
"やるとあとあと面倒なことになる"/"なぜこんな注意書きが現れたのか説明すんのもメンドクセー"の類ならいっそ"やれなく"するのでしょう。

どこいらへんに線を引くかはcase by caseとしか言えないのかしらね。

# センベに入ってるシリカゲルを思い出した。
# 「無害ですが食べられません」って、無害なら食っていいだろ!?

# re: 言うだけならタダ 2007/03/14 12:58 2リットル

製品コードならグレイにします。

せっかく作ったアプリが「 ( ゚Д゚)ゴルァ!」ばっかりしちゃって気に入ってもらえなかったらつまらないもの。

でも、内輪向けなら遠慮せずに「 ( ゚Д゚)ゴルァ!」を仕込みます。

# re: 言うだけならタダ 2007/03/14 13:09 ぽぴ王子

「戦争はお好きですかー?」
「ケケ…ケースバイケース…だと…思います…」
と、case by caseと聞いて真っ先にスネークマンショーを思い浮かべる王子がやってきました。

まぁ確かにcase by caseなのですが。
僕の場合 Fool Proof を心がけているので、グレイで。

# re: 言うだけならタダ 2007/03/14 13:11 とりこびと

普通(?)の人に聞いてきました。

そのUIを最初に見たときに、リストが何も選択されてない状態でで削除ボタンがグレー表示、リストから選択したら削除ボタンが有効になるなら、
「あ、選択したものが削除されるのね。」
って思うらしいです。
もし、リストが何も選択されてない時に削除ボタンが有効なら、
「リストに表示されているものがすべて削除されるかも・・・」
って思うらしいです。

「その人は」ですけども。

# re: 言うだけならタダ 2007/03/14 13:16 HiJun

ちんまいツール(笑)というであれば
問答無用で 「ゴルァ!」BOXですね。

正式なパッケージであればちゃんとユーザさんと
打合せして決めますです。

# re: 言うだけならタダ 2007/03/14 13:20 επιστημη

けいさつはここじゃないお

Fool Proofはわかるんですよ。
"押したら取り返しのつかないことになる"んならハナっから押せなくするってのは。

この例では、
選択してねーもんを"削除!"つったってやりようがないし実際なにもしねーし実害ないし。
せいぜい「できねーよ」って教えてやるくらい。
Fool Proofとは違うよーに思えます。

リストが空のときも(同様の理由で)"削除"をグレイにしないだろうな特に要請のない限り。

# re: 言うだけならタダ 2007/03/14 13:23 επιστημη

> もし、リストが何も選択されてない時に削除ボタンが有効なら、
>「リストに表示されているものがすべて削除されるかも・・・」
> って思うらしいです。

アッーーー! なるほど。
使う側(の慣れ?)に依りますねぇ。

# re: 言うだけならタダ 2007/03/14 13:39 とりこびと

追記です。

[削除]ボタンのほかに[すべて削除]ボタンがあれば、リストに何も選択されていなくても選択して削除するということを意識できるそうです。

なかなか面白いですね~。

# re: 言うだけならタダ 2007/03/14 13:59 中博俊

しかしですね、みんなほとんど漏らしているのはユーザ教育の概念です。
ユーザは一度エラーが出ると理解できます。
エラーが出ない場合にはなぜ押せないのかを教育する機械を失います。
もちろんエラーメッセージは適切かつバリエーション豊かに出す必要がありますが・・・
とにかくえぴさんと=ですね。私は。

# re: 言うだけならタダ 2007/03/14 14:53 2リットル

>エラーが出ない場合にはなぜ押せないのかを教育する機械を失います。

なるほどー。
たしかにグレイ表示だと「このボタンを押すためにはどうしたらいいのか」がわかりませんね。

# re: 言うだけならタダ 2007/03/14 14:55 Mr.T

#あとはなんにもしないから

Mr.Tです、こんにちは。
私はグレーにしない、メッセージ出す派ですね。
グレーに(若しくは見えなく)したら、「どうしてそうなるのか」がユーザに説明できなくなるので。

適当にボタンを押しても、メッセージ出せばユーザを誘導できますし。

# その他 2007/03/14 15:45 なか-chan@最愛のiMac

A. 最初から、項目を何か(全部)を選択しておく。
B. 「リストから削除したいものを選択してください。」と書いておく。
C. ボタンのキャプションが、最初は[未選択]となっている。
D. 「~、~、~を削除してよろしいですか?[削除][キャンセル]」というダイアログを出す。
E. リストを右クリック→[削除]を選択。
F. リストをダブルクリックで削除。
G. リストの1行ずつに[削除]ボタンをつける。
H. リストの項目をゴミ箱アイコンにドラッグ&ドロップ。

あと何かあるかなぁ...

# re: 言うだけならタダ 2007/03/14 16:28 黒龍

ユーザに対しての情報量が多い点でグレイにする方が優しいインタフェースだとは思いますがお仕事でやる以上バランスですね。全画面にそのようなフィードバックを盛り込む工数を認めてくれるかどうかで決めます。
押せないvsメッセージっぽいですが対立要素じゃないと思いますよ。リアルタイムなバリデートという観点ではメッセージ領域(ステータスバーなど)に反映することもできるので意味を伝えることはできますから。

# re: 言うだけならタダ 2007/03/14 16:30 シャノン

>エラーが出ない場合にはなぜ押せないのかを教育する機械を失います。

極端な話になりますが…
では、Enabled = false を使うのが望ましい局面とは、たとえば?

# re: 言うだけならタダ 2007/03/14 16:42 ぽぴ王子

# なぁεπι、このBlogな、盗聴されてるんだよ

よく考えたら神にFool Proofを説くなんてバカなことをやってしまった王子が来ましたよ。

「見えなくする」は中さんの言うユーザ教育という概念からも外れているような気がするので却下でいいとして。

僕の場合のポリシーですが。
ボタンが押せるとして、押したら「押すなよ!!押すなら選択してから押せよ!」と言われてしまうと
「そういうのを押してから言うぐらいなら最初から押せなくしておいてくれよ」とか思っちゃう
タイプなのですね。
余計な手間を増やすなとか考えちゃう。
「取り返しのつかないこと」じゃないから押せてもいいじゃないかってのもわかりますが。

それをふまえた上で。
ユーザ教育という部分から見ると確かに漏れている気がしますね。
もう説明を書いたラベルを貼るとか、ToolTipに説明を入れるとか、ヘルプに書いておくとか
そういうので逃げてしまいそう… orz

ちょっと考えてみます。

# re: 言うだけならタダ 2007/03/14 17:00 ゆーち

あちきの場合、どのようなスタンス、うんぬんの前に政治的な圧力に応じるよう指示されてしまいます。

説得の余地や教育の余地さえも却下され、無駄な無償残業を強要される毎日です。

下請けはつらいっす。

ヽ(`Д´)ノウワァァン!!

# re: 言うだけならタダ 2007/03/14 18:04 επιστημη

# ぅ、ぅわんわんっ、わんっ

すげー。ここまで盛り上がるとは思わなんだぜ。
ボタンひとつにこれだけ様々な思い入れ/思惑/意図/感情移入/愛憎があるんだ。

僕ら…やっぱプログラマだよ。

# re: 言うだけならタダ 2007/03/14 18:25 とりこびと

>僕ら…やっぱプログラマだよ。

感動した!この合言葉すごく(・∀・)イイ!

# re: 言うだけならタダ 2007/03/14 18:28 ghost_shell

>僕ら…やっぱプログラマだよ。

青春ドラマみたいなくさいセリフと思いつつも、じ~んと感動。(うわ~ん)


書いたコメントのコピーができておらず(消えてしまい)、うわ~~ん。

# re: 言うだけならタダ 2007/03/14 19:44 2リットル

シャノンさんへ
>では、Enabled = false を使うのが望ましい局面とは、たとえば?

ボタンを押せるようにするための条件が直感的にわかるときはEnable/Disableがわかりいいんじゃない。

例えば自動販売機のボタンとか。


# re: 言うだけならタダ 2007/03/14 23:21 中博俊

>Enable=false
ボタンに対してではなく、項目などに対しては非常にわかりやすいです。
何を入れるべきかを明示するという意味でね。
ラジオボタンとパネルの組み合わせが一番だと思います。

ボタンに対してって考えると、戻るボタンなんかは押せなくても理屈がわかる。
でも更新ボタンじゃやっぱいやだな。

# アプリケーションのユーザ教育 2007/03/14 23:33 中の技術日誌ブログ

アプリケーションのユーザ教育

# re: 言うだけならタダ 2007/03/14 23:44 επιστημη

あ…ふと思ったんだけど、
ボタンのキャプションが"選択項目の削除"だったらグレイにしてもいいのかな? とか ^^;

# re: 言うだけならタダ 2007/03/15 1:46 nagise

>ボタンのキャプションが"選択項目の削除"だったらグレイにしてもいいのかな? とか ^^;

名称で逃げる手はよく使いますね。
「何の」を明示すれば誤解がないからいいよね、みたいな話。
「全部消えそうで怖い」って話も削除の対象が何かということが不明瞭だからですし。

私が今手がけているシステムは削除の可否判定が複雑なので、
わざと押させてから理由をユーザに説明する仕様にしていますが。
というか、整合性チェックが入っているのでDB確認しないと判定が出来ない…

# re: 言うだけならタダ 2007/03/15 9:33 Mr.T

#だ、だ~れ~?
Mr.Tです、こんにちは。

どういう時にグレーにするか、で
基本的に「そういうを操作しちゃいけないとき」にしかグレーにしません。
曰く、
「エディタでファイルを開いていないのに保存ボタンが有効になっている」

# re: 言うだけならタダ 2007/03/15 10:06 さすらい

MS かどこかの UI ガイドラインで読んだことがあります。
* ユーザーが何かの操作をすれば操作可能になるボタンは Enabled=false
* ハードウェアがないなど、ユーザーの通常の操作範囲では操作可能にならないボタンは Visible=false
* 「何をすれば操作可能になるか」が十分に明確でない場合にはエラーメッセージ
最後が若干曖昧ですが。

# re: 言うだけならタダ 2007/03/16 6:24 Jitta

> "見えなくする"てのはヤだなー。
同感。しかし。。。
改造物件で、「マニュアル直すの手間だから」と、“消えるメニュー項目”を実装することにorz

# re: 言うだけならタダ 2007/03/16 7:21 επιστημη

どっかの電力会社の臨界隠しみてぇだぞ。

それに"消えるメニュー"はあまりの危険性から1982年コペンハーゲン大会で封印された幻の技のはず。

# What do you think about new Social Network website FacesEpicentre.com ? 2012/02/16 23:27 addedgivy

What do you think about new Social Network website http://facesepicentre.com/ ?

タイトル
名前
URL
コメント