フォント大好きデザイナーのベーコン(@dogdog464646)です! 良質なデザインを作るには、良いフォントが欠かせません。 それでは、「良いデザイン」ってなんでしょう? ちょっと頭に思い浮かべてみてください 例えば… ・かわいいデザイン? ・お客さんが使いやすいデザイン? ・意味が伝わりやすいデザイン? こんな感じでしょうか? じゃあ正解の発表です 正解は… 全部です! というかデザインの正解は、状況によって変わるんですよね なので、状況によって変わる「いいデザイン」に対応するためには「たくさんの種類のフォント」が必要になります たくさんの種類のフォントで、表現の幅を広く持つことで、デザインを正解に導きやすくなります この記事はデザイナーだけではなく ・イラストレーター ・エンジニア ・ブロガー ・プレゼン資料を作っている人 ・学校やサークルでチラシを作る人 このような人たちに役立つ、
YouTube YouTube logo maker. Roll your own logo by adjusting the texts in the logo of various major brands. Legal Notice: The logo portrays a parody of a commercial logo that is the legal property of YouTube, LLC. This is an unofficial version, based on the "Fair use" doctrine. This site is not endorsed by nor related to YouTube, LLC in any way. We disclaim any responsibility for any legal issues r
はじめに 本記事では2017年の5月にSketchのプラグイン、Craftの新機能として追加されたプロトタイプ機能、Craft Prototypeをご紹介します。 Craft Prototypeによるメリットと現時点で見つかっている問題点などもみなさんにお伝えできればとおもいます。 最後には簡単なデモをします。Craft Prototypeを使用しようか迷ってらっしゃる方の一参考となればと思います! CRAFTとは CraftとはSketchとPhotoshop用の無料プライグイン集です。 普段、ダミーで画像や文字などを入れることが多いデザイナーの方もいらっしゃるんではないでしょうか? Craftの一機能として、写真や画像をリアルデータの形で出力してくれる、というものがあります。 例えば、画像は「Getty Images」や「iStock」などから取ってきてくれます。 画像を入れる際には、
Figma:https://www.figma.com/ (2019 年 12 月 1 日 : 古くなって意味消失してた部分を編集しました) Figma とは デザインツール、Figma をご存知でしょうか。 一言で表すならば、コラボレーション機能満載の Sketch です。 本記事を公開した 2017 年時点では、あまり知名度が高くなかったものの、2019 年時点ではだいぶユーザーが増えたように感じます。Google Trends で、Sketch と XD、そして Figma の今と昔を比較してみます。 2017 年 2019 年 (純粋には比較できませんが)2 年前は Sketch と Figma に約 25 倍も開きがありました。ですが現時点では約 10 倍くらいでしょうか。日本ではなんと逆転しています。(タイトルの通り!) そこでもう少し Figma に頑張ってもらうべく、本記事
Holiday 事業室の多田です。先日 Elasticsearch の記事を書いた内藤と共に Holiday ( https://haveagood.holiday ) の開発を行っています。 Holiday は、去年9月に Web 版をリリースしましたが、よりおでかけを楽しくするために今年3月に iPhone アプリをリリースしました(ダウンロードはこちら)。 アプリの開発過程ではコンセプトや仮説を立て、その検証や実現のために作っては壊すことを何度も繰り返し行いますが、実現したい価値を提供するためには、出来上がったプロダクトの細部のインタラクションも重要になってきます。細かい部分に気を配り使い心地を良くしてこそ、本当に提供したい価値をまっすぐに届けることができるためです。逆に言えば、最後の最後で細かい部分がちゃんとしていないばかりにそれまでの過程が無駄になったらもったいないですよね。 今
VASILYデザイナーチームが2月にデザインインスピレーションを受けたアプリをご紹介VASILYでは、より良いアウトプットをするためにもデザインインプットの時間を週1回設けています。画面遷移であったり、ちょっとしたアニメーションなど優れたUIをチームで共有し、実際にiQONのUIやUXという部分に反映しようと日々、試行錯誤しております。 今回はその中で、VASILYデザイナーチームが2月にデザインインスピレーションを受けたアプリをいくつかご紹介したいと思います。 1. Spring Apple Design Award 2014にも選ばれている、NY発の新コマースファッションアプリ。 ユーザ発信のコンテンツをブランドが上手く活用するという手法を取り入れています。 買い物本来の楽しさを味わってもらえるよう、あえてシンプルな構成にしているそうで、全体的に繊細で上品なアプリというイメージを
by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい&メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例えば、データがない場合にNULLにするか or 空配列にする or property自体がないなどきめる pagingの場合とか複数のパターンが存在することを覚えておくと幅が広がる。単純なページング or twitterみたいなsince_idなど起点id以
ベスト・プラクティスは多くの人には固定的なものだ。しかし本来は流動的なもので、革新者によって大きな変化が起きる。ウェブ制作におけるベスト・プラクティスも変化しており、その過程でいくつも失われていった。 ウェブ制作においては、技術革新の多い世界であることと、他の世界の変革に対応しなければならないことから、よりいっそう変化が速いとも言えるだろう。だからといってベスト・プラクティスが意識するに留めておけば良いという程度のものというわけではない。例えば<!DOCTYPE html>について考えてみよう。 <!DOCTYPE html> これはHTML5が産声を上げた時期に先駆者である人々が編み出した魔法の言葉だ。これによりほとんどすべてのブラウザーでウェブ標準に準拠した形でHTMLが表示されることが保証される。つまり個々のブラウザーで大幅に違う挙動になることはなくなり、予期せぬ問題の発生を大幅に低
Replacing Throwing Exceptions with Notification in Validations If you're validating some data, you usually shouldn't be using exceptions to signal validation failures. Here I describe how I'd refactor such code into using the Notification pattern. 09 December 2014 I was recently looking at some code to do some basic validation of some incoming JSON messages. It looked something like this. public v
Flows are just as important to good interfaces as individual screens are. Customers don’t land on screens from out of nowhere. Specific sequences of actions lead customers through your app as they try to accomplish their tasks. But as important as they are, flows are hard to communicate during the design process. Drawing out every state of a flow is too time-consuming. And drawings become instantl
2014.11.19 / UI 画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール Tomohiro Suzuki クライアントやディレクターから渡された画面遷移図を元にワイヤーフレームを作ってみると、後から足りない画面が次々に発見された、または画面内の情報がどこに繋がるのか分からないといった経験はありませんか? この画面遷移図というものは本来は制作範囲の全体像と構造を明確にし、必要な画面というものを洗い出したりするものです。通常のWebサイトであれば、従来のような画面遷移図でも問題ないかもしれませんが、多くのインタラクションが発生するサービスの設計では複雑化しやすく、何度も情報を行き来して確認することになるため時間がかかります。 原因のひとつとして、画面遷移図では画面名のみを記載して繋げていくことになるため、必要な情報が不足していることが挙げられます。その結果、本来で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く