HyperCard tribute

ユーザーインターフェース

　ユーザーインターフェースは、スタックを作る上で最もしっかりと作成しなければならない点の一つです。この章ではいくつかの注意点を並べてみることにします。

■フィードバックを返す

　フィードバックとはユーザーの何らかの動作に対しての反応のことをいいます。使いやすいスタックには、フィードバックが必ず備わっているといっても良いでしょう。
　最も基本的なフィードバックは「即応性」です。ユーザーの反応に対してすぐに何らかの反応を返すという事です。例えば、ボタンをクリックした時、何も反応がないとユーザーはスタックがちゃんと動いているのか、それとも止まっているのか不安になります。そこで、フィードバックを返すわけです。

方法１：ハイライトや点滅をさせる
方法２：サウンドを鳴らす
方法３：処理中はマウスの形状を変える

　ボタンを用いた場合には、ボタンの設定の「オートハイライト」をONにすればハイライトをさせることができるのですが、これがフィールドの場合だと少し難しくなります。これに対しては、フィールドの上に同じ大きさのボタンを置いておけば良いのですが、しかしオブジェクトの増加に伴うスピード低下がおきてしまいますので気を付けて下さい。
　ハイライトはスクリプト中でもさせることができます。

  • set the hilite of <オブジェクト> to
    　オブジェクトのハイライトプロパティーが、trueならば黒く反転し、falseならば通常の状態に戻ります。（この命令はボタンでしか使えません）
    　この命令を使うことでボタンの点滅をさせることができます。mouseDownハンドラにこの命令を用いて、mouseUpで通常の処理をさせるようにすれば、オートハイライトと同じ動作をさせることもできます。

    　マウスの形状を変えるのも一つの方法です。Macでは処理中には腕時計のカーソルに変わるのでよくご存じだと思います。

  • set the cursor to <カーソル名>

    カーソル名：
    IBeam（テキストを入力するときに使う、縦棒のカーソル）
    cross（十字のカーソル）
    plus（表計算で出てくるような、太い十字カーソル）
    watch（腕時計。針が動きません）
    hand（HyperCardの通常時のカーソル）
    arrow（Macintoshの通常時のカーソル）
    busy（ビーチボール。処理中は回転します）
    none

    　処理中であるというサインを返すことで、待ち時間が短く感じられるということもありますので、しっかりとフィードバックは返しましょう。


    ■キャンセルを付ける

    　Macのほとんどの動作にはキャンセルボタンがついています。これにより、ユーザーは安心して処理をさせることができるのです。間違ったボタンを押してしまうと、終わるまで大変な時間がかかったり、重要なデータが消えてしまったりするスタックは誰も使いたくないと思うでしょう。もちろん、それほど重要でないスタックでも同様に、キャンセルボタンは付けておくべきです。
    　例えば、ダイアログボックスを用いてある連続するデータ（住所録などを思い浮かべて下さい）をユーザーに入力してもらうことにします。データを入力しているときに、気が変わったり、突然の用事で中断を余儀なくされるかもしれません。そんなとき、キャンセルボタンがなければ、終わるまで続けるしかありません。
    　スクリプトを途中で止めるためには、コマンドキー＋ピリオドを押します。しかし、これはHyperCardに用意されているキャンセル方法ですので、ユーザーの中には知らない方もおられるかもしれません。そこで、長い処理の場合など処理の途中でキャンセルをさせる必要があると判断するならば、スクリプト中に処理中断のチェックをしておけば良いでしょう。例えば、画面には「キャンセルしたいときはマウスボタンをクリックして下さい」などと表示しておき、スクリプト中でmouseのチェックをするのです。
    　キャンセルをした後には、元の状態に戻すことも忘れないようにしておいて下さい。フィールドの内容を書き換えるようなスクリプトの時は、その処理をする前の状態を他にコピーしておいたりすることが必要です。


    ■モードを作らない

    　これはMacintosh全般に言えることですが、モードを作らないということも重要です。この処理をするためには、先にモードを切り替えておくという動作の事をいいます。
    　モードを導入すれば慣れた人にとっては、大変すばやく目的の動作ができるようになります。しかし、慣れてない初めてそのスタックを使う人の立場から考えると、このモード切り替えはわかりづらいものになってしまいます。
    　例えば、自分の名前をデータとして登録するとしましょう。画面内にフィールドを用意しておき、そこに名前を入力した後「登録」ボタンをおすという動作と、「登録」ボタンを押すと名前を聞くダイアログ（あるいは名前を入力するフィールド）が出てくるという動作のどちらが、わかりやすいでしょうか。おそらく、後者の方がわかりやすいと思います。それは、似たような物が２つ以上あることに対するユーザーの不安が引き起こしたものと言えます。
    　つまり、この動作をするためには、先にモードを変更する必要があるということを避けることで、初めてそのスタックを使う人にもわかりやすくなるのです。


    ■ユーザーが覚えなければいけないようなインターフェースは作らない

    　当然のことですが、覚えることの少ないスタックほど、ユーザーはそのスタックを早く理解することができます。あるデータをコピーするのに、メッセージボックスから copy と打ち込まないといけないとするならば、それは最低なスタックといえます。それは、ユーザーに無駄な努力をさせているからに他なりません。
    　これは、このようにコマンドをタイプするような場合だけに限らず、複雑な動作をさせるスクリプトには、説明を付けるといったことにもつながります。例えば、ボタンをクリックしたときと、オプションを押しながらクリックしたときの動作が違う場合などです。このような場合などは、メッセージボックスに説明を出したりすることで、ユーザーは無駄なことを覚えることを避けることができます。
    　同じように、アイコンの作りすぎにも問題があるでしょう。確かにアイコンはわかりやすいですが、何でもかんでもアイコンにしてしまうと、逆にわかりにくいものとなってしまいます。


    　ユーザーインターフェースは大変重要な部分です。この部分のできにより、そのスタックの評価が大きく左右されるという部分ですから、じっくりと時間をかけてユーザーの立場にたったインターフェースを考えなければいけません。