ここ数年で、「デザインシステム」はウェブ開発やデザインのコミュニティでとても人気の話題になりました。そして「コンポーネント」として定義される一連のデザイン成果物を開発・メンテナンスするために、StyleguidistやStorybookといったツールが多くのプロジェクトで一般的に使われています。このプロセスはデザインシステムという概念の一部として、コンポーネント駆動開発（Component Driven Development）と定義することができるでしょう。 さて、コンポーネント駆動開発にまつわる資料のほとんどは、ReactやVue、Angularといった、フロントエンドのビューのためのメジャーなライブラリを利用することについてのものです。しかしもっとトラディショナルな技術スタックの場合はどうすればいいでしょう？ 例えば私たちスタンダードデザインユニットでは、静的なHTMLとCSSのアセ
1画面1APIと比べるとGraphQLのAPIはどこから作ったらいいか分かりにくい - hitode909の日記
Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。 グラフをたどって開発することになる GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。 このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。 スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係
Vueを用いた開発プロジェクト用に「コンポーネント設計・実装ガイドライン」を作った話 - Qiita
はじめに こんにちは、モチベーションクラウドの開発にフリーのエンジニアとして参画している@HayatoKamonoです。 この記事は、「モチベーションクラウド Advent Calendar 2018」8日目の記事となります。 概要 モチベーションクラウドの開発チームでは2018年10月から改善期間と称して、開発に関するガイドラインやルール作りをはじめとする、様々な改善活動に取り組んでいます。 その改善活動の一環として作成した「コンポーネント設計・実装ガイドライン」を今回は説明を交えながらご紹介して行きたいと思います。 目次 Componentの粒度に関して Container ComponentとPresentational Component コンポーネントの共通化に関して コンポーネント実装時の細かな決め事 CSSに関して まとめ Componentの粒度に関して これまではフロント
自社サービス『ツクリンク』はリリースから7年が経ちました。 直近でAtomic Designをベースにしたデザインシステムの作成と、CSS設計の変更をしたので紹介します📛 CSSの変遷現在の設計の話をする前にこれまでのCSSを紹介。 Ver１ 初回リリース時 昔懐かしいCSSです。Sassも使わずベタ書き。 #main .articles p { } #main .articles .header { }実は今でも一部で生きています。反省してます。探さないでください。 Ver２ リニューアル リニューアルをしたタイミングでCSS設計にはMindBEMdingを採用、SCSSを使い格段に書きやすくなりました。ファイルはBlockごとに分け、クラスの衝突を防いでいました。 # _block.scss .block { &__element { &--modifier {} } } # ディレ
We're tasked with making interfaces for more users in more contexts using more browsers on more devices with more screen sizes and more capabilities than ever before. That's a daunting task indeed. Thankfully, design systems are here to help. Atomic Design details all that goes into creating and maintaining robust design systems, allowing you to roll out higher quality, more consistent UIs faster
Atomic Design ～堅牢で使いやすいUIを効率良く設計する 読了 - くらげだらけ
昨今ではデザイナーの間でも、アプリやサービスに使われる色やテキストなどをまとめた「スタイルガイド」や、デザインコンポーネントをまとめた「パターンライブラリ」、さらにそれらを全てまとめてドキュメント・原則・思想なども含めた「デザインシステム」などを作りながら効率よくより良い体験を提供できるように開発できるようにしようという取り組みがよく見られます。 DropboxやAirbnbなどをはじめとして積極的に自社サービスの「デザインシステム」を公開している企業も多く見られるようになってきました。 それにともなって、自分たちでも作ってみよう・開発現場に取り入れてみようと取り組み始めているという話もよく聞くようになってきましたが、どんな風にどんなところから手を付けて良いか？というのは良く聞く質問です。 「デザインシステム」を考えていくにあたって、設計の手法・考え方の一つにAtomic Designとい
Atomic Design と Figma の組み合わせでデザインが便利になる｜デザインシステムの作り方｜スマートキャンプ デザインブログ
まだ開発中のサービスですが、このBiscuet（ビスケット）のデザインシステムの考え方を紹介していきます。 上記のランディングページ（LP）の作成プロセスも過去に紹介しています。気になる方はあわせてお読みください。 Figma と Atomic Design の採用デザインツールは「Figma」、考え方は「Atomic Design」を採用しました。 Atomic Designをデザインに落とし込む際、コンポーネント単位での管理がしやすいFigmaが便利だと考えました。 Figmaに関する記事には、チュートリアルやテンプレートなどの内容は多く見かけますが、実務での採用・運用を主にした記事は少ないため、スマートキャンプでの例を紹介します。 ※本記事内で紹介する画面キャプチャは開発中のものや、記事用に独自に編集したものも含まれます。 Atomic Design についてAtomic Desig
この記事では、デザインシステムを作成するときの基本ガイドをまとめています。 この記事は3つのパートで構成されています。 デザインシステムを理解する（デザインシステムとは何か、いつ作るべきか？） デザインシステムの作成（作成プロセスとやっておきたい項目） デザインシステムの具体的なサンプル例（デザイナーとデベロッパー、それぞれの観点より） デザインシステム追加の検討事項（その他のコンセプトや参考文献など） *この記事では、Webサイトやアプリ、オンラインサービスなどを表す包括的な用語として、「プロダクト（Product）」という言葉を使用しています。 この記事のコンセプトをイラスト化するために作成した、デザインシステムを公開しています。ご自由にお使いください。 Basic Design System – Figmaファイル デザインシステムを理解しよう デザインシステムとは？ デザインシステ
Website Style Guide Resources GitHub repo Twitter updates Contributors Examples Real life pattern libraries, code standards documents and content style guides. Carbon Design System By IBM Carbon is the design system for IBM Cloud products. It is a series of individual styles, components, and guidelines used for creating unified UI. frontendcodepatternsvoiceandtone Code For America frontendpatterns
Create atomic design systems with Pattern Lab - Pattern Lab
Create atomic design systems with Pattern LabPattern Lab is a frontend workshop environment that helps you build, view, test, and showcase your design system's UI components. Run the following command in your terminal and read the installation guide to get started: npm create pattern-lab
Atomic Designの概念に基づいたJavaScriptフレームワークのコンポーネント設計とは？ - pixiv inside
はじめに こんにちは。はてなブログとエモい話が何よりもすきな17新卒のエンジニアPotato4dです。 ひょんなことからこのpixiv insideに技術的な記事を書く機会に恵まれたので、JavaScript周りの話を書きたいと思います。 概要 モダンなJavaScript環境に慣れ親しんだ方には、「コンポーネント」という単位をベースとしたUIやロジックの開発を行う事は珍しくないかと思います。 しかしながら、その「コンポーネント」という単位の大きさと分割指標については、中々まとまった資料が存在せず、それぞれの開発者や、フレームワークによりけりとなっている印象を受けます。 昨今のフロントエンド開発、特に全てJavaScriptで完結するSPA開発で頭の悩ませる部分としては、状態の管理に次ぐ、大きな課題となっているのではないでしょうか。 今回の記事では、そんなJavaScriptにおける「コン
「コデアル」という求人サービスのデザインシステムを作ってみました。CIリニューアルに伴う全スタイル＆コンポーネントの刷新、エンジニア＆デザイナー間の協業、そして約3ヶ月運用してみた感想をつづってみます。 実際に使っているドキュメント、Sketchファイルはこちら↓ ・Codeal Design Guideline ・Codeal UI Kit.sketch ・Sketch Tips for Codeal Design Guideline Codeal Design Guidelineの中身はこんな感じ。 1. デザインシステムとは組織やサービスの形態によって解釈は分かれると思いますが、私はデザインシステム＝ブランド、設計、開発をつなげるガイドラインだと認識しています（引用：結局デザインシステムは何なのか） スタイルガイドやテンプレートだけではなく、それらをチームでどう活用するかを言語化して
こんにちは。デザイナーのohsです。 Swiftが気軽に学べるサイトまとめ（初級）や（中級編）では、自分で学習できるサービスを紹介してきましたが、私の中で一番効果的だったのが、タイトルにあるペアプロです💡 ただSwiftを学びたいからはじめたというより、チーム開発の効率化という点も期待してはじめました。 ※ペアプロとはペアプログラミングの略で、2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法である。Wikipediaより 📘目次 ・ペアプロにより期待していた効果 ・ペアプロのはじめ方 ・ペアプロしてみてどうだったか ・技術力が身につく以上の効果とは？ペアプロにより期待していた効果ペアプロにより、共通言語で話せたり共通認識の幅が広がる事で、コミュニケーションコストが削減でき、開発効率アップできるのではないか？という期待のもとはじめました。 もちろんSwi
ReactNativeで理解しておくと良いReduxとMiddlewareのフローを理解する - tomoima525's blog
(5/29/2017追記 ‘必要不可欠’ とタイトルに書いていたら'必要不可欠でない'と指摘を受けました。なんらかのデータフローの仕組みは必要だけどReduxである必要はないのでタイトル修正しました) 最近ReactNativeをちょこちょこ書いています。アプリ向けのReactNativeを書くにあたって理解がのぞましいのがデータフローの仕組みであるRedux、及び様々な処理を仲介するMiddlewareです。小さなアプリをつくってみて一通り把握したので、整理も兼ねて初めてReact-Reduxを触れる時にどの辺を見ればよいかまとめてみます。 作ったのはChuckNorris FactsのJokeを検索して表示するアプリです。 github.com デモ動画 昨日のReactNativeアプリ続き。Reduxにローディングのステートも追加してみた。iOSとAndroidでも想定通り動く。
Atomic DesignをVue.jsで実現するための構成と考え方 | Biscuetでの例をもとに - SMARTCAMP Engineer Blog
スマートキャンプのデザイナー/エンジニアのhaguriです。 弊社では8月1日、インサイドセールスに特化したCRM Biscuet（ビスケット） という新サービスをリリースしました。 biscuet.jp Biscuetでは Vue.js + Atomic Design でコンポーネント設計をしています。今回はその構成と考え方・Biscuetチームでの運用について紹介していきます。 Atomic Design について templatesとpagesについて Biscuetでのルール atoms molecules organisms pages ディレクトリ構成 App.vue components/ plugins/biscuet-materials/ さいごに Atomic Design について Atomic Design とは、コンポーネント単位で設計していくデザイン・開発手法で
この記事は何？ DMMさんで「Atomic Design & Design Systems」をお話させて頂いた時に、自分が読んだ記事をまとめたものになります（いちおう全部目は通してる…ハズ）。デザインシステムについて書かれている記事ってまだまだ少ないのですが、情報源自体もまとまってないんですよね。実際、自分が↑の資料を作る時はほぼ手探り状態でした。 この記事がデザインシステムについてこれから学ぼうと思われている方の力に少しでもなれたら幸いです。例によって海外記事は僕の認識違いが起きている可能性があるので、「これそういう記事じゃないから！」というツッコミがあればぜひお願いします。 （追記：記事執筆後も参考資料が増えてきたため、資料作成時に限らず参考にできるものを追加しています） まずデザインシステムについて学びたい時は Design Systems Handbook InVisionが作成し
11月30日のTHE GUILDさまの勉強会にてお話させて頂いた時の資料です。 詳細は https://yory.design/note/theguild-atomicdesign-sketch/
Atomic Designの概念を参考にSketchのシンボルを効率的に管理する方法 | UXデザイン会社Standardのブログ
新年明けましておめでとうございます。 2017年も、未来の豊かさにつながる仕組みをデザインする組織として、STANDARDメンバー一同、常に学び、考え、邁進して参ります。本年もどうぞ、よろしくお願いいたします。 Sketchの連載記事を執筆しました 私事ですが、年末にWPJさんでSketchの連載記事を執筆させて頂きました。 吉竹 遼のSketch入門 for UIデザイナー – WPJ 対象はこれからSketchを触ろうと思っている方や、使っているけどもっと色々使い方を知りたい、という方です。今回はこの連載の中から、周りの反応が上々だったテクニックについて、編集さんに許可を頂き増補バージョンとしてお送りします。 Sketchはバージョン41以降シンボルのオーバーライドが可能になり、ますます効率化が進み使いやすくなりましたが、一方でシンボルを作成する機会も多くなり、管理の手間が増えてきまし
CSS設計におけるコンポーネント粒度について Object Oriented CSS https://www.slideshare.net/stubbornella/object-oriented-css Bootstrap - Components http://getbootstrap.com/components/ BEM https://en.bem.info/ Atomic Design http://atomicdesign.bradfrost.com/ Enduring CSS http://ecss.io/
ビズリーチで「HRMOS（ハーモス）採用管理」のフロントエンドエンジニアをしています、浅井です。 前編では「AngularJSのリプレースにAngularを選んだ話」についてお話しました。 今回は、長期的にサービスを発展させていくことを念頭に置き、アプリケーションの規模もチームメンバーの人数が増えていってもスムーズに開発・メンテナンスしていくために、AngularでWebアプリケーションを再構築していく中で盛り込んだことをご紹介したいと思います。 AngularJS時代の課題 せっかくAngularに移行するからには、「AngularJS時代からの負債は引き継ぎたくない、メンテナンスしやすい仕組みにしておきたい」というのがチームメンバー全員の想いとしてありました。 まずは、AngularJS時代に実装・運用フェーズで感じていた課題を洗い出したところ、 ページ単位で 似たようなUIが別々に
はじめに この記事は、業務でフロントエンドのディレクトリ設計思想を変更した際の作業をまとめた記事です📕 それなりの規模のプロジェクトでの移行作業のため、新規機能実装などに影響が出にくいようにリファクタリングを進めてきました。そこでの進め方や感想も含めてお伝えできればと思います。 前提 6年ほど運用しているReact Nativeのプロジェクトでの移行作業のお話です。 従来のディレクトリ設計思想はAtomic Designを採用していました。しかし、organismsのコンポーネントが300個近くにも及び、プロジェクトの規模が大きくなるにつれて様々な課題が浮き彫りになりました。これを機に設計思想の移行を決めました。 Layer型のAtomic DesignからFeature型のディレクトリ構造に移行していこうと思います😌 参考: ソフトウェアアーキテクチャの基礎 なぜ移行したか なぜ移行
ここ１年ほど実務でVue.jsを利用してWebアプリケーションを開発しています。 今回はVue.jsを使ってチームあるいは個人で開発を始める上で予め考慮しておくと良さそうな事をいくつか書きたいと思います。 コンポーネントルール Vue.jsは単一ファイルコンポーネントによって、とてもシンプルな記述でコンポーネントを作る事ができます。しかし、開発者同士でコンポーネントの認識を揃えておかないと同じようなコンポーネントが作られてしまい、保守性を低下させる要因になってしまいます。 そのため、昨今ではAtomic Designなどの考え方をベースにコンポーネントを管理する方法が用いられています。Atomic Designを用いたコンポーネント設計方法については、以下の記事が参考になるかと思います。 Vue.js × Atomic Design - it's an endless world. いずれ
「Divide and Conquer / 分割統治法」 という解法（アルゴリズムの話でよく出てきますね）は、「困難は分割せよ」 として知られる、デカルトが『方法序説』で提唱した思考法が元になっています1。 第二は、わたしが検討する難問の一つ一つを、できるだけ多くの、しかも問題をよりよく解くために必要なだけの小部分に分割すること。 ―― 岩波文庫 『方法序説』 デカルト著 谷川多佳子訳 同様に、React で多機能で複雑な画面を作りたい時、それを小さな機能の集まりと捉えて、それぞれをコンポーネントにすることで、開発がラクになることがあります。 フロントエンドの複雑さや、デザインのための Atomic Design という考え方の影響、または /scripts のように分ける習慣の名残なのか、フロントエンド開発者には、《再利用のためにコンポーネントを作る》という思い込みがあります。（もしくは
TypeScript の型を用いたコンポーネントの責務の明確化 - Timee Product Team Blog
はじめまして！フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは Next.js × TypeScript で toB 向け管理画面を作成しています。 この記事は、toB向けの管理画面の開発時に筆者が気づいたコンポーネント間の責務の明確化の必要性と、 TypeScript の型を用いて責務の分割をサポートする方法の紹介しています。 背景 利用者の様々なニーズに応えるために、toB向け管理画面には様々なページが実装されています。 2つ以上のページを実装していると、それぞれのページで実装の粒度がバラバラになることがあります。 一方ではフックの中で実装していたようなロジックが、他方ではコンポーネントで実装されている あるページのコンポーネントは複数のファイルに分割しているけど、こちらのページでは巨大な一つのファイルで実装が完結している 属人的な責務の分割が失敗した様子
レガシーなフロントエンド環境をリプレースするためにチームでやっていること｜食べログ フロントエンドエンジニアブログ
はじめに はじめまして！食べログFE（フロントエンド）チームの金野と申します。 普段は、食べログフロントエンドの設計・開発や、新規事業・食べログテイクアウトの技術サポートなどを行っています。 食べログテイクアウトについては、Nuxt.js + TypeScriptの開発について記事を書いているので、興味がある方はぜひ御覧ください。 さて、以前の記事でご紹介したように、食べログFEチームではレガシーシステムのリプレースをReact/TypeScriptで行っています。 今回は、新しいシステムについてもう少し詳しい技術スタックや、どのようなプロセスで開発しているのかを紹介します。 開発効率化のための取り組みリプレースのお仕事はただひたすら実装するだけではありません。 「壊れにくいアプリケーション」「メンテナビリティが高いアプリケーション」にするために、アーキテクチャや採用する周辺技術について、
こんにちは。フロントエンドエンジニアの小林和弘です。 Vue.js + Atomic Designでつくられたプロジェクトにビジュアルリグレッションテストを導入しました。 ビジュアルリグレッションテストでUIの安全性を高める コンポーネントの改修、新機能の追加、ライブラリのアップデートを行う際、UIに不要な変更が入っていないか不安になることがあると思います。リファクタリングをしようにも、意図しないところでUIが壊れないか心配になります。 画面表示に関わるコードを改修するたびに、ローカル環境やステージング環境で全UIコンポーネントを確認するのは難しいです。 また、ステージング環境と本番環境を並べて変更されたUIを目視で確認するのも非現実的です。 ビジュアルリグレッションテストはその名前の通り、視覚的な回帰テストを指します。改修前後のスクリーンショットの差分を検証するためのテストです。 開発に
弁護士ドットコムライブラリーのフロントエンドのアーキテクチャ（Next.js + TypeScript） - パンダのプログラミングブログ
弁護士ドットコムライブラリーのフロントエンドのアーキテクチャを紹介します この記事は弁護士ドットコム Advent Calendar 2020、2日目の記事です。2020年12月に執筆された記事です。 私は弁護士ドットコムライブラリーというサービスを開発しています。これは法律書籍をネットで読める弁護士向けのサブスクリプションサービスです。 フロントエンドの採用技術はNext.js + TypeScriptで、要件定義から設計、実装は私が担当し、現在も運用しています。 この記事では、2020年5月にリリースしてから半年間、Next.jsで上記サービスを運用した知見の中から、フロントエンドでのアーキテクチャについてご紹介します。 弁護士ドットコムライブラリーの特徴は以下の通りです。 画面数は10画面ほどの中規模アプリケーション（OOUIの考え方を取り入れたら画面数が減りました） 基本的にバック
Atomic Design思考でVue.js×Plotly.jsでのグラフComponentを実装した結果 - ABEJA Tech Blog
第0章：はじめに こんにちは。はじめまして。 ABEJAでフロントエンドとバックエンドをフラフラしているエンジニアの齋藤(@z-me)*1です。 本ブログは ABEJA Advent Calendar 2019 の9日目です。 不本意ながらABEJAで開催するフロントエンドのミートアップやカジュアル面談でよく、 ABEJAってAIの会社ってイメージはあるけどUI/UXガッチリやってるイメージがない。 と言われる事が多いので、当ブログ編集長*2が言っている通り*3、ABEJAではプロダクトを開発＆提供しているということをお伝えしたいと思います。 今回はその中でも、あまり外部に広く知られていない、ABEJA Insight for Retailの提供しているDashboardで、どのようにUI/UXに力を入れて開発しているのかや、その開発手法(Atomic Design)やグラフCompone
流行りの monorepo 風味と DDD 風味？ 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web
DMM.com ラボさまの社内勉強会にお声がけ頂き、「Atomic Design & Design Systems」というテーマでお話させて頂きました。 当日の構成 勉強会のテーマがAtomic Designについてだったので、前半はGUILDさん勉強会でお話させて頂いた内容を少し持ってきました。 後半ではAtomic Designの視点をもう少し広げて、Design System（毎回デザインシステム表記とどっちにしようか悩む）全般について、僕が調べたり考えたことをまとめました。 と言っても自分は何かしらのデザインシステムを取り入れたり実践したりと言った経験はありません。そのため、内容のほとんどは海外の事例や記事の引用・意訳になります。Design Systemについてまとまった情報が知りたい！という方には有益かと思いますが、基本的なことは知ってるよーという方にはあまりお役に立てないと思
react-native-dom とは experimental と書いてあるが普通に動く。デモを見ると React Native で提供されている仮想 DOM は大体動くといった感じ。 2018 年の React Europe で発表された資料。 https://rndom-slides.vincentriemer.app/ https://www.youtube.com/watch?v=aOWIJ4Mgb2k これの何がすごいかというとブリッジの仕組みにのっとって構築されているところだ。 Native First と言っている。 ブリッジの仕組み iOS のブリッジの仕組みは次でまとめているので参照のこと。 https://speakerdeck.com/januswel/discussion-about-the-bridge https://qiita.com/janus_wel/i
ECSSというOOCSSとはほとんど反対のアプローチをするCSSの構成案があります。製品によってデザインが大きく異なるWebサイトに向いているのかなと個人的には考えています。あるいは、うまく共通化をすることができれば大規模なWebサイトにも適応可能ではないかなと期待しています。 Enduring CSS 案件で使いたいなと思ったのですが、あまり広く知られているものでもないですし、検索しても該当する記事はまだまだ少なかったりします。 公式サイトを読むのが一番いいのですが、ボリュームがあり、さらに英語であることを考えるとそれも難しい。というわけで、ECSSの概要と考え方を日本語で比較的短い文章でまとめることにしました。 このドキュメントの目的はECSSを詳しく調べたくなったり、実際に使い始めるためのきっかけになることです。 以下の文章の最新版はGitHubにアップしています。 ECSS End
アウトプットの精度が上がる！「Adobe XDをプロトタイピングに活かす方法」 研修レポート | メンバーズクリエイターズブログ
2021.3.1 アウトプットの精度が上がる！「Adobe XDをプロトタイピングに活かす方法」 研修レポート ツールデザインナレッジ研修 皆さん、こんにちは。 メンバーズキャリアカンパニー所属ディレクターの森山です。 この度、2021年1月26日にオンラインにて開催された「Adobe XDをプロトタイピングに活かす方法」研修を受講しました。 講師は株式会社まぼろし取締役CMOであり、メンバーズキャリアカンパニーの技術顧問も務めてくださっている益子貴寛さんです。 今回の講義は、Adobe XDの機能の中でも、それぞれのワイヤーフレームやデザインをリンクで有機的につなげて、ブラウザで動く画面を作ることができる「プロトタイピング」という機能にフォーカスした内容でした。 ディレクターやマーケター、プランナーなどのノンデザイナー及びノンエンジニア向けの講座ではありましたが、プロトタイピング自体はU
この記事は、「BASE Advent Calendar 2018」の8日目の記事です。 devblog.thebase.in こんにちは、BASE Design Groupマネージャーの早川（@match0129）です。 今日は、ネットショップ作成サービス「BASE」の管理画面のリニューアルプロジェクトである「次世代管理画面」の話を少ししてみたいと思います。 次世代管理画面とは？ ネットショップ作成サービス「BASE」は、現在「次世代管理画面プロジェクト」として大規模なリニューアルの真っ最中です。 プロジェクトが最初にはじまったのは今年の1月で、今は最初の大きな区切りのリリースに向けて開発が佳境を迎えているところです。 キックオフから早1年経とうとしているこのプロジェクトについて、やってきたことを少し振り返ってみたいと思います。 プロジェクトの方向性とコンセプトの定義 そもそもなぜ今リニュ
諸事情で締め切りまでに歌詞を考えないといけないのですが、全く思いつかないので、表題の駄文を書き始めてしまいました。 とある IT の事業会社でインハウスデザイナーのマネージャー、エンジニアのマネージャーをそれぞれ短い期間ですが数年経験した身として、ふとした場でこの話が聞こえてくることもあるので、考えをまとめてみました。あくまで IT 系のデザインの話ですのでご注意ください。 デザイナーや、デザイナーに関わる誰かの参考になりましたらと思います。 UI や Web に関わるデザイナーはコードを書くべきかまず、これをデザイナーに言えるのは以下のパターンです。 社長、経営者（給料を出す人）そのデザイナーのマネージャーや、先輩デザイナー（キャリアを導く人）そのデザイナーが入るプロジェクトマネージャー・エンジニアの「お願い」（猫の手を借りたい人）「一般論として『デザイナーはコードを書くべき』とは言えな
Sketchから学ぶコンポーネントデザイン : could
部品から設計することに慣れる デザインツールとして Sketch や Figma を推している理由のひとつにシンボルがあります。Adobe CC ライブラリのアセット管理とは異なり、デザインした部品（コンポーネント）を拡張したり組み合わせることができるのが魅力。様々なスクリーンサイズに耐えられるように作るのはもちろん、デザインを運用していくには、部品からしっかりデザインできるのはこれからのツールでは必須です。 コードが書ける人、コードを書く思考が分かる人であれば、部品から作ってレゴブロックのように積み上げるという Atomic Design 的な考え方は当然と思えるでしょう。なので、デザインシステムを作りましょうという考えに至りますが、画面の全体像から徐々にディテールを作るやり方でデザインしていた人には難しかったりします。いきなり部品から作ることに慣れていないですし、マクロ（画面全体）とミ
Atomic Designの実装例 〜Atomic Designを使ったコンポーネント指向のUI開発：Q〜 - UGAP Engineer's Blog
本稿は（序）（破）（Q）のシリーズの3番目の記事になります。 本稿では前回（破）で説明したAtomic Designを導入する際に工夫した点をふまえた実装例をJSフレームワークを使用する場合と使用しない場合の２つの場合について紹介します。 シリーズ（序）ではAtomic Designの概要 シリーズ（破）ではAtomic Designの導入に際して工夫した点 について説明していますので、そちらをご覧ください。 実装例題材 下のサイトテンプレートを題材に実装していきます。 https://html5up.net/prologue シチュエーションとしては、デザイナーからもらったデザインカンプをエンジニアが実装する想定で説明します。 コンポーネントの分割 エンジニアはデザインカンプをAtomic Designのコンポーネント単位に分割していきます。 コンポーネントの分割フロー図は（破）で以下の
What is Atomic Parts Base CSS(APB CSS) Atomic Design + OOCSS + SMACSS = Atomic Parts Base CSS (APB CSS) Atomic Parts Base CSS(APB CSS)って何？？ Atomic Design + OOCSS + SMACSS = Atomic Parts Base CSS (APB CSS) APBCSS は Atomic Parts Base CSSのそれぞれ頭文字を取っていて、「エーピービーシーエスエス」と呼びます。 APBCSS は Atomic Designをベースに設計された「CSSアーキテクチャ」の一つとなります。 Point - Simple - Predictable - General versatility - Reusable - Maintainabl
脱・Atomic Design - HTML+CSSコーディングの粒度分類法（HTML Parts） - Qiita
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
今さら聞けないビジュアルリグレッションテストをChromaticで始める - Sansan Tech Blog
Bill One Entry*1グループの秋山です。 1. はじめに 2010年代前半に登場したReactやVue.jsに代表される宣言的UI実装は、大規模なSPAの構築を可能にしました。その一方、フロントエンド領域に新たなアーキテクチャが導入されたことで、それまでWebアプリケーション開発で定石とされたテスト手法を適用しづらいケースが増え、新たなベストプラクティスが求められるようになりました。 その要請に応える形で、2010年代後半にはフロントエンドのテスト手法に緩やかなパラダイムシフトがありました。この記事ではそのパラダイムシフトを振り返りながら、フロントエンドで必要なテストについて考察し、最後にChromaticを用いたビジュアルリグレッションテストを紹介します。 2. Testing Pyramid と フロントエンド テストを語る際によく持ち出されるメタファとして、Testing
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
静的なHTMLのためのコンポーネント駆動開発―その導入を振り返って
Atomic DesignをベースにしたデザインシステムとCSS設計｜あっきー
Atomic Design by Brad Frost
デザインシステムの作り方徹底ガイド 参考にしたい導入事例まとめ
Website Style Guide Resources
CI&UIリニューアルしながらデザインシステムを作った話｜Yoko Nishida
エンジニア↔デザイナー間のペアプロのススメ｜ohs / Pilll ピルリマインダーアプリ
デザインシステムの資料を作る時に参考にしたリンクまとめ | よりデザイン
THE GUILD勉強会『Atomic Design & Sketch』
あのモジュールこのコンポーネントそのブロック
大規模Angular SPA開発に立ち向かうためにアプリとUIを切り分けた話
フロントエンドのディレクトリ設計を移行した話 | Atomic Design → Feature
Vue.jsで開発を始める前に決めておきたい事 - Qiita
【React】「困難は分割せよ」―― 複雑な画面は小さな機能に分けて実装しよう。 - Qiita
ビジュアルリグレッションテストを導入した話 - メドピア開発者ブログ
コード設計編: context による縦軸分類とレイヤードアーキテクチャ（新規開発のメモ書きシリーズ3）
「Atomic Design & Design Systems」をお話させて頂きました | よりデザイン
react-native-dom の何がすごいのか - Qiita
ECSSの概要と考え方のまとめ - Qiita
「BASE」の管理画面リニューアルプロジェクトのこれまでとこれから - BASEプロダクトチームブログ
デザイナーはコードを書くべきか - feb19
APB CSS - Atomic Parts Base CSS -