この記事は2022年12月10日開催のSpectrum Tokyo Design Fest 2022で話したセッションの内容を文字起こししたものです。 僕は15年ほどWebに関する業界で働いています。はじめは小さなベンチャーでWebデザイナーとして仕事をはじめ、自分でデザインして自分でコーディングするというキャリアからはじまりました。それからフロントエンドデベロッパー、UXエンジニア、デザインエンジニアと肩書を変えてきています。 その中で、CSS設計の書籍の執筆や、Figmaのプラグイン開発、デザインシステムのリードなどの活動をしてるんですが、基本的にはコードを書くことをメインにしつつも、デザインに近い領域で仕事をしてきています。 Code is a Material僕がデザインとコードの両方についての考えを巡らせるきっかけになったのは、2019年に観たデザインシステムのカンファレンスのい
Send feedback API design guide Stay organized with collections Save and categorize content based on your preferences. Changelog Introduction This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide that Google follows when designing Cloud APIs and other Google APIs. This design guide is shared here to inform outside developers and to make it eas
2018-02-27Composable な UI 設計を目指したフロントエンド開発こんにちは、開発本部の舘野です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていたジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前はAngularをフレームワークとして採
「なぜこういうデザインになったのか」というデザインフローシリーズ。 前回までは、情報のグルーピングから、歯の番号の図をどう入れるか、と日付の秘密をお伝えしました。 歯科予約システムの3回目の今回は、「デザイン編1」としてどういうデザイン（レイアウト）に展開できるか、そしてその意味を解説していきます。 色については次回に。。 前回までの話を読んでいない方はまずこちらからお読みください。 歯科予約システムの治療履歴画面（基本） ｜ DESIGN LAB by tuqulore 歯科予約システムの治療履歴画面（応用） ｜ DESIGN LAB by tuqulore 前回の記事に関して受けた指摘 さて本題に入る前に、前回の応用編で歯の番号の図を入れたわけですが、SNSで次のような指摘が入りました。 「カルテって、ふつう左右逆に書くもんじゃないですか？」 たしかに！！ 整形外科のカルテなどを見ても
「なぜこういうデザインになったのか」というデザインフローシリーズ。 前回の基礎では、必要な要素を整理してからの情報のグルーピング、さらには人が使うための気づかいを少しだけ書きました。 今回は応用として、引き続き同じネタで、 歯の番号わからんよね 日付に隠された秘密 を書いていきます。 前回の基礎を読んでいない方はまずこちらからお読みください。 歯科予約システムの治療履歴画面（基本） ｜ DESIGN LAB by tuqulore 【7】歯の番号わからんよね 前回、治療内容についてはこのように「左上7」「右下3」などと、歯医者さんの専門用語で書かれていて、これわからないよね、ということを書いていました。 もしこれを使う人が歯科医の業界にいる人であれば、「左上7」といわれてピンとこなければ、ちょっとヤバいレベルだと思います（わたしたちが「Photoshopってなんだっけ。。」と言うのと同じく
デザインに関する何かを書いていくDESIGN LAB、わたしのターンでは「なぜこういうデザインになったのか」というデザインフローを毎月お伝えしていこうと思います。 具体的な例については、架空の仕様のアプリが多くなると思います。 デザインには正解がない、でも最適なものはある デザインにはいろいろなアプローチ、表現があるので、「デザインには正解がない」とよくいわれます。 でも、その案件に応じた最適なデザインというのはそれぞれにあると考えています。 この「最適な」の根底にあるのは、クライアントの要望。…と思われがちですが、それだけではありません。クライアントの要望プラス、ユーザーの動向や気持ちも見逃してはいけません。 クライアントの要望だけを見ていると、ユーザーの気持ちを忘れがちになる わたしがデザインをするときに必ず考えるのは、「ユーザーの気持ち」。 クライアントと話をしていると、ついついクラ
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
18. <div class="speaker"> <div class="avatar"> <img src="tani.jpg"> </div> <div class="inner"> <p class="name">…</p> <div class="biography"> <p>...</p> </div> </div> </div> 19. .speaker { overflow: hidden; /* Clearfix */ padding: 20px; background-color: #fff; } .speaker .avatar { float: left; margin-right: 15px; } .speaker .avatar > img { border-radius: 50%; } .speaker .inner { overflow: hidden; }
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
