デザイニング・インターフェース（１）

読書会向けの自分用のメモです。

デザイニング・インターフェース 第2版 ―パターンによる実践的インタラクションデザイン

posted with amazlet at 17.08.27

Jenifer Tidwell
オライリージャパン
売り上げランキング: 294,275

Amazon.co.jpで詳細を見る

1章 ユーザの行動

インターフェースデザインの格言

「汝のユーザを知れ ― 彼らはあなたとは別人なのだ！」

インターフェースデザインはユーザとマシン(モノ)の会話を仲介する手段

目的達成の手段

ユーザが本当に達成しようとしている目標が何なのか見極める

”なぜ” その機能やソリューションを求めているのか、十分に現状把握ができるまで質問を繰り返そう

(！) より魅力的で成功するアプリケーションをつくるためには、
　既存のメソッドにあてはめるだけでなく、数多くの「よりソフトなファクター」を考慮する必要があるよ

ユーザ調査の基礎

ユーザグループはそれぞれ固有の性質を持っている

秘訣は対象となるユーザーグループについて “おおむね” 該当する事実は何なのかを見極めること

そのメソッドとして挙げられたもの

• 直接観察
• ケーススタディ
• アンケート調査
• ペルソナ

ユーザの学習意欲

ユーザーは自分の作ったインターフェースを学習するためにどれくらいの努力をしてくれるのか考慮しよう

• 中級〜上級のユーザ
  • 開発・管理ツールなど
• 永遠の初心者
  • インストールウィザードなど

ユーザの学習意欲がインターフェースの随所に関係してくるよ

(！) いずれのユーザ層にも対応するデザインを作りたいという苦悩も発生してくる
⇒ それは２章のマルチレベルのヘルプでやるよ

パターンの解説

14個もあるので簡単に

1. 安全な探検

優れたソフトウェアでは、慣れていない操作をやってみてからもとに戻して、また別の操作を試してみる、ということがストレスなく実施できる

⇒ ユーザは探検することで多くを学び意欲的になる

2. 即座の喜び

アプリケーションを使い始めて即座に “成功体験” が得られる

⇒ プリケーションに対する信頼が強まると同時に、ユーザの自信も増していく

3. 最小限での充足

より良いモノや手段があると知っていても、多くの時間や労力がかかる場合、人は “最善” ではなく “必要十分” な結果を受け入れたがる

(！) 最小限での充足は、多くのユーザに中途半端な習慣を身につけてしまう要因でもある
　効率の良い新しい手順で改善される労力 と 古い習慣を打破して新しいことを身につける労力 のトレードオフ

4. 途中での方針変更

ユーザのゴールは操作途中に変化することがある

⇒ ユーザが方針変更できる機会を提供する必要がある

(！) ただし、方針変更させない妥当な理由が伴うケースは別だよ
　⇒ それは２章、３章で

5. 回答の先送り

ユーザに対して、最初からあまり多くの先行的選択を迫らないこと

⇒ 「2. 即座の喜び」につながるよ

6. 少しずつの組み立て

ユーザの創造的活動は小さな変更の積み重ねによって少しずつ行われることが多い

⇒ 素早い変更と保存やプレビュー、フィードバックなどの機能で創造的活動をサポートしたほうがいいよ

7. 習慣化

習慣化はユーザがそのツールの上級者へと成長していくのに役立ち効率をアップさせる

(！) ただし、アプリケーション間での一貫性が重要だよ
　アプリケーションごとに習慣が違うと逆に混乱させるよ

8. 小刻みな休止

小刻みな休止に対応するポイントは、その機能を簡単に実行でき、すばやく呼び出せるものにすることだよ

9. 空間的な記憶

何かを探すときに人は空間的な記憶を用いることが多い

• 既に配置されているコントロールの位置を変えることによる混乱
• 「7. 習慣化」と同様にプラットフォーム間を跨いだときの一貫性の欠如

⇒ ３章ログインツール、４章反応的な追加表示 で詳しくやるよ…

10. 展望的な記憶

ユーザはこれから何かしようと計画するとき展望的な記憶を忘れないように手元に残す

⇒ 展望的な記憶を促すためのインターフェースを提供しよう

(！) 機能を提供することよりも、作成中のものを勝手に片付けたり、
　ユーザの要求なしに自動的に整列やソートするような "親切" 処理が行われてしまっていないか注意しよう

11. 繰り返しの効率化

ユーザはさまざまな種類のアプリケーションで、同じ操作を何度も繰り返し実行していることがある

• よく使われる機能の繰り返し処理のサポート
• 操作の記録と再生 ⇒ ６章のマクロで詳しくやるよ

12. キーボードのみ

身体上の困難によってマウスを使うことができない人々やキーボードに手を置きっぱなしで作業したい人がいるよ

13. 他者のアドバイス

他のユーザのアドバイスは直接的か間接的かに関わらず、何かきめるべきことがある時に我々の判断に影響を与える

そしてそれが良い結果につながるケースが多い（と言っているように聞こえる）

⇒ 他者のアドバイスを集める仕組みを考えてみよう ２章マルチレベルのヘルプ など

14. 個人的レコメンデーション

「13. 他者のアドバイス」をさらに有効にする個人的レコメンデーションを促す仕組みについても考えよう

• 仲間へ共有するためのディープリンク
• 自動表示テキストより個人的なメッセージ
• ソーシャルネットワークとの連携

まとめ

より効率良くユーザの目標達成を可能にするインターフェースのパターンや考え方を学ぼう！

iTerm2 の screen でスクロールバッファ

ほんと今更ですけど...

screen のバッファをマウススクロールできるようにする

https://github.com/omohayui/dotfiles/blob/master/_screenrc#L16

termcapinfo xterm* ti@:te@

.screenrc にこの１行を追加するだけ

iTerm2 で status bar 表示時もスクロールできるようにする

[Preferences] ⇒ [Profile] ⇒ [Terminal] ⇒ "Save lines to scrollback when an app status bar is present" にチェック

Exercise on A Tour of Go

A Tour of Go の練習問題 『Loops and Functions』 についてのメモ

文系（美術系）の自分にはそもそも計算式の意味が・・・

10回ループ

問題文に書いてある通り、とりあえず ニュートン法の式をそのまま関数に入れて 10回ループさせて x の値を増やしていき math.Sqrt との近似値を確認する。

package main

import (
    "fmt"
    "math"
)

func Sqrt(x float64) float64 {
    z := float64(1)
    for i := 0; i < 10; i++ {
        z = z - (z * z - x) / 2 * z
    }
    return z
}

func main() {
    x  := float64(2)
    sq := Sqrt(x)
    ms := math.Sqrt(x)
    fmt.Println(ms, sq)
    // Diff
    fmt.Println(ms - sq)
}

10回ループした結果

1.4142135623730951 1.3351578377717581
0.07905572460133703

10000回ループした結果

1.4142135623730951 1.4106685607006662
0.0035450016724289934

ここまではなんとか・・・ 10000回ループすると math.Sqrt に近づいているのがわかる

zの値の直前との差が小さくなったら停止するようにループを変更

if 文を追加して直前のzの値との差が定義した許容値以下になったら break するように修正

package main

import (
    "fmt"
    "math"
)

const tolerance = 0.001

func Sqrt(x float64) float64 {
    z := float64(1)
    t := z
    for {
        z = z - (z * z - x) / 2 * z
        if math.Abs(z - t) < tolerance {
            break
        }
        t = z
    }
    return z
}

func main() {
    x  := float64(2)
    sq := Sqrt(x)
    ms := math.Sqrt(x)
    fmt.Println(ms, sq)
    // Diff
    fmt.Println(ms - sq)
}

結果

1.4142135623730951 1.414713296482291
-0.000499734109195904

最初、自分は直前との差を出すのに if z - t < tolerance { とやっていてうまくいかず・・・

調べたら差分がマイナスになることもあるので絶対値をもとめる math.Abs を使うべしということがわかった

がしかしチュートリアル充実してるし
思ってたよりGoシンプルでわかりやすいし
逃げずにコツコツ勉強しようと思います。たぶん。

Slackに野球ニュースをpostするbotを作った

職場のSlackに #baseball チャンネルを追加したついでに、
野球ニュースを投下するbotをつくりました。

開発環境

• node.js : v0.12.0
• npm : 2.5.1
• hubot : 2.16.0
• CoffeeScript : 1.10.0
• Heroku

データ元

• プロ野球 - nikkansports.com

• 最初はgoogleニュースからキーワード「野球」で拾ってこようと思ったのですが、
  いい感じのニュースにならなかったので、日刊スポーツさんのrssから頂くように

ソース

github.com

利用方法

• 毎朝10時に #baseball チャンネルにニュースを投下
• コマンド "baseball news" で #baseball チャンネルにニュースを投下
• 日時やチャンネル、ニュースの数は変更可能

YAPC::Asia 2015 リファクタリングの話

先日、今年で最後という YAPC::Asia に参加してきました。
中でも面白かった Benさんのリファクタリングの話についてまとめてみたのでご共有。
（実は職場で紹介する予定だった）

テーマ

• Adventures in Refactoring

発表した人

• Ben Lavender
• githubの中の人で内部ツールの開発を担当

トーク概要

リファクタリングとは

• 振る舞いやIOを変えずにソースコードを変えること
  ⇒ あたりまえのことだけど機能を変えてはダメ絶対

リファクタリングをする理由

悪い理由の例

• コードの一貫性を増すこと
• DRYにこだわること
• 抽象化レイヤを追加すること
  ⇒これら自体は良いこと。でも、これをやるためにリファクタするというのはよくない
  　リファクタリング結果の成否を測定できないから

良い理由

• Developer がハッピーになること
• パフォーマンスの向上
• 将来の作業への自信（技術的負債の返上）
• Developer の教育
  ⇒これらはリファクタリングの成果が計測しやすい

どのようにリファクタリングするか

計測できること

• git diff stats でコードが減っている（例：+31 -40だと10行減った）
  ⇒行数が減るということは、エラーが起こりうるコードが減ったということ
• テストカバレッジの改善
• パフォーマンスの改善
• 開発者満足度

スタイルガイドの重要性

• メンバーの方針をあわせる
• スタイルガイドも PullReq でメンテナスしていく

具体的なテクニック

• ”_” でつないでいる長いメソッド名の一部をオブジェクトに切り出す

pull.branch_valid?
pull.branch_exists?
 ↓
pull.branch.valid?
pull.branch.exists?

• ひとつのクラスからしか継承されていないクラスがある場合はまとめてしまう
• ツールの導入（ for Ruby ）
  • Backscatter
  • scientist

リファクタリングの落とし穴

• 既存バグの修正と一緒にリファクタリング
• 抽象化レイヤの追加によるパフォーマンスの悪化

小さなところからハッピーになる

• 少しづつリファクタリングすること
• リファクタリングと機能追加の優先順位判断
  ⇒ 機能追加に自信が持てなければリファクタリングすべき
• リファクタリングが成功した PullReq には、ご褒美として「:hocho:」を与えること

感想

• スタイルガイド（規約）の github管理やりたい。PullReq 上でお互いに意見を出し合ってメンテナスできそう。
• ” デザインパターンに固執するとコードがテストに合わせがちになる。良いテストは良いコードの結果であるべき " というテストに関するご意見も面白かった。
• :hocho: は使うようにしたい。