amchartsを1画面に2つ以上配置してみる
概要
amChartsというリッチなグラフ描画ライブラリを使って、
1つのWebページに複数のグラフを配置します。
その際はdiv要素のidをコードと合わせ、styleで幅と高さを指定する必要があります。
続きを読む
IDとPWの入力欄の空欄補充提示について
例えば、自身のIDとPasswordが
ID : aiueo@abcde.co.jp
pw : kakikukeko
だとしよう。
ログイン時にヒントとして、
a●●●●@●●●●●●●●●jp
などと表示されることが少なくない。
この表現はユーザへ一定のヒントを与えているように見せる一方で、
「"a" , "@" , "jp" の文字は入力する必要がなく、"●"部分だけを空欄補充すれば良いのではないか」
と思わせる。
結果、ユーザは"iueoabcde.co."と入力してしまう。つまり、NOT 表示文字 だけを入力してしまい、ログインできないという事象が発生する。
もちろん、これを防ぐために「表示されている文字を含めてIDのすべての文字を入力してください」などと事前に表示するのは一手だが、画面によっては（殊にスマートフォン端末用の小さめの画面の場合）冗長性が高い。
《読書感想文》渡邊恵太 : 融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論 (2015)
はじめに
本記事は営利・販売促進や権利侵害を意図しておりません。もし不利益・不都合が発生する場合は対応致します。お手数ですが @plum_shiga までご連絡願います。
随分前に読みきった本ですが、ちょっと読み返すきっかけがあったので、改めて以下感想文を。
目次
はじめに - 融けてゆく世界
第１章 Macintoshは心理学者が設計している
第２章 インターフェイスとは何か
第３章 情報の身体化 - 透明性から自己帰属感へ
第４章 情報の道具化 - インターネット前提の道具のあり方
第５章 情報の環境化 - インタラクションデザインの基礎
第６章 情報の環境化 - デザインの現象学
第７章 メディア設計からインターフェイスへ
あとがき
キーワード
デザイン、インターフェイス、道具、環境、文脈、自己帰属感、透明性、UX、サクサク感、道具化、環境化、実世界、暗黙性、インタラクション、現象学
どんな本？
以下3点のポイントから紹介できる。
- 最近のHCI潮流の解説書である。
- 概念と実装がつながっている解説書である。
- ちょっとした方向性（あるいはそのきっかけ）を見つけるための解説書である。
1. 最近のHCI潮流の解説書である。
HCIの概念や基本的な解説書・教科書と呼ばれるものは、D.A.Norman の "誰のためのデザイン？ 増補・改訂版 ―認知科学者のデザイン原論"や、加藤 隆先生の "認知インターフェイス" が挙げられるが、
本書は特に最近のHCIの潮流を抑えている。例えば4章〜6章は特に文脈や現象という視点から現代的な概念やトピックを具体的に解説している。
2. 概念と実装がつながっている解説書である。
上記でも少し触れたが本書はよくわからない概念を別のよくわからない言葉で言い換える類ではない。
むしろ、筆者の研究に基づく実例（画面のスクリーンショットもある）や、実働するアプリケーションを引き合いにしながら見た目にイメージがつきやすいように議論されている。
3. ちょっとした方向性（あるいはそのきっかけ）を見つけるための解説書である。
新しいサービスや顧客へ新規性のある提案を行う際など、よく方向性が見えないときに「こういう考え方があるよ！」と新しい視点や切り口を与えてくれる。
またその切り口は決して突飛すぎるものではなく、「ユーザのために」という大前提を以って議論された観点である。
誰が対象？
感想
本書を読んでいると、素朴に「ああ、なるほどね」と納得できることが多かった。
近年のUI/UXを取り巻く抽象的な概念や議論は決して簡単な内容ではなく、混乱をきたすことが多い。なぜなら、時間軸や文脈、人物（使い手も作り手も含め）など様々な角度から議論が展開されるためである。
本書では、あくまで読み手自身もひとりのユーザとして難しい概念の理解をサポートしてくれている。また、（私は）あまり本書を読み進めるにあたって、単語や概念を都度ググったりせず、そのまま読み進めることができた点で非常に快適だった。従って、なるべく快適に今の潮流をキャッチアップするのに本書は非常に役立つ印象である。
黒歴史勉強会 #4
本日、久々の黒歴史勉強会でした。
いつものコンセプトは
「うひゃwwwwイテェwwwwwwww（けど参考にしよ）」
ってなる内容をセッション形式で発表する という形です。
今回はワンドロ形式ということで、
1時間手を動かそう！ というコンセプトで行いました。
タイムテーブルは以下の通り。
１４：００：説明含めいろいろ開始
〜１５：１５ 創作タイム
〜１５：３０ 休憩
〜１６：００ 手直しタイム
〜１７：００ 回し読み鑑賞タイム
ここからそれぞれの感想。
創作タイム）
マジでやる空気が生まれて個人的には心地よかったなと。これはあり。本当に1時間も存在したのかな？ ってくらい一瞬で終わった。非常にGOODでした。やって良かった。
手直しタイム）
っていう名前のロスタイムですけども。これも用意しておいて良かったなと。結構みんなガッツリ手直ししていた？ ちなみに僕はしていました。それでも脱字が残ってしまった。反省である。
回し読み鑑賞タイム）
あー、こうきたかー。これ入れるかーってなったんで、創作→回し読み→創作で他人のテイストを入れてみる回とか面白いかなーって思いました。次は和のテイストを入れ込んでいきたみ。そしていわゆるハーレムものをきちんとした文章で処理してみたい。
総括）
結局、やってよかったなと。セッション形式→セッション形式→わんどろ→セッション形式……って感じで2:1のペースならありかな？ と。
参加者各位ありがとうございました＆おつかれさまでした！
関西フロントエンドUG座談会#1 参加レポート
関連リンク
表題の通り、フロントエンド系の勉強会に参加してきたので報告する。
実はこういうフロントエンドエンジニアが集まりそうな勉強会は初参加なので、
「どっかのタイミングで行きたいなー」と漠然と思っていたら、なんと
関東ではなく関西で開催され、縁を感じているところ。
さて、本会の構成は以下の通りであった。
- javaScript Framework 40min
- alt js 40min
- css 40min
- LT大会 3min * 5
では以下でそれぞれのセクションの内容を踏まえて報告。
javaScript Framework
最初の問いかけは「使っているフレームワークなんですかー」というもの。
挙げられたフレームワークはこちら。当日のコメントを（メモった範囲で）
１行で付け加えています。
angular
学習コスト高め。バインディングの概念が理解できてもまだ辛い……
sencha
有料。サポート厚め。
react
reactive
flight
twitterの。
vue
angula.jsよりは学習コスト軽め
ember
htmlを書かない実装多し
knockout
Microsoftの。意外に覚えることが少なく分かりやすい。日本語ドキュメントあり。
marionette
backbone
バインド系。jQuery, underscore, marionetteあたりが必須。
casper
と列挙されただけでも11点……多すぎやろ……
altJS
さっきと似たスタイルで、列挙してコメント加えます。
Coffeelintで色々チェックできる
Typescript
Babell
EcmaScript6から5に変換
hame
livescript
jsで関数っぽく書ける、coffeeのfork
sclala.js
型安全。scala to js
CSS
勉強会上はCSSという切り口のみであったが、今回はもう少し切り口を増やしてみる。
CSSフレームワーク
Bootstrap
pure
軽量フレームワーク。読み込みも早くサクサクな模様
SemanticUI
ぷらむイチ押し。htmlに実現したい内容と表現を一致させて書けます。
fundation
UIkit
gumby
根強いファンがいる模様。興味あり。
フレームワークを選ぶ基準
見た目
altCSSとの相性
altCSS
sass (scss)
やはりcompassユーザ多し
less
stylus
LT
-
plum_shiga さん 『フロントエンド（哲学）』
-
aa7th さん 『CasperJSについて』
-
tan_go238 さん 『JSが嫌い』
進撃パロ。Single Page Applicationに泣かされたっていうのと、関西版進撃のお話。
-
itozyun さん 『GPUアニメーションとUIデータバインドについて』
オレオレフレームワークのお話
- mikakane さん 『フロントエンドというカオスな世界について』
やっぱフロントエンドは追いかけるもの多すぎってお話。ほんまそれ。
感想的な
今回、初めてフロントエンドエンジニアの集まる勉強会に飛び込みました。なんかフロントエンド系の勉強会って意外と少ないような印象が。デザイナーさん向けとか、サーバサイド系エンジニア御用達！ 的なのはよくみかけるんですけどねー。そんな折に関西で開かれていてめちゃくちゃテンション上がって参加しちゃいました。
もっともっとこういう場が増えてほしいし、参加するエンジニアも増えてほしいと心から願っています。当日はおよそ20名程度（もっといましたかね？）だったので、まだまだエキスパートさんがいらっしゃるでしょーと。
個人的にはデザイン思考のあるエンジニアくらいの気分でこういうフロントやUI/UX周りは今後も積極的に出て行きます。こういう系のイベントご存知でしたら是非お誘いください！
CodeZineスーパー対談「2020年のUI/UX」聞いてきた！
概要
本記事では、DevelopersSummit 2015 2日目の最後のセッション、
「CodeZineスーパー対談 2020年のUI/UX 」について報告する。
セッション流れとしては、
渡邊先生の講話
黒須先生の講和
パネルディスカッション形式
という感じだった。
トピックス
テーマは上記の通りだったが、実現場では
- 2020年のUI/UX
- 今後のデザイナー・エンジニア
という大きく二つの柱があったように思う。
それぞれについての回答は以下のように理解した。
- 2020年のUI/UX
黒須先生：人工知能をバックグラウンドにもったものが強くなっていく。また、製品（モノ）よりは意味のあるサービス（コト）が重視されていく
渡邊先生：趣味や楽しさを生み出すという目的を満足していく傾向になっていく。またWebにアクセスするのではなく、Webが人にアクセスしにくる
- 今後のデザイナー・エンジニア
黒須先生：コトをデザインできる人間が強くなっていくだろう
渡邊先生：デザイナー兼エンジニアという人種が強くなってくる。プロトタイプを手早く作れる人間が必要とされる
これからぼくらが設計すること 明治大 渡邊 恵太先生
？検索は本当に便利か
→ 確かに便利だが、その後検索結果を受けて人間が行動せねばならない
PC「これがお前の欲しかった情報やろ、あとはがんばれ」って感じ。
→ ググるは易く、行うが難し
タブレットをキッチンに持ち込めて料理ができる
→ タブレット見ながら料理をする？？
→ 情報と行動が乖離している（無理がないか？）
→ そこで、レシピデータに連動して変形する計量スプーン（ユーザがすくうだけで単位を気にせず計量できるスプーン）
2020年は行動も支援してくれるデバイスがくるのではないか
スマホを部品とした入れるべき容量を可視化する計量カップ（スマホが入れるべき水の量を可視化してくれる）
→ 加速度センサで水平を保つ
Webブラウザでは分かりにくい実寸をただ引くだけで取り出せる 1次元プリンタ
既にあるデータを現実世界に持ってくる
アクセス（UI・検索・ナビゲーション）→ 理解（UIとコンテンツがかたち・しくみ を持つ）→ 行動 → アクセスしやすくする
コンテンツとUIを分けずに一体にする
IoTはセンサネットワークのデータを人間に直接返す
情報の道具化；情報を道具のように問題に対して直感的に落とし込んで道具として用いる
インタフェースデザインの歴史
機械のインタフェース（ミスしにくく） →
マンマシンインタフェース
コンピュータのインタフェース（わかりやすく）→ HCI
インターネットのインタフェース（Webと人間がどういう関係を持つか？）
＝＞ これからはグラフィックデザインからプロダクトデザインでもUI設計的思考が求められる
エンジニアの進むべき道 黒須先生
エンジニアが考えるべきこと３つ
意味性
人工物の進化
ユーザ工学
意味性
素朴に嬉しいなと思えること。人の営みの上で浸透できうる特性
UXとは：
ユーザ体験はサービスに対して
モノの場合はユーザ経験（こちらの方が長期スパン）
イノベータ理論とキャズム
アーリーアダプターとアーリーマジョリティーにキャズムがある
→ なぜ？ 人々が意味がない（満足しない・嬉しくない）と思ったから
＝ 意味性の欠如
人工物は進化する
・本当に意味のある目標は消滅しない
→ 望ましい方向に進化し続ける
・現在地と目的地を知る の変化
昔の地図→紙地図→カーナビ（AR）→最近のAR（情報付与）
ユーザ工学
単なる面白いガジェットはあかん
→ ユーザを理解して本当に意味のあるものを提供する
これには洞察と直感」がいる。向いてる人と向いてない人もいる
失敗の秘訣～失敗するためのイロハ～
開発者の思い込みで突っ走る
新規で面白そうなものを開発する
何となく良さげが基本方針
2020年の方向性
サービスは必要
実用に耐える→キャズムを超えられるか？
UI/UXはわけがわからない
！2040年くらいの未来は知的インタフェース
気の利いた対話（もっというならインタラクション）をどうデザインするか？
→ 心理的に満足する会話のデザイン
和文タイピストは進化で仕事が消えた
→ デザイナーやWebクリエイターも消えるんじゃないか
AIの登場で考えることが不要になり、またできなくなる多くの人々
→大学教授の失業か
パネルディスカッション
#1 GoogleGlassが示した課題をAppleWatchは克服できるか
中村）なぜ失敗したと思うか
黒須）ウェアラブルは信用していない。腕時計（まさに伝統的な腕時計のこと）は時間を計測する装置として妥当だが、メガネはモノを見るためのもの。情報をみるためのものはスマホで不十分なのか？ という検討が十分されてない。本当にメガネにひっつける必要性は本当にあったか？ 人間の本質的・かつ生理学的な特質を考えてない。視覚の奥行の知覚とか考えていなかった。
3次元テレビが消えたのと同じ理由。アプローチも失敗してる。売れると思ってない。アップルウォッチも。スマホとほぼ同じ。小さいだけにかえって操作しにくい。スマホはポータブル。十分密着してるし、それで良い
中村）道具のインターネット化という観点からもどうか。
渡邊）デバイスありきではなく、アプリケーションありきでデバイスを作るべ
き。アプリの上でデバイスを作るくらいの意気で行くべき。現場では難しいかも
しれない。普及したくても、ハードはDLとかできないから普及ができない。
GoogleGlassはできて欲しかった感はある。常に情報を得てたいというニーズはあ
るはず。話ながらスラスラ検索できるとか嬉しさある。失敗かどうかはともか
く、チャレンジしていかないといけない。
中村）結局グラスがうまくいかなかったのも、キラーコンテンツというかナイスなものが無かったから？
#2 IoT・モノのインターネット化
中村）デバイスメーカーが今後は色々と出してくると考えられる。お二人がこれだったら使う！ とかあるか。
渡邊）行動に繋がらないものは失敗する。モノのインターネット化は結構なことだが、画面・スマホでいいじゃんって思うものがある。あえてモノにするとしたら、行動につなげていくのが大事。そういうものは興味がある。
黒須）確かに、これからはますます普及していくことは間違いない。ただ、使い方として、人とモノが接触する。モとモノの接触する。どういう意味があるのか？ 意味の解釈ができてないなら作ってもだめ。データの解釈が大事。ビッグデータを使えば相当広範な内容を話、AIの会話につなげていくことができるはず。会話の話し相手になれるはず。インターネットの「コト」をつなげてAIにする。お医者さんの話し合いだけでなく、教育もそう。相手の学力や好き嫌いも考えた先生役をしてくれるものを作っていくことになっていくだろう。
#3 インタフェースの方向性
黒須）結構難しい。結局人間が情報を受け取るためには五感ありき。目と耳が情報入
力機関。目で見る対象が、デジタルサイネージみたいになることはあるだろう。け
ど、パーソナルな情報はパーソナルなモノになる。となると、スマホは完成度が十分
高い。
渡邊）AIとインタフェースは相性が悪い。ダイレクトマニピュレーション（直接操作感）のが優勢。AIが発達すると人間のやることが減る。人間は何するんやっけ？ ってなる。AIの発達は楽しみを殺す。インタフェースは楽しみ、趣味を作るのもあり。自動運転は趣味のドライブの楽しさを殺す。じゃあその趣味の楽しさの最大化させるところが課題。インタフェース屋は「趣味」「生きがい」を作るっていうところが大事になってくる。楽しみや、生きがいを作るっていうところに需要があるのではないかって気もする。
中村）今後どのような人材が求められるのか？
黒須）プロダクトについては現状維持路線に近くなる。むしろ、サービスデザインはとても大事。今より5年先でも、サービスとして色んなことが可能になる。サービスとは＊＊するコト。人間だったらとても辛抱できないようなことをしてくれる。例えば認知症の相手。話したことをコンピュータは覚えていて同じことでもふんふんと聞いてくれるとか。IoTについては、スマートハウスやらインテリジェントハウスやらは本当に「意味」があるか。ちょっと便利かもしれないが、本当に自身の生活を良くしてくれるか？ という疑問。モノよりは「コト」。サービスをデザインできる必要がある。コトのデザインはさらに求められる。サービスなので人が人にしていたこと。で人がするんじゃなくてICT化していく。図書館の書士にしろ看護師にしろ、人との履歴とかを解析し、Ioコトのデザインとしては、人はどういうサービスを享受すれば満足す
る、嬉しいかというところを考える。みんなが当然だと思って諦めているところをそ
ういうところを探していく。
渡邊）むしろ、UI/UXの部署にどういう人が来てるのか？
中村）今必要なのは、プロトタイピングしながらモノを作っていける人。サイクルを回すことが大事な人。
渡邊）初めからいきなりプログラムを作ってきてそれをハードでやりたいっていう子
がする。動かして伝えろと言っている。
中村）目に見える形で武器を持つのは大事。動かして～～作れます！ っていう人の
方が前に進む。そういうやつは活動してくる。まずさわれるものを作って、そのあと
専門家に流していくって感じだった。コードを書くエンジニアとかが、そうなるべ
き。
渡邊）文系の下請けになるな。アイデアも優れていてモノも作れる人になるべき
#4 2020年に世の中はどうなっているか
黒須）4Kテレビが普通に普及するとかその程度だと思う。むしろその先を見るべきで、エンジニアはデザイナーとインテグレートしていく必要がある。デザインっていうのはコンセプトを外化する。外化することによってそれを対象化できる。じゃあ次はどうすればいいかっていう次のことを考える必要がでてくる。また、収束的ではなく発散的な思考が大事。これをエンジニアが持つ必要がある。これで5年と10年でかなり変わる。モノではなくてモノを含めた環境。環境っていうところも含めてエンジニアはデザイナーの特質を取っていく必要がある
渡邊）地味の話では、各言語対応（オリンピックに向けて）が必要になってくるっていう意識が変わるだろう。テクノロジー的にはウェアラブルっていうのはないかも。マップアプリとかは増えてくる。言語コミュニケーションをどうしようかなっていうところになるだろう。
Developers Summit 2015 2日目 報告
概要
に参加してきた！
本記事では @plum_shiga が参加した2日目の各プログラムについて報告する。
ちなみに資料まとめもある
実践！ クロスプラットフォームモバイルアプリ開発
ハンズオン。
ハイブリッドアプリ（ネイティブアプリ でありつつ Webアプリ でもある）を作ろうというもの。
作ったアプリは、おみくじ。ランダムで大吉～凶までの結果を返すという分かりやすいものだった。
開発環境について
基本的にはMonaca上で行った。
html, css, .jsの各ソースをWeb上で編集・保存・プレビューを行えるという分かりやすいシステムになっていた。
また、Apache Cordovaにも対応しているのでネイティブの挙動も対応できる。
今回はバイブレーションだけおみくじを引くと同時にバイブする形で
navigator.notification.vibrate(500);
を呼び出した。
ただ、Monacaではデプロイまではできないので、別途探す必要がある。
開発者こそ知っておいてほしいモバイルコンテンツデザイン -ハコと中身の整え方-
基本的なデザインプロセスの紹介と、登壇者（矢野りん 氏）が考えるデザイナーとの付き合い方について。
箱の話（モバイルコンテンツのデザインプロセス）
ターゲットユーザの定義は大きく2つの特性を使う
人口統計上の特性（年齢、性別、所得、しょくぎょう、学歴）Demographic information
心理学的な特性（ライフスタイル・好み、価値） Psychographic information
例）コミュニケーションの質を求める人 特に女性 とか
定義する理由
チーム内で統一した対象者像を持つため
マーケットを絞るため
デザインの目的をハッキリさせるため、
サービスやUIのデザインをするとき、ドキュメントに書き添える。
注意すること
ユーザ定義はざっくばらんな方が良い（細かすぎるとぶれる）
insightってほどでもないプロフィール的なもの
プロトタイピング
アプリの操作手続きを理解するために作る。画面の集合
基本機能を最初に作って→次に拡張を付け足す（既存アプリなら差分だけ作る）
なんでプロトタイピングするのか？
開発に迷惑をかけないため → 事前に問題を洗い出す
デザイン上の問題を見つける → 効率のいい操作手順になってるかを確認する
UIテンプレキットまとめ
speckyboy.com/
Keynote
Sketch - UIレイアウトツール
ZEPLIN デザインガイドラインを作ってくれるサービス
デザインのコツ
グラフィックは仮のもので良いが、言葉づかいだけは仮のものにしない
例）「OK」ボタンが「わかった」ボタンって世界観がだいぶ変わる……
あとは複数人の視点を入れて微調整する
デザインレビュー
デザインの効果をはかって、アプリをよりよくする会議
2種類の指摘
1. 客観的な事実（集計データ、ユーザからの批評）に基づく指摘
※基本はこっちでがんばる
メリット）
レビューワーの課題設定能力のばらつきに振り回されにくい
デザイナー・開発・マーケなどの異なる職域の人間が同じ目標を達成しようとしやすい
2. レビューワーの趣向、主観に基づくもの
ダメじゃないけど非効率的
喧嘩になりやすい
特に経験の浅いデザイナーは感情的になりやすい
開発経験者は開発コストを下げることに注力する
PMは権限を振りかざし主観的なこと言う
→ お互いそういうもんだと思って歩み寄る
自分の言うことを聞いてほしいがゆえの指摘
→ 目的とズレる
レビューのプロセス
- デザインを最適化することで達成が見込める・目標を設定 or 確認
- 目標が達成できていない部分についてレビュー
- 目標を再確認 or 再設定。うまくいっているところはケーススタディとして共有
- TODOにしていく
建設的レビューのコツ
デザインそのもの（見た目）に対する変更は、あまりその場で言わない
→ 会議に時間がかかっていい結果にならない
些末なレベルはもう、ヤイヤイ言わない（命令しない）。
デザイナーにはアイデアだけ言ってあげて、そのまま任せる！
具体的なアウトプットの出力権限はデザイナーに委ねて、修正結果はあらためて確認する
定義を共有できていない用語については常に注意する（ブランディングっていう言葉とか）
議事録を取る（あいまいなTODOを作らないようにする！）
デザイン評価
ユーザの定性的な意見を一番尊重する。
→ デザインを良くするにはやっぱりヒアリング
KPIについて考える
デザイナーもKPIあるしMAU背負ってる けど、デザインの質につながらん
→ デザインはMAU、KPIにコミットしにくいもの
中身の話
マイクロソフトのデザイン原則いかしてる
デザインこそがコンテンツである
その他のTips
モバイルに顕著な中身の特徴
一息で読める文字量を意識 100-140文字
読みにくい漢字はひらがな
サービスのユースケーズを常に意識する
コンテンツの量がUIの姿形を決定する
終わりに
今回はDevlopers Sumiit 2015 2日目の内容をメモ的に報告。
しかし、個人的なメインイベントである「CodeZineスーパー対談 2020年のUI/UX」について全く触れていないので、それについては別の記事で報告する。
