Goalist Design Blog

Devtoolsでの作業が消える悲劇を二度と起こさないためのChrome65からの新機能!(「検証」の使い方入門:後編)

こんにちはミツイです。
先日はChromeのDevToolsについて書きましたが、今回はその続編としてChrome 65で新しく追加された機能について。
エンジニア(さらに言えばフロントエンジニア)が使うツールはUI・UXが優れたものが多いと思うんですが、ChromeのDevToolsもやはりよくできてます。
歴史も長く使っている人も多いツールなので全体的に複雑であることは否めませんが、部分部分のUIは「凝りすぎでしょ!」と思うくらいよくできてます。
Chrome65で追加された機能も、ちょっと感動するほど「これが欲しかった」感があるので、ご紹介します。
※ちなみに2018/10/12現在、Chromeのバージョンは69です。ニュース性のある記事ではないのであしからず。。

Local Overrides

前回の記事で書いたとおり僕は、cssを書く時間の少なくとも半分以上をChromeのDevTools上で作業しています。
そこで怖いのが、編集作業は保存されていないということ。
ふとした瞬間にページをリロードしてしまい、しばらく編集していた内容が消えてしまった、何ていう経験は皆さんも覚えがあるのではないでしょうか?
そんな事故をなくすための機能、Local Overridesのご紹介です。

1.sourcesパネルのoverridesタブでfolder for overridesをselect!

f:id:k-mitsui:20181011160848p:plain

2.選んだフォルダの使用許諾が必要です。

f:id:k-mitsui:20181011160037p:plain

3.選んだフォルダが表示されていればOK。

f:id:k-mitsui:20181011160900p:plain

4.今回はとある要素のheight、とある要素のbackgroundを変更。

f:id:k-mitsui:20181011161310p:plain f:id:k-mitsui:20181011161319p:plain

5.すると、、変更した部分を含むファイルができていてます!

今回だと、style.min.cssがそのファイル。
ちゃんと変更が反映されています。
リロードしても、このファイルを優先して読み込むので変更が効いたまま!

f:id:k-mitsui:20181011161340p:plain f:id:k-mitsui:20181011161330p:plain

6.さらに、変更点を確認する方法!

show console drawerでコンソールドロワーを開き、changesタブを開くと、変更点が分かります。
とはいえ、今回のファイルはminifyされているので意味ないですね。。

f:id:k-mitsui:20181011161350p:plain

f:id:k-mitsui:20181011161416p:plain

7.ファイルは、いつでも読み込み直すことができます!

f:id:k-mitsui:20181011161456p:plain
先程のファイルはローカルに保存されているので、select for overridesで選ぶだけでいつでも読み込むことができます。 これで、安心してDevTools上でcss編集することができますね!
しかし、minifyされているとchangesの比較ができないのはもったいない。。
changesタブでも自動整形を使えるようにするなど、カイゼンして欲しい部分です。


Contrast ratio in the Color Picker

DevToolsでは色の■をクリックするとカラーピッカーが開きます。
今回のアップデートで、このカラーピッカーにコントラスト比が出るようになりました。

1.■をクリックすると、、、

f:id:k-mitsui:20181011161539p:plain

2.カラーピッカーが開きます。

contrast ratioと書いてある部分がコントラスト比です。13.77になってますね。
f:id:k-mitsui:20181011161552p:plain

4.さらに詳細を開くと、、、

憎いのは彩度明度のグラデーションの部分。
白い曲線が引いてあり、そこから下にしないとコントラストがなくなって見づらい、ということが表現されています。
contrast ratioの下にあるAAやAAAはWeb Content Accessibility Guidelinesのレベルです。
AAAの方がレベルが高いです。
丸の中にAaとある部分で、背景色と文字色が表示されています。わかりやすいですね。
f:id:k-mitsui:20181011161602p:plain

New SEO audits

auditsとは、会計検査とか審査の意味。
SEOテストが簡単に受けられるようになってます。

1.まずはauditsパネルを開きます。

f:id:k-mitsui:20181011162757p:plain

2.さっそくrun auditsをクリック

f:id:k-mitsui:20181011162805p:plain

3.シミュレーションが流れます。

f:id:k-mitsui:20181011162825p:plain

4.結果

ゴーリストHPで試した結果です。
「Progressive Web App」の点数が58点と低い。。
アンドロイド表示時の設定等、今まで気にしてこなかった部分に気づけたりします。
f:id:k-mitsui:20181011162832p:plain
f:id:k-mitsui:20181011162843p:plain

パフォーマンスの改善案がズラリと。
7月にGoogleの新アルゴリズム「スピードアップデート」が導入されましたが、auditsの機能が追加されたのも、もっとカイゼンしなさいということでしょうか。

まとめ

Chromeも69になってガラッと見た目が変わりましたが、DevToolsは65ですでに大きく進化していました。
機能を全て理解して使いこなす必要もないとは思いますが、自分が欲しい機能があることくらいは知っておきたいですね。
この記事が知る機会になってたら幸いです。
ではまた。

LP制作を通してウェブマーケティングに関わってみたこと#2

f:id:e-nagata:20181012171031p:plain

 

こんにちは、レタスです。

去る5月に弊社サービスHRogチャートのLP作成の記事(前編)を書いたのですが、後編を書かないままにあれよあれよと月日が過ぎ去っていました…。

LPをリニューアル公開したのは6月。いいかげんブログ書こうと思います!

一応リンクはこちら。

design.goalist.co.jp

 

おさらい

そもそもなぜHRogチャートLPのリニューアルをしたのでしたっけ。まずはそこからおさらい。

今年の頭からウェブマーケティングを進めている中で、

自社メディアHRogのオリジナル記事数を月8~10本発信

→サービスLPへの流入を狙う

→LPのPV数が劇的にあがる

→しかし、肝心のCV数はなかなか伸びない <なんで?>

という問題がでてきたのでした。

そこで、HRogチャートのLPでサービスのメリットや情報が訪問者に伝わっておらず、CV数が伸びない要因になっているのではないか?

と仮説を立て、リニューアルに挑んだのでした。

 

そこからHRogチャートユーザーとなるペルソナを設定し、競合サービスの調査をし、一般的なLPの情報構成などをリサーチしました。

ウェブマーケターの方と記載内容をすりあわせ、訪問者が何を思うかを予想する、というところまで前回の記事でご紹介しましたね。

f:id:e-nagata:20180516150044p:plain

f:id:e-nagata:20181012160904p:plain

 

 

ワイヤーを起こす

情報の構成が決まればワイヤーを起こす作業はとてもスムーズです。

それまでに自社ウェブサイトや新卒採用サイトなどのページも制作したことがありましたが、その際は記載情報のたたきも同時に作らねばならず(そもそものコンテンツから決める必要があった)、こんなに定まっていなかったので今回は本当に楽でした。

f:id:e-nagata:20181012161443p:plain

 Sketchでぽいぽいと作っていきます。弊社デザイン部ではウェブサイトやUIUXの画面作成はSketchを利用しています。

学生時代にillustratorやphotoshopなどはちょいちょい触ったことがありましたが、入社するまでこんなツールがあることも知りませんでした。触るうちに慣れてくるので、未経験でも案外問題ないです。

この頃はやっとシンボルの概念を理解し始めた段階だった気がします。プラグインとか、使いこなせたらもっと便利ですね。

 

おっと、話が脇道にそれてしまいました。

ワイヤーを一通り起こすと、

・配置すべきコンポーネント

・ユーザーのアクションや導線

・情報量

・スクロール量

などが具体化されていくので訪問者がページをどう閲覧するかわかりやすくなります。この段階でテキストを削ったり、必要であればボタンを追加してみたり。見落としている要素がないかなども確認します。

PC版が組み終わったら、モバイル版も作成します。モバイルでは縦長になるので、どうしてもスクロール量が多くなってしまう…。テキスト量は大丈夫か?場合によっては表示方法をPC版とは違うものにするべきか?など検討・調整していきます。

 

 

デザインを作る

ワイヤー確認後、いよいよデザインの作業に入ります。

いろいろな他サービスのLPを調べて参考になりそうなものをピックアップし、どの雰囲気に近いか方向性を確認したり、画面を作るヒントになる言葉や大事な部分を探り出していきます。

HRogチャートの売りポイントは「データの裏付けをもって営業できる」「エクセル操作が苦手でも簡単に集計できる」という点です。そのため、ファーストビューでは「このツールを使うと営業活動がスマートになる」「誰にでも簡単に使える、カジュアルで親しみやすそう」といった印象をもたせたい、という意見になりました。

 

スマートさを念頭におきつつ作ったのがまずこちらの案です。多色使いにはせず、同一系の色でスッキリまとめてみました。

HRogチャートは集計ツールなので、グラフや方眼紙のようなマス目のグラフィックをおき、ツールの内容がイメージできるように。

f:id:e-nagata:20181012163529p:plain

いったん作ったのですがどうでしょう...と営業部長、ウェブマーケターさん、デザイン部リーダーが集まるMTGでレビューしてもらいました。しかし反応は 「う〜ん?」といまいち。

「なんだか、方向性を決めたときはそれ(スマートなイメージ)で良いと思ったけど、ターゲットはもっとインパクトの強い言葉やデザインを好みそう...」「色をまとめすぎるとクール、無機質に寄りがち。あんまり親しみやすさが感じられない?」「ターゲットは普段iMacのようなパソコンを業務でさわらない人たちだから、自身で使うというイメージがつかないんじゃないかな。(画像の)素材がスタイリッシュすぎても親近感わかないかも」等の意見をもらいました。

確かに方向性を決めた段階では「営業活動がスマートになることを印象づけたい」と一致したのですが、ある程度形にしてみると、ターゲットが求めるデザインはもっとツールのメリットがダイレクトに伝わるものだったり、にぎやかな印象のものかも、と気がつきました。自分たちが印象付けたいことを意識しすぎてしまったのかもしれません。

デザインの方向性を定めたつもりでも、それが最適解かどうかはわかりづらい...。基本ですがここでも作ったペルソナ像に立ち返りつつ、印象やビジュアルを決める精度を高めねばと思いました。

ターゲットに親近感を持たせるために、PCモック素材の種類やテイストまでちゃんと選択するというのも発見でした。一般的には営業マンが会社で利用しているパソコンってWindowsやノートパソコンが多いですもんね。細部ですがこういうところでも理解の度合いがでるのか...なるほどでした。

 

 

決めかねてABテストへ

最初に作った案からアクセントカラーを追加したり、ファーストビュー上の情報を多くするなどして、テイストを変えたバージョンを作りました。

f:id:e-nagata:20181012163607p:plain

ちょっとゴテゴテ具合が増して、スマート感はないけれど、お問い合わせフォームに誘導するボタンなどがわかりやすくなりました。

 

双方の案を出したのですが、HRogシリーズ全体のテイストの指針がまだ定まっていないという理由もあり、結局どちらを採用するかはっきりと決まらず(あれ)、ABテストを行うことになりました。

少々脱線しますが、デザインチームリーダー(ミツイさん)が3、4年前にゴーリストへジョインした頃は、とにかくサービスやウェブサイトを作っては出し、作っては出しという状態でした。制作だけでも手一杯、とてもじゃないけど全体の指針やブランディングまで着手できる状況ではなかったのですね。

最近やっと人も増えてきたので、そろそろそういったことを決めても良い時期なのかも、とも思います。デザイン部の中でもサービスのUI制作や受託案件の担当とは別に、会社全体や自社サービスに関するガイド作りや改善に携わる担当をつくっても良い気がしてます、(チラッ...) 今のところ全員が手を動かすタスクに追われているのも事実ではあるのですけど、一度決めてしまえば迷いが減ったりチームでの制作が楽になりそうです。

まあ、悪く言えばデザインのガイドラインやトータルの方向性を定めきれていない状態だけれど、よく言えば何も決まりきってない分、好奇心旺盛な人やサービスをトータルにみてみたい人、コンセプト作りやブランディングまでやりたいデザイナーさんには面白い環境かもしれません。小さな会社ならではのデザイナーの守備・攻防範囲の広さといいますか。

 

ABテストの試みも実は今回が初めてです。

今回はGoogle optimizeを使ってテストを行いました。2種類のページを用意し、URLをリダイレクトさせることによって表示するページを分岐させるという仕組みです。どのページを何%の割合で表示させるか、なども設定することができます。

前例がない分進むのも探り探りですが、担当案件を通して様々な知見を貯めていけるのは良いことだと思います。

そして気になるリニューアルの効果はいかに。

 

 

気になる結果は

結論:わからない

(なんだそれ!)

・・・

初めてのABテストということもあり、デザイン変更によって数値が変化するのかどうかわくわくしていたのですが。

リニューアル公開後しばらく様子を伺ってみたものの、そのタイミングを狙ったかのようにHRog(自社メディア)自体のPV数が下がり、そこからのLP流入数も直接打撃を受けるなどのハプニングが勃発。

HRogの投稿記事数はこれまで通りだし、コンテンツ内容もさして大きな差はないはず...なのに、なぜ?!とマーケターさんと共に考えられる限りの要因を洗い出してみましたが、結局これだ!という答えが見つからず、途方にくれてしまいました。最近Googleのアルゴリズムが変更されたとの噂もあるし、それも一要因として考えられるかもしれませんが定かではありません。

もしかして構成やデザインを変えない時の方がよかったのか...!?と、急遽旧バージョンも含めたテストに変更しましたが、結局目に見える差は現れないままです。現在もテスト進行中です。

ウェブは…要因がありすぎてわからん…わからんですね…安定しないと難しい!

 

また、弊社サービスはtoBかつ、ニッチな業界のユーザーに向けられたものなので、この点でも壁があるのかも、とも。

一定数のPVをとりにくい以上、ABテストでどちらが効果的なのかも判断しづらいので、どちらのデザインが良いか...はいまだに保留状態です。数値に差が開くのを確認するには、予想以上に時間がかかりそうです。腰を据えて実験をしていかないとダメなんですね。

でも、同系色でまとめたバージョンと、アクセントカラーをオレンジにしているバージョンでは後者の方が効果ありということが見えてきました。それがわかっただけでもいったんはよしとしましょう。

改善は地道に、継続的に、1つずつ進む!を実感したのでした。

 

 

まとめ

ウェブマーケティングに関わってみると、サービス全体の流れを洗い出して、理想像を描いて、どこが一番改善の優先度が高いのか、ボトルネックになってるのかを見つけ出して、目的が達成されるようにアクションしていく...というフローが見えてきます。全体像が見えてくる、視野が広がる感覚といいましょうか。その中で自分が担当するデザインワークがどこに位置して、何を達成すべきなのかがクリアになります。

もちろん、実際今回のABテストのようになかなか思い通りに進んでくれないこともありますが、それも改善に必要な一部と思えばそれはそれで。

今後もテストは継続しつつ、CVに繋がる要素について考えたり、改善を重ねていきたいですね。一歩ずつ。

はじめてのCSS flexbox使ってみた!

こんにちは。マスダです。
この前まであんなに暑かったのにここ数日しれっと涼しくなってきましたね。
秋ですね(という文章を書いたのはもう1週間前、ブログ途中まで書いて放置するのあるあるではないでしょうか、、)。

今回は社内報を作るにあたり、CSS初心者がこんなCSSの書き方あったんだ!という発見を書いていきます。

ところで、私がCSSに初めて触れたのは今から2年前のこと。
趣味で作った手芸作品を掲載するHPを作ってみたいな〜なんて思ったのがきっかけで、HTMLとCSSを勉強しはじめました。
独学でグーグル先生に教えてもらいつつ CSSを覚えていったので、知識に偏りがあったり、非効率な書き方だったりとかするのかなぁなんて思います。でも、まぁ画面崩れてなければOK的なところもあるので、なかなか新しい知識を増やしていくのは難しいですよね…。

ゴーリストの新卒の技術研修でもHTML、CSS、JavaScriptを触る機会がありましたが、自学自習がメインだったのでやっぱり知識増えた!という感じはしなかったですね。

新しい知識を増やすのって難しいものです。

しかし、社内報を作る時にはコードレビューしてもらえたので、新しい知識も増えました!
そう!flexboxの知識です!

 

前置きが長くなりましたが、ここから本題に入ります〜

 

flexboxを使ってみた

私が社内報を作るとき、こんなレイアウトを組みたいな〜なんて思っていました。

f:id:ikamasuda:20180913133542p:plain

こちら、メンバーの好きな映画の一覧です。3列でコメントが並ぶレイアウトです。

今までの私の知識であれば、

f:id:ikamasuda:20180918152019p:plain

というふうに、それぞれのコメントを左寄せにして余白の調整を入れていました。
余白の調整の仕方ももっとましなやり方あるのでは…と思っちゃいますが、、

 

でもここでふと、そういえばミツイさんが「float: left; はもう古い!flexboxというのがあるんです!」ということを言っていたのを思い出して、少し調べてみることに。

 ほうほうなるほど、簡単にレイアウトを組むことができるのか。
さっそく使ってみよう!

ということで、先ほどのコードをこのように書き換えました。 

f:id:ikamasuda:20180918151735p:plain

floatプロパティの指定は消して、コメントの親要素のdisplayプロパティをflexに指定。

f:id:ikamasuda:20180914113458p:plain

そうすると、指定する前はこのように縦に並んでいたコメントが、

f:id:ikamasuda:20180914113318p:plain

きれいに横に並ぶように、、はなったものの、横幅の320px指定が無視されちゃっています。なんでだ・・・?
これじゃあ画像も切れちゃってるし、コメント読みにくくて台無しじゃないか、、

実はこれ、簡単に修正することができます!先ほどのコードに1行追加するだけ!

f:id:ikamasuda:20180918151822p:plain

「flex-wrap: wrap;」というのを親要素に付け足しました。

f:id:ikamasuda:20180914120711p:plain

するとこう!きれいに3列でコメントが並んでくれました!

これ、なにをしたかというと、flex-wrapというプロパティはflexアイテム(ここではコメントのこと)をひとつのラインに全て詰め込むか、それとも複数ラインに折り返して配置するかを決めるプロパティです。

今回指定した「wrap」という値がflexアイテムを複数ラインに配置してもいいよ!という書き方です。
このプロパティは初期値が「no-wrap」となっています。こちらはひとつのラインにflexアイテムを配置せよ!という書き方なので、なにも指定しないままだとコメントがぎゅうぎゅうに詰め込まれたわけですね。

 

なるほど!
display: flex;
flex-wrap: wrap;
と書けば、子要素を横並びにしてくれるのか!

新しい知識が増えた瞬間です!

  

余白の調整にも便利!flexbox!

さて、これだけではまだflexboxの便利さがよくわかりません。
社内報を作った時はこれくらいの指定しか知らなかったので、あまりflexboxの恩恵を受けることができませんでした。

でも、まだまだできることはたくさんあります!
私がおぉ!すごい!と思ったのは自動で余白の調整をしてくれるところです。

これには、「align-content」と「justify-content」というプロパティを指定します。

たとえば、、

f:id:ikamasuda:20180918162000p:plain

このようにflexコンテナ(親要素)の中にアイテム(子要素)が入っているボックスがあるとします。

これのflexコンテナに「justify-content: space-between」というプロパティを追加すると、

f:id:ikamasuda:20180918162251p:plain

このように、横(主軸)方向の要素間の余白を均等に割り振ってくれます。
縦(交差軸)方向は「align-content: space-between」と書けばOKです。

このように。

f:id:ikamasuda:20180918162514p:plain

この指定方法を知っておけば、いちいち余白が〜pxと計算して指定する必要もなくなっちゃいますね。

ちなみに、それぞれのプロパティの値を「space-around」に書き換えると、

f:id:ikamasuda:20180918162851p:plain

このように、子要素の周囲の余白を均等にしてくれたりもします。
おぉ〜。

 

以上、flexboxを使って要素を横並べにしてみた!ついでに余白の調整もしてみた!という内容でした〜。

ウィンドウサイズによって、アイテムの並ぶ方向や並ぶ順番を指定すると、レスポンシブ対応なんかに使えたりもするみたいです。
いつか使ってみたいですね!

 

ちなみに、デザイン部ではレスポンシブ対応にflexbox使ってたりします。こちらの記事に書いてますので興味あればご覧ください。

design.goalist.co.jp

 

まだまだ自分の知らないことがいっぱいなので、どんなことができるんだろう〜とワクワクしますね。知識増やすために、ググり力も鍛えなければです!

cssが効かない!時のDevTools(検証)による原因究明方法

f:id:k-mitsui:20180829155300p:plain

こんにちは、ミツイです。

cssを組む時にchromeの検証は必要不可欠ですよね。
ゴーリストではデザインチームがコーディングまで行うことが多いので、chromeのDevTools(検証)にはお世話になりっぱなしです。
下手したらillustratorとかSketchとかよりも使ってるツールですが、その実、使われ方が共有されていなかったりするので、僕なりの使い方を書いておこうと思います。

要素の検証ざっくり紹介

まずは、DevToolsの基本的な使い方から。
呼び出し方は大きく分けて、
・右クリック→検証
・cmd + Option + c(cmd + Option + iでも出ますが、cの方がハイライトする場所を選択できるので便利です)
f:id:k-mitsui:20180829123058p:plain
f:id:k-mitsui:20180829123115p:plain
の2種類があります。
どちらからでも良いので、とりあえず開いてみましょう。

Elements・Console・Sources・Network・Timeline・Profiles・Application・Securityのモードがあります。
f:id:k-mitsui:20180829123128p:plain
今回見てほしいのはElementsパネルだけです。

Elementsパネルをざっくり言うと、左がHTML(DOM Tree)で右がcss、です。
cssの部分(Styles pane)は、Styles・Computed・EventListeners・DOM Breakpoints・Properties・Accessibilityのタブがありますが、今回見てほしいのはStylesタブだけ!
f:id:k-mitsui:20180829123151p:plain

DOM treeで要素を探す

・実際のページの検証したい部分をもう一回右クリック→検証
・cmd + Option + c(もしくはcmd + Shift + c。何でショートカットがどちらもOKになってるんでしょうかね。。)
で実際の画面上で選択部分が色付きになります。
f:id:k-mitsui:20180829123211p:plain
青が本体、緑はパディング、オレンジがマージンです。
実際の画面上にtootltipの形で縦横のサイズが表示されます。これもよく使いますね。

f:id:k-mitsui:20180829123222p:plain
imgタグのsrcの値をホバーすると表示画像サイズと元のサイズが表示されます。これも、助かる。

画像のurlを知りたいけど、imgタグがない!

f:id:k-mitsui:20180829123238p:plain
cssのbackground(background-image)に書いてあることが多々あります。
画像の縦横比が変則的でbackground-size:containかcover を使いたい時などにありがち。

階層多すぎて、次の要素を探すの大変。。

f:id:k-mitsui:20180829123258p:plain
適度に閉じた方が構造含めて見やすいですよ。
フッター部分にある階層をクリックして、必要な階層に移動するのも使えます。

Styles paneを見る。上から順に。

f:id:k-mitsui:20180829123325p:plain

セレクタ {  
   プロパティ: 値;  
}  

がバババッと並んでますが、上にあるものが強いセレクタです。
※セレクタには強さってものがありまして、基本的にはどれだけ詳細に書かれているかってことになります。
詳しくは下記ページがわかりやすいです。

『CSSセレクタの優先度を手軽に計算して比較できるツール「Specificity Calculator」 』 https://nelog.jp/specificity-calculator

同じ要素に対して同じプロパティの指定があった場合、Style pane上で上に書いてあるスタイルの方が効くってことです(基本は)。
負けている“プロパティ:値”は、打ち消し線がついてます。
なお、セレクタで勝ってても、!importantで負ける場合もあるので、一番上にあるからと言って油断はできません。
また、継承されるタイプのスタイルは打ち消し線で消されていても反映されている場合があるので、こちらも合わせて注意です。
f:id:k-mitsui:20180829123350p:plain

該当のcssが書いてない。

右クリックやセレクトモードを使ってページの該当部分を選択しても、書いたはずのセレクタが見つからないなんてことがあります。 ・選択されているDOMの子供(か子孫)に書いてある。
・選択されているDOMの親(か祖先)に書いてある。
・選択されているDOMのbefore要素・after要素に書いてある。
f:id:k-mitsui:20180829123434p:plain
・javascriptを使ってインラインスタイル(HTML上にstyle=""で書くスタイル指定)に吐き出されるようにしてある。
f:id:k-mitsui:20180829123446p:plain

他のスタイル指定に打ち消されている。。

【対処法→】セレクタを強く書き換える。上の記事を読みつつ、子孫セレクタを使ったり、複数クラスにしたり。!importantは基本的に使わないでください。未来の自分や同僚のために。

ライブラリのcssに負けている(ことごとく)。。

【対処法→】cssを読み込む順番を変える。カスタムスタイルシートは後で読み込みます。cssは後勝ちなので。
いや、あるんですよ。意外と。wordpressとかで特に。
f:id:k-mitsui:20180829123514p:plain

セレクタの強さが無茶苦茶になってきてて、!importantが連発してある。。

【対処法→】classの命名規則を考え直したほうが良いですね。静的ページならBEM、SMACSS、OOCSS等を使って書く。Angularやreact等ならcssのカプセル化をするのがオススメです。

そもそも書いたはずのセレクタがない。。

【対処法→】Style paneに書いたはずのセレクタがない。下の方まで見たけど見当たらない。。。
原因は様々です。頑張って原因を探ります。よくあるのは、
・セレクタが間違ってしまっている。間違った子孫セレクタの書き方等(scssで書いてるとありがち)。
・そもそも、該当するスタイルが書かれているcssが読まれていない。リンク切れ。(ローカルで作業しているのにcssファイルだけ本番ファイルを見ていたなんてことも)
・cssのセミコロンやコロンの閉じ忘れ。(cssファイルの一番上に書いたら効くのに下の方に書くと効かない、何ていうのはこの可能性ありです)。
・media queryで違うディスプレイサイズを指定していた(その辺り一帯が実はモバイル用のcssになっていたり。。そのためにも、media queryはごそっと書くんではなくこまめに書くのをおすすめします。)
・カプセル化の影響で効かない(Angularとかでありがち)。
・ブラウザのキャッシュが残っているだけ(スーパーリロードは、cmd + shift + r)。

書いたはずのセレクタが見つからないとDevToolsは使いものになりません。
とりあえずstyle paneに出るように修正していってください。

cssを直す

style paneに目的のセレクタがあったら、DevTools上で編集していきます。
プロパティ名、値の部分をクリックするとそれぞれ編集状態になるので修正します。
f:id:k-mitsui:20180829123612p:plain
サジェスト機能があるので、基本的にはそれを使っていきましょう(スペルミスで効かないという無駄時間をなくすため)。
f:id:k-mitsui:20180829123937p:plain

色指定の左にある■をクリックすると
こんなのが出てきて、
f:id:k-mitsui:20180829124002p:plain
直感的に色の変更をできるので便利です。

あと、各セレクタの右に書いてあるファイル名と行数は非常に便利です。 sass(scss)だと、セレクタを検索しても出てこなかったりするのでこれがないと結構困ります。 f:id:k-mitsui:20180829124206p:plain
(ネストしている場合はその塊の先頭行までしかわからないのがたまに傷ですが。。ちなみにAtomでは ctrl + g で指定した行へ移動できます。)

まとめ

表示崩れをcssファイルだけ見て直すとか、0から作る時にcssファイルだけ見て書くとか、今ではもう考えられないです。
できるなら、DevToolsで完結したいくらい。(Atomのプラグインでそういうのありそうですね。なかったら、作れないかしらん)
もしまだ使ったことがないという方いましたら、今すぐcmd + option + c で検証してみてください。
もちろんDevToolsはcssコーディング以外にも活躍するので、機会があればそれらについても書いてみたいと思います。 ではまた!

社内報作ってみた 後編 〜デザインとコーディング〜

こんにちは。マスダです。
前回に引き続き、社内報制作について書いていきたいと思います!
ラフについては前回書いたので、今回はデザインとコーディングについてです。

社内報はこちらからご覧いただけます。

ゴーリスト社内報
ゴーリスト社内報

ざっくりと説明すると、
デザインの工程では、ピクトグラムの作成や配色やそれぞれの要素の細かい配置・余白などを決めていきます。(今回は配色について書きます)
コーディングはデザインをweb上で誰でも見ることができるようにHTMLやCSSを書くことになります。 

 

与えたい印象から配色を決めようとした…!

まずはじめに色を決めるところから始めました。
色はサイトの印象を決める重要な要素の一つになります。
たとえば、赤は力強さや情熱を連想させる色で、青はクールさや信頼感を与える色です。

 

なので、サイトを作るときは、訪れた人にどのような印象を持ってもらいたいかを考えて色を選ぶ必要があります。
また、サイトには1つの色だけではなく、複数の色が使われていることがほとんどですが、この色の組み合わせを配色と言います。
配色はランダムに色を選ぶのではなく、統一感のある色の組み合わせを考える必要があります。
配色はメインカラーとサブカラー、アクセントカラーの割合が7:2:1が一番見栄えがするらしいです。

さて、社内報でどんな色を使うのか、これにはとても悩みました。

まずはゴーリストがどのような会社だと思ってもらいたいのかを考えたのですが、なんせまだ入社して3ヶ月目なので、どんな会社かわからないです。
しいていうなら、情熱的とまではいかないものの、活発なイメージとかメリハリのあるイメージがありました。(研修では営業部のみなさんとの関わりが多かったからかもしれないです。)

なので、今回は「活発・メリハリ」というキーワードを元に色を考えました。

これらのキーワードを連想させるような色、、そんなに色の知識も多くない中いろいろググりまして、活発さを表すのはオレンジなんじゃないか!という結論に至りました。
また、メリハリの部分は一つの色では表せないと思い、使う色のコントラストを強めることによって表そうと思いました。

そこで、彩度の高いオレンジと白の組み合わせでデザインをし始めました。

ところが、、、

どうしても私のしっくりくるものが作れません。
というのも、私の好みがメリハリのあるはっきりとしたものではなくて、曖昧なふわっとしたものなので今回作ろうとしているものとはほぼ真逆だったからです。

これはこれは大変でした。
どこに色を使えばいいのかやそもそものメリハリのつけかた。まったくわからなかったです。
とにかく作っては先輩にレビューしてもらいつつようやく完成したのがこちら。

f:id:ikamasuda:20180828160049p:plain

うーん、今見てもやっぱりしっくりこないです。
自分の好みじゃないからなのか、色の使いどころがおかしいからなのか、単色しか使っていないからなのか。
明確に言語化することは難しいですが、なんかしっくりきません。

 

とりあえず自分のしっくりくる配色を考えてみた

これを社内報発案者の林さんにも共有したところ、作っている人がしっくりこないんじゃダメでしょということで、1からもう一度やり直し。

配色が1パターンだと良いのか悪いのか決めることができないので、数パターン作ってどれがいいのか決めることとなりました。

また、与えたいイメージとかなしにして、自分の好きなように作ってみるのもいいんじゃない?
というアドバイスもいただいたので、配色パターンでしっくりくるものを探してきて色の割合を考えつつ配色していきました。

ちなみに、自分で配色を考えるのはとても難しいのでネット上に転がっているいろんな配色ツールを利用したりもしました。
たとえばこんなものです。(http://paletton.com/
1色指定すれば、相性のいい色を提案してくれます。

そして、いろんな配色を試したものがこちら。

ゴーリストカラーであるレッドを使ったものから、パステルカラーのものまで。

f:id:ikamasuda:20180828163700p:plain

これをひっさげてもう一度林さんのところへいきました。
すると、評価基準も加えてどのデザインがいいのか決めてもらうことができました。

評価基準は下記3点です
・コンテンツとの相性(ふんわりしてる)
・ゴーリストが持つイメージ(グイグイしすぎず中庸)
・全体(GoalistHPなど)との統一感(赤)

これらを総合評価したところ、これがピンとくる!というデザインでした。

f:id:ikamasuda:20180828164701p:plain

なんとこれは、自分の一番しっくりくる配色でした。
おそらく、自分が見慣れている色だと配色のバランスとかとりやすくまとまったものを作れるのですかね。

いろいろパターンを作ってみて、自分の好みのデザインがわかった気がします。
ふんわりしたものが好きで、メリハリのあるデザインはあまり好きじゃないし、作るのも苦手だということを感じました。

 

さて、デザインはこれで決定です。
(最初に、伝えたいイメージを考えたのはどこにいったんだというツッコミは置いておいて、、)

職種や文理のピクトグラムなども自分で作っていろいろ学びがありましたが、ちょっと長くなりそうなので割愛しちゃいます。

 

デザインが決まったらいよいよコーディングです!

 コーディングはさくっと!

 デザインについて書いたら少し長くなってしまったので、コーディングについてはちょこっとにしておきたいと思います。
まず、今作ったデザインをchromeなどのブラウザ上で見れるようにするには、HTMLで文書の構造を書き、CSSで見た目を装飾していきます。

デザインを正確に表現するためにはこの2つの言語を扱えるようにしなくてはいけません。

私の場合は大学生の時に自分のHPを作ったこともあり、基礎レベルの知識はあったので、デザインを表現するのは割とさくっといけたのですが、classの命名に一苦労しました。
自分だけがコードをいじるというわけではないので、誰が見てもこれはどの部品かというのを名前を見ただけで容易にわかるようにしなければいけません。

これが比較的難しかったです。

BEM(Block Element Modifier)という命名規則にならって名前をつけていきましたが、うーんどれがブロックで、エレメントで、、と判断するのが慣れておらず時間がかかりました。
あとは単純に日本語を英語にするのが面倒でした(笑)

コーディングは特筆することも思い浮かばず、、、というより他でまとめて書いた方がわかりやすいと思うので、このブログではさくっとこの辺で終わりたいと思います。

 

1から社内報を作ってみた まとめ

まずはなにか目的をもって制作するのは難しい!

ただ見た目をいい感じに整えるだけだと思っていたので(言い過ぎ)、ターゲットとか目的とかコンセプトとかをしっかり考えること、ターゲットの興味を引くようなコンテンツを考えることなど 、なぜ作るのかの目的を明確にして制作に取り組むのがいかに大変かを知りました。
また、今回は初めての制作ということでラフでどこまで詳細に作ってデザインではなにをするのかという制作の過程をはじめに思い描けていなかったために、過程を行ったり来たりしたしんどさもあったと思います。

なんとなくですが、ラフの段階ではコンテンツの内容を決めることと、コンテンツの中でどれが一番重要な情報かというのを決めること、色をどこにつけるのか白黒で考えておくことが大切なんじゃないかなと思いました。

そうするとデザインの段階では配色を決めたり要素の細かいところに統一感をだしたりすることに集中できていいのではないかと思います。

 

デザインというものは正解がないので、答えを求めたがる私にとってはもやもやが残るものでした。
本当にこれでいいのだろうか。私が作ったものが世に出ていいのか?とは今も思っています。
でも、こういった不安は経験値を積んでいくことでしか解消することはできないと思っているので、あれこれ考えるよりもとりあえず手を動かしていこうと思います。

 

いろいろ書きましたが、無事に社内報がリリースできてよかったです。
今後も社内報は月1回更新されていく予定ですので、興味がありましたらご覧ください。

ゴーリスト社内報

最後まで読んでいただきありがとうございます。

社内報を作ってみた 前編 〜制作のきっかけと、ラフ作成〜

こんにちは。マスダです。

まだまだひよっこでいつになったら自信が持てるようになるのかと日々悶々としています。
そんな私が、6月の職種別研修で製作したものが7月頭にリリースされました!
ゴーリスト初の社内報です!制作期間は1ヶ月。
はじめて自分で1から作ったので、その過程をざっくりと紹介したいと思います。

 

また、社内報ですが、社外にも公開しています!
下記から見ることができるので、興味がありましたらご覧ください!

 

ゴーリスト社内報

ゴーリスト社内報

https://fresh-recruiting.goalist.co.jp/newsletter/

 



社内報を作るきっかけは?

とある5月の某日。

 

「社内報作ってみたいんだよね。」
「それ、職種別研修で作ってもらったらいいんじゃない?」

 

というなにげない会話をきっかけに私が制作することになりました。

 

どうして社内報を作ろうと思ったのか人事部長に理由を聞いてみると、
スタバの店頭においてある「今日いるスタッフの紹介」を見て、これいいじゃん!となったからだそうです。

何がいいかというと、単純にへぇ〜が生まれる。
へぇ〜が生まれると、会話につながる、コミュニケーションが増える。いいですよね。

 

現在ゴーリストでは、社員数が40名近くに増えてきたので、部署が違うとほぼ喋らないという状況が生まれつつあります。

でも、これはあまり良くない状況で、部署間でコミュニケーションが生まれないとそれぞれの部署が思っていることが共有されなくなってしまいます。

なので、雑談ベースでも、いろいろな部署の人とコミュニケーションを取ることはは大切なんですね!

 

このコミュニケーションを活性化させるため、メンバーのことをもっとよく知るために社内報を作ることになったのです。



ターゲットと作る目的、コンセプトを考えよう!

さて、社内報を作るにあたり、まず行ったことはターゲットと目的、コンセプトの明確化です。

これらを明確にしておくことで、方向性を見失うことがなく一貫性を持って制作することができます。

f:id:ikamasuda:20180822124759p:plain

 

社内報制作の言い出しっぺの人事部長の林さんにいろいろとヒアリングしながら、目的やコンセプトを決めていきます。

 

まずは、ターゲット

今回の社内報は社内だけではなく、社外にも公開することが決まっていたので、ターゲットはゴーリストメンバーと新卒・中途の求職者。考えるまでもないです。

 

次に、作る目的

社内と社外の二つのターゲットがいるので、それぞれのターゲットで目的を決めます。
社内:コミュニケーションの活性化
社外:メンバーのこと、会社のことをより深く知ってもらう

うん、これもサクッと決まります。

 

最後に、コンセプト

これが難しいんですよね。
作る目的としてはメンバーのことを知ることができて、コミュニケーションの活性化につながること。

う〜ん。

割と個人のことにフォーカスする内容で、さらっと読める感じ!コミュニケーションしている感じ!

う〜ん。

へぇ〜とか、そうなんだ〜とか、わかる〜が生まれる感じ!

・・・。

「メンバーと対面しているように思えるwebページはどうでしょうか!」
「それいいね!」

 

ということで、「コンセプトは対面しているように思えるwebページ」に決定しました。



無事これでターゲット、目的、コンセプトが決まりました。

 

まとめると

ターゲットと目的
全社内メンバー:コミュニケーションの活性化
新卒・中途の求職者:メンバーのこと、会社のことをより深く知ってもらう

コンセプト
対面しているように感じるwebページ




はじめてラフを作ってみた

コンセプトなど諸々が決まったら次はいよいよ内容を考えていきます。

掲載するコンテンツと、そのコンテンツのレイアウトを考えます。

f:id:ikamasuda:20180822125141p:plain

今回の社内報は社内アンケートの回答結果をインフォグラフィックスでまとめたものです。

 

ということは、コンテンツを考えるために、

  1. アンケート回答を見て、
  2. みんなが興味惹かれる(へぇ〜となる)切り口を見つけ出し、
  3. インフォグラフィックでの表し方を考える

というなかなか大変な作業をすることになりました、、、

 

というか、そもそもラフ作成の作業にコンテンツを考えるフェーズと、そのコンテンツをどのように配置するか考えるフェーズがあるのを全く知らなかったので、

これらの作業を行ったり来たりしながらラフを作っており、めちゃくちゃ時間がかかりました。


コンテンツを固めてから、レイアウトを考えるのがいいですね!
社内報制作で学びました!


ということで、コンテンツを考えます。

今回の社内アンケートでは、

・出身学部
・好きな漫画
・好きな映画
・初めて買ったアルバム

の4つを聞きました。

 

これらのまとめ方を考えていきます。

見た人が「へぇ〜」となることが大事ですから、できるだけ違いが現れるようにまとめることを重視しました。

職種別にまとめたり、年齢別にまとめたり、ジャンル別にまとめたりといろいろな軸で集計してみて、一番面白い!と思える軸を採用します。

 

例えば出身学部の質問では、出身学部を文理に分類して、職種ごとに人数がわかるようにしました。

f:id:ikamasuda:20180821115219p:plain

これは、見た人が「エンジニアでも文系出身の人いるんだ〜、へぇ〜」となるようにするためです。

 

アンケートをまとめるのに一番苦労したのは好きな漫画です。
というのも、私自身が漫画を読まないので、どんな切り口のコンテンツが面白いと思ってもらえるのかがわからなかったからです。

まずはじめに思いついたのがこちら。

f:id:ikamasuda:20180822143935p:plain


漫画を青年漫画や少年漫画の大枠でわけて、どんな漫画を読む人がいるのかを表したもの。
「ふーん」って感じかなと思います。決して「へぇ〜」ではない気がします。

自分では思いつかなかったので、いろいろな人にアドバイスをもらって最終的にはこうなりました。

f:id:ikamasuda:20180822144139p:plain

メンバーの年齢と漫画のジャンルを表形式にして、それぞれの年代の人がどんな漫画を読んでいるのかがわかるようにしました。

情報が増えたことで、さっきよりは「へぇ〜」となると思います。

 

このような感じで他のアンケートもどのようにまとめるかの切り口を考えていきました。

他のアンケートをどのような切り口でまとめたのか知りたい方はぜひ社内報をご覧ください!

https://fresh-recruiting.goalist.co.jp/newsletter/

 

 

 

さて、切り口を考えた後はレイアウトをいい感じに整えていきます。

先ほどの出身学部のものを例に挙げると、全体での文理の割合を表す円グラフの大きさや職種別の人数を表したグラフの大きさなど、どの情報を一番見せたいか考えつつバランスを整えていきます。

こちらがはじめに考えたもの。

f:id:ikamasuda:20180822144840p:plain

全社員での文理の割合と、職種別の人数グラフが同じ大きさなので、いまいちどっちを見て欲しいのかパッとしません。

ということで、次に作ったのがこれ。

f:id:ikamasuda:20180821115219p:plain

職種別の方を大きくして、目がいくようにしました。
これなら、伝えたいことの「エンジニアにも文系出身の人がたくさんいます!」ということがわかりやすいです。

 

ラフを作るのは初めてなもので、先輩デザイナーの皆さんに何度もレビューしていただいて、もうちょっとメリハリあった方がいいとかアドバイスをたくさんいただきながら改善していきました。

 

ちなみにデザイン部では毎日朝会が開かれていて、その日やることの確認とレビューなどがあれば見ていただけるのでとても助かります。



レビューを繰り返して、コンテンツとレイアウトが決まればいよいよデザインに入っていきます。

長くなってしまったので、デザインとコーディングについては後編でお送りします。

最後まで読んでいただき、ありがとうございました〜

 

HTMLは変えたくない!でも、レスポンシブで表示順序を変えたい。そんなあなたに贈るFlexbox tips

f:id:e-nagata:20180822191534p:plain

お久しぶりです。レタスです。
前回書いたブログがなんと5月...だったことにびっくりです。
すでに8月、夏真っ盛り。もはや残暑。皆さんは今年の猛暑は大丈夫でしたか?
私個人の今年の夏はゆるくハイキングしたり、富士登山したり、川でSAPしたりと、野外で割とアクティブに遊ぶことが多かったです。
東京のオフィスより自然に近い方が好きなので、デザインの仕事と何かうまいこと繋げられないかな〜なんて思っているところです。


さて、今回はLP制作でコーディングしながら得たCSSネタについて書きたいと思います。
使う時はごくごく限られるかもしれないですが、私自身もflexboxで日頃利用しない組み方だったので、同じような場合に必要とする人がきっといるはず...!と見込んでメモしておきます。



ちなみに

そういうコーディングもデザイナーがやるの?という声が聞こえそうなので補足しますと。
ゴーリストデザイン部ではSketchやillustratorでのデザイン画面作成に加えて、フロントのコーディングも担当する場合が多いです。
WebページだったらHTML,CSS,JavaScriptを書き書き、
Webアプリなど、プロダクトであればHTML,CSSはこちらが担当し、何かしらの操作やアクションが関わる部分に関してはバックエンドのエンジニアさんにお願いし、それぞれカバーし合って実装してます。
専任のフロントエンドエンジニアが不在ゆえの体制ではあるのですが、作業自体や頭を使う部分が全然違うので、一つのプロジェクト内でも工程が変わるとがらりと気分が変わって面白いです。
得意不得意はありますが、未経験でも関係なくOJTで習得しながらやっています。
私はHTML・CSSの実装は割と苦労しませんでしたが、ロジックを書くのが不慣れなので、JavaScriptに関しては勉強中です。
デザイン部新卒のマスダさんは、デザインワークにも精を出しつつ、これからAngularの習得も目論んでいるようです。どっちもできるようになったら強いだろうな〜。
担当や仕事が分業しきってない規模の会社だからこそなのかもしれませんね。デザインエンジニアリングを深めるという点では良いのかも。

 

いざFlexboxの小ネタを共有せん

弊社サービスHRogチャートのLPを例にしていきます。

 

モバイル表示時、デスクトップとは異なる順番で要素を並べたい

こちらの図はサービスの特徴について説明する部分なのですが、目線が単調にならないように図を左右交互にレイアウトしています。
PCでの表示ですと、こうなります。

f:id:e-nagata:20180822165353p:plain
モバイルではそれを縦並びに表示させればよかろう...と思っていたところ、2番目の段落では図が先にきてしまいました...ヌーン。

f:id:e-nagata:20180822184114p:plain


それはそうなんですけど、順番が変わることについて考えていませんでした。モバイル表示の際には説明文が先に来るように入れ替えたい。

 

そこで登場するのがflexのorderプロパティです。こちらはflexがかかってるアイテムのレイアウトを、数字で順序づけた順に並べることができます。数字が小さい方が先にきます。
ついでに、Flex-directionプロパティを変更すると、並ぶ方向も自在に変えることができます。

参考:

Flex アイテムの順序を設定する - CSS: カスケーディングスタイルシート | MDN


ここでは特徴のテキストを記載している部分のクラス名を.feature、画像部分のクラス名を.feature__imageとして、
その二つを包むdivのクラス名を.feature__wrapperとしました。

.feature__wrapper{
  display:flex;
  flex-direction: column;
}

.feature{
  @media (max-width: 479px){
    order:1;
  }
}

.feature__image {
  @media (max-width: 479px){
    order: 2;
  }
}

すると、こう!

f:id:e-nagata:20180822184133p:plain

思い通りに並べることができました。



要素を縦並びに、かつ折り返すように並べたい

次はこちらです。

f:id:e-nagata:20180822161748p:plain


この中身をアイウエオ順で、縦並びに、かつリストアップされるアイテムが追加されても減っても影響のないように並べたい。

例えば、媒体名を表示している白い背景部分を.medias__detailとして、そこにflex-directionとflex-wrapプロパティを指定してあげます。

.medias__detail{
    display: flex;
    flex-direction: column;
    flex-wrap: wrap;
    height: auto;
    max-height: 280px;
}

flex-directionは子要素の並ぶ方向や始点を決めるプロパティで、
・row(横並び、HTMLの記載順に左から右へ)
・column(縦並び、HTMLの記載順に上から下へ)
・row-reverse(横並び、HTMLの記載順に右から左へ)
・column-reverse(縦並び、HTMLの記載順に下から上へ)
の4つの値から1つを設定できます。
※言語によっては左→右へ読むのがデフォルトではなく、右から左へ読む場合もありますので、アラビア語などでは方向が逆になります。

flex-wrapはflexのアイテムを単一ラインに押し込むか、あるいは複数ラインに折り返してもよいかを指定します。

flex-wrap - CSS: カスケーディングスタイルシート | MDN

 

今回はflex-direction:column;で縦並びにし、

flex-wrap: wrap;で.medias__detailのmax-heightを越えると勝手に次の列へ折り返すように指定しました。

これでどの部分に媒体名が増えたとしても、元からあった要素が後ろに押し出されていくだけなので修正や編集が楽ですね。

 

 

以上、Flexboxのtipsでした!

 

コーディングは調べるたびに小さな知識が増えるので面白いですね。

単語や調べたいことの適切な表現を知らないといけないのが難しいですが...日々日々ぐぐり力も増してってます!

ではまた!