2013年06月24日 20:21Fujii

魔法系操作を取り入れるための最適なUIデザインプロセス

IMG_3657

音声入力、ジェスチャー操作などの扱い

いわゆるGUIにおいてグラフィカルに表現するのは基本。

目新しあ音声入力、ジェスチャー操作を取り入れる時にも変わらない。

何かのUIのあとに別のUIの時代がやってくると思うのは楽しいかもしれないが、視覚的な表現というのものの時代が終わるとまでなるのかというと、それは現実とずれている。

視覚的な表現というのはなくならない。

音声入力やジェスチャー操作は補助だと考えたほうが良い。

視覚的な表現よりも大事になるということは、暗闇の中でしゃべったり、身振り手振りで操作する時代がくるのでなければありえない。

扱いの手順

表現が冗長になっている時に、音声入力やジェスチャー操作で行うことで軽減できる時もある。

しかし、この場合は代替ではなく、優先度の変更になる。

音声入力やジェスチャー操作を取り入れることで、いわゆる魔法系の操作のデメリットが生まれる。

なので、オーソドックスに視覚的な表現をすることが基本で、音声入力やジェスチャー操作を取り入れるならば、あえてデメリットを知りつつも取り入れるのが正直なやり方になる。

先に視覚的な表現、そこから冗長さを軽減するためにトレードオフ、ようやく魔法系操作の採用。この順番がよい。

このトレードオフの検討がないと、結局後で視覚的な表現も取り入れることになり、最も冗長な表現になる可能性もある。

2013年06月16日 19:20Fujii

機能に名前をつけるときに陥りがちなことと対処法

IMG_3641

「情報」と「管理」というネーミング

アプリケーションでよくあるラベルの中であまり意味がないものがあります。

それは、「なんとか情報」とか「なんとか管理」です。

なぜ意味がないか?

なぜ意味がないかというと、「情報」についていうと、画面にでているものはほとんど情報だからです。

また、「管理」のほうは、大抵のアプリケーションは何か操作します。

なのでこちらもいわずもがなで、ほとんどが「管理」になってしまいます。

柔軟性を失う

もちろん、編集権限に応じて、編集権限があれば、「なんとか管理」というラベルにして、逆に編集権限がないものは「なんとか情報」というラベルにするということもできます。

しかし、これは問題があります。

まず、アプリケーションを作っていくステップで最初の段階で、そのときに、閲覧専用なのか、編集もできるようにするのかを確実に決めることはあまり意味がありません。

もちろん各バージョンごとに決めることは意味がありますが、長い目でみた場合には変化するものだからです。

最初は閲覧専用だったものを編集することができるようにするというのはよくあります。

このときに、ラベルが「なんとか情報」だったものから「なんとか管理」に突然変わってしまうと、ユーザーは混乱してしまいます。

また、仮にそういったことがないとしても、権限の有無によって、ラベルを変更していると、同じユーザーでも権限が変わってしまうとラベル名が変わってしまうので、混乱します。

結果的に、柔軟性を失ってしまいます。

なぜこういったラベルが生まれるか?

これは予想ですが、アプリケーションを作るときに、最初に一機能しかないこともあります。

本当に最初の一歩のときです。

例えば、私がスノーボードのスキー場の担当者だとして、スノーボードパークの管理をしているとします。

日によってスノーボードパークに設置するアイテムが異なるとします。

このときに、何かアプリケーションが欲しくなり、アイテムを便利に管理しようと思うのです。

こうして生まれたアプリケーションは、まず日にちごとにアイテムを組み替えられるものになるでしょう。

できあがったときに、この機能について名前をつけるときがきます。

本来一機能であれば、ダイレクトに表示すればいいのでメニュー名はいりませんが、ここではアプリケーション名とします。

このときに、「スノーパークアイテム管理」というネーミングがうまれるのです。

このときに、長い目でみて、今後管理者以外が見るかもしれない、リフトの管理や、レストランの管理、従業員の管理を増やす必要がでてきて、管理者以外がみた場合や、なんとか管理だらけになるかもしれないとはなかなか考えられないものです。

対処法

既存のアプリケーションとの一貫性や業界や文化的な言い回しの慣習などにより、管理や情報をつける必要がなければ、最初はとってしまうほうが良いでしょう。

苦肉の策として「情報」を使うときもありますが、やたらめったら使わずそのときまでとっておきましょう。

先ほどの場合だと「スノーパークアイテム」だけです。

「リフト管理」も「リフト」、「レストラン管理」も「レストラン」です。

管理者権限があれば編集もできるようにして、なければ一覧を閲覧するだけにします。

このことで、管理者権限があってもなくてもまずはひとつの一覧をみるという共通のことを、なんとか管理や、なんとか情報にしてバラバラにしてしまうことを避けられます。

2013年06月14日 09:58Fujii

魔法系操作の復活と特徴

IMG_3630

UIの変遷

UIはテキスト主体のUIから、グラフィカルなUIに変わった歴史があるようです。

テキスト主体の操作は、方法を知らないとなかなか使えません。

グラフィカルなものは、表現レイヤーの組み合わせによってユーザーに微妙な差異を示唆するので、ある程度こんな感じかなというように使えます。

テキスト主体の操作は、プログラミングに近く、呪文を知らなければ使えないような側面があります。

これは魔法系の操作です。

魔法系の操作の復活

そういった変遷があるのですが、近年はUIの進化として、魔法系の操作が復活してきたと思います。

それは音声入力による操作や手がかりのないジェスチャ操作です。

音声入力による操作

音声入力は、自由にしゃべることで入力しますが、単なる文字の入力ではなく、操作を行おうとすれば、何か決まった型のことをしゃべらなければいけません。

これは魔法系の操作なのではないかとおもいます。

まさに、何かの呪文を唱えなければ何もおこらないのです。

手がかりのないジェスチャ操作

ジェスチャ操作には、目の前のものを触って動かすようなもののほかに、まったく手がかりのない操作もでてきています。

これらは知っている人には使えますが、知らない人には使えません。

こういったものも魔法系の操作で、いわば秘密の印を結んで唱えることではじめて操作できるようになります。

魔法系操作の特徴

一時は姿を消したはずなのに復活してきた魔法系の操作ですが、特徴としては魔法使いにならなければいけないことが挙げられます。

昔から魔法使いになるためには修行が必要で、魔法の書をよみあさり、覚えなければなりません。

まれに、日常生活で使う言葉や身振りで呪文が発動してしまうこともありますが、基本的には修行が必要になります。

魔法系の操作はこの点が弱点になりますので、修行をしてもらうか、補助的なショートカットのための操作になるかもしれません。

2013年06月12日 09:27Fujii

UIの表現の仕組みと注意点

IMG_3621

表現のレイヤー

UIは表現のレイヤーを重ねることでつくりあげる側面があります。

まず、基本的な要素を配置します。

例えばテキストで配置します。

ここで、各要素間の配置、距離の調節や整列を行い、グルーピングを行います。(細かくは要素の大小、フォントの種類なども用います)

次に要素に応じて形という表現を重ねます。

例えばボタンの要素であればボタンの形になります。

ここでなんの形も持たない要素はテキストのままになります。

また、バーのような複数の要素をグループ化したエリアも形を持たせることもあります。

例えばウェブサイトであれば、グローバルナビゲーションで、アプリケーションであればツールバーなどです。

また、リストの各要素ごとに線で区切るなど形を持たせることもあります。

次にハイライトとシャドウを用いて陰影をつけ、平面と立体的な要素を区別します。この表現レイヤーが追加された要素はインタラクションできることを強く示唆しはじめます。逆に、この表現レイヤーを追加しなければ平面のままで、インタラクションがあることを強く示唆しません。

例えば、これらすべての表現レイヤーが重なると、ツールバーの中のボタンで押せることを強く示唆した要素になります。

これらの表現レイヤーに加えて色のレイヤーを重ねることで、より細やかな要素の違いを表現します。

例えば、グレーのボタンは基本的なボタンであったり、赤い濃いボタンは削除であったりです。

インタラクションのあるものはその状態に応じてこれらの表現レイヤーを組み合わせて変化をつけます。

例えば、ボタンが選択されていれば凹んでいるように表現するなどです。

なぜこれらの表現レイヤーを用いるのか?

これらの表現レイヤーはなぜ重ねあわせるのかを考えてみます。

それは冗長な表現にならないようにするためです。

例えばテキストのみで、その要素がボタンで押せる要素であり、現在は押されていない状態であり、表の一行の中ではなく、ツール類のひとつであることを示唆することはできなくもありません。

しかし、とても冗長になります。

具体的には、ツールという見出しの下にツール類のリストがテキストで並び、昔のウェブサイトにあったような「ここをクリック」という文言、さらに押されているときは、「クリック中」、選択状態の時は「現在選択中」などの文言も必要になるかもしれません。

仮に各要素の違いを、レイアウトによる配置、距離の調節、整列を用いて表現した場合、ツールであること、表の一項目でないことなどを区別するために多くの面積が必要になります。

表現レイヤーの種類を減らすと、残りの表現レイヤーの柔軟性が低下する

複数の表現レイヤーを重ねることで表していたことを、それよりも少ない表現レイヤーで表そうとすると、ルールをより一層厳密にしなければなりません。

例えば、陰影や形による表現レイヤーを使用しないとしましょう。

この場合、要素間の距離、整列だけでは表現できないため、配置を厳密にする必要が出てきます。

具体的には、画面の上と下に並んでいるものは押せるもので、左上にある要素は戻るためのものとするなどのルールが必要です。

バージョンアップなどで変更した場合、それまでの配置の法則に則っていれば表現レイヤーを減らした影響はそれほど大きくないかもしれません。

しかし、表現レイヤーを重ねるというのは単に一部分の表現ではなく、微妙にシフトさせて拡張することができるという特徴もあります。

例えば、ボタンの形をしていたものがほかの位置に表示されたときにも、いつもと違う場所にあるけれど似たような要素であるという表現になります。ユーザーのそれまでの学習を生かし、要素に対する理解を広げることができます。

対して、先ほどのように表現レイヤーを減らしていた場合、つまり配置がとても重要な意味を持っている場合、位置を変えてしまうと、要素が表現することが変わってきてしまいます。

左上にあるテキストならば押せるし戻るという厳密なルールは、逆にほかの場所にテキストが移動した場合に全く表現できなくなってしまいます。こういった柔軟性が失われてしまうのです。

表現のレイヤー内の種類が多過ぎても機能しない

先ほどのようにテキストによって区別しようとすると冗長になるのと同じように、例えば、陰影という表現レイヤーのみで区別しようとしてもできません。

表面の質感や柄を細かく区別しすぎても伝わりませんし、アイコンの中に複数の意味を持つ表現をたくさん組み合わせてもつたわりません。

表現レイヤーは組み合わせることではじめて微妙な表現ができます。

表現レイヤーを重ね過ぎても冗長になる

ここまでの話の大前提として、すべての表現レイヤーはささやかに使うということがあります。

当然単に論理的な構造に合わせて増やしていけばいいわけではありまさん。

表現レイヤーを重ねたものも最後はひとつの要素としてまとまりがなければならないからです。

そして、さらに画面としてのまとまりや、システムとしてのまとまりも必要です。

なので、あまりに重ねすぎてよくわからないものになるよりは、多少区別できなくても、これ以上はやったところで良くならないというように引いていくことが重要になります。

たまに、いままでにないものを!と思っているとここで、新しい漢字を作ってしまうようなわけのわからん表現をしてしまう落とし穴にはまります。そういった表現は発明した気になっていても、オリジナルの漢字のように誰も読めない上に、あの漢字を間違って書いちゃったのかな?と思われ中途半端な結果になることもあります。そういう誘惑に負けないように冷静に判断する必要もあります。

2013年06月06日 09:22Fujii

小さい単位のコンテキスト

IMG_3594

異なるものを扱っていても似ているUIになる

UIをデザインしていくと、異なるものを扱っていても不思議と似ているUIになることがあります。

コンテキストを把握してそこに最適化された特別なものをイメージしているとギャップがうまれます。

なぜこういうことが起きるのでしょうか?

基本的にユーザーのコンテキストによってUIは変わりますが、小さな単位ではユーザーがやりたいことが同じであることが多いからだとおもいます。

例えば、一覧することや、その一覧を検索するという要望です。

扱っている対象は映画なのか、電車なのか、写真なのか、つぶやきなのかはコンテキストによって大きく変わりますが、それを一覧する、検索するという小さい単位のユーザーのコンテキストは似ています。

その結果、異なるものを扱っていてもある点からみれば似ているUIになります。

注意点

扱うコンテンツは異なったとしても、一覧したい、検索したいというのはたくさんの人が同じようにもとめます。

なので、似通ったものができることがあり、それは自然なことでもあります。

このときに、こういった小さな単位のコンテキストを無視して、調査をしてわかったことを元に作ることにこだわってしまうと、基本的な部分が抜け落ちたUIになります。

特に機能を先に考え、UIにすべて押し込めようとすると、こういった基本的なコンテキストが下手すると押し出されてしまうこともあります。