仕事のプロジェクトで “Japan Kokura Stripe” という Web コンテンツのアートディレクション / デザイン / フロントエンド周りを担当しました。

北九州に伝わる「小倉織」という古くからの織物があり、残念なことに昭和の初期にその伝統は一時途絶えてしまったのですが、染織家である築城 則子さんの手により現在は「縞縞 SHIMA-SHIMA」のブランド名の下、現代的なセンスも取り入れ新時代の小倉織として見事に復活を遂げています。

その縞縞さんのクリエイティブ パートナーを務めている HULS Inc. さんからお誘いいただき、縞縞さんの縞デザインをより広く認知させる目的で Web らしい表現でコンテンツに落とし込むことができないかと考える機会をいただいたのが発端でした。また、縞縞さんが今月開かれるミラーノ・サローネへ出展されるため、その会場で見ていただく展示物のひとつとしての意味合いも含んでおります。

今回の技術面でのスコープは SVG / CSS3 / Webfonts / Device Motion / 縦書き で、さほど技術的な目新しさはないものの SVG をここまで扱ったのは自分にとって初めての経験でしたし、実現にあたりその他にも細々とノウハウなども溜まったので書いておくことにしました。

縞デザインと遷移エフェクト

縞デザインをどうやって Web らしく見せるか悩んだ結果、あえて写真は使わず縞のデザインをグラフィック的に解釈し、繰り返しパターンとして見せるシンプルな落としどころとなりました。写真を使わないというのはかなりチャレンジングですが、縞のデザインそのものにフィーチャーするという点をクライアント様にご納得いただけたことが大きいのではないかと思います。

そして、生地のデザインを切り替えて見せる際にただフェードイン・アウトさせるだけでなく、せっかくなら少し動きが欲しいよねというところで検討したのが今回の動きで、織物を織る際の糸の動きにインスパイアされたものです。実際に小倉織を織り上げる工程がこのような動きをすることはありませんが、小倉織の特徴である「縦縞」が徐々に出揃って模様が浮かびあがる様子を少しでも表現に取り入れたかった。

で、これをやるのに利用を検討したのが canvas / SVG / CSS3 だったわけですが、生地の縞デザインが「パターン」の繰り返しであることを踏まえつつ、

• canvas: 速いだろうし表現力も高いが、一定パターンの繰り返し描画の仕組み自体から自分で実装する手間がかかる。レスポンシブ以前に、ウィンドウサイズが変わった時の描画の再計算の仕組み作りも面倒なことになりそう。そして個人的に苦手意識。
• SVG: 調べてみたら柔軟に繰り返しパターンの定義ができる、よっしゃ。CSSとの親和性が高くアクセスできるプロパティも多い、よっしゃ。工数も他2つより手軽、よっしゃ。ただ、canvas と比べると遅くなるのかも。
• CSS3: 背景画像の扱いはお手のもの。ただ、背景画像を動かしてアニメーションを実現させることを考えると工数がおぞましいことになりそうだし動作の負荷が高そうでまともな動作速度を得られるかが不安。また、背景画像ではなく <div> で構成することも考えたが前述する SVG のようなパターン定義の仕組みはなく、それならば CSS 単独で実装するメリットがない。

上記の理由から SVG が最善と結論づけた。canvas の速度と表現力には最後まで迷いましたが、縞縞のブランドやテキスタイル デザインの持つ雰囲気や佇まいにド派手な演出はそぐわないため SVG でいけると判断したわけです。

実装の基本デザインを検討する

さあ SVG でやるぞと決め、バックエンドも含めた構成は次のようにすることを考えた。

[sc-figure src="https://flat.onotakehiko.com/wp/wp-content/uploads/2016/04/160413_1.png" bgcolor="#D2D2D2"][/sc-figure]

生地の名称・説明文・サムネイル画像・アイキャッチおよび OG 画像など各生地に付随するデータのうち、縞デザイン以外のデータを管理する CMS として WordPress を利用しました。管理画面構築の手間がかからないほか、各生地のページをテンプレート化できた方がやはり便利ですし、簡単な修正ならお客さんでも対応できるメリットが大きかったからです。

一方、生地のデザインデータも可能なら WordPress で一元管理したかったのですが Advance Custom Fields（ACF） の環境下では管理画面が混沌としすぎるほか ACF の構造上、データの読み出しにコストがかかりすぎるという判断で、デザインデータについては独自で生のテーブル (= Textile Table) を利用するのみとした。生地データの追加は基本こちらで請け負う前提なので CMS は特に入れないことにしました。

また図中には書きませんでしたが、SVG を都度生成したり API を毎回呼ぶ必要はないのでキャッシュの仕組みも入れてバックエンドの負荷を軽くする工夫も施しています。

CSS からアクセシブルな SVG の属性にはブラウザ間相違がある

大枠の実装デザインが固まったのでここから SVG の実装に入っていく。縞縞さんからは Web コンテンツに掲載する実際の生地のサンプルをご提供いただいたので、それを元にして

1. 生地を一枚ずつスキャンする。
2. スキャンした生地を元に Photoshop のシェイプツールを使って描き起こす。色調整はスポイトツールで機械的に拾うほか、一定のホワイトバランスの照明の下、目視で確認しつつ調整した。
3. Photoshop から CSS として書き出し。
4. CSS を SVG の描画に必要な値のみ残して整形。
5. 上図の “Textile Table” に示す DB のテーブルにインポートするため、CSS を CSV データに変換する。この作業は手作業では面倒なほかミスを起こす可能性が高いので変換用のプログラムを書いて行った。
6. CMS として仕込んだ WordPress から SVG を出力するテンプレートや、Ajax アクセス用の API を作成。

というプロセスを経て画面上に描画できた画像がこちら。

See the Pen Indigo Rondo by Takehiko Ono (@onopko) on CodePen.

See the Pen Indigo Rondo (with CSS) by Takehiko Ono (@onopko) on CodePen.

さて。ここで上下同じ画像が見えているという人が使っているブラウザは Safari か Chrome の WebKit ブラウザでしょう。そして下の方は見えないという人は Edge / IE11 / Firefox のいずれかその他のブラウザだと思います。両者の違いは明確で、上の SVG 画像はパターンの各要素に関連する x, y, width, height の値を XML 属性として定義しているのに対し、下の SVG 画像は CSS で定義してます。

最初自分は下の方法で進めていて WebKit 以外でまともに表示されないことに気づき、これは地雷を踏んでしまったかもしれないやはり canvas でやっておけば... と絶望を味わったのですが、これは WebKit が優秀すぎるというか余計な実装をしているからであって、他のブラウザが悪いというわけではありませんでした。

W3C の SVG styling の項目を見ると、CSS からアクセス可能なプロパティがちゃんと定義されているんですね。その中には x, y, width, height どれもありません。ソースとスタイリングを厳密に分けることができないのは残念ですが、アクセシブルでないプロパティについては XML 中で定義してあげる必要があります。

---

Velocity.js is Justice

現在表示している生地から次の生地へデザインをトランシジョンさせるには、まず次の生地のデザインを構成する各縞のデータを API から読み込み、Velocity.js を用いてアニメーションさせました。この時、毎回同じアニメーションとならないよう各縞の動き始めの時間をコントロールして順序をランダマイズしています。

[cc lang="javascript" escaped="true" line_numbers="off" noborder="1"] $('#stripe1').velocity({ translateZ: 0, x : 100, width : 5, fillRed : 128, fillGreen : 32, fillBlue : 64 }, { duration : 300, delay : 100 }); [/cc]

のような形で各縞にアニメーション効果を当てていきます。x や width は SVG の XML 属性であり CSS からアクセシブルではないことを書きましたが、他の CSS プロパティのアニメーションと同列に扱えてしまうところが Velocity.js の強力なところ。Velocity.js 同様に CSS アニメーション ライブラリとしてそこそこ使われているものとして Transit が挙げられると思いますが、こちらは SVG の XML 属性にはまるで対応していません（CSS のアニメーション ライブラリなのでそこを求めるのが酷というものですが）。

なお “translateZ” の指定は本来実現したい動き上は不要なのですが、指定をしておくとPC・スマートフォンとも CSS アニメーションに強制的にハードウェア アクセラレーションが働きますので動きが高速になるほか CPU の負荷も下げられます。なんでもかんでも指定してしまうとブラウザの使用メモリが増大するほか描画のバグが出てしまうデメリットもあるようなのですが、滑らかな動きが欲しい時には必須と言えます。

Forcefeeding

概ね大満足な Velocity.js なんですが、時たまどうも不思議な挙動をして困る。アニメーションをさせたい要素に対し、CSS 内であらかじめ別のアニメーションが定義されている時などに起こりがちです。

期待されるアニメーションを確実に実行するには、[] を用いてアニメーションを開始する時の初期値も合わせて指定するのが無難です。アニメーションを強制するという意味合いで Forcefeeding と呼んでいるようです。

[cc lang="javascript" escaped="true" line_numbers="off" noborder="1"] $('#stripe1').velocity({ translateZ: 0, translateX: [目標値, 初期値] }, { duration : 300 } ); [/cc]

なお要素の現在の translate の値を得るのは vender prefix の影響もあり実は結構厄介なので、関数化しておくと便利でした。

[cc lang="javascript" escaped="true" line_numbers="off" noborder="1"] function getTranslates ($_obj) { var transformMatrix = $_obj.css("-webkit-transform") || $_obj.css("-moz-transform") || $_obj.css("-ms-transform") || $_obj.css("-o-transform") || $_obj.css("transform"); var matrix = transformMatrix.replace(/[^0-9\-.,]/g, '').split(','); var x = matrix[12] || matrix[4]; // translateX var y = matrix[13] || matrix[5]; // translateY transformMatrix = matrix = void 0; return [x, y]; }; var translates = getTranslates($('#id')); var translateX = translates[0]; var translateY = translates[1]; [/cc]

---

画像のブレンドをしたいなら canvas

生成した SVG に生地の質感を与えるため、当初はテクスチャ画像を SVG Filter を用い全体に「乗算」する形でブレンドしたのですが、これでアニメーションを行うと CPU 負荷が跳ね上がりコマ送り状態の非常に厳しい処理結果となりました。

動かす要素がベクターであっても、そこに画像をブレンドした瞬間に内部的にはラスタライズしているのと同じとなり、アニメーションの毎フレームごとに全体を画像としてレンダリングする形となるようです。今回はテクスチャを SVG 全域にわたってかぶせる必要がありましたし、また SVG の表示領域も大きかったことから「使える」動作速度にはなりませんでした。

モダンブラウザでの繰り返し実行によるアニメーションの実装には、setTimeout / setInterbal ではなく requestAnimationFrame を使え。と言われて久しいですが、少なくとも setTimeout を使う機会は定期的な処理の実行時ではなく、複数の処理を並列で実行する場合に一部の処理をあえて遅らせて負荷分散を図る「遅延実行」時に多くはないでしょうか。

また setTimeout は指定された遅延のタイミングで何が何でも渡された処理を実行しようとするのに対し、requestAnimationFrame はウィンドウがアクティブではない時には FPS を落とすなど柔軟性を持っています。そのため、requestAnimationFrame で処理を実行中に setTimeout で別の処理を実行すると、ユーザーの行動によっては両者の実行タイミングの辻褄が合わなくなることも考えられます。

そこで setTimeout が実現する機能を、モダンブラウザが持つ requestAnimationFrame と performance.now で代替する jQuery プラグインを書いた。

使い方は setTimeout とほぼ同じで

などとしてもらえば OK で、一度セットしたタイマーを途中でキャンセルしたければ clearAnimationFrameTimeout してください。一応レガシーブラウザ向けの polyfill も実装していますが確認はしてません。ｷﾘｯ

富士フイルムの “X-T10” というミッド レンジ クラスのミラーレス カメラと、“FUJINON XF35mmF1.4 R” という銘玉単焦点レンズを買った。その話はまた今度として。何か撮影してみたいなあと思ったら、その日はちょうど空気のキリッと澄んだ冬の晴れ日だったこともあり、以前から気になっていた川崎の臨海工業地帯のプラント群を観にドライブがてら出かけてきた。

川崎の臨海地域は、北九州・室蘭・四日市に並ぶ関東の一大工業地帯だ。夜中には照明が点灯し、複雑に金属の絡みあうプラント群の造形が暗闇の中に浮かび上がる。その光は「ライトアップ」という訪れた人たちを楽しませるためのものではなく、狙いのない実用的な機能のためのものと言えるだろう。だが、研ぎ澄まされた機能は確かに美しい。

浮島エリア

千鳥町エリア

思っていたよりも見所が多く撮影にどれだけ時間を割くかにもよるが、1・2時間では数箇所回るのが限度だろう。今回は東側エリアばかりになってしまったので、冬の間に水江町や扇町エリアなど西側も掘り下げていきたい。馴染みのない業種なので普段はあまり足を踏み入れることがない地域であるし、ましてや夜ともなるとなかなか訪れる機会もない。車もないと不便な場所なので、大人だからこそできる社会見学として楽しい。

Chrome の最新バージョン (ver.48.0.2564.103) で、特定のサイトのページ読み込みが愕然とするほど重くなる現象が発生した。重くなるどころかほぼブラウザがフリーズしたかのごとく、通常であれば体感的に5秒も待てば読み込みが完了するようなページが、同期・非同期の読み込みに関わらず猛烈に遅くなり読み込み完了に2〜3分近く待たされる。ちなみに Windows 版にはなく Mac 版にのみ発生する症状。

問題のページを Developer Tools を起動した状態でロードし、ネットワーク ペインを確認したところ画像・JavaScript・Web Font など数多くのファイルの読み込みで “pending” 状態が長く続いてしまう。ブラウザとサーバー間のリクエスト処理に何らかの問題が発生しているらしい。

初めは Chrome 内部の問題（バグ）としてアップデートまでの辛抱と匙を投げかけたが、そうもいかないので。

1. 画像や WebFont を一旦サーバーから削除して読み込み確認。
   → 改善なし
2. HTML ソースから外部ファイルの読み込みを行う記述を1つ1つ削除しながら検証。
   → 特定の CSS ファイルを読み込み対象から外すと現象が治る事を確認
3. 展開した状態で14,000行あまりになる該当の CSS ファイルの記述から、あやしそう（勘）な記述を削除してみては検証を繰り返す。

という涙ぐましいローラー作戦の元、ついに原因を突き止めた。いやぁ、BGM でアルマゲドン鳴ったね。ﾄﾞｳｫﾅｸﾛｰｽﾏｲｱｰｲｽﾞだったね、おれやった。

というわけでまさか（IEでなくて）Chrome が？という非常に珍しいと思われるバグに苛まれたわけですが、この無益な時間を他の人も味わう必要はないので以下解答です。

CSS に text-rendering: optimizeLegibility や font-feature-settings: 'kern' など、フォント レンダリングに関して「合字」や「カーニング」の指定を行うと問題の現象が起こります。

Chrome と特定のフォントとの相性が原因という可能性もありますが、Web Font を削除しても治らなかったため Mac 内のデバイスフォントが起因する問題かもしれません。また、CSS のフォントのレンダリングに関する設定がネットワーク リクエストに問題を引き起こす理由もただただ謎。私のタイム リソースを返してください。

Mac 内のフォント管理にながらく FontExplorer X Pro を使ってきたが、あらゆる面で機能を凌駕する “RightFont” というフォント マネージャが登場していたので閃光の様に乗り換えた。トライアルのダウンロードができないところがやや心配だったものの、ウェブサイトからしてしっかりしている感が伝わったので Team License で購入してもらった。

結果、購入して本当に良かったと思える。太陽系に住んでいる全ての Mac ユーザーが使えばいい。それはまあ言い過ぎだとしても、ウェブなり DTP なりデザイン業で大量のフォントを扱われている方には導入をおすすめせざるを得ない。

Sync! Sync! Sync!

RightFont はライブラリをフォルダで管理する仕組みとなっており Dropbox と Google Drive 内へのライブラリ設置をサポートしています。つまり複数の Mac 間でのフォントの同期が可能になります。

フォントファイルそのものは Dropbox 等を使えば、同じく単一フォルダでのライブラリ管理をする FontExplorer でも可能ではありました。しかし FontExplorer は別の Mac から同期されライブラリフォルダ内に新しく加わったフォントを認識することができず、インストール作業はそれぞれの Mac でしてあげる必要がありました。そうしなければ、新しくフォントファイルが加わったところでシステムが認識をしていないのでインストールされていない状況と変わりません。せっかくフォントファイルが同期しても、「今どのフォントがシステムに存在するか」については同期することが出来ないところが FontExplorer の残念なところでした。

RightFont が特筆すべきなのは、あらかじめ “Live List” （後述）と呼ぶ専用フォルダを作っておけば、その中に新たなフォントファイルが追加された時に、それを「検知」し即座にフォントとして利用可能な状態にセットアップしてくれる点にあります。この Live List を Dropbox 内に設置すれば自宅と事務所にある2台以上の Mac でフォントファイルがスムーズに同期され、夜中に自宅の Mac にインストールしたフォントが翌朝事務所に到着すれば直ぐに使える状態になっているという利便性が生まれます。

Team! Team! Team!

もしかするとラップトップの Mac を使っており自宅と事務所で常に持ち運びをしているという人もいるかもしれません。僕もそうなのですが、フリーランサーの方々なんて特にそうかも知れませんね。すると個人で持っている Mac は一台しかないので一見同期に関してはメリットがないように思えてしまうのですがそれは違います。

ポイントは、Dropbox や Google Drive の「共有」機能にあります。ご存知のようにこうしたサービスでは設定を行うことでアカウント間でファイルの同期が可能です。つまり RightFont の Live List フォルダに共有設定をかければ別のアカウントのユーザーとフォントの同期が可能になることになります。

RightFont は複数の Live List を作成することが可能なので、プロジェクト用の Live List フォルダを作成し共有すれば、プロジェクトごとに扱うフォントをチームで共有・同期をすることが可能ということになります。Dropbox を使ったフォントサーバーが実現できるわけですね。これは非常に熱い。

やさしさライセンスとフォントライセンス

というわけで RightFont を使えば複数 Mac 間やチーム内での強力なフォント同期・共有の環境構築ができるようになるわけですが。一応釘を刺しておくと、フォントにはライセンスがあります。そしてそれはとても大切なものです。そもそも複数の Mac やユーザー間で共有を行うことができるかについてはライセンスの確認を怠らないようにしましょう。やさしさライセンスを持っているデザイナーさんたちはきっとフォントにもやさしいはず。

List と Live List

RightFont には “List” と “Live List” という管理の仕組みがあり名称が似ているので混乱しがちですがそれぞれ性格が異なります。

List

まず “List” に関しては iTunes でいう音楽のプレイリストのようなものを想像してもらえるとわかりやすいでしょう。RightFont で管理しているフォントを、例えばあるプロジェクトで使用しているフォントのみを集めたリストに分類するとか、「ガーリー」など独自の視点でフォントを分類することが可能です。

同じフォントを2つ以上のリストに登録している場合、あるリストからフォントを削除しても別のリストからそのフォントが削除されることはありません。

Live List

一方、“Live List” は作成しようとすると外部のフォルダの指定を求められます。この Live List を作ると、以降 RightFont はそのフォルダを監視し、フォントファイルが設置されると即座にライブラリに取り込みシステムで使えるように設定してくれます。逆にフォントファイルが取り除かれれば RightFont の管理下から外されます。リストというより別個のライブラリとしての性格が強いですね。

Live List に含まれるフォントは List にも登録することが可能ですが、もし Live List からフォントを削除した場合にはライブラリからフォントが削除されることと同意ですので、それを登録していた List からもフォントの登録が解除されることを覚えておいたほうが良いです。

前述した Dropbox による複数 Mac 間やチームでの同期はまさにこの機能を使うことになるわけです。

超高速かつシンプルなインターフェース

OS X デフォルトの Font Book に比べ超高速で動作するのがウリで、30,000個のフォントのロードに0.9秒かからない。

...らしいのですが、そんなベンチマーク的な要素はよくわからないので置いておくとして。体感としてめっちゃ速いです。フォントの検索はキーを押すたびに検索結果の更新されるインクリメンタル サーチなのですが、鬼のように速い。そして、全フォントがそのフォント自身でプレビューされるのですがその生成やスクロールもストレスを感じさせません。日本語フォントがややもたつく程度です。自分の Mac は MacBook Air 11" (Mid 2013) で今となってはさほど高速なマシンではありませんが、充分な速度で動作しています。

文字タイプ・ウェイト・幅によるフィルタリングと Font Family によるグルーピング

セリフ・サンセリフ・スクリプトという基本構造の違いによる絞り込みのほか、ウェイトや文字幅による絞り込みも可能で、こちらについても当然インクリメンタルに結果を表示してくれます。

また各フォントをウェイト別に個別にリストに表示させることも、Font Family としてグルーピングして1件のみ表示させることも可能です。またこの表示は ⌘ + G キーで即座に切り替えることができる。

日本語フォントにおける不自由さ

基本的にはベタ褒めしたい RightFont なのですが、日本語フォントの扱いについてはやや不満が。まずインクリメンタル検索は「和名」での検索に対応していません。

例えば「ヒラギノ角ゴシック」フォントを検索したいときには通常 “ヒラギノ” などと入力して検索をかけると思いますが、RightFont では英文名に含まれる “hiragino” と入力しなければヒットしません。また、上述した文字タイプ・ウェイト・幅によるフィルタリングも日本語フォントのデータにそのメタ情報が含まれていない（？）ために機能しない。

これらについては少々不満の残るところですが、和名を知っていればなんとなく英文名も想像がつくのでなんとかなる点ではあります。でも正直なところ和名検索くらいには対応して欲しいところですね。

自動アクティベート

PSD等のデザインデータを開く際、システムにはインストールされているが有効化（アクティベート）されていないフォントを RightFont が自動検出しアクティベートするか尋ねてくれます。そして編集を終えファイルを閉じる際にはまた無効化（ディアクティベート）してくれます。

大量のフォントを常にアクティベートした状態にすると各アプリケーションのフォントリストが非常に長く閲覧しにくい状態になるほか、システムにも相応の負担をかけるため動作が緩慢になる原因にもなります。使用頻度があまり多くないフォントはディアクティベートしておきたいところですが、上記のようなシチュエーションで面倒なのでこの機能はとてもありがたい。

アイコンフォントとの蜜月関係

各種 SNS のアイコンや、メニュー・ボタン等のインターフェースなどで FontAwesome 等のいわゆる「アイコンフォント」を利用する機会が非常に増えています。ですがこのアイコンフォント、検索が非常に困難です。

アイコンフォントは基本的に文字に対しアイコンを割り当てているので、どのキーを押したらどのアイコンが表示されるかの想像がつかず使いたいアイコンをすぐに呼び出すことのできない点が大きな効率ロスを招きます。また、FontAwesome には無いがもしかしたら Material Icons や Entypo+ にはあるかもしれない。そうしたアイコンフォント別のアイコンの有無もまた調べにくくて困りものです。

しかし私は今日、神を目撃しました。

RightFont にはアイコンフォント専用の検索ペインがあります。「Facebook」のアイコンを見つけたければただ “facebook” と打ちましょう。すると、FontAwesome をはじめ9つのアイコンフォントの中から該当するアイコンを横断ピックアップして検索結果に表示してくれるのです。

しかも検索結果のアイコンは Photoshop 等へドラッグ & ドロップが可能になっており、「ベクターオブジェクト」として取り込むことが可能です。どうですか。こみ上げてくるニヤニヤとした薄ら笑いを抑えきれますか。

たとえこの機能だけであったとしても、僕は RightFont を購入していたことでしょう。しかも今後新しいアイコンフォントが追加される前提の仕様となっています。

というわけで、最近ではめずらしい震えのくるアプリケーションとしてご紹介しました。アプリを起動したところ普通に1週間のフリートライアル期間が設けられているのでお試し可能なはずなのですが、サイト上にはトライアルのダウンロード ボタンが無く購入ボタンだけですので意向を汲んで URL は伏せておきます。2015年が終わろうとしていますが、個人的に今年のベスト・オブ・ベストなアプリとなりました。メリークリスマス。

やばい、肩こりが。

この仕事に限らずデスクワーカーは肩や腰、目や首などに多かれ少なかれ凝りや痛みを感じている人が多いのではないでしょうか。自分の場合肩が酷いらしく、酷い割にはあまり痛みなどは感じていなかったのですが、ある日髪を切りにヘアサロンへ行ったら、カット後のマッサージ サービスで触れられた瞬間、スタイリストに（え...）と凍りつかれた。「おのさん、、なんか鉄板みたいなんですけど。」なにが？「いや、だから、肩があるはずの場所に鉄板があるみたいなんですけど...。」と。

曰く、それまでも結構凝ってるなーと内心思い続けてきたのだが、その時は想像以上でびっくりして声が出てしまったらしい。いやまあ自分でも凝ってるなーとは思ってましたけど。そう言われるとなんだかやばい気がして整体とかも行ったは行ったのだけど、あれって単発で行く程度ではその場しのぎになってあんまり解決にならんのですよね。

じゃあどうしようかな、と思って行き着いた先が自分でも極端だとは思いますが、以前から気になっていたスタンド ワーキングを取り入れることでした。もう読んだままですが、「立って仕事をする」ただそれだけのことです。スタンド ワーキングは欧米でトレンドになりつつあるようですが、得られるメリットや効能については以下の記事を参考にしていただければ。

• 日本のIKEAでも発売？スタンディングデスクの効果についての考察
• “立ったまま”のデスクワークが実は効率が良いらしい - NAVER まとめ
• 【美容と健康の為に】オフィスで立って仕事をする「スタンディングデスク」が大ブーム | ニュース・話題のことならキャリアパーク
• 【ＳＴＯＰ！メタボリックシンドローム】オフィスで「立ち仕事」…腹囲減少、生活習慣病予防に効果（1/3ページ） - 産経ニュース

無印良品の「組み合わせて使える木製収納」が有能

とはいえ、立って仕事をするとなるとそれまで使っていたデスクは使い物にならなくなる。デスク・オン・デスクな形も考えてみたけれど、27インチの Thunderbolt ディスプレイを支えるとなると相応のしっかりしたものが必要になるし、その前にとりあえずダサい。そういうわけで「スタンディング デスク」と呼ばれるスタンド ワーキング用の机を探してみると、なるほど結構な種類が出回り始めてる。その中から自分の食指が動いたのが “Refold” だったわけなんですが。

うん、ええ感じ。なのだけれど BUY NOW してしまう寸前で、ダンボールに 250ドル... ない、ないないっ。と我に返った。で、自宅に何か代替物がないかなと見回してみると、あるじゃないですか。数年前に買った無印良品の「組み合わせて使える木製収納」のハイタイプ本棚が。

試しに棚板を何枚か外して高さを調整したら、横幅・奥行きともディスプレイとキーボードやトラックパッドを並べてまあ使えなくはないなという状態で見事に収まった。細かいことを言うと、ディスプレイの電源や入力ケーブルなどの引き回しで棚板の隅に「穴」を開けなければならなかったのですが、あまり見えない部分だしノコギリで必要なだけ切り落として仕上げた。へたなことをしても後から追加でパーツを買って現状復帰したり違う目的への転用が利く、無印良品の「組み合わせて使える木製収納」や「スタッキング シェルフ」はひじょうに有能。

そんな感じでスタンディング デスク代わりに使い始めましたが、副次的な効果としてディスプレイが棚の奥まった位置にいくので横からの光の影響を受けにくくなり、ディスプレイ自体の光量をこれまでより落としても問題なくなった。目に優しそう。

さよならアーロンチェア

この仕事はとにかく座っている時間が長い。そういう仕事の仕方が良いかは別として、繁忙期には睡眠と食事の時以外ほとんどデスクで過ごすこともある。なので身体のために「いい椅子（といいベッド）を買うことに出し惜しみをするな」という不特定多数の先人からの教えもあって、7年前に奮発してハーマンミラーのアーロンチェアしかもフル装備を15万円ほど出して買った。当時引っ越しと重なって飛ぶようにお金がなくなっていたので財政的に非常にきつかったし無駄に大きいし重いが、ただ座り心地だけは本当に良かったし、この椅子に座って、元を取るにはあまりある分は稼いだので良かったと思う。

それが突然、主人の浅はかかもしれない思い立ちによって座られない椅子に役ばらいされてしまった。そうなるとこれまで使っていたデスクとともに場所を取るだけの代物なのでだいぶ迷うところはあったがリサイクルショップに買い取ってもらうことで処分した。

7年も使って2万5千円だったので少し得はした気分なのだけど、売ったそばから若干の後悔に襲われていることは言うまでもない。

2週間経った

自分の場合、週の2日ほどは代々木の事務所に通っているので実質週3日スタンド ワーキングという状態で、とりあえず2週間が経った。この2週間は立ち続けるのが苦痛でしかなかったけれど、だんだん慣れてきた自分がいる。今のところ、

• デスクに向かっている間、SNSの閲覧など余計なことをあまりせず集中しやすくなった。はよ座って休憩したい（苦笑）と思うので、今やっている作業（をとっとと終わらせての1ブレイク）へのモチベーションが上がった。

  スタンド ワーキングを続けると立つ苦痛はなくなってくるそうなので、その時にまた何か変化が起こるのかもしれない。

• 肩や首の凝りが軽減されたほか、腰痛については全く起こらなくなった。代わりに、足の裏・ふくらはぎ・腿と、下半身に筋肉痛が起きたのには驚いた。普段からランニングなどで多少は動いているつもりでいたけれど、そもそも走るのと立つのとでは使う部位が異なるのかもしれない。自分の場合には今は足裏の痛みが一番厳しいので、部屋履きでニューバランスあたりのソールのクッション性が高いスニーカーが欲しいかも。

  スタンド ワーキングの場合続ければ多くの人に体型に良い方向の変化が起こるらしいので半年後を楽しみに続けてみようと思う。

• 食後の14時前後、胃に血流が集中して途方もない睡魔に襲われて何も出来ないことが多くなっていたが、スタンド ワーキングにしてからはそれがだいぶ軽減された。どうしても眠い場合には15分ほど横になって寝てから戻ると、立つことの相乗効果もあって驚くほど頭がすっきりすることに気づいた。

• デスクから少し離れた場所にある物や資料を取りに行くのが億劫でなくなり、後回しにせず直ぐに取りに行けるようになった。

• デスクとアーロンチェアを置いていたスペースが空いて部屋が広くなった。

• デザインの構成やプログラムのロジックに煮詰まったとき、体をストレッチして心地よい刺激を与えつつ気分転換できるようになった。デスクで悶々と考え続けるよりも、ちょっと散歩に出てみたらすんなりと解決策が出てきたというような経験ってあると思いますが、それと似た効果が出ないか期待。

• あまり立ちながら物を食べる習慣がないからか、お菓子など間食が減った。

という感じです。デスクと椅子を処分して引くに引けない状況に追い込まれたこともありますが、やってみると意外にも続けられそうな気がする。ただ、あまり長時間立ち続けるのもまた良くないし繁忙期の徹夜仕事にはさすがに耐えられそうにないので、疲れたけれどデスクを離れられない時のために古家具屋にバースツールでも物色してこようかと思ってます。気にいる物があればええなあ。

10年前に完成して以来、一度は見学したいなと思い続けていた「首都圏外郭放水路」にようやく訪れることが出来た。

首都圏外郭放水路は埼玉県春日部市にある、中小河川から溢れた水を取り入れる流入施設です。地下で貯水したり江戸川へと放水を行うことで周辺地域を水害から守る施設で、それそのものが一級河川の指定をされている。中でも「調圧水槽」はこの施設を象徴する構造物となっておりその様子から「地下神殿」と呼ばれることもある。

湛水時以外は予約を行えば見学をすることが可能ですが穴場の観光スポットとしての人気が高く、応募して当選して初めて予約が可能となっており、見学できる時間も1時間限定となかなかハードルが高い。ところが、11月14日の土曜日に年に一度（？）開催されるという「特別見学会」というイベントがあることを知ったので早起きして行ってきた。開催時間内にさえ行けば予約無しで、しかも時間の制限も特に無く好きなだけ滞在でき、普段は見学することの出来ないエリアまでオープンにするというまさに特別な日。

庄和排水機場

目指すは調圧水槽の出入り口が存在する春日部の庄和排水機場。10時からの開場より少し早い9時半頃に周辺に来られたが、特別見学会開催時に限り会場に駐車スペースは無いとのことで近くの庄和総合公園の駐車場（無料）に停めさせてもらい、徒歩で向かった。同じ目的と思われる人たちの列が出来かけていたのでそれに従って歩き、迷うことなく15分程度で到着。

会場には既に多くの人が詰め掛けており、列に並んで待たされることになった。10時から開場の予定だったところ人が溢れそうになったため20分早く開場をしたらしいが、自分が行ったタイミングでは列が庄和排水機場の建物をぐるっと一周取り囲み、結局40分近く待たされることになった。自分が見学を終えた時には最後尾がどこにあるのか分からないほどの大盛況で、少なくとも2時間半〜3時間待ちというアナウンスで、イベントの開催時間自体は15時までだったが待ち時間の都合で13時以降に並んだ人は入場が出来なかったそうです。開場時刻に合わせて向かうのがおすすめ。

入り口は「えっ、これですか」というほどあっさりしており地下に巨大空間が広がっているとは思えないが、ドアをくぐって一歩入るとすぐにそれに相応しい螺旋階段が待ち構えていた。段数にして116段。皆はやる気持ちを抑えつつ地下18mの世界へと降りていく。階段を下りきった先、コンクリートの低いゲートを抜けるとそれはあった。

調圧水槽

圧倒的という言葉が相応しい。

長さ177m × 幅78m。調圧水槽のちょうど真上にはサッカーのフルコートが広がっているが、それを大きく上回る空間に59本もの巨大なコンクリート柱が林立し、その1本あたりの大きさは幅2m × 奥行き7m × 高さ18mで重量は500トンにもなる。

その様相はバルセロナのサグラダ・ファミリア内部を想起させる面あり、イスタンブールの地下宮殿を思い出させる面もありましたが、それらをはるかに上回るスケールに遠近感が狂うような感覚を味わいました。

しかしこの巨大な水槽も外郭放水路全体から見ればその一部の空間でしかありません。これよりさらに深い地下50mには全長6.3kmにも及ぶ直径10mのトンネルが存在し、溢れた水を取り込む深さ70mの立坑にはスペースシャトルを発射台ごと収めることができるそうなのですが、これが5本も存在します。

1本目の立抗は調圧水槽に隣接しているため穴の手前まで近づくことができるのですが、マトリックスのザイオンさながらの迫力が感じられた。外郭放水路全体を流れる水量を考えると途方もない。ロボット、怪獣、なんでも収められそうな秘密基地みたいな巨大な空間はですね、男子にとって正義です。

Impeller

通常時の見学会では見られない施設として、Impeller（インペラ） が公開されていた。調圧水槽に計4台が設置されており、これで溜まった水を巻き上げ江戸川へと放水する。視界の範囲内に収まるものが見られて若干落ち着くが、これでも大人7〜8人が肩を組んで円陣を組んだ程度の大きさはある。この Impeller は航空機用のガスタービンを改造したモーターで回され、一台で毎秒50立方メートルの水を巻き上げるそうな。凄いですね（棒）。

というわけで、巨大建造物に胸が踊る方には社会科見学として本当におすすめ。特別見学会に参加すれば、予約や時間の制限なく見学することが可能ですが、その一方で係員の方の説明はあまりじっくり聞くことは出来ず、また撮影目的の場合には人物が映らない写真の撮影等は極めて困難です。特別見学会はかなりの混雑を見越してはいましたが、内部が巨大なこともあり渋谷の交差点ほどの混雑は感じずに割と落ち着いて見ることが可能でした。

ちなみに長い階段の上り下りや一部内部に滑りやすい場所があるという安全上の配慮から、階段の上り下りが困難な年配の方や、小学生未満のお子さんは見学不可となっています。また、中学生以下の場合には保護者の同伴が必要なことから大人の社会科見学に向いてそうな代物と言えます。

OS X El Capitan へアップデートしたところ、互換性に概ね問題はない印象ですがそれでも古いバージョンのソフトウェアにはぽろぽろと不具合が見つかった。その中でも大きめなのが Adobe Fireworks CS6 が起動しないまたは起動しても即ダウンしてしまうという件。

デザインの制作環境は概ね Photoshop と Sketch に移行しつつあるので大打撃ということはないのですが、過去案件で作業が発生した場合に困るので対応した。

レガシーソフトウェア用の Java 6 ランタイムをインストールする

レガシーソフトウェア用の最新の、というよく分からない言い回しになってしまうのですが、Apple が公式に古いソフトウェア用の Java 6 ランタイムの最新版を提供しています。Fireworks の動作にはこれが必須ですのでダウンロードしてインストールしてあげる必要があります。

アプリケーションのフォント キャッシュをクリアする

OS X Yosemite 以前のフォント キャッシュが溜まっている状況だと、Fireworks の起動に問題が生じる模様。Adobe 公式サイトにある方法でフォント キャッシュを再構築することで一旦初期化されるそうですので試してみてください。

フォントキャッシュを再構築する方法

なお、フォントの管理に FontExplorer X Pro を使っている場合にはメニューバーから Tools - Clean Application Font Caches を選択することで フォント キャッシュを削除可能です。

念のため同じ Tools メニューにある Clean System Font Caches も実行して OS X 自体のフォント キャシュの初期化とシステム再起動をしても良いかもしれません。

以上行った上で Fireworks を起動したところ自分の環境では問題なく動作するようになった。ただし一部ではフォント キャッシュだけが問題でなく、インストールされている（アクティベートされている）フォントによっても引き起こされるという報告もあるので、フォント キャッシュのみが原因とは断定しきれない。

FYI:

• 【メモ】Macを「OS X El Capitan‎」にしたら「Fireworks CS6」が動かなくなった件 | mutter
• 【解決】Macを「OS X El Capitan‎」にしたら「Fireworks CS6」が動かなくなった件 → フォントだった | mutter
• MacOS X「El Capitan」でFireworksCS6を起動させる方法 | こくまろトレンディ

ちなみに、Apple が Java 6 ランタイムをサポートするのは El Capitan で最後となる模様。ということで Fireworks には完全な死刑宣告が下されました。メインのデザイン環境が移った今でも、Fireworks は非常に優秀で深遠で敬愛すべきソフトウェアだと思っているので、マクロメディアから買収後ろくなケアもせずただディスコンに追いやった Adobe にはひたすら残念な感情が湧き上がるばかりですが、これも時代の流れなので仕方がないですね。

個人的には操作性・快適性・描画の観点から Photoshop でデザイン作業するのはできる限り避けたいと思っているので、Sketch の次期バージョンにはものっそ期待せざるを得ない。

タイトルそのままの内容ですが WordPress で問い合わせフォームを作る際かなり使われているだろう Contact Form 7 に、リアルタイムなバリデーション チェックを加える jQuery Validation Engine、チェックボックス・ラジオボタンをカスタムデザインに差し替える iCheck プラグインを併用した場合に、それぞれが元々持つ実装時の独特なクセが相まってかなりややこしいことになったので次回迷わないようにメモしておく。

Validation Engine の attach 先

これは Validation Engine 単体の注意点だが、Validation Engine を起動する際の validationEngine('attach') メソッドは form 要素に対して行わなければならない。

ドキュメントに “the plugin can only be instanciated on form elements” って書いてあるので当たり前なのだが、どの親要素でも大丈夫だろうという勝手な思い込みで form 要素以外に attach してしまい、うまく動作せず無駄に時間を費やすことになった。忙しい時ほどドキュメントはよく読みましょうの典型例。

バリデーション チェックは Validation Engine に一任する

Contact Form 7 にも Ajax で行うそこそこ機能的なバリデーション チェックの仕組みが備わっていますが、Validation Engine も使うのであれば、バリデーション チェックは Validation Engine に一任し、Contact Form 7 側の機能は一切使わない。使ってもいいけどただ複雑になるだけなのでおすすめできません。

• フィールドが入力必須か
• メールアドレス・URL・電話番号のフォーマットが正しいか
• 数値が指定範囲に収まっているか

Contact Form 7 で可能なこうしたバリデーション チェックは Validation Engine でも行えますし、より柔軟に対応が可能です。

ただし。Contact Form 7 のバリデーション時のエラーメッセージは WordPress の管理画面から変更が可能なのですが、この方法を採るとそれが意味をなさなくなることはデメリットとなるかもしれません。

フィールドへの data 属性追加は JavaScript で行う

Contact Form 7 は独自のショートコードによってフォームの各フィールドを定義する仕様になっています。例えば <input type="text" name="your-name" class="required"> というソースのテキストフィールドを作成する際には

と入力する必要があり、ドキュメントに従えば class や placeholder など出力されるソースの多少のコントロールは可能になっています。一方 Validation Engine ではテキストフィードのバリデーション チェックのコントロールをしようと思うと

といった具合に、行いたい処理によって class だけでなく data 属性も付加する必要があります。

Contact Form 7 と Validation Engine を組み合わせることを考えると、Contact Form 7 のショートコードから Validation Engine が必要とするソースコードを出力させなければなりませんが、Contact Form 7 にはそもそも data 属性を自由に付加するためのオプションがありません。

なので先ず Contact Form 7 で最低限のソースを出力してから、JavaScript で Validation Engine 用の data 属性を動的に加え、その後 Validation Engine を起動するという方法を使う。

バリデーション チェックの内容を Contact Form 7 (WordPress) と JavaScript に分ける形となり一箇所にまとめられないところが非常にややこしいのですがプラグイン自体を改変するという禁じ手を使わないのであればこうする以外にありません。

iCheck 利用時に必要なこと

iCheck を使うことにより、チェックボックスやラジオボタンのデフォルトの UI デザインをオリジナルのものにカスタマイズ可能です。が、iCheck を起動するとそのままでは Validation Engine のリアルタイムなバリデーション チェックが動作しなくなってしまいます。これは iCheck がチェックボックスやラジオボタンの本来のヒット領域を完全に隠してしまい独自のUI・イベントに差し替えてしまうことに起因します。

iCheck によってカスタム化されたチェックボックスやラジオボタンで Validation Engine を利用するには

という具合に iCheck の “ifChanged” イベントに Validation Engine をキックする処理をバインドしてあげれば OK です。

iCheck ラジオボタンと Validation Engine の相性問題

また iCheck のラジオボタンに Validation Engine を適用する際にはさらに注意が必要。同じラジオボタンのグループで現在選択している選択肢から別の選択肢に変更しようとクリックした際に、Validation Engine が一瞬「選択してください」とエラーメッセージを表示させてしまいます。一瞬のことで、別の選択肢のラジオボタンが checked 状態に変わった後はすぐにエラーメッセージは消えてしまうのですが、視覚的にはとても気になる。

どうやら iCheck の内部処理で【現在の選択肢 checked: FALSE】→【クリックした選択肢 checked: TRUE】と状態を変化させる際に一瞬「未選択」の状態が出来るらしく、その一瞬に Validation Engine が反応をしてしまうようです。結論として以下の様にして同じグループのラジオボタンが選択されているかどうか判別式を挿入することで回避可能でした。

Validation Engine と iCheck の起動順序

この点についてはこの限りではないかも知れませんが、正常な動作が確認できた順序として

1. Contact Form 7 にフィールドを定義
2. Contact Form 7 が出力したフィールドに対し、Validation Engine で行いたいチェックに必要な class や data 属性を JavaScript で動的に付加
3. $('form').validationEngine('attach') で Validation Engine を起動
4. チェックボックス・ラジオボタンに対し iCheck を実行し、デザインのカスタム化を行う
5. iCheck のチェックボックス・ラジオボタンの “ifChanged” イベントに $('form').validationEngine('validate') をバインド

とすることで良さそうです。

デジタルエージェンシー FICC inc. 様のコーポレートサイトのデザインおよび実装を担当させていただきました。

デザインは様々なデバイスでの閲覧を考慮したレスポンシブ仕様とし、ページ読み込み時の負荷と表示演出のバランス・タイミングに配慮したフロントエンド実装の工夫をしました。また、CMS には全面的に WordPress を採用し独自のカスタマイズを加えつつも、コンテンツの編集はもちろん、将来的な機能拡張の自由度を残した設計を実現しています。