ソフトウェア開発」カテゴリーアーカイブ

Leap Motion User Experience Guidlines の訳

Web上のページでは見つける事が出来なかったのだが、SDKには User Experience Guidlines がついてくる。
Leap Motion の障壁としては、やはりどれだけ操作を楽に行う事が出来るのか。
そのために開発者が何を考えるべき(知っておくべき)なのかが書かれている。

英語に関してはからっきし自信は無いが、適当に日本語訳してみる。

Keep in mind that symbology can be difficult to learn and memorize.
Avoid forcing users to learn complex hand gestures to interact with your application.

記号と言うものは学習したり覚えたりするのが難しいと言うことを覚えておきなさい。
あなたのアプリケーションで、ユーザーに厳密なジェスチャーを矯正するのは避けなさい

Instead, draw inspiration from physical interaction and real-world behaviors.
The more physically inspired interactions are, the less training a person needs and the more intuitive and natural your application feels.

その代わり、自然な操作や、現実世界の振る舞いから着想しなさい。
本当に自然な操作と言うものは、トレーニングを必要とせず、より直感的に、より自然に感じられるものでしょう

Don’t feel constrained by the limitations or inconveniences of the real-world — this is your world.
Interaction doesn’t have to be the way it has always been. It can be any way we imagine it to be. Why force the user to reach all the way out and grab an object? Why not have the object reach back? — Give them “the force”!

現実世界の制限や不便さを持ち込む必要はありません。これはあなたの世界なのですから。
操作は決められたものである必要はありません。それは、私たちがイメージしたように出来るのです。なぜユーザーにブジェクトをつかみ取る事を強制するのですか?なぜオブジェクトを引き寄せないのですか?力を与えてあげてください

The user should feel as if their intent is amplified rather than subdued or masked.
For example, users often like their movements to be amplified when using a mouse (i.e. they don’t need 10 inches of mouse movement to move 10 inches on screen). For gestural interactions, amplifying or exaggerating responses can have an even more positive result. Keep in mind that some people are more sensitive than others, so link this exaggeration to a sensitivity setting for users to modify this effect to their preference.

ユーザーは、彼らの意図が増幅されていると言うよりむしろ地味に、またはマスクされているように感じるでしょう。
例えば、ユーザーはマウスを使っている時に、意図が増幅されている事が好きです(10インチモニタ上を動かす時に10インチマウスを動かす必要が無いように)。ジェスチャー操作の場合、増幅または誇張されたレスポンスは、ポジティブな結果を産みます。何人かの人たちは、他の人々よりもとても敏感だと覚えておいてください。なので、これらの効果は、彼らに合わせた形へ設定変更出来るようリンクを貼りましょう。

Concentrate on giving the user dynamic feedback to their actions. The more feedback they have, the more precisely they can interact with your software.
For example, the user will need to know when they are “pushing” a button, but can be more effective if they can see when they are hovering over a button, or how much they are pressing it.

ユーザーの行動からフィードバックを得る事に集中しましょう。多くのフィードバックによってあなたのソフトウェアで彼らは正確な操作を得る事が出来ます
例えば、ユーザーは自分たちがいつボタンを押したのかを知る必要がありますが、もし、ボタン上をホバーしているのが見えたり、どれくらい押しているのかが見えたりすればより効果が上がります。

On screen visuals (such as representations of hands, tools, or digital feedback) should be simple, functional, and non-intrusive.
The user should not be distracted from the task by their tools or environment. Decoration should not distract from your purpose.

画面上の見た目(手やツール、デジタルフィードバックに代表されるような)はシンプルで機能的で、そして邪魔にならないようなものであるべきです。
ツールや環境によって、彼らの作業が邪魔されないようにするべきです。あなたの趣旨によって装飾するべきではありません。

Require more deliberate action for destructive or non-reversible acts than for harmless ones.
Subtle gestures should be reserved for subtle actions. Conversely, an act such as closing an application or deleting a file can be a non-reversible event requiring a more deliberate action. Double check with the user when unsure, such as a prompt for confirmation.

無害なものよりも、破壊的もしくは不可逆な行動と言うものによりゆっくりとした動作を求めるべきです。
目立たないジェスチャーは目立たない動作へ割り当てるべきです。逆に、アプリケーションの終了やファイルの削除のように不可逆なイベントにはより確証がなかったりする場合は、確認プロンプトを出すなどして2重のチェックを行うべきです

Provide a clear delineation and specific sense of modality between acts of navigation and interaction, unless both are simple or one is handled automatically (or with assistance). Mixing the two in a complex situation can lead to confusion or disorientation.
For example, moving an object while having the user simultaneously position their viewing angle inside a 3D environment is inherently difficult. However, if the viewing angle moves automatically in response to the user’s movement, then working with the object is easier. Likewise, when navigating a large data set the user will want the view to move easily, but when highlighting a portion of the data the view should remain still.

ナビゲーションや操作がシンプルだったり自動的だったりしない限り、明確な線引きを提供出来るだろう。複雑な2つの状況が重なりは、混乱や方向感の喪失へと繋がります。
例えば、ユーザーは3D環境で、同時にアングルと位置決めを行う事は本質的に困難です。しかしながら、アングルが動作によって自動的に変わってくれれば、オブジェクトを動かす事は容易になります。同様に、大きなデータを扱う場合、ユーザーは容易にビューが動いてくれる事を望みますが、データの一部を強調させたい場合には、ビューは固定されるべきです。

Overall, imagine that your user is faced with no instructions or tutorials on how to use your application.
Strive at all costs to make their first intuitive guesses the right ones. Where appropriate, create more than one proper way to do something.

あなたのアプリケーションを使うとき、ユーザーが操作に対するチュートリアルや説明が無い場面に出くわす事を想像してみてください。
ユーザーによる直感的な推測が正しいものとなるように力を尽くしなさい。場合によっては、成し遂げるためのよりよい方法を作り出しましょう。

(LeapSDK/docs/GetStarted/Leap_UX_Guidelines.html)

 

いやー。英語力の無さになんだかがっかりしてしまうがしょうがない。
相当、怪しい訳になってしまったので突っ込みどころ満載だと思うので指摘をお願いします。

ほんと、訳をやってる人は凄いわ。
私も修行つまないといけませんね。

Leap Motion コントローラーの置き場

SDK付属のサンプルアプリケーション「Touch Emulation」をとりあえず作ってみた

Airspaceに最初からついてくるOrientationアプリケーションでも分かる事なのだが、実際にどういう風に認識されるのか。
ジェスチャー毎にサンプルで見てみると検出がうまく行っていなかったりする事がよくわかる。

とりわけ、Google Earthで苦労した、「手のひらを飛行機に見立てて動かす」と言うことがうまく行っていないのが分かる気がした。
気を抜くとすぐに指の位置がばらついてしまったり傾いてしまったりするのだ。

アプリケーションでどういう操作をするのかで置き場を変える

なんで水平に手がならないのかを考えてみればすぐに分かった。

もちろん、単純に水平にする事が難しいと言うのもあるんだろうけど、私の場合はLeap Motion のコントローラーを体の中心線上に。
つまり、左右の手の真ん中においているからなのだ。

その状態で、片手を真ん中に持ってきて水平をしようとすれば無理が出る。
マウスをどちらの手で使うかは別にしても、使う手の方にマウスは置く。
であれば、Leap Motion のセンサーも使う手の真下に来る形に配置してあげればいいわけだ。

Leap Motion の場合、アプリケーションによっては片手ではなく両手を使って操作をすることもあるので、アプリケーションで必要とするジェスチャーによって、センサーの位置を調整するほうがいいように感じる。

というか、そういう調整によって操作性が著しく変わるのであれば、アプリケーション側でそういうナビゲーションをした方がいいのかな?
でも、一々マウスの配置を指定するようなアプリケーションは邪魔臭いだろうし。

うまく認識しない時の、ヘルプというかアドバイス機能と言った所だろうか。

色々と使ってみると、ちょっとした発見があって面白いですね

Leap Motion アプリあれこれ

妻に「これすごいでしょー!」って見せたんだけど、
「何に使うの?家でプレゼンでもするの?」
って、そそくさとPCの前を去られました。

悔しいので Leap Motion でいくつかのアプリを動かしてみたので備忘録代わりに書いておく

LeapMotionのアプリケーションは、専用のランチャーであるAirspaceにまとめられる。

アプリケーションはAirspace Storeで取得する事が出来る

MacとWindowsの対応状況を確認して入手することになります。

ゲームや地図アプリケーション

Google Earth では手のひらを飛行機のように見立てて3D空間の中を移動する事が出来る。これは体験としてはとても面白いもの。
これに慣れてしまうとマウス操作での3Dマップ移動はとてももどかしく感じてしまうのではないかと思えてしまう位楽しい。

ただ、現状では操作に少し熟練を要する。

やってみると分かるのだが、思ったように移動が出来ずにクルクルと回ってしまったりする。手のひらを見ながらであれば、ある程度水平に保つ事が出来るが画面を見ながらだとこれが意外と難しい。

Boom Ball では指差しによるブロック崩しを楽しむ事が出来るが、これも思ったように動かす事が出来ない。
ゲームで息抜きするはずが、逆にストレスをためてしまいそうだ

Boom Ball に関しては、下方向からだけのセンサーで扱うには少し厳しいのではないかと思ってしまった。Google Earth は慣れればそれなりに動かす事が出来る。

ただ、何れにしてもずっとアプリケーションを動かしていると意外と手が疲れる。
この辺りは、もう少し体験に慣れて気持ちが落ち着けば、疲れの感じ方も変わるのかもしれないけれど。

プレゼンテーション

タッチと異なり、奥行きの操作が出来るので、やはりLeap Motion で3Dは外せないだろう。
そう考えると、ゲームやマップの移動以外では、3D模型のプレゼンテーションに使える

Cyber Science – Motion 

や、Molecules 

は、まさにそういうアプリケーションだ。
拡大や縮小。方向転換を容易に行う事が出来るので、平面の教科書で勉強するのとはだいぶ違ってくる。

こういう使い方であれば、常にLeap Motionを操作し続けるわけでもないだろうし、それほど操作が複雑にはならないので受入れやすそうに感じる。

3D以外

奥行きがあるのでどうしても3Dアプリケーションに意味を求めてしまいたくなるが、単純にジェスチャーによる操作が出来ると考えてしまえば通常のアプリケーションへも適用できる

 

これはNYTimesのニュースアプリ。
同じように、Facebook のPhotoアプリもある

私はFacebookにろくに写真をアップロードしないので何も面白くなかったけれど、まぁ、誰かと話をしながら見る分には面白く使えるのかもしれないな

何のジェスチャーにどの操作を割り当てるのかは結構考えどころだ。
それに関しては、また今度に。

Leap Motionがやってきた

水曜日に発注したLeap Motionがようやく到着しました!

パッケージや梱包は、なんだかAppleを思い起こさせるような外観ですね。
妻が「またよくわからないものを・・・」と怪訝そうな顔で見てきましたが、
気にせずに行きます

 

本体をUSB接続したところ。
真ん中と両脇でセンサーが光っているのが分かりますね。

 

早速いくつかアプリケーションを試してみました。
写真はGoogle Earthを手のひらで動かしている所。

まだ、触り始めたばかりなので何とも言えない所ですが、
センサーがあくまで下から出ているので、水平方向の認識はそれなりにするけど、
垂直方向に少し傾けてしまうと思ったように認識してくれなかったり、難しく感じる場面が多いです。

この辺り、他のアプリケーションを動かしてみながらもう少しまとめられればと思います。

 

Leap Motionが楽しそう

世間ではお盆だそうです。
お盆ってなんでしたっけ。
あぁ、通勤電車が不思議と空いていて快適に会社に行けるラッキーな期間の事ですよね!
確か5月にも似たような期間があった気がしますが。

まぁそれはさておき、Facebookのタイムライン見ていたらLeap Motionの記事がシェアされていた。

Leap Motion

以前、何かの記事で軽くは見た事はあったんだけど、今読み返してみるとかなり面白そう。

Leap Motion
https://www.leapmotion.com/

初めてのLeap Motion開発
http://www.buildinsider.net/small/leapmotioncpp/01

簡易版のKinectみたいな感じだけど、普通のPC操作においてKinectのように全体をとらえる必要性ってそれほどなくて、Leap Motion くらいがちょうどいいように思う。

以前、Kinectを医療現場で使っているような動画があったけど、タッチすらし辛い環境と言うものはやっぱりあって、色々と使える場面はありそうな気がする

ただ、ジェスチャーでモノを動かすと言うのは結構難しいはず。
それほど人間の動きは安定しては無いので、思ったように動かなかったり誤作動したりする
懸念はありそう。
ただ、この辺りはやってみないと分かんないと言えば分かんない。

ちなみに、本家から購入すると10,500円かかる。
Amazonで見てみると15,980円。
随分と高い手間賃だなぁ

トラブルの調査は楽しいか

ここ数日、お客様先で発生したトラブルの調査やらなんやらにかなりの時間を費やしています。

IISのログやOracleのログを追いかけてみたり、関係各所に調査を打診したり
カウンタの値を見ながら原因を推察したり。

何となく原因説明のストーリーは立てられなくもないけど、それを裏付けるには
トラブル発生時の状況を示すための資料が足りない。
足りていない部分をあれこれと推察しながら資料を作っていくことになります。

不謹慎ながら、こういう技術系の調査や原因の究明に頭を使うのって楽しいんですよね。
それは多分、原因を調べていく過程で、これまで把握していなかった知見を得ることが出来たり、
推測をデータで裏付けていくことが出来た時にすっきりするからなのかもしれません。

でも、ぶっちゃけてしまうとどれだけ考えても明確な裏付けを持たせることが難しい場合もあるし、
こうやって考えたりしている時間は短ければ短いほどいい。

なぜならば、こういうことに時間をかけていても、その時間で価値を生み出している訳ではないから。
本来は、もっと価値を生み出すことに時間を費やし、そこに楽しさを見いださなければ行けない。
そこが中途半端だったりするから楽しく感じてしまうのかもしれないな。

と言う訳で、障害からの復旧をいかに手をかけずに効率よく行えるのかをもう少し真剣に考えてみることにする。
え?障害が起きないように頑張れ?

そんな夢、見てらんないよ

テストから見えてくるグーグルのソフトウェア開発

表題の本を読んだ

テストから見えてくるグーグルのソフトウェア開発
ジェームズ・ウィテカー ジェーソン・アーボン ジェフ・キャローロ
日経BP社
売り上げランキング: 1,971

本書は、Googleにおけるテストの考え方やテストの実践を通して、Googleにおけるソフトウェア開発や思想を紹介しているのであって、テストの仕方を学ぶものではない。

もちろん、Googleという巨大企業がどういうテスト体制というか、ソフトウェア開発体制をしいているのかということは知ることが出来る。
そこから展開できることも多くあるのだが、考え方は参考になってもやり方はまねできるものは少ない印象を受けた。

私は開発の現場を多く知っている訳ではないので、知っている世界と言うものはたいへん狭い。
なので、どういう開発体制が一般的なのか?ということに関して語る言葉を持たない。

しかし、開発の現場によってどういうメンバーがいるのかと言うのは大きく変わっていくんだと思う。
テスターと呼ばれる専門メンバーを用意できる体制もあれば、仕様検討と設計、コーディングが完全に別れている体制もある。

何がベストかは結局の所何を開発するのかにもよるだろうし、ベストと思われる方法があったとしても、会社の経済的な理由やリソースが足りないこともよくある話だ。

結局の所、その場その場で考えて動くしか無いという結論になってしまうのかもしれない。
ただ、だからこそ、こういった様々な事例をインプットしておくのは必要なことだと思う。
実践できるかどうかは別として、中々面白く読むことが出来た。
思わずGoogleに入りたくなるくらいだ(門前払いが確定しているが)

テスターという位置づけを確保することは、ちと難しいかもしれないが、
それでも持ち回りでそういうことを意識する役割を設けてみるのも面白いかもしれない。
なんて思った。

JINS PC メタルスクエア

これまで、職場では基本的にJINS PCをかけていて、家ではそれほど多くの時間をPCの前にいないので裸眼でした。
週末だけ、家にもってかえって着用するような形です。

それはそれで何とかなっているのですが、最近、少しずつ家でのPCに向き合う時間が馬鹿にならない気がしていてもう一つ欲しいと思っていました。
と言う訳で、少しお出かけした際に購入。

写真の奥においてあるのが今までのもの。
今回買ったのは、手前の「メタルスクエア」というタイプ。
見てわかるように、これまでのものよりフレームが細いです。

私のように、元々メガネをかけていない人間にはメガネをかける事自体が少しストレスです。
なので、少しでも軽くてフレームが気にならないタイプの方がいいのではないかな?と思った次第です。

1週間ほど会社で着用してみましたが、正直どれほど効果があるかは思っていた以上にわかりませんでした。
自分でも思っていた以上にメガネに慣れてしまっていたのかもしれません。

それよりも困ったのはメガネケース。
以前購入した際は、プラスチックのケースが付属されていたのですが、今は布で出来たソフトケースだけのようです。
これは持ち運びにはとても怖くて使えません。

と言う訳で、以前購入した際についていたケースを会社用に。
家で使う用にソフトケースを、と言う形で入れ替えて使うことにしました。

体感することの無いJINS PCの効果ですが、体感してからでは遅いってのもあるとは思うので、暫くはつき合ってみようと思っています。

ネットワークトラブル

お客さん先で、不可解な現象が発生していてその調査をしています。

実際問題、アプリケーションの問題と言うよりはインフラ。
特にネットワークの問題である可能性が高いのですが、
そこまで完全に決めつけるには一貫性ある説明が出来ない苦しい状況。
さてはて。困ったな。

今回に限った話ではないけれど、トラブルの原因がネットワークや
それに類する機材にあった場合の原因の切り分けは骨が折れる。

よく、ネットワークモニター等を利用してパケットの流れは確認し、
問題が起きている事はわかる。

ただ、それがどこで起きているのか。
何が原因で発生しているのかを突き止めるのは地道な作業になる。

ロジックとして説明出来る事もあれば、機器の故障で本当に不可解な現象が発生して、
機器を交換して初めて「この機材が原因だ」とわかる事もある。

もちろん、ネットワークに対する知識が足りずにそういう判断しか出来ないという話もあるのだが、
この分野だけはどれだけ勉強しても”詳しい”と言えないような気がするなぁ

一言多い人になっていないかを気をつける

少し前にオルタナティブブログにてこんな記事を見かけた

実際にあった怖いバグ票(バグレポート)
http://blogs.itmedia.co.jp/morisaki/2012/08/post-a506.html?ref=rssall

見ながら、「あ〜、あるある」と思った節が何度となくあった。

指摘している内容や、考えている方向性だったりするものはしっかりとしていて、
それ自体は本当は評価されるべき内容なのにも関わらず、
最後に余計な一言が書いてあるせいで読み手にものすごい不快感を与えている。

それでいて、その人にとってはその一言こそが言いたい事だと考えている。
そこがまた一際厄介なんですよね。

言っている事がわからなくはない。
背景を教育しなければ、今回の問題はクリアされてもまた別の形で現れるかもしれない。

ただ、それはバグ票という媒体の役目かというとちょっと違う気もする。
その辺りの交通整理を、プログラマ以外の人に対してもわかる形で行えるようにならなければダメだと思う反面、
自分自身がそういう動きをとっていないかを気をつける必要がある。

なんだかんだ言って、私がメインでプログラムを書く機会というのは減って来ている。
どちらかというとチェックする側に立っているわけで、文句を付けたい衝動に駆られる機会も多い。
ううむ、少し自信無くなって来たぞ