1-4no diary

自作キーボード, CSS, その他好きなことなど

Helix の OLED に RGB_MODE を表示する

Helix ユーザーの僕ですが、会社ではステンレス版、自宅では通常版を使用しています。
そして、どちらもバックライト仕様のものを作成しました。
やはり光ると綺麗ですし、折角はんだ付けしたのであれば光らせないともったいないですよね。

ただ、デフォルトの設定では、左の OKED に Mac or Window と Layer の表示がされていますが、バックライトのモードがわかりません。
特にモードは同じで速さが変わるものは、「このモードになってから◯回目」というように判断するしかありませんでした。

そこで、OLED に今のパターンを表示したいと思いました。

いろいろ試した結果、とりあえず下記のようになりました。(反射してしまうためカバーを外しています)
※この後更に修正し改良しています。最後に少し記述しています。

LED_MODE14 と表示されています。 これを表示させるための手順をまとめていきます。

その前に注意点です。 僕は C言語は専門外で全く書いたことがありません。
普段は、Java, RubyRailsを本当に少し)、Javascript, html, css などを書いています。
そのため、なんとなくは読めてもメソッドなどはさっぱりなので、既存コードを真似てなんとかなっただけです。

手順

書き換えるのは、 keymap.c です。
キーマップを変更するときに書き換えるファイルです。

この中に render_status というメソッドが定義された箇所があります。

qmk_firmware/keymap.c at master · qmk/qmk_firmware · GitHub

ここを見ると、Layer を表示している箇所があることがわかると思います。
matrix_write_P とか matrix_write を使えばいいようです。 これを真似ていきます。

RGB_MODE はちょっとコードを追ってみると、 rgblight_config.mode のようです。 これを表示すればよさそうだとわかりました。

ただ、これはそのままだとダメのようです。
型変換が必要なようです。
とりあえず下記を真似てみました。

qmk_firmware/keymap.c at master · qmk/qmk_firmware · GitHub

char rgblight[40];
snprintf(rgblight,sizeof(rgblight), "LED_MODE%d", rgblight_config.mode);

そしてこれを matrix_write(matrix, rgblight); と書いてあげれば表示されます。
これによって LED_MODE14 と表示されます。MODE を切り替えると 14 の部分が変更されていきます。

参考になるかわかりませんが、最終的にできあがったものが下記になります。
GitHub のリンク貼るほどでもないので該当部分だけそのまま貼っておきます。参考にしてみてください。
OLED 表示スペースの都合で、既存の表示部分を省略したりしています。

// Define layers here, Have not worked out how to have text displayed for each layer. Copy down the number you see and add a case for it below
  char buf[40];
  char rgblight[40];
  snprintf(buf,sizeof(buf), "Undef-%ld", layer_state);
  snprintf(rgblight,sizeof(rgblight), "LED_MODE%d", rgblight_config.mode);

  matrix_write_P(matrix, PSTR("\n"));
  matrix_write(matrix, rgblight);

  matrix_write_P(matrix, PSTR(" "));
  switch (layer_state) {
      case L_BASE:
          matrix_write_P(matrix, PSTR("Default"));
          break;
      case L_RAISE:
          matrix_write_P(matrix, PSTR("Raise"));
          break;
      case L_LOWER:
          matrix_write_P(matrix, PSTR("Lower"));
          break;
      case L_ADJUST:
      case L_ADJUST_TRI:
          matrix_write_P(matrix, PSTR("Adjust"));
          break;
      default:
          matrix_write(matrix, buf);
  }

もう少し頑張ってみたらこんな感じにもできました。 ロゴを行毎に挿入する必要があるので、2回に分けてロゴをいれればいけます。 AppleWindows のロゴは2行に分かれているようです。 そのため、各行の先頭で読み込む形になります。

全ての親要素の padding を無視して横いっぱいに要素を広げる方法

CSSを書いていて、親要素からはみ出して表示したくなるときってありませんか?

ページを作成する上で、左右の padding を一括で設定してしまいたいですよ。
しかし、特定の要素だけそれを突き抜けて背景色が付いている…という状況です。
具体的には下記のような状態です。
(わかりやすいように左右に border を引いています)

f:id:hotate0:20191117215751p:plain

しかし、 padding を一括で設定してしまうと下記のような状態になってしまいます。

f:id:hotate0:20191116142332p:plain

padding を指定したまま、横いっぱいに要素を広げる方法を紹介していきます。

対応方法

1. 設定した padding の値を左右のネガティブマージンに指定する

これで解決できればこれでいいと思います。
この値を sass の変数として管理しておけば、変更にも強くなります。
#{} を使用して、マイナスにしてあげればいいです。

2. vw と calc を使ってネガティブマージンを指定する

対象の要素が複数の要素の下にあり、それぞれの要素に padding の指定がある場合、1 の方法では対応できません。
必要な値を計算すればいいのですが、面倒ですし、変更にも弱く、現実的とはいえません。

そんな時に便利なのが、 vw を使った指定です。
横いっぱいに広げたい要素に下記の指定をするだけです。

margin-left: calc(((100vw - 100%) / 2) * -1);
margin-right: calc(((100vw - 100%) / 2) * -1);

これの仕組みを簡単に説明しようと思います。

(100vw - 100%)

横いっぱい(100vw)から、対象の要素の値(100%)を引きます。
この計算結果は、左右の余白(padding)となります。 しかし、これだけでは左右の合計値です。

((100vw - 100%) / 2 * -1)

2で割ることで、片方の値にします。
そこにさらに -1 をかけることでネガティブマージンの値ができあがります。

原理自体は 1 の方法と同じです。
画面端からの距離を自動で計算してくれるようになっています。
1 の方法を使わず常にこちらを使用してもいいかと思います。

使い分け

1 の方法は単純に親要素を無視するとき、2 の方法は画面いっぱいにしたいとき、という形にはなるかと思います。

キーキャップが購入できる海外のサイト一覧

以前海外でキーキャップを購入する際の住所入力について書きました。
今回はキーキャップが購入できる海外サイトをまとめていこうと思います。

keycap とかでググると見つかるかと思いますが、一覧としてまとめられている方がいいだろうと思い、まとめてみました。

キーキャップが購入できる海外サイト

KPrepublic Global

KBDfans – KBDfans Mechanical Keyboards Store

NovelKeys, LLC

Mechanical Keyboards and Awesome Stuff Worth Buying — Kono Store

CandyKeys Online Store | Mechanical Keyboards, Keycaps & Components | Candykeys

MechSupply — Home

https://pimpmykeyboard.com/

基本的にトップページのリンクになるので、ページ内の keycap のうなリンクから遷移してください。

また、個人的に特にここがおすすめ、というのはありません。 気に入ったキーキャップがあったサイトで購入すればよいかと思います。

そして、購入時の住所入力で困ったらこちらを…。 1-4nomiya.hatenablog.com

ステンレス版 Helix をキースイッチ変更可能なホットスワップ対応にした話

前回自作キーボードを作成してからかなり時間が空いてしまいましたが、久しぶりに作成しました。
以前も作成した Helix です。

yushakobo.jp

いろいろなキーボードを試した結果、ここに戻ってきました。
しかし、以前作成した Helix はロープロファイルで作成したので、キースイッチやキーキャップの選択肢があまりありませんでした。
また、ステンレス版の販売も再開していたので、ならばこれを買って新しいものを作成しようと決めました。

ホットスワップに関しては、前回 ErgoDash を作ったときに得た知見も材料もあったのでこれを使用しました。

1-4nomiya.hatenablog.com

ただ、前回購入していた、ベリリウム胴のソケットコネクタが少しだけ足りませんでした。
前回購入したものはこれです。

www.digikey.jp

遊舎工房さんの通販で取り扱いが始まっていたので、今回はこちらを購入することにしました。

Mill-Max ソケット | 遊舎工房

※後述しますがステンレス版 Helix で使用する際は注意が必要です

実際に作成してみる

前回作成しているので、はんだ付けなどは特に問題なく完了しました。
しかし、途中あることに気がつきます。

キースイッチの穴が空いているステンレスプレート版はに、付属の絶縁用シールを貼るのを忘れていまいた…。
貼る場所は、キースイッチの穴が空いているプレートの裏側のようです。
ホットスワップ対応していたので、助かりましたがしていなかったと思うとぞっとします。
キースイッチ全てをシュッ太郎するのは辛すぎます。
一度作ったことがるからと調整にのったのが原因ですが、ステンレス版を作成するときは、作成手順に注意してください。
上から、キーキャップ、キースイッチ、プレート、絶縁シール、基盤、プレート、という順番になります。

あと、シールを剥がすのが地味に大変でした。
端の方が切れてしまい、シールが無い箇所も一部できてしまいましたが、特に問題なさそうです。

ソケットコネクタに関する注意

ある意味今回一番重要なことかもしれません。 今回遊舎工房さんで追加購入したものだと、底面のプレートにくっついてしまい、通電状態?になり常にキーが押されている状態になってしまいました。

少しわかりにくいかもしれませんが、右側の方が少し長いため、底面に接してしまっています。
ステンレス版の Helix で使用する場合は、注意した方がよさそうです。
f:id:hotate0:20190720153604j:plain

以前購入していた絶縁テープがあったので該当箇所に貼ることで問題は解消されました。

使ってみた感想

とりあえずどっしりしています。
これで殴られたら絶対にやばいってくらいしっかりしています。
正直持ち運びには全く向きませんが、持ち運び用途がないのであれば、アクリル板より安定感があって好きです。

f:id:hotate0:20190720153500j:plain

f:id:hotate0:20190720153506j:plain

f:id:hotate0:20190720153512j:plain

透過するキーキャップもっていなかったので、白系をつけてみましたが、一気に LED が目立たなくなります。 まぁこれくらいの主張でちょうどいいのかもしれません?

今後

とりあえずキーボード作成は、自分の中で答えがでたかなと思います。 会社では今回作成したステンレス Helix、自宅ではアクリル Helix を使おうと思います。

そして、これまでお世話になってきた各種自作キーボードをどうするかが悩ましい。 会社で、自作キーボードに興味あるけど…って人に貸し出したりもしている。 また、 Helix の後に ErgoDash を作成した際、これからはこれだと思ったものの、気分転換で Helix を使ったらやっぱりこれからはこれだ、って感じで心変わりしたのでまた心変わりする可能性もある。 ただ、正直結構な金額かかっているし、設計者の方に申し訳ないと思いつつもメルカリとかで売ってしまいたいという考えも無くはない…。 悩ましい。

あとは、qmk_firmware を修正してもっといい感じにしたいです。 TAPPING_TERM, PERMISSIVE_HOLD を設定して、レイヤーキーにかなキーとか設定したりしているけど、delete の長押しなどによる削除や、アローキー長押しによるカーソル移動などに問題が発生しまっているので…。 5文字くらいの削除が一番面倒なことになっています。特定のキーだけ TAPPING_TERM を変更したりできるのかな? という感じで全然わかっていないので、この辺りの知識をつけていきたいです。

Mac側の設定のせいでした…

CSS設計でボタンのコンポーネント対応って実は難しいのでは?と思ったらそもそもに問題があるかも

CSS設計やコンポーネント化を考える上で、ボタンというのはよく例にあげられます。
しかし、パターンが多いと、コンポーネント化がとても難しいです。

ボタンのパターン

ボタンのよくあるパターンを考えてみます。
(ここからはBEMを使用していることを前提に進めていきます)

色違い

これは特に問題ありません。
下記の用になるかと思います。
hover 処理を mixin にしています。

.btn {
  // 共通ルールは省略

  @mixin set_btn_color($background_color, $amount: 7) {
    background-color: $background-color;
    transition-duration: 0.3s;

    &:hover {
      transition-duration: 0.3s;
      background-color: darken($background-color, $amount);
    }
  }

  &--primary {
    @include set_btn_color(#f00);
  }
  &--secondary {
    @include set_btn_color(#0f0);
  }
}

サイズ違い

問題となるのはここです。
サイズを指定する方法が複数存在しているためです。
それぞれの方法について確認していきます。

width, height が固定されている

一番シンプルなパターンです。
完全にサイズが固定化されているというものです。
small, medium, large くらいのパターンで終わるのあればいいのですが、
クラス名にサイズが入ってくるようになればそれはちょっと設計的に失敗したといえるでしょう。
また、テキストが長くなるとボタンの中に収まらなくなることもあるので、汎用性はないといえます。

.btn {
  // 共通ルールは省略

  &--small {
    width: 〇〇px;
    height: 〇〇px;
  }
  &--medium {
    width: 〇〇px;
    height: 〇〇px;
  }
  &--large {
    width: 〇〇px;
    height: 〇〇px;
  }

  // ここからははやりすぎ
  &--w300h80 {
    width: 300px;
    height: 80px;
  }
  &--w300h100 {
    width: 300px;
    height: 100px;
  }
}
padding, min-width, min-height を指定

これはよくあるのではないでしょうか?
サイズ固定と違い中の文言によってサイズが変わっていきます。
そのため、テキストが収まらないということはなくなりますが、サイズを完全に統一することはできなくなります。

.btn {
  // 共通ルールは省略

  &--small {
    min-width: 〇〇px;
    min-height: 〇〇px;
    padding: 〇〇px;
  }
  &--medium {
    min-width: 〇〇px;
    min-height: 〇〇px;
    padding: 〇〇px;
  }
  &--large {
    min-width: 〇〇px;
    min-height: 〇〇px;
    padding: 〇〇px;
  }
}
指定なし

ボタン自体にはサイズを持たせないというパターンです。
ボタンコンポーネントを使用する場合は、ボタンを入れる要素(親要素)でサイズを指定したり、別途クラスを付与(マルチクラス)で対応する必要があります。
汎用性はとてもありますが、単体ではサイズの指定ができないので、サイズという Modifier を持っていないだけともいえます。

.btn {
  // 共通ルールは省略

  width: 100%;
  height: 100%;
}

displayには何を指定するか?

これも悩みます。
中に入る文字列を中央寄せにしようとすると、inline-block, flex あたりにしたくなります。
1行限定であれば、block でも line-height = height にすれば可能ですが…。

ボタンのコンポーネントって難しくない?

見出しや、カード的なコンポーネント作成する方がよっぽど楽じゃん…。

と思いました。

デザインを確認しても、このサイズ指定が入り乱れていることもあると思います。

「このボタンはテキスト折り返しているのでサイズ固定?」
「このボタンは2文字だけど結構大きめだからサイズ固定?」
「このボタンはテキストによってサイズ変わっていそうだから padding で実装する?」

というように、わけがわからなくなります。

「padding実装で可変でお願いね」と言われてもそこから、最小サイズやパターンを見つけるのは結構大変です。

全ての要望を満たすボタンを作る

結局、可変も固定も混在していることが判明したとします。

それを受けて、下記のようなことを考えながらボタンクラスを作ってみるとします。

  • サイズは、固定、可変に対応できるようにそれぞれのクラスを用意する
  • サイズ + (可変 / 固定)クラスの組み合わせでいい感じになるようする

できました。

.btn {
  $block: &;

  // 共通ルールを記入
  ... 省略

  // サイズの指定
  &--small {
      padding: 3px 5px;
      font-size: 1.2rem;
      border-radius: 3px;

    &#{$block}--fix {
      min-width: 60px;
      min-height: 40px;
    }
    &#{$block}--variable {
      width: 60px;
      height: 40px;
    }

  }
  &--medium {}
  &--large {}

  // 色の指定
  ... 省略
}

こんな感じでしょうか? では、size: small + fix, color: primary のボタンを表示してみましょう。

<button class="btn btn--small btn--fix btn--primary">test</button>

1つのボタンを生成するのに、必要なクラス多くない?

これでも問題ないということであれば、それでもいいと思います。
人によっては、固定ボタンと可変ボタンを別々にしたくなる人もいるのではないでしょうか?
そうすれば、必要なクラスは1つ減ります。(クラス名長くなったので文字数はそんなに変わらず…)
ただ、sassの方は工夫しましょう。
共通部分を重複させると、後々管理が面倒になるので、可能な限り mixin で共通化しましょう。
結局は、クラスを減らすための負荷が sass 側に寄るということです。
とはいえ、関連を切りたいということであれば、共通化しない方がいいです。
一緒に変わるべきか、ということを考えて対応しましょう。

<button class="fixBtn fixBtn--small fixBtn--primary">test</button>

あとは、頻発するパターンは、別名のクラスを用意してしまい、その中で必要なクラスを読み込むこともできます。
ただ、組み合わせパターンから生成したものと、それに気が付かず組み合わせで対応してしまうということも発生してしまします。
そうなると、結局別物ということになってしまうので、使い所が難しい対応方法ではあります。

まとめ

この状態でなにをまとめられるのか…という感じですボタンのコンポーネントって難しくない?というのがまとめです。
結局、パターンが多すぎるということが根本原因だと思います。

サイズに関しては、思い切って決まったパターン以外は管理しないというのもありかなとは思っています。
決まったパターン以外は、その場でサイズ指定をしてもらうという方法です。

基本パターンと例外パターンをわけることでこの対応はできるので、どうしようもないときは試してみてはいかがでしょうか?

既存サービスにCSS設計(コンポーネント管理)を導入する方法

1からサービスを開発するときなら、1からCSS設計を行うことができますが、自社サービスの開発だとなかなかそんな状況には出くわしません。
既存サービスのぐちゃぐちゃなCSSに対して、開発をしていくことになります。
しかし、少しずつでもCSS設計を導入していきたいという場面があるかと思います。
既存CSSの依存を完全に断ち切れればいいのですが、そうはいかかないのではないでしょうか?
そんなとき、どのように設計(コンポーネント管理)を行うべきか、ということについてまとめていきます。

コンポーネント管理は可能な限り大きな単位で行いたい

この考え方の元進めてきます。
なるべく大きな単位で行っていた方が、いろいろなところで使用することができます。

よくある、一覧と詳細という単位で考えてみます。

一覧でAというコンポーネントを作ったとします。
一覧で何回か同じ見た目がでてくるので、これをコンポーネントAとしました。
そのため、list.component のようなディレクトリを作成し、この中に、_A.scss をおきました。
そして、 list 下に index.scss を作成して、この中で _A.scss を import しました。

今度は、詳細を考えていきます。

先ほどとは別の人が開発したとします。
そしてこのひとは詳細という中で、コンポーネント管理を行うことにしました。
そのため、detail.component のようなディレクトリを作成し、この中に、_B.scss をおきました。
そして、 detail 下に index.scss を作成して、この中で _B.scss を import しました。

結果以下のような構成になりました。

sass/
 ├ detail/
 │ ├ component
 │ │ └ _B.scss
 │ └ index.scss
 │
 ├ list/
 │ ├ component
 │ │ └ _A.scss
 │ └ index.scss

でもこのまま進むと、 detail と list は別々のまま進んでいきます。
もし detail で _A.scss を使用したくなったらどうしましょうか?

コンポーネントの呼び出し

そのまま detail.scss で _A.scss を import する。

この対応はどうでしょうか?
Sass的にも可能な方法です。でもこれはちょっと気持ちが悪くないでしょうか?
特に、_A.scss からしてみれば、list 以下のコンポーネントとして作成されているはずなのに、なぜか全然違う箇所から呼び出されています。

僕はこれは絶対にやって欲しくない方法です。混乱しか招きません。

sass 下に common 的なものを作る

下記のような構成に変更します。

sass/
 ├ common/
 │ └ _A.scss
 │
 ├ detail/
 │ ├ component
 │ │ └ _B.scss
 │ └ index.scss
 │
 ├ list/
 │ ├ component
 │ │ └ 移動
 │ └ index.scss

この後はいろいろな対応ができます。

 1. 必要なコンポーネントを各自で import する

毎回 import を追加したりしないといけないので、正直面倒です。
あまりオススメしません。

2. view 側で読み込むcssを増やす

これは common 下でも index.scss を作る必要があります。
common + 各ページ のCSSで1ページを構成することになります。

方針次第かなと思います。別に間違った方法ではないです。
レイアウト用の view ファイルで読み込んでおくというのいいと思います。

3. 各ページで import するためのファイルを用意する

1, 2 の組み合わせといった感じでしょうか。
全ての common を読み込むけど、css は1枚になります。
common 下に 一括 import 用のファイルを用意しておくと便利です。

今回の例では common が sass 直下に用意していますが、階層によってはもっと深いところに common が存在していることもあります。
大きなサービスだと、この状態になることが多いと思います。
そんなときはこの方法がオススメです。
詳細については後述します。

4. コンポーネントの枠を取っ払う

コンポーネントの管理を一括で行うということです。
各ページ単位では component ディレクトリを作成して切り出しません。
こうなっていれば、管理はとても簡単です。
ディレクターやデザイナーを巻き込んで対応した際の究極がここかもしれません。
コンポーネントが出揃えばページを作成する際に、ほとんどCSSを書く必要のないレベルが目指せます。
まぁ現実的にはここまでは厳しいです。


総合的に見て 3 がオススメです。
既存ページにも採用しやすいです。

ディレクトリについて

途中から採用する場合も、徐々に階層を上げていくことで、段階を踏んでリファクタが可能になります。
ただし、クラス名にプレフィックスをつけるなどの対応を取らないと、クラス名が衝突する可能性があるので注意が必要です。

徐々に階層を上げていくことで、最終的にはサイト全体に関わるものとなります。
最初から、わかっていればいいのですが、そういったことはなかなかありません。
なので、他に影響しない可能な限り大きな単位で、コンポーネント管理をしていくこをオススメします。
これが上記で 3 をオススメした理由です。

一番よくあるのは機能単位の開発だと思います。
そういったときは、その機能単位でコンポーネントを意識してCSS設計するだけでも、練習にもなるしスッキリすると思います。

ページ単位の場合、例に上げたような状況に出くわすこともあります。
そんなときは、なるべくいい方法で対応しましょう。
最初に作成した人がCSS設計を心がけていても、その後の対応次第ではぐちゃぐちゃになってしまいます。

まとめ

以上が、既存サービスにCSS設計(コンポーネント管理)を導入する方法になります。
チームで開発をする際は、一人で進めても間違った対応が入ってしまうと結局破綻するので、チームでルールを決めておく必要があります。
コンポーネント化ができないメンバーがいたとしても、設計を破綻させないようにルールだけは守れるようにしておきましょう。
import や view からの読み込みルールだけでも守れれば、破綻に向かうことはかなり軽減されるはずです。

CSS設計(コンポーネント化)を会社やチームとして導入するには

CSS設計を導入する際、エンジニアだけで進めることはとても難しいです。なぜ難しいのか、どうすればいいのか、といったことに対する僕の経験と意見をまとめてみました。

僕はデザイナーではなくエンジニアです。デザインの入門書のようなものはいくつか読んでいるので本当に初歩的なことはわかりますが、デザインを仕事で行うことはありませんし、デザインのアプリケーションの使用もできません。

また、今回はCSS設計そのものではなく、会社やチームでCSS設計を導入し、コンポーネント化を行い、極力CSSを書くことを減らしていくまでに必要なことについて述べていきます。すでにやってみたことについては失敗例にも触れまとめていきます。さらに、今後どうしていくべきなのかということについても、僕の意見を書いていきます。

 

エンジニア側のみでCSS設計を導入する

まず最初にやったのは、エンジニア側のみでCSS設計を導入していくということです。これは、CSS設計についての学習コストもあるので、学習対象者を最小限にするためです。

結論からいうとこれは失敗しました。

いくらエンジニアが設計手法に沿って対応しようとしても、コンポーネント化を意識していないデザインに対して、コンポーネント化するというのは厳しいものとなります。デザイナー側としては、何かルールに沿ってデザインしているのかもしれないですが、それをCSSとして表現しようとしても難しいことが多いです。

 

実装前にコンポーネント化の調整をデザイナーと行う

次に対応したのが、出来上がったデザインを元に、コンポーネント化を試み、ルールがぶれているところを洗い出し、デザイナーさんと調整するということです。

CSSがわかるデザイナーの方であれば、ここの調整はやりやすいと思いますが、そうでない場合はとても厳しいです。

しかし、これを行っても、設計が後付けになるので、大きな成果はあげられません。場合によってはデザインを大きく変更する必要がでてきてしまうこともあるからです。そういったことになっても、デザインを変更するところからやり直すということはあまりないかと思います。結局後付けの設計となるので、気休め程度のコンポーネント化となってしまいます。また、CSSも無理した実装になってしまったり、使いにくいコンポーネントとなってしまいます。

 

デザイナーにもCSS設計の概念を理解してもらう

結局はここに行き着きます。

デザインの段階で、使用するCSS設計の概念を取り入れてもらい、概念に沿ったデザインにしてもらいます。ここでもCSSがかける人とそうではない人では、結構差が出ると思いますが、CSS設計のルールに沿ったデザインになっていれば大きな問題ではありません。

最近 AtomicDesign を採用したという記事を見かけることが増えていますが、AtomicDesign でいう Atom や Molecule といった小さい部分を管理してもらうだけでも大きな効果がでるはずです。FLOCSS でいうなら component だけでも管理してもらえれば、あとは componet という基本ルールを使って、 project を作成していけます。

また、この後に詳しく書いていますが、似たようなページのデザインが不要になり、こだわるページに時間を割くことが可能となります。CSS設計を行うメリットをデザイナーの方にも理解してもらいましょう。

 

ディレクターにCSS設計導入のメリットを理解してもらう

ここまでくると、現場側はCSS設計の恩恵が理解できていることかと思います。しかし、最終的にはディレクターの理解が必要となります。

理解のないディレクターからすれば、似たようなページばかりができあがり、手抜きのように感じる人もいるかもしれません。とはいえ、もっと凝ったデザインのページにしたいというのはわかります。ただ、使い回しというのは工数も削減できますし、バグのリスクも削減できます。

ここで勘違いして欲しくないのは、別に全てのページで作成したコンポーネントを使用する必要はないということです。使用した方がサイトとして統一感がでるとは思うので最低限のものは使用することをおすすめしますが…。

しかし、こだわりたいページは存分にこだわればいいと思います。そうではないページはコンポーネントを使用することで、デザインと開発の時間を短縮し、浮いた時間をこだわるところにあてることができます。

また、速さとこだわりは反比例することを理解してもらいましょう。こだわればその分新規で書くコードが増えるので時間がかかります。当たり前のことですが、ここの理解はとても重要です。

 

最終的には会社用のCSSフレームワークが完成する

ここまでの活動を行っていくと、最終的には会社用のCSSフレームワークが出来上がることになると思います。僕はここまで至ったことがないので、推測にはなってしまいますが…。

正直コンポーネント化とかつまらない と感じるデザイナーの方もいるかもしれません。でも最終的にCSSフレームワークを作り上げることになると思えば、すごいことやったんだと思えるのではないでしょうか?

また、ここまでくればデザイン不要で、サイトの開発が進められることが増えくるはずです。その結果、その空いた時間でもっと別のことができるようになります。

 

まとめ

以上がCSS設計を導入するために必要なことのまとめになります。

今回は触れていませんが、実際にコンポーネントを使用してもらうには、スタイルガイドのようなものがあった方がいいと思います。これも面倒ですが、あるとないとでは大きな差がでます。コンポーネントを認識してもらえないと、別の人が再デザイン、再実装といったことが発生し、意味がなくなってしまいます。

最悪、実際の使用箇所のキャプチャを用意しておくだけでもいいかもしれません。無いよりはましです。CSS更新しても反映されないという問題はありますが…。

また、今回は導入するために必要なことということで、CSS設計そのものには全然触れていませんが、機会があればその辺りについても書いて見ようと思います。ただ、そういった記事はすでに多くあるので、あまり新鮮味がないものになりそうですね。

 

文字だけの記事をここまで読んでいただき、ありがとうございました。