Summer KMSF Mtg. ORFスケジュール ● ● システム設計  どこで推論させるか (端末上・リモート)  アルゴリズム (Dynamic Bayeis / HMM)  全体設計 (データをどう送信するか、取得するか) インタラクション設計  振る動作の設計 (ボタンを押しながら、押さずにふるか)  コード表記の設計  評価項目の設計ポスターについて ● ● 4回の組み合わせの4という数はなぜ？  4という理由が薄い。  最大の数を何通りにしたいから何回必要。  4つまで情報を含んでいて、5からは行動など。規定が規定ではなくなっている。  4つまで情報を含んでいて、5からは行動など。  コードの表記の指定の問題システム設計議論 ● 推論させる場所  携帯端末上 ●  フィードバックが必要。携帯端末上で実装する必要がある。リモートサーバ上 ● どちらにしても、データ取得でサーバが必要。システム設計議論 ● エリアの線引きシステム設計議論 ● アルゴリズム  Dynamic Bayeis  Hidden Marcov Model システム設計 ● 全体設計  完全なシステムの形で実装する。  詳細は後に考えて、APIをきって、担当を決める。インタラクション設計 ● 振る動作の設計 ● ● 音によるフィードバックがあるとよい。ボタンを押している間、認識する。インタラクション設計 ● コードの設計  組み合わせに関して ● ● 必要ベース(想定環境で数えて評価) 制約ベース(短期記憶・チャンクにおける評価)      空間的な制約論文で短期記憶についての学術的な根拠今回の場合による実験による具体的な定量的なデータ何秒で覚えられるか・何秒覚えていられるかコードの組み合わせを1チャンクとして3つ使うかコード設計 ● コードの設計  意味を持たせるか ● ●  ソニー＝S、東京メトロ＝メなど。意味を持たせる。コードに自由度を持たせる。方向の数 ● ● ● 4方向だと、人間が考えるのに簡単だけれど数が少ない 8方向だと、人間が考えるのが難しいが、数は多い 4方向+コードに意味   太い矢印は早く振るコードの上に２と書いてあったら往復コード設計 ● コードの設計  そもそも問題 ● ● ● ●  コードを設計する上で何が問題だったのか。 QRコードの弱点、URLの弱点を補う。コードを設計する上での指針。覚えやすさなど、何がほしいのか。意味の持たせやすさ。設計指針 ● ● ● ● 情報密度、注目ひきつけ度合い、表現の自由度など。瞬間的に人が実行できること。瞬時に理解して覚えることができる。←大前提数字とくらべた優位性の意味づけインタラクション設計 ● 評価項目の設計