トップ > Webフロント > エンジニアブログに「はてなブログPro」を選んだ理由とリニューアルでのあれこれ

エンジニアブログに「はてなブログPro」を選んだ理由とリニューアルでのあれこれ

Webフロント

f:id:sumzap_engineer_blog:20200723140228p:plain

はじめに

サムザップでフロントエンドエンジニアを担当しています。
当ブログは2020年06月24日にデザインをリニューアルしました。 今回はその経緯や実装面でのお話をしたいと思います。
　
ブログ開設当時は更新体制を整えることを重視し見た目の優先度は下げていたのですが、最近は安定運用してきたこともありエンジニアブログ運営チームから「デザイナーとフロントエンドエンジニアを介入させて綺麗に仕上げたい」と相談を受けました。
（※ブログの立ち上げ時は、ひとりのサーバーエンジニアのみで実装をしています。）
元々普通に見る分にはあまり影響なかったものの、各種レイアウトの調整や「遊び心でアニメーションも加えようか」と演出的にもこだわってみました。
　

ブログの環境

その前にブログの環境に対して説明を。
サムザップのエンジニアブログは「はてなブログPro」のサービスを利用しています。
WordPressなどでの運用も考えたのですが、同ブログはエンジニアの技術系記事作成によく利用されていてテーマとの親和性が高いこともあり採用を決めました。
有料のProでは下記のように運用面でメリットが多く、記事作成に集中できるのも大きいです。
　
・独自ドメインが取得可能
・固定ページが作成可能
・TOPページを記事一覧に変更可能
・広告やキーワードリンクを下げられる
・複数の管理者で運用が可能
・記事のバックアップ（過去50件の履歴を保存）
・スパム対策やSEO周りはお任せでOK
中でも
・AMPに対応
という部分は推しポイントだったりします。
　

AMPとは

https://amp.dev/ja/
Accelerated Mobile Pagesの略で、モバイル端末でWebサイトを高速表示させるための仕組みです。
2016年にリリースされたもので普及率を考えるとまだこれからでしょうか。
WebページをGoogleやTwitter側で予めキャッシュさせることで読込時間を削減しているため、表示速度やデータ量の改善に寄与します。
（とはいえキャッシュ表示しているURLと本来のURLは異なることを認識しておく必要はあります。）
ブログ/ニュースサイト/EC系のように全員が同じ情報を見せるページとは相性が良い一方、SNSのような閲覧する人によって表示されるコンテンツが異なるものにはあまり効果的ではありません。
　
ちなみにサイバーエージェントの「アメーバブログ」でも対応しています。よろしければ下記も参照してみてくださいませ。
https://amp.dev/ja/success-stories/ameba/
　

【実装】レイアウト

f:id:sumzap_engineer_blog:20200715224505p:plain

既にブログはリリース済のため、別アカウントで「はてなブログPro」を契約しdev環境を用意するところから始めています。
公開済の記事に影響あっては元も子もないので、基本構造は変えず spacing / size / color 要素を中心に調整する方向としました。
レイアウトを改修する際「はてなブログPro」設定画面上からではCSSやJavaScriptを直接編集しづらいため、ローカル環境で編集を行ってから設定画面にコードを貼り付けています。DOMをいじれない箇所はCSSで非表示としました。
またリニューアル前はPCとSPで別々のCSSを使用していたため、設定の「レスポンシブデザイン」をONに変更し共通のCSSを使用するよう変更しています。
レスポンシブ仕様については以下の設定です。

・SP：540px以下
・PC：541px以上
・タブレット：PCペースで表示しつつ、viewportのwidthを1600pxに設定し調整

【実装】アニメーション

f:id:sumzap_engineer_blog:20200715224518p:plain ロゴのアニメーションに関してはデザイナーより共有されたAdobe After Effectsのサンプルを何度も見ながらイメージをすり合わせしました。 CSSでドットのアニメーションを設定し、JavaScriptで順番に再生するようにしています。
ドットの配置は2次元配列で設定後、アニメーションを開始する順番も別の配列で設定しました。(※縦12行 横122列で構成)
配列targetsにアクティブなドットの座標を設定し、sort () メソッドで並び替えています。
　
ドット表示の手法としてはCSSのclip-pathプロパティを使用しています。指定したクリッピング領域の外側が非表示となって内側だけが表示されるものです。同等機能でclipプロパティもあるのですが、現在はWeb標準から非推奨となっているため利用を控えました。
全部の文字が表示された後はループによる動きを追加しています。カッコよさとインパクトを両立させるため、ブラウン管のノイズや歪みの表現を得意とするグリッチエフェクトで仕上げました。テレビ番組やプロモーション映像ではよく使われている手法ですが、ここ数年ではWebデザインに採用される場面も増えてきています。
エフェクト部分の画像を中央に配置するため、top: 50%;left: 50%;transform: translate(-50%, -50%);と設定しました。
　

タブレット端末の対応方法

今回制作に辺り検証に手間取ったのはiPad系タブレット端末での表示です。
通常のレスポンシブデザインの作りであれば素直にブレイクポイントを数カ所配置していけばよいのですが、iPadのiOS13系でSafariにて閲覧した場合、デフォルトで「デスクトップ用Webサイトを表示」がオンになっており、このままだと強制的にデスクトップPC表示になってしまう現象がありました。 iOS12までは何も問題がないため見落としやすい部分かもしれません。
（iOS13リリース前にWebサイトを作成した経験のある方は一度チェックしておいた方がよろしいかと思います。）

とはいえ12.9インチはともかく10.5インチでPCサイトをそのまま表示するのは流石に厳しいため、別の方法でiPad判定が必要になります。
結論としては「デスクトップ用Webサイトを表示」がオンの状態ではユーザーエージェントでiPad判定ができないため、タッチイベントで判定するようにしました。
　

class Custom {
  ua = navigator.userAgent
  isAndroid = this.ua.indexOf('Android') !== -1
  isMobile = this.ua.indexOf('Mobile') !== -1
  isIPad = this.ua.indexOf('iPad') !== -1
  isIPhone = this.ua.indexOf('iPhone') !== -1
  isKindle = this.ua.indexOf('Kindle') !== -1
  isSilk = this.ua.indexOf('Silk') !== -1
  isSafari = this.ua.indexOf('Safari') !== -1
  isTouchDevice = typeof document.ontouchstart !== 'undefined'
   
  constructor () {
    this.changeViewport()
    //...
  }
 
  changeViewport () {
    const viewport = document.querySelector('meta[name="viewport"]')
    if ((this.isAndroid && !this.isMobile) || (!this.isAndroid && !this.isIPhone && this.isTouchDevice && this.isSafari) || this.isIPad || this.isKindle || this.isSilk) {
      viewport?.setAttribute('content', 'width=1600')
    }
  }
  //...
}

まとめ

今までAmeba OwndやBloggerなど色んなブログサービスを触ってきましたが、それぞれ得意分野が異なっているのは興味深いです。
無論ゼロからスクラッチで作成するのが一番試行錯誤できて楽しいものの、コンテンツの更新性にフォーカスすると日々の運用コストも意識する必要があります。
技術はあくまで目的を果たす手段であること、用途に応じて最適なサービスを選択しながら無理のない運用を心掛けていければと思います。

参考文献

・CSS Glitch Effect
tympanus.net

・iOS13とiPadOSに備える（フロントエンド）
qiita.com