はじめに こんにちは、都内でソフトウェアエンジニアをしているYSasagoです。 私はフロントエンドの開発時に、Chromeのブラウザを使うことが多いです。 Chrome には開発を便利にするchrome 拡張機能がたくさんあります。 普段、フロントエンド開発時に私が使っている拡張機能を紹介したいと思います。 UI Build Assistant アイコンは IT 大学と面白いですが、こちらの拡張機能を使えば、ワンクリックで背景と線に色付けをしてくれて、レイアウトが見やすくなります。こちらの拡張機能を使うとマージンの調整等が簡単にできるようになりとても便利です。 また、作成者のしまぶーさんの Youtube 動画は、フロントエンド学習にとても有益なのでよく拝見させていただいてます。 OFF ON Responsive Viewer 次に紹介するのは、Responsive Viewer です
アクセシビリティとはアクセシビリティは、サービスや情報をどんな利用者も円滑に利用できるかの度合いです。 アクセシビリティが高いほど、より多くのユーザーが円滑に利用でき、アクセシビリティが低いほど、より多くのユーザーが利用できないということです。 アクセシビリティ向上は、障害当事者だけでなく、さまざまな環境や状況にいる人、高齢者、日本語以外を得意な言語とする人など、すべての人のためのものです。人だけでなく、サービスや情報にアクセスする機械(ロボット)もアクセシビリティの影響を受けます。 SmartHRの開発方針SmartHRは「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会を作る。」というミッションを掲げ、働くすべての人を後押しするプラットフォームをつくっています。 誰もがその人らしく働ける社会を実現するため、SmartHRはアクセシビリティの向上に取
AWSは、マネジメントコンソールなど同社が提供する製品やサービスのWebアプリケーション画面を構築するために開発したデザインシステム「Cloudscape」をオープンソースで公開しました。 Cloudscape Design System, an AWS solution for building intuitive user experiences, is now open source! Cloudscape consists of guidelines to create web applications, along with the design resources and front-end components to streamline implementation.https://t.co/M8wKGqzH5E pic.twitter.com/9JOtkMF8Bi — A
授業ではあまり習わないですが、UIデザインの実務において常に考えなければならないフレームワークの一つにThe five UI statesがあります。雑に説明するとUIは以下の5つの状態になる可能性があることを踏まえて、それぞれに対してデザインを作っておくというコンセプトです。 • 何も登録されていない状態 (Blank state) • ロードしている状態 (Loading state) • 不完全な状態 (Partial state) • エラーが起きている (Error state) • 理想的な状態 (Ideal state) 授業のプロジェクトや提案型プロジェクトではそこまで深く考えないのかもしれませんが、UIデザインの実務では相当な時間を占めていることが多いです😑 特に複雑な構造のB2BプロダクトだとError stateのUIパターンを一週間考え続けるみたいなことも多々あり
Webページやスマホアプリでよく見かけるレイアウト、ナビゲーション、UIコンポーネントなど、それだけを実装するHTMLとCSSのシンプルなコードをまとめたCSS Layoutを紹介します。 それだけを実装するため、HTMLとCSSのコードは非常にシンプル、カスタマイズも簡単だと思います。スニペットに登録しておくと、便利ですね。 CSS Layout CSS Layout -GitHub CSS Layoutの特徴 レイアウトやUIコンポーネントだけを実装するコード CSS Layoutの特徴 CSS Layoutは、よく使用されるレイアウトやUIコンポーネントだけを実装するためのHTMLとCSSのコードがまとめられたコレクションです。 MITライセンスで、商用プロジェクトでも無料で利用できます。 CSS Layout 依存関係は一切無し フレームワークは必要無し ピュアCSSで実装、CSS
ソシオメディアがまとめている、ヒューマンインターフェースをデザインする際の指針です。これらは、インターフェースデザインに関する様々な文献と、実際のデザインコンサルティングで得た知見をもとに、ソシオメディアが独自に編纂したものです。継続的に追加・更新していきます。 すべてモデルインタラクションプレゼンテーション
Mercari Advent Calendar 2019も、この記事を入れてあと3個となりました。最後まで読んでくださいね。 23日目はAutomation&QAグループで、Webのテスト自動化を行っている@AHA_oretamaがお送りします。 今回はWebの自動テストについて、この1年やってきたことを振り返ってみようかと思います。 Webのリアーキテクチャ 現在、Webではリアーキテクチャを進めています。 進め方としては既存のモノリシックなWebアプリケーションを残したまま、パス(例えばトップ /jp/ や検索ページ /jp/search/ )ごとに新しいWebアプリケーションにマイグレーションする方法をとっています。 影響範囲を小さくしつつその範囲の中でチャレンジが行えることがこの方法の利点です。 詳しくは去年のMercari Tech Confの資料をご覧ください。 speaker
こんにちは!普段都内でアプリやWebのUIデザインをやってます。nakattyanです。ついにnoteデビュー笑(というか個人としては人生初ブログ) 今回は個人開発でStockeyというアプリを作ったので、そのことについて書きたいと思います。一緒に開発してくれている相棒のエンジニアはこちらmn@D128 どんなサービスなのか?スクリーンショットを保存するアプリで、見やすく管理することを目的にしています。 なぜ作ったのか?・デフォルトのカメラロールにちょっとした課題があった ・デザインストック用のアプリが欲しかった ・1度個人でサービス作ってみたかった普段僕は気に入ったUIやグラフィックのスクショを撮って勉強に役立ててます。また仕事では競合サービスの比較をする際に、片っ端からスクショを撮って分析してます。 撮ったスクショのほとんどはPCに送ってグラフィックツールのアートボードに並べるケースが
こんにちは、iOSエンジニアのtakao(takaoh717)です 今回はクラシルiOSアプリのフィードのパフォーマンス改善を行った話をご紹介します。 改善を行ったフィードはUICollectionViewで構成されており、レシピ、画像バナー、広告など複数の異なる型のデータを表示しているような画面です。 今回行った変更は以下の内容です。 差分更新ライブラリの導入とデータの管理、更新ロジックの変更 セルのサイズ計算を事前に行うよう修正 通信時やログ送信時の重い処理をバックグラウンドスレッドで実行 改善前の課題 改善を行う前は、アプリを動かしていると実際に分かるレベルでパフォーマンスに問題がありました。 スクロール自体の挙動が若干重くてスムーズじゃない(指の動きに対して若干ひっかかりがある) ページングの読み込みをしたときにスクロールが止まることがある 更新時に画面がチラつくことがある 差分更
はじめに 「AndroidはiOSと同じデザインで!」と言われてどう実装しようか悩んでる方向けの記事です。 Androidアプリを作るなら当然マテリアルデザインガイドラインに合わせて1から画面設計するのが最高なんですが、そうはいかないことが経験上多いので対応案をざっくりまとめました。 諸注意 これは「iOSとAndroidのUI対応一覧」ではありません。 iOSとAndroidで同じような見た目のUI部品でも作られた経緯や目的は違うので、比較して置き換えるようなことは基本的にできないと思います。 とはいえなんの指標もないと辛いので、ここでは「iOSのこのUIをAndroidで代用できるのはこれかもね」くらいのニュアンスで列挙しています。 必ずしもどのアプリにも言えるようなことではないので、あくまでたたき台と思ってください。 「なぜAndroidらしくする必要があるのか」についてはこ
円滑にiOS/Android同時開発するための心得まとめ ■設計 ◇UIパーツやフレームワークはそれぞれの素材・特長を活かす 当然ながら共通設計 define値やクラス名などを統一する 永続化する項目を統一する UIデザイン マージンやセンタリングなどのルール統一 端末/画面サイズに応じて、固定/可変する箇所の認識を合わせる 無理やりiOSのパーツをAndroidに適用しない ダイアログやドラムロール(ピッカー)などのUIパーツ iOSのタブ機能はAndroidでは画面上部かサイドメニューを検討 戻る機能はAndroidではBackキーを活用 それぞれの特長を活かす iOSではSQLiteを直接使用せずCoreDataを使用するなど ■実装 ◇開発者間の情報共有を密にする! LOGの記述体裁を合わせる ファイル名、メソッド名、行数、コメントなど体裁を合わせる (ついでに…LOGはデバッグで
どうもこんにちはJBです。 アプリの開発&デザイン時に、関わる人たちがデフォルトのUIコンポーネントについてきちんと知っているとお互い話が通じやすいし、設計もしやすいですよね!という訳で、今回はiOSのデフォルトUIコンポーネントについてまとめてみたいと思います。 昔、「あの、あれだよ、あの青くてなんか切り替わるヤツ!」「Segmentted Controls?」「何それ」みたいな会話が繰り広げられて時間と労力を多少無駄にしました。 開発しない人も名前ぐらいは知ってた方が良いですね…と言う事をひしひし感じております。そんなわけでiOS8が出るか出ないかくらいの時期に空気を読まず、今回の記事です。 すべて網羅している訳ではないのと、色々端折っておりますのでその辺はあしからずですよ。詳しく知りたい方は、iOSのヒューマンインターフェースガイドラインをご覧ください! それでは行ってみましょう!
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
はじめに これは自分用のメモでもありますが、同時にもし「Storyboard 面倒くさい!ソースコードのみで UI 作りたい!」というような方がいらっしゃいましたら、ご参考になれればと思います。 また、ソースコードは GitHub に公開しております。 なぜコードで UI 作るか ぶっちゃけ言いますと自分 Storyboard 使えないだけです。はい。そもそも以前 Interface Builder の時代からまともにそういったツール使ったことなかったし、要素配置とかページ遷移とかもどうやって作ればいいのかわからないし、今まではゲームを作ってきたから iOS 特有の画面遷移とかも特に使ったことなかったし、あとマウスよりもキーボードのほうが速いってのもありますね。まあ要するに自分にとってソースコードのほうが画面配置がわかりやすいです。 実際作ってみる 目標と手段 まあ何事もまずは目標を決める
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く