The slides describe how you can adopt Atomic Design to make your UI development agile.
![UI 開発をアジャイルに行うための Atomic Design](https://cdn-ak-scissors.b.st-hatena.com/image/square/9b012465fd86f82e9c2be7b81687f216f1627c55/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fatomic-design-for-agile-development-180606162313-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
開発環境 Nuxt.js v2 Express v4 bootstrap v4 (bootstrap-vue) Atomic Designとは Atomic Design はデザインシステムを作るための1つの手段 ざっくり言うと、UI コンポーネントの粒度をカテゴリーに明確に分ける手法 Atomic Designの詳細については割愛しますので、下記サイトをご参照ください。 Nuxt.jsとAtomic Designの開発が最高なポイント Nuxt.jsの機能: routerなど面倒な設定を特に意識しないで実装できとても楽! 生産性向上 & 一貫性: コンポーネントの独立性が高く、さらにVuexを使うとデータの操作とビューの表示が依存性低く、仕様変更に柔軟に対応できる デザイン変更が発生する際、一箇所を修正するだけで、全てが適用される(これが一番好きなポイント) もちろん、それぞれのページの
大阪からこんにちは、福山健(@kenfdev)です。 フロントエンドに関わっているエンジニアであればAtomic Designというのを聞いたことがあるかもしれません。 フロントエンドの開発をしていく上で大事なことの一つに、画面の部品をどのようにComponentに分割していくかというものがあります。 きっとたくさんのフロントエンドエンジニアがこの点については毎回悩まれると思います。 そこで、どのように分割していくと良いかという指標の一つとしてAtomic Designという考え方があると僕は解釈しています。 Atomic DesignはBrad Frostさんという方が提唱したもので、英語であれば下記にて公開されていますし、本を注文することもできます。 atomicdesign.bradfrost.com また、日本では下の書籍がReactを使って具体的にわかりやすく説明されています。(
この記事はVue.js #3 Advent Calendar 2017の13日目の記事です Atomic Design自体の記事は色々ありますので、この記事ではAtomicDesignで設計したコンポーネントをVue.jsで実際に運用してみて感じた事をまとめてみました 実際にどんな感じになるか結論から言うと、AtomとMoleculeにStoreを持たせず。 OrganismsとTemplateあたりの粒度でStoreを利用するとIA的にも収まりがいい様に思えます。是非デザイナーにツッコミ入れましょう。 VueコンポーネントをAtomicDesignで実装するとだいたいこんな感じになります。Atomの役割色・タイポ・ボタン固定文言など 直接描画要素にデータをレンダリング描画要素のイベントを発行親要素からのデータ受け取り登場箇所がすごく多いのでステートレスを徹底するStoreみちゃダメ絶対!
スマートキャンプのデザイナー/エンジニアの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 とは、コンポーネント単位で設計していくデザイン・開発手法で
DevicebookというNuxt.jsとLaravelを使ったWebサービスを個人開発しています。 最近、「うわっ、わたしのコンポーネント設計、見づらすぎ・・・?」と思いはじめたため、重い腰をあげてAtomic Designを導入しはじめました。 Atomic Deisngのメリット Atomic Designを導入すれば、コンポーネントの設計に統一感をもたらすことができて、再利用性が高まるという恩恵を受けられます。 今まではVue.jsのスタイルガイドに準拠しながら設計をしていましたが、個人開発サービスの規模感でも、そろそろ限界が見えはじめました。 コンポーネントの設計が、機能や開発時期によってバラつきがあるため、可読性が低い。 コンポーネントが他のコンポーネントやVuexと密結合になっているため、再利用しにくい。 つまり中規模段階に入るとVue.jsのスタイルガイドに限界が見え始める
Vue.js 講演用資料です。 # 概要 コンポーネントをどのような粒度で分割し、どのように実装するべきかというのは難しいテーマです。 一概に正解があるとも言い切れないテーマですが、この指針を疎かにすることはチームを混乱に陥れることと同義です。 それが SPA 未経験のチームであればなおさらです。 直近のプロジェクトはまさにそんなプロジェクトでした。 本セッションではアトミックデザインのエッセンスを用いてコンポーネント分割の指針を示し、 またコンポーネント実装時に注意すべき事柄についてお話します # URL HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
Atomic Designってむずくないすか? なんか、良さそうなのは分かるんですよ。 UI要素を最小単位まで分解して、それを共通化して再利用性を高めて工数減らしていこうぜ!ということなのは分かるんです。 Atomic Design を分かったつもりになる こちらはDeNAの記事で、単純に「Atomic Design」でググると最初に出てくる記事です。SEOが強め!(2018/07/30現在) こちらの記事、確かに詳細に書かれているんです。 2016年にこんな記事を書けるなんて、当時口を開けてアホ面で仕事をしていた自分なんかからしたらもう感服するしかないです。 英語の記事しかない中で、最先端なことを書けるDeNAはやっぱりすごいな私は何してんだよって話なんです。 ただ、この記事を、こんな優良な記事を読んだとしても、実際に作り始めると、、、 ButtonってIconも文字も入ってくるけど、こ
Atomを作ったことありますか? 以前、「Atomic Designってデザイナーには難しくない!?という話」という記事を書きまして、大変反響があり、今でも時折いいねをいただいていて大変嬉しく思っています! この反響からも、やっぱり世間的にこの手の話題はみんな一生懸命悩みながら、わからないながらに作っているんだろうなーとなんとなく感じています。 そんな私の記事ですが、前はAtomsからPagesまでの全体の話をしました。 それゆえに、実際に運用できるレベルの、超具体的なAtom自体の実装についてはそこまで触れませんでした。 なので今回は、堅牢で使いまわしやすく運用しやすいAtomをガチで作ったらどうなるのかを記事にしてみたいと思います。 「Atoms」とはどんな存在なのだろう? 「車輪の再発明」という言葉がありますね。 しれっと皮肉を言っているこの言葉ですが、確かになにか家具を作るときに、
ECSSというOOCSSとはほとんど反対のアプローチをするCSSの構成案があります。製品によってデザインが大きく異なるWebサイトに向いているのかなと個人的には考えています。あるいは、うまく共通化をすることができれば大規模なWebサイトにも適応可能ではないかなと期待しています。 Enduring CSS 案件で使いたいなと思ったのですが、あまり広く知られているものでもないですし、検索しても該当する記事はまだまだ少なかったりします。 公式サイトを読むのが一番いいのですが、ボリュームがあり、さらに英語であることを考えるとそれも難しい。というわけで、ECSSの概要と考え方を日本語で比較的短い文章でまとめることにしました。 このドキュメントの目的はECSSを詳しく調べたくなったり、実際に使い始めるためのきっかけになることです。 以下の文章の最新版はGitHubにアップしています。 ECSS End
はじめまして。UIデザイナーのカミソルです。 わたしはOHAKO.incの受託事業の部署でサービスの体験設計からUIデザインをしています。 今回はSketchのSymbol機能を使って、デザインしながら効率よくガイドラインを作る方法について書きたいと思います! ※この記事はSketch Advent Calendar 2017 19日目の記事です。 なぜデザインしながらガイドライン化したいのかガイドラインを作る目的は2つあります。 1. エンジニアとの連携のため "カラーの種類"、"テキストスタイルの種類"、"画像として書き出すもの"、"コンポーネント"の4つがはっきり伝わるSketchデータにしたい。 2. デザイン運用のため デザインを運用をするとき、誰でも追加や変更がしやすいようにしたい。「デザインしながら」とつけた理由は、デザインしていたら自然にガイドラインが出来ていた。という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く