パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Office 2007、只今ダイエット中?」記事へのコメント

  • 新しいUI の採用 (スコア:2, おもしろおかしい)

    by Anonymous Coward
    また「Office風メニューを実装する」で記事が1本書ける予感。
    • by Anonymous Coward
      っていうか、変わりすぎ!

      しかも、IE7 共々、メニューバーがノイズのように扱われだしている点が気になります。メニューバーって、ツールバーやコンテキストメニューと比べて、ずっと安定しているから、実は地味に電話サポートやメールサポートなどで活躍してるんですよね。

      サポートや教育にかかるコストを想像するとオソロシイ..。
      • メニュー至上主義がここに一人 ノシ

        メニューってのは、(少なくともそのウィンドウの)すべての機
        能にアクセスできる唯一の手段で、ツールバーやポップアップメ
        ニューは、頻繁に使われる機能へのショートカットでしかないは
        ずなんですがね。

        一時期、ユーザーサポートに身をおいたことがあるのですが、た
        しかにメニューをもとに操作を説明する方が、相手もわかりやす
        く感じているようです。ツールバーやポップアップメニューは
        非表示になっている場合があるので、そこで面倒くさくなります。

        個人的に不思議なのが、ツールボタンのクリックイベントに本処
        理を書いて、メニューのクリックイベントはその処理を呼び出す
        …というように実装するプログラマがいることです。
        まぁ、どのように実装しようとバグさえなければ問題はないんで
        すが、そういう方って、無駄にツールボタンを追加していく傾向
        があるようです。これもメインメニューが操作の基本という基本
        がないためでしょうか。

        #愚痴ってすいません。
        • by Anonymous Coward on 2006年06月15日 10時00分 (#960149)
          >ツールボタンのクリックイベントに本処理を書いて、
          >メニューのクリックイベントはその処理を呼び出す
          >…というように実装する

          違うよね。
          メニューのクリックイベントに本処理を書くんだよね!
          #さあ、正解を以下に書いてくれ!
          親コメント
          • by kei100 (5854) on 2006年06月15日 12時12分 (#960220)
            >>ツールボタンのクリックイベントに本処理を書いて、
            >>メニューのクリックイベントはその処理を呼び出す
            >>…というように実装する

            >違うよね。
            >メニューのクリックイベントに本処理を書くんだよね!
            >#さあ、正解を以下に書いてくれ!

            正解はメニューとツールバーの両方のクリックイベントに本処理をコピペして実装するんだよね?

            # 本当の正解は両者とも本処理を呼び出すだと思うのでID
            親コメント
          • by gwamodin (2081) on 2006年06月15日 20時14分 (#960567)
            単純な処理なら、メニューのイベントに書いてもかまわないでしょ
            う。両方のイベントから呼び出すメリットがなければ、一方に書
            いてあるほうがソースは読みやすいです。

            ここで言いたいのは、ユーザーに安定して機能を提供できるのは
            メインメニューであろうから、こちらに重点を置いておくのが良
            かろう、というところですので。

            #ネタ(じゃないけど)にマジレスに、もういっちょマジレス
            親コメント
          • 機能を実装する関数を書いて各イベントから呼び出す。
            が正解では。
            とはいってもソースが長くなるので私は好きではありませんが。
            後からコードを読む人がいるならきれいに書きましょう。
            それがデスマーチの短縮につながるのです。
            --
            void office2007LikeMenuItem_新規作成_Click(Object o,EventArgs e)
            {
                NewDocument();
            }
            みたいに。

            #学生だけどプログラミングで徹夜経験があるのでID
            • 後からコードを読む人がいるならきれいに書きましょう。
              は同意なんだけど、同じ人が
              とはいってもソースが長くなるので私は好きではありません
              というのは違和感があります。きれいに書くってのは、短いってことだけじゃなくてモデルとしていいかってことも問題です。短くても分かりにくかったり、モデルとしてぐちゃぐちゃならメンテナンスをできなかったり再利用できないでしょ?「分かりやすく書く」目的がなんなのか考えなければいけないと思います。

              長いのがメンテナンス性や再利用性が悪い傾向があるのは理解しますが、逆にメンテナンス性や再利用性を向上させようとすれば多少は長くなるのは仕方ないと思います。

              もちろん、組み込みとかで「短く書かなきゃいけない」ってことがあるのは分かってますが、それは「分かりやすく」「正しい」プログラムが出来た後の最適化のフェーズだと思ってます。

              --
              vyama 「バグ取れワンワン」
              親コメント
              • というよりソースが長くなると「読む」段階で苦労します。
                長いソースになると開発中の手間も倍増しますし(スクロールの回数ですら侮れません)、見通しが悪くなります。
                なので私は短いソースこそ美しく高度だと思い、また長いソースが嫌いです。
                要は「長さ」と「理想的なモデル」の問題は「可読性」と「再利用性」との問題といえます。

                同様にして基本的に前サンプルのような関数呼び出しだけの関数はソースを読みにくくします。
                しかしながら、イベントハンドラの場合、イベントの種類によって引数の型が異なるため
            • by Anonymous Coward
              ネタにマジレス無粋

計算機科学者とは、壊れていないものを修理する人々のことである

処理中...