Slack のロゴが新しくなりました！
本日、ブランドデザインのリニューアル計画の第一弾として、Slack では新ロゴを発表しました。Slack 社員だけでなく、ユーザーの皆さんにも愛されてきた以前のロゴ (とデザイン) をなぜ変えるのか、疑問に感じる方もいるのではないでしょうか。そこで、デザイン刷新の理由と、新しいデザインに込めた思いをご説明したいと思います。 まず、今回の変更は、なんとなく…といった軽い気持ちで行ったわけではありません！諸行無常とあるように、何事も変化というのは避けられず、自然の流れかもしれませんが、ロゴ変更の理由としては十分ではありません。ロゴというブランドの顔を変更するのは「本来のロゴの役割を果たしていない」という確固たる理由がある場合です。私たちが愛してきたロゴは、まさにこのケースでした。私たちはその事実を認め、よりシンプルでわかりやすい、ロゴとしての役割を果たす新しいデザインに進化させるため、今回のロ
決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note
中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
なぜ製品仕様を合議制で決めてはいけないのか。
プロダクトマネジメントにおいて「製品仕様を合議制（多数決）で決めてはいけない」というルールがあるが、それは何故なのか。そして、だとしたらどのように人の意見を取り入れるのが良いのか、を考えてみた。 なぜ製品仕様を合議制で決めてはいけないのか。合議に参加している人たちは、その問題の責任者ほど制約条件や問題の背景を深く理解をしていないから。合議制や多数決で物事を決めると、必ずその結果に満足している人たちの方が満足していない人たちよりも多くなる。これは素晴らしい手法だ。 しかし、製品開発の目的は社内の人を満足させることではない。正しい製品をつくることだ。製品にとっての正しさとは、「その製品を顧客（市場）が求めていること」であり、これを満たすためには様々な調査や知識が必要だ。 製品仕様のように、問題の複雑さが一定を超えると、知識を持っている人と持っていない人の意見に違いが出始める。世の中（「社内」と
フォームバリデーションと送信ボタンの状態の最適解 - Konifar's ZATSU
タイトルを見て「あーあれね」と思った人もいると思うが、アプリデザインの世界ではすでに議論され尽くされているであろうこの話題について雑に考えをまとめておきたい。とは言っても明確な答えがあるわけではないので意見がほしいというのが正直なところなので、もしフィードバックがあれば @konifarまで直接教えてもらえると嬉しい。 何を言いたいのかというと、『フォームに入力されていない or 入力された文字が異常である場合に送信ボタンを押せる状態にするか押せない状態にするか』という話だ。たとえば次のように氏名を両方入力しなければいけないケース。 初期状態の送信ボタンがdisabledで、入力に応じて状態が切り替わる。 本当に送信できる時だけ送信ボタンがenabledになるというのはわかりやすそうだが、問題もある。入力項目が多くなってきた時に、ユーザーがなぜ送信ボタンを押せないのかわからないかもしれない
ランキング設計はどうあるべきか？ その2｜深津 貴之 (fladdict)｜note
前エントリで論じられた、正しいランキング設計の考察の続き。第2回は、ランキングの収奪性、格差の固定性を軽減する手段を、具体的に論じてみる。 前回の記事へのTwitter上のフィードバックは、Togetterにまとめてある。こちらもご興味があれば、一読の価値がある。いくつか被ってしまったものもあるけれど、諸々の後半記事。 「ランキング」以外の名称を用いるこれはほぼ確定。ランキングという名前は、「noteとして競争原理を推奨する」という強いメッセージを発する。noteの全てのユーザーが、競争原理で動いているわけではないので、これは望ましくない。 おそらく最終的には「注目」「人気」などの名称を使うことになるかと思われる（「オススメ」はパーソナライズ用にとっておく）。また、「ランキング」という名称やスタンスをやめることで、後述するようないくつかの公平性のための施策を行う余地が生まれる。 時間による
デザイナーのパラダイムシフト｜hiranotomoki
※ここでのデザイナーとは、主に、グラフィックデザインやUIデザインを扱うデザイナーのことである。 そして、Design with AIの時代へ近年、高性能のパソコンとデザインアプリケーションが安価で手に入ることで、誰でもデザイナーを始めることが可能となった。また、AppleやGoogleが提供するデザインのコンポーネントとデザインのガイドラインは、成果物の品質保証を底上げし、美的センス（審美眼）の必要性を下げた。さらに、人工知能の発達は、熟練デザイナーのブラックボックスだった職人的技術を解放しはじめている。 コンピューターが投入される前に必要だったデザイナーの技術は、例えば、1mmの間に何本のまっすぐの線を引けるかといった技術である。しかし、コンピューターが現場に導入されるとその技術の希少性は消え、いまや、0.25mmのまっすぐな線を引くことに、特別な訓練は必要ない。これと似たような現象が
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
テンプレートエンジンのくせに最近のPHPはオブジェクト志向やらDIやらイキり始めた件 - JavaScriptをがんばるブログ
※2017/05/29現在Repositoryの章までしか聞けていません。聞いている際に浮かんだインスピレーションが揮発しないよう永続化する為に書いた記事です。 php-genba.shin1x1.com まさか日本語でこの内容を聞けるコンテンツがあるとは思わなかったです。 これは英語をマスターすれば Sound of Symfony The Laravel Podcast Ruby on Rails Podcast JavaScript Air devchat.tv などのPodcastからより多くの興奮を得られる事を意味します。 プログラミング経験3年、細かい修正ばかりで設計レベルの経験値が全くない自分ですが、各章について以前から個人的に思っていた事、お三方の知見からインスピレーションを得た内容を書き残します。 1. DI 「依存性の注入(Dependency Injection)」と
CSSのposition:stickyがすごく便利 | q-Az
最近新しく追加された position の新しい値 sticky が場合によってはすごく便利なので記事を書いてみます。 対応ブラウザがまだあまり多くないので実用性は乏しいかもしれませんが、今まで JavaScript の力を借りなきゃ出来なかったことがたったの2行の CSS で出来てしまう魔法みたいな position の値です。 position: stickyMDN が説明が詳しいので貼っておきます。 参考：position - CSS｜MDN 簡単に言うと「スクロールでその位置まで来たらそれ以降は fixed する」みたいな感じです。 サンプルこの記事内で「position: sticky」や「サンプル」など h2 要素に position: sticky をかけています。対応ブラウザであれば h2 要素が fixed しているはずです。 HTML<h2 class="h2-stic
生年月日の入力欄のレスポンシブ対応についていろいろ考えてみた
先日、生年月日の入力欄をレスポンシブに最適化する良い方法はないか検証してみたら、想像以上に大変だったのでメモを残しておきます。 日付の入力と言えど実はいろいろな実装方法があって、マルチデバイスに対応しながら要件にあった実装をするにはどうしたらいいのか、改めてゼロベースで考えてみました。結局、最終的には振り出しに戻った感じなんですけどね（結論を先に見たい方はこちらからどうぞw）。 近い将来、レスポンシブな日付入力欄の実装が必要な方々の参考になれば幸いです。ちなみに、以下に書いたもの以外に「これいいよ」というのがあったら、ぜひご教授願いたいです。 要件定義とチェックポイント 今回、日付入力欄を実装した際の要件は以下の通りです。生年月日のように年の選択が必須な日付の入力欄の実装だったので、たとえば、ホテル予約の日付選択などとはちょっと違った要件になっています。 a. 年が選択しやすい 生年月日の
誰も教えてくれない「分かりやすく美しい図の作り方」超具体的な20のテクニック
【追記】この記事をきっかけに、名著「ノンデザイナーズ・デザインブック」の20周年記念特典eBookの制作に協力させていただきました。詳しくはこちらを御覧ください。 ノンデザイナーズ・デザインブック20周年記念の特典に寄稿しました デザイナーである・なしに関わらず、仕事の中で伝えたいことを「図」で説明する機会は多々あります。提案書で事業内容を説明することもあるでしょうし、具体的な数値をグラフで説明することもあるでしょう。そんな中でこんな指摘を受けたことはありませんか？ ・最終的に何を言いたいのか結論が見えないよ。 ・関係性が複雑すぎて理解しずらいんだけど。 ・要素が多すぎて全てを把握するのが大変。 ・何をどこから見れば良いの？ ・結局一番言いたいことはなんなの？ ・文字サイズがたくさんありすぎてまとまりがないね。 ・安っぽいチラシみたいでダサイなぁ。 ・全体的にバランスが偏ってて不安定。 ・
なぜ日本が世界共通語「Emoji」を生み出したのか、そしてその影響とは／古川健介『TOKYO INTERNET』｜PLANETS
なぜ日本が世界共通語「Emoji」を生み出したのか、そしてその影響とは／古川健介『TOKYO INTERNET』 Daily PLANETSでは毎月第2水曜日に、古川健介さんの連載『TOKYO INTERNET』を配信しています。 今回のテーマは、日本社会で生まれ世界中に普及した「Emoji」です。この独特の表現形式がどのようにして生まれたのかを、日本語のデザイン特性や表現の歴史から紐解きます。 (イラスト・たかくらかずき) 絵文字の簡単な歴史を振り返る今回のテーマは「絵文字」です。絵文字の普及には日本が大きな影響を与えており、日本が絵文字を生み出した、といっても過言ではありません。 絵文字の起源には諸説あり、いま使われているような絵文字の原型は、もともとはアメリカの雑誌で使われた顔文字から、という説(※1)や、「:-)」という横から見た時に笑顔に見えるという、英語圏の顔文字が起源だ、とい
Googleは巨大なインフラをどうやってセキュアに保っているか。独自のセキュリティチップ利用やDoS対策、安全なソフトウェア開発など、全体像を解説したホワイトペーパーを公開
Googleのクラウドは間違いなく世界最大規模のコンピュータシステムです。膨大なハードウェアとソフトウェアから構成されるこの巨大なシステムを、同社はどうやってセキュアに保っているのか。そのことを解説したホワイトペーパー「Google Infrastructure Security Design Overview」が公開されました。 ホワイトペーパーには、Googleのデータセンターを構成するデバイスの1つ1つにまで独自のセキュリティチップを組み込んで正規のデバイスかどうかを相互に認証するという物理レベルのセキュリティから、何層のものロードバランサーからの情報を集約してDos攻撃を検知すると、その通信を破棄するといったDoS対策。 そしてマシンも従業員もサービスも包括するグローバルな名前空間など、きわめて広範かつ綿密なセキュリティ施策が説明されています。 クラウドがいかに高度なセキュリティで
Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
テストしやすいGoコードのデザイン
テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザイナーからプログラマーになって生きやすくなった話
Backlog UI リニューアルの舞台裏 / Backlog Renewal UI
【必見】プロデザイナーによるC91新刊怒涛の20作品レビューがめちゃめちゃ参考になる！（5作品追加）
