menu
works company

11.12.01

category

comments

0

trackbacks

0

permalink

MapFan for iPhone 1.5 が iPad のトップ有料で1位を獲得

mzl.eycobknf.480x480-75.jpg

UI 設計/デザインをお手伝いさせていただいている MapFan for iPhone 1.5 がリリースされております。
大きく進化したのは横画面対応、iPad 対応(ユニバーサル)。iPad のトップ有料で1位を獲得しました。

これは INCREMENT P スタッフのみなさんのモチベーションの高さ、ものづくりにおける包容力、大胆な戦略をとれる決断力のなせる技だと思います。

mzl.cmhdjcco.480x480-75.jpg

そして、制作サイドではやはり実装とデザインが深くコミュニケーションしながらものづくりができることはとても強力なのだと実感しました。
実装を行っている HMDT さんとは、Agile 的なこともずいぶん前からあたりまえのようにやっていましたし、少しの無茶もいえる関係があったからこそクオリティを生み出すことができたのだと。

こういう形でプロジェクトに関わることができ、今回こうして結果もついてきたことは本当に嬉しいことです。みなさまに感謝!

関連リンク:


11.11.10

category

comments

0

trackbacks

0

permalink

[AIIT]インターフェイス設計の8原則

認知科学はときに難解で数回に分けて行われている授業でもたびたび睡魔に襲われつつようやくあと1回を残すとこまできた。昨日は特に UI デザイナーにとってはとても重要な講義だった。

講義ではノーマンのメンタルモデルの話やよいデザインの4原則などが紹介されたのだけど、なかでも「インタフェース設計の8原則(Shneiderman, 1996)」は自分がデザインや設計を行うときに常に肝に銘じているもの。

shneiderman.png

UI の使い心地をダイレクトにユーザが感じてしまう今日のタッチデバイスのアプリケーションにおけるデザインでは非常に強力な原則だと実感しているものなので、この機会にもう一度おさらいをしておきたいと思ったのでエントリ書いてみました。
(でも、いっぺんにはできないのでちょっとずつw)


1. 一貫性を持たせる

「一貫性」とひとつかみにすると難しいのだけど、なぜ一貫性を持たせるべきなのか?という問いに対する自分の理解としては、

・「システム」と「ユーザ」のメンタルモデルの乖離を最小限にするため
・ユーザのメンタルモデル形成時において、ルールを設けることでユーザがデザイナーの意図したモデルを正しく学習できるようにするため

という感じ。

一貫性と言われて、手短かなところで例をあげると iOS のナビゲーション。

画面のリストをタップすると、画面が右から左にスライドしてより詳細な情報の画面へ遷移する。上のバーの左にある横向きベース形状のボタンをタップすると遷移元の画面へ戻れる。
詳細画面が左からスライドして現れることから「左から右に向かって情報が階層的になっている」というルールをあることを理解する。
遷移した画面の上部のバーの左側の横向きベース形状のボタンをタップするとどうなるか?(遷移元の画面に戻る)は、物理的な側面から類推することができる。

navigation_controller.png

しかし、利用するうちに「左上にあるボタンは戻るボタンである」という感じに位置的記憶が強くなりすぎでMusic Appの「Store」ボタンを間違ってタップしてしまう、というようなエラーを招くこともある(あ、これ蛇足だ)ので注意。

情報構造のテンプレートを用意したり、アニメーションをつかって物理的なイメージを与えたり、ビジュアル的な記憶を使ったりして、一度使えばシステムのメンタルモデルを理解できるのはそういう手法によって生み出された一貫性によるもんなのだよね。

で、一貫性を持たせるためにはどんなことをするかというと、

(Model)
・情報の構造化(noun)
・コンテキストにおけるユーザのアクションの予測(verb)
・モードの利用

(Visual)
・空間的な記憶の利用
・正しいマッピング
・体制化の利用(ゲシュタルトの法則)

などを利用する。
デザイナーはとかく見た目の一貫性だけに固執してしまいがちだけど、そうではなくて全体として「一貫性」というものをとらえないといけないすね。自戒も含め。

てなわけで、今日はここまで。
時間ができたらまた続きをエントリします。

11.11.04

category

comments

0

trackbacks

0

permalink

[AIIT]評価グリッド法による価値分析

今日の演習は評価グリッド法を用いた価値分析だった。
フローモデル図のときと同じく、また理解がしきれずもやもやが残ってしまったので少し整理をしてみた。
講義で教えていただいたことと復習のために web などで調べたことを自分的な基準で統合して書いているので、もし理解が間違っている部分があればぜひ指摘してもらいたいです。


評価グリッド法

どのようなことができるか
・サービスやプロダクトに対してのユーザの評価を
 「抽象的価値」「感覚的理解」「客観的・具体的」と階層的に把握できる
・被験者(interviewee)の本音が聞ける

どんなときに使えるか
・(サービスやプロダクトの)スペックの判断材料
・改善の糸口の発見、改善後のベネフィットの把握

gridmethod111103.png

これだけ聞くとマーケティング的な側面しか見えずらいのだけど、調べていくとこれがメンタルモデル・アプローチ(この言葉すごくしっくりきた!)におけるユーザ側のモデルの一種だと考えると、以前演習したペルソナ/シナリオ法の3つのモデル(フロー、文化、シーケンス)と並ぶペルソナづくりの素材にもなると感じた。
KA 法は価値項目の抽出が効果的にできる反面ユーザ像が若干希薄になる感じがするのだけど、評価グリッドはその人自身の価値観のモデルが浮き出てくる感じ。

mentalmodel111103.png

どういうふうにやる?
・半構造化インタビュー(用語難し杉)
 事前に大まかな質問事項を決めておき、
 回答者の答えによってさらに詳細にたずねて行く簡易な質的調査法
・比較対象物を用意してそれらを被験者に比較評価してもらい、その評価理由を聞き出す
・ラダリング技法
 上位概念(how、どのように好ましいか?)・下位概念(what、好ましくあるための条件とは?)の抽出


演習

・この手法を理解しよう
・プログラム上の共通課題「旅支度」
というところから(だと思う)、既に調査済みの4人分の旅支度に関するコンテキストインタビューメモの項目を比較対象物として、3人1組で「interviewer」「interviewee」「recorder」役をそれぞれ実習。調査した結果は9人組になって1つの構造図にした。

インタビュー実施
1つ1つの行動についてのラダリングはまあなんとかできて、横方向の構造化?はできた。
inteviewer と recorder が別なので「あ、いまラダーアップしたつもり」なんだけどラダーダウン方向に記録されたりすることはあったけど、あとでみんなでレビューしたときにそれぞれの意見を出し合って修正できたから問題なし。
あと、これは復習しているときに見つけた blog に書かれていて「うん、たしかに」と思ったことなのだけど、その場で3人が記録されたグリッドを見ながらやるとラダーの方向が整地されるのと interviewee に内観的なことが起って答えも整地されるので「グリッドを共有しながらインタビューする」というのはいいですな。

難しかったのは比較素材がサービスやプロダクトといった具体的なものではなくて、インタビューのメモだったということ。そこから「比較対象を決定する」ことがつまずきどころ。

Q:No1さんとNo2さんの「持っていくアイテム」について、どちらが好ましく思いますか?(一対比較になるのかな?)

みたいに始められると、ラダリングっぽさ?がでてよかったのかもしれない。
(けど、両方の人に書いてあって比較できる共通項目を探すのが大変)
interviewee 自身の考えと No1さんの考えを比較するだと(単独評価になる?)、どうしても「比較してどう思う」というより「私はこう思う」にながれがなってしまってラダリングからはみでる感じがした。

どこかのサイトでインタビューの始めに比較する商品について好ましい順に並べてもらうという手法が紹介されていたが、全体のヒエラルキーを作ってもらうことで interviewee 自身で複数あるであろう価値の視点をある程度見切ってヒエラルキー化するので、それも構造化してあげればそこからもその人の価値のプライオリティが分かっていいと思ったけど、見切るのにそれなりに内観する必要があるだろうし、見切りが適切に行われるかどうかは微妙な気もするから、このあたりは気にして取り入れるべきだと思った。

統合
横構造のみにフォーカスしていたのが功を奏して2項目については統合することができた。が、それ以外はラダリングの開始地点がばらばらすぎて統合できず。ちなみに統合すると班になった9人から抽出された価値観をもったペルソナができる?と考えていいのだろうか。

全体的には
自分が演習の時点で評価グリッド法の優位点を見いだせなかったのは手法の理解不足につきる。それと最終的な目標がやってるうちに手法の習得になってしまって、なんのためにやっているのかとか、最終的にはなにが出来上がるのかを理解できていなかったところにあるのかな。
演習の最後の講評会で質問とか意見が、このあたりのもやもやはどうやらみんな同じだったぽい...?


統合についてのさらなる疑問

重複してでてくる着目点については重なった数を記すなどして重みをつけないと統合の意味がない気がした。複数の評価グリッドを統合する際の正しいオペレーションがあれば知りたいところだ。
というわけで復習したつもりが、違うモヤモヤを増やす結果になったのでした... orz


11/10追記:霧が晴れて来た

上のほうにあった図は、複数人のモデルを統合して一人のモデルにするイメージで作ったのだけれども、エントリ後に山口先生からいただいたコメント----

「基本的に評価グリッド法の使い方は、ユーザ全体の評価構造を抽出して俯瞰し分析するためのものです」

「(統合では)定量的に扱う意味でも、重なった評価ワードの人数や、関係線の人数、価値観の系統のネーミングなどを行います」

「数十人分の評価グリッドを統合することで一覧しやすくなりますし、抜け漏れの評価項目が少ない構造MAPができあがり、それを手掛かりに設計につなげることができます」

から理解をし直すと、数人分を代表する一人のモデルを作るというよりは、数人分の価値マップとして統計データ的に利用するほうがこの技法の使用方法としてはふさわしいようです。先生ありがとうございます!


参考になった記事

[AIIT]ユーザモデリングワークショップ

「ペルソナ/シナリオ法」の授業でのユーザの行動モデリングのワークショップ。
6人ぐらいのチームに別れて(自分は赤組)、分担を決めてユーザ2人分の行動モデル分析を行いました。

自分も含め要領を得ないので分担の仕方も微妙な感じに、とりあえず最初は Aさんのフローモデルを作成開始。
共同作業者と情報を共有/すりあわせしながら、ひとりが用紙にプロットしていく感じ。
けど、みんな読むスピードや読解力が違うので、自分は全然ペースが掴めず若干置いてけぼりに。>本当にすいません...

そして、分担を変えて今度はBさんのシーケンスモデルを開始。
こちらはパラグラフにわけて分担をしたので、自分の担当部分に関しては集中して理解できてよかった。
その集合知になるシーケンスモデル全体も(たぶん)うまい感じになっていると思う。
反面、自分の担当外のパラグラフの理解についてはほとんど頭に入ってなかった。

そのあと、チーム内でできあがったモデルをみんなで共有/レビュー。
メンバーそれぞれが意見を出しながらになるので、自分の性格的に意見を理解するのに手一杯でモデルそのもののレビューができないと途中で気がついて、自分でざっくりBさんのフローモデルをつくってみたりとかしていたのだけど、見合わせるとこまではいかずにタイムアップ。
みなさん頭の回転よ杉で、ちゃんとチェックしたりしていてちょっとショック。

今度はそのモデルをもとにユーザ要求を抽出していきます。
ここでついやってしまったのが、解決策やアイディアを考えながら抽出を行ってしまったこと。
自分も含めアイディアについてのほうに話題がいってしまって、機械的に抽出作業ができなかったのは反省材料かなと思う。
つか、抽出の途中でアイディアとか頭に浮かんでしまうのはどうしようもない気がするので、
それを心に留めておくとかするほうが心得的にはあっているのかも。

そんなこんなで、モデリング作業ができましたが、自分的にはフローモデルのところがすっごく出来なかった気がしたので、レビュー中に途中まで書いてあったBさんで復習してみることにしました。

授業でやってみて、最終的なモデルにまとめるのにかなりの書き直しが必要だなとわかっていたので、普段業務でワイヤフレームを作るときに使っている OmniGraffle を使いながら進めることにしました。
手書きで書いたものをベースに配置を最適化しながら、どんどんプロットしていきます。

途中まで来て、疑問に思ったのは「どこに行った」とか「どうやって移動した(電車に乗った)」とかをどうプロットするかということでした。
そこまでの作業ではほとんどが「情報のやりとり」に関するフローだったのだけど、旅の実施のセンテンスでは「実際の旅行行動」に関するフローがでてきたのです。
で、判断としては「情報のやりとり」をメインにしてプロットすることにしました。この判断が正しいかどうかはわからないのですが。

flowmodel_b.png
そんなわけで、出来上がったのが上の図になります(PDF版)。
わかりやすさを向上させるための工夫としては、
・「情報の要求」を青、「情報の提供」をオレンジ、「依頼」を緑色に色分け
・やりとりの矢印を「要求」「提供」で1セットになんとなくまとめる
といったところでしょうか。

ここまでやるのに約3.5時間ほど。疲れましたー。

11.10.06

category

tags

comments

0

trackbacks

0

permalink

No title

t_hero.png
あなたから学んだ Philosophy を胸に今日も僕たちは歩き続けます。
ありがとう。

11.08.04

category

comments

0

trackbacks

0

permalink

第3回 HCD-Net サロン「ペーパープロトタイピング ワークショップ」

IMG_1499.JPGのサムネール画像

初の参加でどきどきでしたが行ってきました。
(ほとんど写真とるの忘れていたので、文字多めですがご容赦を)

◆ 課題
居酒屋のセルフオーダリングシステム

コンセプト
・各テーブルからタッチパネル式オーダリング端末を使って、料理を注文できるシステム

基本要件
・料理の注文から会計(おあいそ)まで端末で出来ること
・選んだ料理の変更や取り消しができること
・複数の料理を一度に注文できること
・端末画面の操作ですべての注文ができること(紙のメニューとの併用は不可)

端末仕様
・11インチタッチパネル式液晶モニター
・フルカラーXGA(1024 x 768 ドット)
その他条件等
・店舗側は各テーブルの端末から入力されたオーダーを厨房で確認しながら調理を行う

◆ シナリオ記述ノート
居酒屋に入店〜会計までの想定される状況を記述していく。「Aさんは、いつもの野球仲間とテーブルに着き、雑談をしながらメニューを眺めていた」という例が示されていたのだけど、僕たちのテーブルは

・5名それぞれがポストイットにシナリオを記述する
・シナリオを記述する際に読み上げすることで即座に共有する
・記述されたポストイットを入店〜支払のながれでざっくりわけた台紙に貼っていく

という感じで行った。

scenario.png

個人的には

・第三者的ではなく、自分がお客さんに「チャネリング」して居酒屋を脳内体験をしながら完結に状況を書き出す

ようにした。
脳内体験は業務でもよくやる手法で、第三者的ではないユーザの視点で考えることがしやすい。

作業は1畳ほどのテーブルを囲む形で行ったのだけど、このシナリオを列挙するだけでテーブルがいっぱいになってしまった。
続くタスクフローの作成はこのシナリオを見ながらやれると効率的なはずだから、壁を使ったほうがよかった(許可が降りたかはわかんないけど)。広い場所 or 壁必須だな。

◆ タスクフロー記入
シナリオで記述した内容を、各要素に分けて関係性を図式化する
各要素とは
・だれが(人物名)
・何をするのか(行動)
・そのときに何を考えているのか(思考)
・そのとき使う道具は何か

flow1.png

タスクフローの記述はシナリオで列挙したポストイットをまとめていくことで行った。
類似内容のポストイットをまとめていき、時系列に並ベなおす。
実際のところ、お客側の行動をまとめるのが精一杯で(つまり人物名は全てお客)、厳密に各要素を持ったフロー図は作れなかった。

◆ タスクフローシート作成
前項で記述したタスクフロー記入シートをもとに、基本フローを書き出して必要な画面要素を記述する。

flow.png

このフローに関しては僕のテーブルでは正直ほとんどできていなかったように思う。
シナリオをまとめた時点で実際の画面をつくり始めてしまったので、画面作成と画面要素の抽出が同時進行で行われることになったためだ。

時間的にもこのシートに全てのシナリオを網羅したフローを書き上げるのは無理だったと思うけど、特にこのあとのタスクフローシート作成ができなかったことで、タスクを全員で共有・把握できず、プロトタイピング作業中に画面要素の検討作業がかぶったりと、作業があっちにいったりこっちにいったりすることになってしまった。

よかったのは、大事な機能とか、時系列によらない機能(例:トイレの案内表示、現在の勘定総計)などをプロトタイプ上に早い段階でプロットできたので、それを骨にして画面作りを進めることができたこと。
インタラクティブなUIを提案できたのも、このあたりの作業が寄与しているんじゃないかと思う。

◆ ペーパープロトタイピング
えーと、作業フローに従うとここで始めてプロトタイピング開始なのだけど、僕らのテーブルにはもういくつかの画面のラフがころがっていた。

IMG_1500.JPG

ここでタスクフローシートがしっかり出来ていると、もっとスムーズに設計作業ができた気がするのだけど、なにしろ最初のシナリオを時系列にまとめたものが唯一の頼り。

画面の構成要素を検討したりする一方、新しい機能要件がでてきたりと、みんな楽しみながら作業はできていたものの、進行はだいぶ混沌とした感じだったと思う。よく例えればより現場っぽいって感じ。

途中でコンセントの長谷川さんにスクロールエリアのちょいテクを教えてもらって取り入れたり。実はこのテク以前に業務でやったことがあって、iPadで画面上のスクロールの範囲をどうするかってケースだったのだけど、そのときは正式なテクだと思ってなかったんでちょっと嬉しかったり。

hcd.png

あーだこーだやっているうちにタイムアップとなった。
...やばい、戻る系とかやり直し系とかちゃんと検証できていないぞ。

◆ ユーザテスト
各テーブルから1名を他のテーブルへテスターとして送り込む。
僕のテーブルには新横浜ユーザビリティ研究会で何度かお会いしたことがあった@hokorinさんが刺客wとしてやってきた。やばい。

テスターは与えられたタスクを実際にペーパープロトタイプを使って行っていく。
テスターの操作に対する反応をホストが行う。ホストは操作説明を示唆したりヒントを与えたりしてはいけない。要はデバイス役。

ここで早々に問題発生。勢いで最後につけた「いらっしゃいませ画面」が仇となって、メインのメニュー画面へたどり着けずにタスク未達成。

「もういっかい!」とゴリ押しで、メインメニューの画面からタスクをもう一度やってもらう。全員必死だから、このときはホストは全員でフォローしあう状態w
ある程度は達成できたものの修正系がちゃんと検証できていなかったりインタラクションのホスティングがうまくできてなかったこともあって、結構いろいろ指摘をうけた。

テスターさんを変えてもう1つのタスク。
こんどは清算と清算後の割り勘ができるか。やった、うちらの案、割り勘機能ありますYO! というわけでスムーズにタスク達成。高評価をいただいた。...と思う。
時間があまったので、同じテスターさんに1つめの注文のタスクをやってもらったのだけど、さきほどのテスト後に修正を加えていたおかげで、こちらもスムーズにタスク達成。パチパチパチ!

テスターさんの指摘は本当にためになるし、この時間を通して全員が画面のフローを把握したり、即座に問題点を修正することができたのは、ペーパープロトタイピングならではだと思う。ペーパープロトタイピング強力。

◆ 講評会
それぞれのテーブルの代表1名ができあがったプロトタイプを発表。
やたら機能が充実しているテーブル、質実剛健なテーブル、優等生なテーブル、いろいろありました。あー、目から鱗だわという機能実装をしているテーブルもあって勉強になる。
僕のテーブルはDeNAから参加の床鍋さんがプレゼン。ユーモアたっぷりのプレゼンでいいところが伝わったと思う。個人的に付け加えとして、文字や画面構成要素が他のチームよりでかめなのは、酔っぱらい対策+テーブルで席が離れた人が見えるようにという配慮からなのですよん。

◆ 終了
そんなわけで、あっという間でしたがめちゃめちゃ楽しい時間を過ごすことができました。業務でもこのぐらいフランクに和気あいあいできたら素晴らしいのに。

個人的に悔いがあるとしたら、タスクフローのまとめがもう少しキチンとやりたかったのと、時間ぎれでできなかったユーザテスト前の操作フローの検証をできていればなあと。
特にタスクフローのまとめ方は勉強不足で有効なメソッドも手持ちにないので、スキルとして強化していかないといけないと。

以上ワークショップの報告でした。
おつかれさまでした!

関連:隣り合わせの灰と青春(@hokorinさんのレポート)

11.06.08

category

tags

comments

0

trackbacks

0

permalink

WWDC 2011

はじめての参加でいろいろ戸惑いながらも参加をしております。
昨日の Keynote はやっぱり雰囲気がとても特別で、朝の3時すぎから並んだ価値はあったと思います。
一緒にならんだドイツ、アメリカ、イギリス、中国といったワールドワイドな人たちと話せたのもすごく貴重な経験。けど、UI デザイナーはやっぱ少ない感じですね(あたりまえか)。
思った以上に忙しかったり、疲れたりでやっつけ気味ですが昨日の様子をちょっとだけ写真で。あとでビデオも追加します。(6/8 16:00 ビデオ追加しました)

IMG_1426.JPGIMG_1428.jpgIMG_1427.jpgIMG_1440.JPGIMG_1443.JPGIMG_1444.JPG

11.04.25

category

comments

0

trackbacks

0

permalink

Passcode screen for MoneyTron

passcode_highdef.png

MoneyTron の次期アップデートではパスコードの実装を予定しています。
これはそのデザインです。地色のテクスチャや光彩の色味を現在のものより少し大人っぽくしたいなあとうっすら考えてますが、どんなもんでしょうね。

The next update of MoneyTron will feature passcode lock function.
This is sneak peek of its design. 

11.01.19

category

tags

comments

0

trackbacks

0

permalink

iPad without physical home button means what...

nextgenipadwithouthomebtn.png

There are rumors that next gen iPhone / iPad will not have home button.
I think that it especially would be a great feature for iPad if they're true.

As you know, iPad is designed as having no right way or wrong way of holding it.

Jony Ive 
"The face of product is pretty much defined by a single peace of multi-touch glass, and that's it.
There is no pointing device, There isn't even a single orientation,
There is no up, there is no down, there is no right or wrong way of holding it.
I don't have to change myself to fit product ... It fits me."

This philosophy is pretty great, also I've been having amazing experience through iPad.
and I realized there are some interfaces unsuitable for this philosophy.

・Home Button
・Mute (or Orientation Lock)Button
・Lock Button

I think these interfaces seems to have usability problem.
For instance, I miss the home button sometimes.
This problem is caused by buttons fixed physically on device, I think.

The button should be placed same place "against the user" always.
Buttons fixed physically are placed different againt the user on each orientation confuse the user.

If using gestures could replace home button, it would be great also it would fit its philosophy more.


次期 iPhone / iPad で home btn がなくなるという噂がでてきていますね。
噂が本当なら特に iPad にとってとてもよい feature になるのではないかと思いました。

iPad はデバイスをどのように持ってもいいようにデザインされています。

Jony Ive
"iPad を形作るもののほとんどは、一枚のマルチタッチガラス、それだけです。
ポインティングデバイスも、縦横や上下を決めるものもありません。持ち方のルールもありません。
製品に自分をあわせるのではなく、製品が自分の一部になるのです"

この思想はとてもすばらしく、実際 iPad を通して得た経験は驚くべきものです。
しかしわずかながらその理念にそぐわないインターフェイスが残されていることに気付いたのです。

・ホームボタン
・Mute (or Orientation Lock) スイッチ
・ロックボタン

これらはユーザビリティ上の問題をかかえているように思います。
例えば iPad を使っているときにホームボタンを見失ってしまうことってよくありませんか?
この問題はデバイス上にフィジカルに固定されているために引き起こされていると考えられます。

これらボタンはユーザに対して同じ位置にあるべきと考えられるのですが、
フィジカルな実装上の制限からデバイスの持ち方によってボタンの位置がユーザに対して上下左右に移動してしまい、それが混乱を引き起こしてしまうのです。

もしジェスチャを利用することでこの問題が解決できるのならとてもすばらしいことで、思想をさらに一歩完全に近づけるものだと思います。

11.01.05

category

comments

0

trackbacks

0

permalink

MoneyTron : Editing categories sneak peak


MoneyTron : Editing categories sneak peak from webtron on Vimeo.


MoneyTron の次の Update の情報を少しだけ。

次回の Update の目玉機能として「カテゴリの編集/新規作成」があります。
非常にたくさんのリクエストをいただいている機能で、次回の Update で提供できることにとてもわくわくしています!

アプリの中枢部分にかかわる機能なだけにテストも十分に行う必要があり、まだすぐにリリースという状況ではありませんがムービーだけでもご覧いただければと思います。

MoneyTron next update will bring some features, one of major feature is "Editing Categories".
We've recieved many requests about this feature, so we're very excited.

We're on testing phase now, so we can provide just the sneak peak video for now.