UI変更が不評な時に役立つ原因の切り分け方
UI変更をした時のことについていろいろと記事を見かけたので書いてみました。ユーザー側と制作側、それぞれの原因の切り分け方や分析、その対応に役立つと思います。 UI設計の際考慮する4つの要因 例えば、UI変更により欲しい情報が見つけにくくなった、ということが起こったとします。 この場合、ユーザーはその原因をUIやデザインに求めがちですし、制作者はその原因をユーザーに求めがちです。アプリのレビュー欄が荒れたり、ブログなどで制作側の主張があったり、というのも最近よく見かけます。 このような課題達成の成功や失敗（この場合はユーザーが欲しい情報を見つけられるかどうか）に関して、ワイナー（Weiner, 1974）は、4つの原因があるとしました。 「能力」「努力」「課題の難易度」「運」です。 「能力」と「努力」はユーザー側の要因、「課題の難易度」は制作側の要因、「運」はそれ以外の要因です。 上記の場合
ansibleを使ってみる — そこはかとなく書くよん。 ドキュメント
ansibleを使ってみる¶ Chefが猛烈な勢いで流行り始めている今日このごろですが、似たようなものは 世の中にいくつもあります。今日はその中の一つ、 Ansible を使ってみます。 書いていたらやたらと長くなったので何回か続きます。 軽くご紹介¶ インストールの前にどのようなツールなのかを軽く説明します。マシンの設定 を自動で行なってくれる、というツールなのはChefと同じです。 そのポリシーは githubのページ に書かれています。 シンプルな設定 最初から超速くて並列 サーバーやデーモンとかいらない。今あるsshdだけあればいい クライアント側になにもいらない モジュールは「どんな」言語でも書ける 超強力な分散スクリプトを書くためのイケてるAPI rootじゃなくても便利に使える 今までで一番使える設定管理システム さて、では見て行きましょう。 インストール¶ ansibleは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
