タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに 今やあらゆるサイトで使用されているハンバーガーメニュー。 私たちウェブサイト系のエンジニアは数え切れないくらい実装してきている定番パーツです。 しかしながらその実装は容易ではありません。自分の作り方に自信を持てていない方も少なくないのではないでしょうか。 ただ単にそれっぽく動くものを作るのであれば簡単ですが、アクセシビリティやメニュー展開時の他の箇所の挙動など、不具合がないように徹底的に作り込もうとするとなかなか難しいものです。 今回はそんな厄介な存在であるハンバーガーメニューについて、私なりの現在の作り方を紹介したいと思います。。 ハンバーガーメニューの実装で気を付けるべきこと ハンバーガーメニューの作り方を見る前に、ハンバーガーメニューのあるべき姿、実装時に気を付けるべきことを洗い出してみましょう。 私が思い浮かぶものだと以下のようなものがあります。 メニューボタン、アコーデ
Webサイト公開前の最終チェック。ベイジでは「ブラウザチェック」と呼んでいます。サイトの規模によって1～4人日とかかる時間はまちまちで、たいてい複数人で分担してチェックすることが多いのですが、実装完了後に一通りチェックを行っています。 このチェックはどちらかというと「最低限これはできてないとダメ」という品質担保の観点から行うものです。ベイジではスプレッドシートにチェック項目をまとめて、案件ごとにシートを用意してチェックが完了したかを項目ごとにステータス管理しています。 この記事では特に重要な項目をピックアップして、どういった内容をチェックしているか解説します。チェック項目は「全体」「ページごと」というふうに二分していて、「全体」はサイトを全体検索かけて一括でチェックが終わるもの（VS Codeの全体検索や、DB内部であればWordPressの管理画面から検索かけたりしている）、「ページごと
『隠れたキーマンを探せ！データが解明した 最新B2B営業法内で紹介されている、BtoBにおける購買関与者の7つの性格分類。「あのお客さんはこのタイプだな」と思い浮かべながら見ると面白い。 https://t.co/pkP22krRTB
文章の各行頭に「。」「、」などの句読点や、「っ」などの小さい文字、「－」「…」などの記号が来ると見栄えが悪いので避けたいですよね。 こうした記号や文字は禁則文字と呼ばれたりもしますが、そんな禁則文字が行頭に来ないようにし、文章の見栄えを整えることを「禁則処理」と呼びます。 今回はCSSを用いて、ウェブサイトでこの禁則処理を施す方法をご紹介します。 3つの対処方針 禁則処理の対処方針としては大きく3つあります。 ぶら下がり 枠外に文字をはみ出させます。 追い込み 文字詰めを行って行内に文章を収めます。 追い出し 禁則文字とその前に来る文字を次の行に送り出します。 ブラウザがデフォルトで対応している禁則処理 ブラウザによって対応状況は異なりますが、勝手に禁則処理をしてくれるブラウザもあります。 ここではベイジでメインターゲットとして扱うChromeを例に挙げてみましょう。 Chromeでは基本
Adobe公式サイトに記載のある通り、Adobe XDは今すぐのサポート終了ではないものの、サポート終了にむけて長期の予告期間となっているようです。新規の開発も終了しているようですね。それに伴い、XDの代わりとしてFigmaを検討されている方もいるかと思います。 弊社ではAdobe XDからFigmaへの移行を約2年前に行いました。そこで、これまでにエンジニアが両方のツールを使用して感じた、Figmaの利点と使いにくい点をご紹介します。 Figmaの利点 ページ機能でのアートボード整理が便利 Adobe XDでは1つのキャンバスですべてのアートボードを管理するような構造になっていました。 Figmaではページ機能があり、これを利用してアートボードをグループ化できます。ワイヤーフレーム、要件定義、デザインカンプなどのプロジェクトを各ページに分類・整理することで、作業が効率的に進むようになりま
今やウェブ制作の現場ではChatGPTが欠かせないツールとなってきている。私自身、業務で積極的に使っており、必要不可欠な存在となった。プログラミング全般にわたるサポートはもちろんのこと、CSSコーディングにおいてもChatGPTを大いに役立てている。今回は、CSSコーディング時にChatGPTをどのように使っているかを紹介したい。 CSSコーディング時の課題 テキスト検索だけでは解決策が見つけにくい ウェブ制作を行う上で、CSSのデザイン調整は日常茶飯事かと思う。ただ、CSSにおいては「テキスト検索だけでは解決策が見つけにくい」と感じたことはないだろうか。 たとえば先日、以下のようなデザイン崩れを発見した。セルの縦列の幅を統一する必要があったが、テキストの長さによって横幅にバラつきが生じていた。 これまでは検証ツールを使ってコードを調査していたがこれでは時間がかかるし、やや面倒。また、検索
採用サイトやBtoBサイトに強みを持つ株式会社ベイジが、11年ぶりに自社採用サイトをStudioで刷新した。 Web制作会社の採用サイトならば、ビジュアルや動きのインパクトがあり、クリエイターの誰もが真似をしたくなるような表現を想像するかもしれない。 しかし、このサイトにあるのは真逆の姿だ。 インパクトのあるビジュアルや動きのあるインターフェイスを排し、ビジュアルもコピーも装飾性を削ぎ落としたシンプルな構成。徹底したユーザー目線で、わかりやすく、使いやすく、ダイレクトに「ベイジ」が表現されている。 なぜあえてこの方向を選んだのか──その背景には、同社代表の枌谷氏によるWebデザインの役割を問い直す視点と、クリエイターに向けた問題提起が見えてくる。 戦略的で実利主義的なアプローチの中に、デザイナーであり経営者である枌谷の「美学」や「思想」が息づいている。その視線の先に描かれるのは、デザインの
結論 結論から話します。サブセット化してウェブサイトにフォント適用するまでに以下の流れが必要です。 Google FontsからはCJKjpはダウンロードできないのでこのGitHubから落とす（設置してくださってる方、本当にありがとうございます🙏）第一水準とか人名漢字とか入れたい文字を定義しておくサブセットフォントメーカーでフォントファイル作成WOFFコンバータでwoff版作成CSSで@font-faceの指定 以降、丁寧に説明してきます。時間ない人は必要なところだけ読んでね。 サブセット化とは？ フォントデータから必要な文字データのみに限定して、オリジナルのフォントデータにまとめなおすことをサブセット化といいます。たとえば「國（国の旧字体）」といった文字はなかなか使わないと思うので、この手の文字一式を削ぎ落としてサブセット化することでフォントデータを軽量化でき、ウェブサイトの読み込み高
コロナ禍において、急速に変化した働き方。副業を始めたり、転職を考えたりした人も多いかと思います。 そんななか、人気の職業のひとつがライターです。株式会社PLAN-Bが運営するウェブメディア「エラベル」が、2021年に11月に実施した「大人のなりたい職業ランキング」調査（※1）では、第1位にライターが挙げられていました。同調査では、「時間や場所に縛られずパソコンひとつで気軽に始められそう」「文章を書くのが好きだから」といった旨のコメントが寄せられています。一方で、いざライターの仕事を始めても、なかなか思うように仕事を進めることができない人も多いのではないでしょうか。 ベイジでも副業が可能で、私を含め3人のライターが副業でも記事制作をしています。私自身はベイジで働く傍ら、副業でもインタビューを中心に毎月7本前後の記事を執筆しています。この記事では、これからライターとして仕事をしてみたい、すでに
はじめに ベイジではウェブアプリのモック実装やJSのフレームワークでフロントエンド実装をすることが多いです。 フレームワークでの案件が徐々に増えていくにつれ、様々なJSフレームワークに合わせてCSSをマークアップすることが大変で、課題となっています。これらを解決するためにTailwind CSSを導入することを検討しました。 結果的にはアプリのフロントエンド実装にはとてもメリットがあり、課題を解決することもできました。Tailwind CSSの具体的な機能と、実際に導入してみての感想をご紹介します。 Tailwind CSSとは Tailwind CSSはユーティリティファーストのCSSフレームワークです。個別にCSSを記述する必要がなく、決められたユーティリティクラスをhtmlに追加するだけでスタイリングが可能です。一般的なCSSの書き方との違いは以下のコードで説明します。 Tailwi
BtoBサイトの種類を分かりやすく4種類に分類し、それぞれの特徴を表にまとめてみました。ちなみにこれ WACUL垣内さんの著書『BtoBマーケティングの定石』の中の話をかなり参考にしています。 https://t.co/oUZiF94YMD
導入 お疲れ様です、ベイジでエンジニアをやっている天野です。 ベイジではWebアプリのビジュアルデザインやフロントエンド実装の案件が増えてきており、エンジニアは日夜設計に頭を悩ませています。今回は、その中で個人的に良いと感じたフロントエンドの設計について共有します。 注意点として、ベイジではモックアップ実装の案件が多く、サーバーサイドとの通信の部分に関しては実装しないことが多いです。よって本記事では、UIなどWebアプリにおけるViewの話が中心となります。 ディレクトリ構成 最初にディレクトリ構成を示すことで、本設計の概要をつかんでもらいます。 src // ルートディレクトリ ├─infrastructure // インフラ層。バックとの通信やデータ管理を担う │ ├─domain // APIのインターフェースの定義など │ ├─interface // データの通信処理 │ └─r
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![「アルゴリズム」が大っ嫌い？ ならRSSを使いなさいよ » p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/0c5257ee2adefe878d86642ccf99314cd9b2a7fc/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2026%2F07%2Fdecentralization-banner.png)
