読者です 読者をやめる 読者になる 読者になる

ジンジャーエール買って

デザイン&プログラミングのことも書くし、それ以外のことも書く。

デザイン案作成前にやること

visual design

(ビジュアル)デザインを考える上で準備が足りず時間を無駄にしてしまったことがあったので
デザイン案作成前にやるべきことをざっくりですがまとめておこうかと。

あくまでイメージを変える・新しく構築するようなデザインワークの場合の話です(新サイトデザイン、LP作成など)。
社内の人に依頼されたタスクを振り返って書いたものなので、
社外のクライアントとの仕事だともっと細かく確認すべきことがあると思います。

依頼を確認

  • なぜ必要か、何を解決したいのか
  • ターゲットは誰か

どこまでやっていいのか

  • 時間をかけていいのか
    • ダメなら既存のリソースを有効活用する
  • どこまでこだわるのか(一から作るのか、すでにあるリソースを使用するのか等)
  • 方向性の変更(ぜんぜん違う方法、やっぱりやらない)

調べる

  • プロダクトについて
  • ターゲットについて
  • 類似プロダクト
  • 市場とか世の中一般的な情報
  • 参考になりそうなデザイン

調査

  • ターゲット(と関係者)に聞く
    • イメージがわかる既存のサイトやイメージをピックアップして意見を聞く
      • 案を作ってから、ではなく作る前に(既存のものを利用して)できたら手間が省ける

方針を決める

  • 方針を言語化する
    • 上記の内容
    • キーワード
    • ストーリー

方針のレビュー

デザイン案作成に着手する前に方針を関係者にレビューしてもらう

だいじなこと

  • 必要無さそうでもこっそりかならずやっておかないとあとでいろんなものがブレて死ぬ。
  • まとめたものをどこまで関係者に見せたほうが良いかは場合による(見せないほうが良い場合もありそう)

東急ストアのセルフレジUI

思ったこと

最近自宅近くの東急ストアにセルフレジが登場しました。
正確にいうと「セミセルフレジ」というものらしく、バーコードの読み取りは店員さんがやってくれて支払いをセルフレジで済ますというもの。
小売店で最近増えているらしいですね。

ルフレジのUI

完全にうろ覚えですみませんですが、上から順に並べると

  1. ディスプレイ(タッチ可能)
  2. レシート出力(&確かこの横にカード入れるところがあったような…違うかも)
  3. 硬化を入れるところ
  4. お釣りが出るところ
  5. 紙幣を入れるところ

みたいな感じでした。

つらい

操作(ユーザーの行動)順と使用する部分を照らし合わせると、

  1. 現金払いかカード払いかを選択:a
  2. 代金を入れる:c, e
  3. お釣りを受け取る:d
  4. レシートを受け取る:b

となります。
(カードで支払いしたことないので↑は現金支払いの場合)

…お気づきでしょうか。
このレジ、操作部分の並びがユーザーの基本となる行動に全く沿っていないため、次にどこを操作してよいか非常にわかりづらいんです。。

あと特にひどいと思ったのが2。
硬化と紙幣を入れる部分が離れているため、初めて使ったときに硬化を入れたあと「紙幣はどこに入れるん??」ってめっちゃ迷ってしまいました。

普通は「お金を入れる部分」「お釣りを出す部分」ってUIの分け方すると思うんですけど、おそらくハードの構造上「硬化を扱う部分」「紙幣を扱う部分」って分け方するのが楽だったのかなーと推測しています。

レシートがお釣りの近くから出ないのも戸惑いましたが、レシートはカード支払いの場合も必要なのでここになったんでしょうね。
一番下でもいいような気がしますがこれもハードの問題でしょうか。

まとめ

まったく関係ないけど紙のクーポンとか独自のポイントカードとかなくしてくれたら嬉しい。

Atomic DesignでWebサービスのフロントエンドをイメージする

css html JavaScript web design

Atomic Designというコンポーネントを組み合わせてシステムを構築していく手法がイメージしやすそうだったので、実際にWebサービスのフロントエンドデザインに当てはめるとどんな感じになるのか考えた。

Atomic Designについてはこの辺を参照
Atomic Design | Brad Frost
珍しいワークフロー:Atomic Designの原則とSketchでデザインからプログラミングまで | デザイン | POSTD

CSS

Atomic Designの階層?を意識してスタイルを定義する。

  • ATOMS
  • MOLECULES
  • ORGANISMS
  • TEMPLATES/PAGES

各階層について

ATOMS

最小単位なので、ボタンやリンクといったものから、カラーやフォントなんかもATOMOSとして扱うようだが、 実際にコーディングすることを考えたとき、カラーやフォントといったコンポーネントを修飾するようなスタイル定義はATOMSから外したほうがわかりやすいのでは。

MOLECULES

ATOMOSを組み合わせた、テキストボックス+ボタンのような一つの処理をまとめたシンプルなコンポーネントのスタイルを指す。

ORGANISMS

MOLECULESを組み合わせた、ヘッダーナビゲーションとか検索フォームとか再利用可能なコンポーネントのスタイル。

TEMPLATES/PAGES

各ページごと、もしくはViewファイルごとのレイアウトを定義する。
ファイル名がURLだったりViewファイル名?になるイメージ。

CSSディレクトリ構成イメージ

コンポーネントに関しては↑の階層で整理して、それ以外をbaseやutilsみたいな感じで用意してあげるのがいいかなと。

  • base: サイト全体に及ぶようなベースとなるスタイルやリセットCSS、Sassの変数定義、@import用ファイルなど
  • utils: カラーやフォントなどコンポーネントを修飾するためのスタイル、コンポーネントとは呼べない汎用的なCSSなど
  • atoms
  • molecules
  • organisms
  • templates

実装

コンポーネントCSSCSS modulesなどで実装してあげるとキレイな感じがする(後述のJSから利用する)。
普通にCSS書く場合、CSSがグローバルなことは変わりないので今まで通りBEMとか使うことになるんだろうきっと。

HTML

もしRailsのPartialのようにView(HTML)ファイルが分割できるのであればORGANISMSはPartialに切り出す、みたいな方針にするのもアリかも…と思ったが、ORGANISMS以外の単位でPartialに切り出したいという場面は結構ありそうなので微妙かも。

HTML(Viewファイル構成)は切り離して考えても良さそう。

JS

React.jsやRiot.jsのようなViewも含めてコンポーネント単位で実装するようなものを使っていると、Atomic Designの考え方がそのまま適応できてわかりやすいのでは。 CSSと同じように4階層に分けて実装できそう。

MOLECULESやORGANISMSを実装してコンポーネントを呼び出したり、SPAでTEMPLATES/PAGESを作ったり。 Atomsを実装することはあまりなさそうかな??

スタイルガイド

スタイルガイドでATOMS〜ORGANISMS(+base, utils)の使用例を見れるようにする。

考えてみて

ほんとにイメージ通り実装できるかサンプルを作ってみたいところです(希望)

Loop processing for NodeList at JS ( ES6 )

JavaScript

Make a note as it is a frequent process.
(get some element and use it at loop processing by JavaScript)

Use for-of

See the Pen Loop processing by for-of for NodeList at JS(ES6) by Fumihiro Nakahara (@711fumi) on CodePen.

Use Array.from (If you need Array returned)

See the Pen Loop processing by Array.from for NodeList at JS(ES6) by Fumihiro Nakahara (@711fumi) on CodePen.

If I need to write in ES5, use Array.prototype.forEach.call() ?

I feel again the merit of Jquery...
Why Is it recommended to not use JQuery? is it a performance problem? Is the library large?

エンジニア(プログラマー)はランニングに向いている

running 思ったこと

そんな気がしています。
※ここで言うランニングとは長距離走のことね

効率化

ランニング力を上げるために重要なのが、無駄を省く(効率化する)という考え方。

  • 無駄な脂肪、筋肉をつけない
  • 効率の良いトレーニングを行う(根性論じゃない)
  • 無駄なペースの上げ下げをしない
  • 走るときの荷物はなるべく少なくする

など、無駄(冗長)なことを良しとしないエンジニアは
ランニング力向上に必要な考え方が得意なわけです。

自己との対話

ランニングは自己との対話です。
体の状態はどうか、練習の負荷は適切か、シューズは自分に合っているか、など
自分を客観視して、コントロール(チューニング)していくことが重要になってきます。

これって、マシンとの対話に近い気がするんですよね(プログラミング、ハードウェアのチューニング)
練習やツールや食事なんかを自分に与えて、結果をモニタリングしてフィードバックを次の行動に活かす。
こういったトライアンドエラーはエンジニアの得意とするとこなのではと。

ツールへのこだわり

ランニングはシンプルなスポーツですが、ハマるといろんなものにこだわりだします。
シューズやウエアに始まり、補給食やプロテイン、筋トレグッズや疲労回復グッズ…

道具にこだわるエンジニアならきっとそのへんも楽しめることでしょう。

効率化できない部分

ただどうしても劇的には効率化できない部分があります。
それはトレーニング時間です。

ランニング力を向上させるには、どうしてもある程度長い時間走る必要があります。
効率を気にするエンジニアにとってこれは苦痛。

ただ最近はありがたいこととにエンジニア向けのPodcastがたくさんありますし、聴ける本なんかもたくさん出ているようなので、勉強しながら安心してランニングを続けることができます。

初心者の方へ

ランニング力を向上させるのにエンジニアは向いているって書いたんですけど、
初心者の人はゆっくり会話できるようなペースで、余裕を持って楽しんで走ることをおすすめします。

楽しいのが一番。

おわりに

書き終わって思ったけど
これってランニングじゃなくてもなんでもいいような。

駅トイレの緊急ボタン

思ったこと

駅のトイレ(個室)の緊急ボタンにはもれなく注意書きが添えてある。
今更感はあるが良い解決策はまだ出てないっぽいので考えてみた。

f:id:blog_711fumi:20160926175257j:plain

なぜ間違える人が多いのか

いたずらなどの可能性は置いておくとして。

1, 見た目・形で区別(役割の判別)がつかない場合がある
上の写真で言えば、水を流すボタンも緊急ボタンも同じアクションであるボタン。緊急ボタンの見た目は白であまり緊急感もない。

2, 使用時に必ず操作しなければいけないスイッチがある
注意書きにも書いてあるように、「水を流す(ボタン等)」という必ず操作しなければならないスイッチがあるのでそれと間違ってしまう。

3, 簡単に押せるボタンにしてある
簡単に届く場所に配置、押しやすいボタンにしてあるのは当然で、非常時にもとっさに気がついて押せるようなボタンでなければいけない。

どうしたらよいだろう

1に関してはまあ水を流すをもっと違う動き(ボタン以外)にするとか緊急ボタンを赤くするとかありそうだけどとりあえず置いといて2,3を考える。

状況によって目立たせる(押しやすくする)べきボタンが変わってしまうのが問題ぽい。
通常時は「水を流すボタン」にすっと気がつけるようになっていなければいけないが、緊急時には「緊急ボタン」に真っ先に手が伸びるようにならなければいけない。

ステータスによってUIを変えることは可能か?

もし、Webやアプリなんかのように

  • 状況によってUIを変えられる
  • 現在のユーザーの状況(通常時:緊急時)を判断できる

のであれば話は簡単なんだけどそうはいかない。

緊急時とは?

そもそもどんな時に「緊急ボタン」が押されるのかを確認する必要がありそう。
どのようなトラブルがあって、どのような状態・体勢で緊急ボタンを押したのか。

…さすがにちょっとググってもどういう時に押されることが多いのかはわからなかった。
鉄道会社にはそういうデータがあるんだろうけど。

なのでありそうなシチュエーションを考えてみた。

1, 突然めまいなどに襲われ動けなくなった
体調を崩す場合は視線がさがる場合が多そうなので(へたり込んじゃったりとか)、スイッチはなるべく下の方に付けたほうが良さそう。

2, ヤベぇやつがずっと個室のドアをノックしてきて外に出れない
この場合はトイレの外(そいつがいる方向)に目が向くだろうから、ドアとかに付けるべきか。

3, トイレが故障して水が溢れて止まらない
トイレ本体(便器)を見ながらワタワタしそうなので、便器にボタンを付けるとか?

というわけで

おそらくシチュエーションとしては一番1が多いと思うので、こうするのはどうでしょう。

洋式トイレの場合

  • 便座に座って正面の壁のすこし下の方に緊急ボタンを配置する
    • 便座に座った時に必ず目に入り、存在を確認できる
    • 便座に座った状態だと手が届かない
    • 水を流す、ウォシュレットといったボタンはまとめて便座に座った状態で手の届く場所に配置する

ボタン類は扉には付けれないと思うので、個室の扉を開けると便座が横を向いて置かれている形になると思います。
ボタンの種類によっては荷物とか足とかで誤って押しちゃう可能性があるかも…

和式だったり、視覚に障害のある方向けにどうするかといった問題があるんですけど。

フロントエンドの勉強も兼ねて「近場の食事できる場所をテキトーに教えてくれるWebapp」作った

web service JavaScript gulp npm

お勉強がてら簡単に作るはずだったのに疲れた。

https://god-of-meal.herokuapp.com/
GitHub - 711fumi/god-of-meal: God will choose an eating place.

やったこと

現在地(緯度経度)から近そうなごはん処をぐるなびAPIを使って取得、テキトーに選んで表示する。

環境(試したかったものとか)

  • React.js
  • Rollup.js
  • Express(Node.js)
  • Heroku
  • Gulp.js
  • Material Desing Lite
  • Enzyme(mocha, chai)

メモっておこう(参考にしたものとか)

JSで位置情報を取得

Geolocation APISSL(HTTPS)じゃないと使えないっぽい。

JavaScriptで位置情報を取得する方法(Geolocation API)

Material Design LiteのTypographyのオプション

なんかTypographyのオプションとかここに載ってなかったので
(見逃してるだけかなー)

material-design-lite/src/typography at master · google/material-design-lite · GitHub
他にもいろいろありそう

静的ページをHerokuで公開

結果静的なページだけじゃなくなったけどね…

GitHub - nulltask/heroku-static-provider: Static site provider for Heroku.

Herokuでデプロイ後にGulpタスクを実行したかった

Haml/Scss/ES6あたりのコンパイルに使用

Heroku Gulp — Medium

Herokuで公開しているサイトでSSLを強制させたい(Node.js)

Node.js on HerokuでSSL(https)接続を強制する方法 - Qiita

Enzymeを使ってのReactコンポーネントのテスト

動くことを確認する程度で終わってしまったが

ReactのテストをEnzymeで書いてみよう - Qiita