タグ

designと設計に関するihokのブックマーク (10)

  • 外国人から見た名前入力に関するBADなUIデザイン|CULUMU / インクルーシブデザインスタジオ

    こんにちは!ゲストライターのトゥクです。 前回は、連載最初の記事として私の大学の学部卒業制作研究をもとにデザインとの向き合い方について、ご紹介いただきました。 私の紹介記事に関してはこちらをご覧ください。 そして今回からは私自身や家族、友人が外国人として日に住む中で感じていることや、出来事についてご紹介していきます。 この連載では、外国人視点から日に住む上で感じたこと、気づき、出来事を通して、読者の皆さんに新たな視点や発見を届けたいと思います。そして社会におけるマジョリティやマイノリティに関係なく、全ての人にとって良いデザインについて共に議論できると嬉しいです。 外国語名を日語名のフォーマットに当てはめるって難しい!今回私が紹介するのは「外国語名を日語名のフォーマットに当てはめること」の難しさと、具体的に私が出会ったBADなUIデザインについてです。 役所や病院、インターネットの個

    外国人から見た名前入力に関するBADなUIデザイン|CULUMU / インクルーシブデザインスタジオ
  • この設計は何がダメなの?ー新人君の設計事例ー | しぶちょー技術研究所

    以前、Twitterで呟いたもので反響が大きかった内容がありました。今回はその呟きに対すると皆様の回答について整理・考察していきたいと思います。 新人くんの設計事例 下記が私がTwitterで呟いた内容です。 【新人君の設計事例】 新人君が出してきた設計案。これは"やってはいけない締結"だよと色々説明したが、あまり納得してもらえず。上司も"部品強そうだし、問題ないでしょ"と一言。 個人的な感覚では、"絶対にダメな奴"なんだけど上手く納得させる説明ができなかった。皆さんならどう説明しますか? pic.twitter.com/FYMZOu9dqx — しぶちょー (@sibucho_labo) September 5, 2020 ある日、新人君がこのような設計を提案してきました。ボルトの下は隙間になっていて、普段あまり見ない形です。詳細な意図は省きますが、他部品との干渉の関係もあり、こういう形

    この設計は何がダメなの?ー新人君の設計事例ー | しぶちょー技術研究所
  • 日本語のドメイン駆動設計 (Domain-Driven Design - DDD) 関連記事まとめ - なにか作る

    ドメイン駆動設計は原典となる「エリック・エヴァンスのドメイン駆動設計」の初版が2003年と歴史があり、モダンなフレームワークであればその思想を取り入れた設計がなされているにも関わらず、日語の情報が少ない気がする。 最近ドメイン駆動設計をやろうと主にWeb上の情報を探っていたので参考になったサイトをリンク集の形でまとめてみる。 概要 概要を把握するのが一番難しいように思うので、色々と目を通すのがよさそう。 little-hands.hatenablog.com enterprisegeeks.hatenablog.com enterprisegeeks.hatenablog.com speakerdeck.com ドメイン駆動設計とは何か 【入門編】 from 増田 亨 www.slideshare.net 3週連続DDDその1 ドメイン駆動設計の基を理解する from 増田 亨 www

    日本語のドメイン駆動設計 (Domain-Driven Design - DDD) 関連記事まとめ - なにか作る
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
  • ランキング設計はどうあるべきか? その2|深津 貴之 (fladdict)|note

    前エントリで論じられた、正しいランキング設計の考察の続き。第2回は、ランキングの収奪性、格差の固定性を軽減する手段を、具体的に論じてみる。 前回の記事へのTwitter上のフィードバックは、Togetterにまとめてある。こちらもご興味があれば、一読の価値がある。いくつか被ってしまったものもあるけれど、諸々の後半記事。 「ランキング」以外の名称を用いるこれはほぼ確定。ランキングという名前は、「noteとして競争原理を推奨する」という強いメッセージを発する。noteの全てのユーザーが、競争原理で動いているわけではないので、これは望ましくない。 おそらく最終的には「注目」「人気」などの名称を使うことになるかと思われる(「オススメ」はパーソナライズ用にとっておく)。また、「ランキング」という名称やスタンスをやめることで、後述するようないくつかの公平性のための施策を行う余地が生まれる。 時間による

    ランキング設計はどうあるべきか? その2|深津 貴之 (fladdict)|note
  • 宣言ブロックのCSS設計 - kojika17

    語で「CSS設計」を検索すると、記事やつぶやきなどでセレクタの命名規則に関する話題が多いです。 CSSを設計する上で、命名規則は重要な要素でしょう。 簡単なセレクタ名だと他のスタイルと重複する可能性もあります。他のスタイルと重複しないようにセレクタの子孫数を増やしてしまうと、今度はスタイルの取り回しが悪くなります。 またデザインをコンポーネントに分ける粒度について紹介されていますが、命名規則の分け方のように紹介されているよう感じます。 論理的に構造をわけて命名していくため、覚えやすく、伝えやすさもあわさって、現在の「CSS設計 = 命名規則」のような構図ができあがったと感じています。 CSS設計は命名規則だけか 命名規則CSS設計において、重要な要素です。 しかしCSS命名規則させ気を付ければ良い、というものではありません。 私は、すでにあるサイトの一部のコンテンツの作成やすでに用

    宣言ブロックのCSS設計 - kojika17
  • 翻訳: WebAPI 設計のベストプラクティス - Qiita

    これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

    翻訳: WebAPI 設計のベストプラクティス - Qiita
  • クラス設計の原則 — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと

    クラス設計の原則 — みんなのウェディングエンジニアリングブログ
  • CSSが破綻する4つの理由 - Qiita

    前回の「破綻しにくいCSS設計の法則 15」は思いがけず大変なご好評をいただきました。ただ書いた当人としては、まとまりに欠けていたように思えましたので、今回はもう少し質的なところを書いてみたいと思います。 CSSとは実際のところ何か CSSが破綻する理由 破綻しないCSS設計とは 1. CSSとは実際のところ何か CSSはJSONと同様にシンプルなフォーマットで、基的には以下のような構造になっています。

    CSSが破綻する4つの理由 - Qiita
  • 主キーはインデックスではない - 設計者の発言

    仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス(キー)というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセ

    主キーはインデックスではない - 設計者の発言
  • 1