<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ベイジの社長ブログ &#187; モバイル</title>
	<atom:link href="https://baigie.me/sogitani/category/%e3%83%a2%e3%83%90%e3%82%a4%e3%83%ab/feed/" rel="self" type="application/rss+xml" />
	<link>https://baigie.me/sogitani</link>
	<description>マーケティング、デザイン、キャリア</description>
	<lastBuildDate>Tue, 24 Sep 2019 11:38:02 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.1.41</generator>
	<item>
		<title>アップルとグーグルのガイドラインに学ぶスマホWebデザインの要点（スライド付）</title>
		<link>https://baigie.me/sogitani/2015/07/apple-google-design-guideline/</link>
		<comments>https://baigie.me/sogitani/2015/07/apple-google-design-guideline/#comments</comments>
		<pubDate>Tue, 07 Jul 2015 07:00:49 +0000</pubDate>
		<dc:creator><![CDATA[枌谷 力]]></dc:creator>
				<category><![CDATA[Webデザイン]]></category>
		<category><![CDATA[Web制作]]></category>
		<category><![CDATA[モバイル]]></category>

		<guid isPermaLink="false">https://baigie.me/sogitani/?p=3203</guid>
		<description><![CDATA[スマートフォン対応させるWebサイトが急増しています。しかし、スクリーンが小さくタッチ操作がメインのスマートフ [&#8230;]]]></description>
				<content:encoded><![CDATA[
<p>スマートフォン対応させるWebサイトが急増しています。しかし、スクリーンが小さくタッチ操作がメインのスマートフォンでは、デスクトップ向けWebサイトのデザインで培ったノウハウの多くが通用しません。このような時代におけるスタンダードなデザインルールを学ぶために、弊社デザイナーの荒砂を中心に、Appleが公開しているiOS Human Interface Guidelineと、Googleが公開しているMaterial Design Guidelineの比較を行いました。（以降、両者をガイドラインと略します）</p>
<p>スマートフォン向けのWebサイトのデザインを考える上で、アプリのUIデザインの定石を知ることは重要です。なぜなら、スマートフォンにおいてはWebサイトをブラウズする機会は14％しかなく（comScore調査／2014）、多くの時間をアプリの中で過ごしているためです。さらにユーザは「これはアプリ」「これはWebサイト」という区別はしていません。そのため、一般的なアプリとWebサイトの振る舞いが異なると、ユーザを戸惑わせる原因になりえます。</p>
<p>AppleとGoogleのガイドラインを比較する目的は、両者に共通する部分、いずれかが優れた部分を抜き出し、スマートフォン向けのWebデザインにおけるセオリーを学習するためです。</p>
<p>以下は、主な比較項目をまとめたスライドです。詳細はスライドを見ていただくとして、要点のみをこのエントリーでは記載しておきます。</p>
<p><iframe style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" src="//www.slideshare.net/slideshow/embed_code/key/493FYnBvQrOIkc" width="720" height="554" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" allowfullscreen="allowfullscreen"> </iframe></p>
<h2>1. 文字</h2>
<h3>1-1. 最小サイズ</h3>
<p>欧文＝11pt、和文＝13pt</p>
<p>Apple、Googleともに文字の最小サイズに関する具体的な指定があります。双方を判断し、欧文は11pt相当、和文は13pt相当を最小サイズとするのが良いでしょう。</p>
<h3>1-2. 見出し</h3>
<p>13pt←15pt（基準）→17pt→21pt→24pt→34pt→45pt→56pt→112ptでサイズ変化</p>
<p>Appleには指定がありませんが、Googleでは、 欧文・和文ごとに、サイズ、ウエイト、行間についてかなり細かく指定されています。Googleのガイドラインはあくまでマテリアル・デザインのためのガイドラインであるため、厳密に踏襲する必要はないでしょう。ただ、デザインをシンプルにするためには、見出しの装飾を極力抑える必要があり、そうなると、文字サイズの違いで見出しレベルを表現しなければならなくなります。その参考値として、Googleが規定している文字サイズを捉えておくとよいのではないでしょうか。</p>
<h3>1-3. 行長</h3>
<p>欧文＝60字以内、和文＝30字以内</p>
<p>Appleに指定はありませんが、Googleには欧文のみ、本文は60文字以内、見出しは40文字以内で折り返すという指定があります。これを参考とし、欧文では60字以内、和文は30字以内を行送りの基準と捉えるといいでしょう。</p>
<h3>1-4. 字間</h3>
<p>大きな文字は狭く（-5～-10）、小さい文字は広く（+5～+10）</p>
<p>Apple、Googleともに、文字が小さいほど字間を広くし、大きいほど狭くすべきと書かれています。Googleではトラッキングの値も明確にされています。こちらも厳密に踏襲する必要はありませんが、大きな文字は狭く（-5～-10）、小さい文字は広く（+5～+10）、という定石があると捉えておくとよいでしょう。</p>
<h3>1-5. 書体</h3>
<p>書体の種類、ウエイトはできるだけ少なく</p>
<p>Appleでは書体を一つに絞る、Googleでは決められた書体を使う、と規定されています。書体はCIやブランド戦略が優先されるべきであり、やはり厳密に踏襲する必要はありません。ただし、書体数、ウエイト数はできるだけ少なくする、というのがセオリーであることは、念頭に置いておくとよいでしょう。</p>
<h3>1-6. 色</h3>
<p>文字色と背景色の輝度を「4.5:1」以上に</p>
<p>Apple、Googleともに、文字色と背景色のコントラストに関する具体的な規定があります。Googleは色の指定まで行っていますが、これを遵守するとブランドに合わせた配色ができなくなります。ここではAppleのガイドラインを優先し、輝度を「4.5:1」以上の比にする、と捉えておくと良いでしょう。</p>
<h2>2. ボタン</h2>
<h3>2-1. サイズ</h3>
<p>横96px×縦96px以上（物理サイズ9mm×9mm以上）</p>
<p>Apple、Googleともに、ピクセル数や物理サイズの規定があります。やや大きめのGoogleを参考値とするのがよいでしょう。</p>
<h3>2-2. 形</h3>
<p>一般的な形状で、種類は3つ以内に</p>
<p>Apple、Googleともに、形状に関する記述があります。Appleはテキストのみの表現としていますが、これは難しい制約でしょう。フラット（文字のみ）、ライズド（長方形）、フローティングアクション（円形）と3種類の形状を設定しているGoogleのガイドラインの方がより現実的といえます。厳密に守る必要はありませんが、一般的な形状を採用する、種類は3つ以内に押さえる、と捉えておくとよいでしょう。</p>
<h3>2-3. 装飾</h3>
<p>立体表現を用い、最低限の装飾を施す</p>
<p>Appleではグラデーションやドロップシャドウなどの立体表現を非推奨とし、Googleでは立体表現の活用を推奨しているのが対照的です。フラットデザインのミニマリズムは継承しながら、より分かりやすいUIを規定したのがマテリアル・デザインという歴史に習うわけではありませんが、やはりGoogleのガイドラインの方が現実的でしょう。装飾過多になるは避けながらも、立体表現も活用し、リンクをリンクと認識できるルールをサイト内に敷設すべきです。</p>
<h3>2-4. マージン</h3>
<p>ボタン同士は16px以上離す</p>
<p>Googleのみ、隣接するボタン同士は16px相当以上空ける、という規定があります。基本的にはこれを参考値として捉えるとよいでしょう。</p>
<h3>2-5. ラベル</h3>
<p>シンプルな動詞を用いる</p>
<p>ボタンのラベル（文字）について、Appleのみがシンプルな動詞を用いるべきという記述があります。Webサイトもこれに準じるのが良いでしょう。</p>
<h3>2-6. 配置</h3>
<p>目的を達成するボタンを右、行動を取り消すボタンを左に</p>
<p>行動を選択させるボタンを左右のどちらに配置するか、ということについて、Appleでは破壊的かどうか、Googleでは肯定的かどうかを基準としています。UXに従って考えるべきで、通り一辺倒のルール化は禁物ですが、多くの場合、目的を達成するボタン（「確認」、「実行」など）を右側、行動を取り消すボタン（「キャンセル」「クリア」など）を左側に置くのが基本と捉えておくのがよいでしょう。</p>
<h2>3. 配色</h2>
<h3>3-1. 原則</h3>
<p>色を多用せず、基本色は2色以内に。機能上の必然性に従いルール化</p>
<p>Appleでは、色は対話の手段であり使いすぎてはいけない、と記述されています。Googleではプライマリカラーとセカンダリカラーの2色を選び、さらにその各色から3色相を選ぶ、という具体的な規定がなされています。色もブランド戦略の影響を受けるものであり、何も考えずAppleやGoogleに従うべきではありませんが、色は機能を補完するもの、ユーザフレンドリーなUIにはシンプルな配色が望ましい、という基本は押さえておくべきでしょう。</p>
<h3>3-2. コントラスト</h3>
<p>前景色と背景色の輝度を4.5 : 1以上に</p>
<p>Appleには数値化された明確な規定があり、Googleには「コントラストを確保する」という緩やかな記述があります。様々な光量下での閲覧が想定されるスマートフォン向けのWebサイトでは、コントラストがユーザビリティに大きな影響を与える可能性があります。ここではより厳密なAppleを踏襲し、前景色と背景色の輝度比を「4.5 : 1」以上に保つと考えておきましょう。</p>
<h2>4. アイコン</h2>
<h3>4-1. 形</h3>
<p>シンプルで分かりやすいものに</p>
<p>両社ともにシンプルであるべきと規定されています。Appleではストロークについて、Googleではベースの形状にまで言及していますが、シンプルという大きな指針のみ、参考にするのが良いでしょう。</p>
<h3>4-2. 色</h3>
<p>基本は単色。非選択時は塗り方とコントラストも調整</p>
<p>Appleでは、選択時と非選択時の色の塗り方に関する言及があります。Googleでは、色の濃度を%で指定しています。双方とも厳密に守る必要はありませんが、単色が基本であるというのは、意識しておくとよいでしょう。</p>
<h3>4-3. モチーフ</h3>
<p>誰もが分かるモチーフに</p>
<p>Googleの、無生物に人間らしさを与えない、という記述が特徴的ですが、これに従うべきかは議論の余地があるでしょう。Appleが規定している「ユーザが認識しやすい普遍性」というのは順守すべき基準になりえるでしょう。独創的なアイコンはNGということです。</p>
<h3>4-4. サイズ</h3>
<p>アイコン本体は24 x 24 px～50 x 50 pxの間、タッチエリアは44 x 44 px以上</p>
<p>Apple、Googleともにサイズに関する規定があります。両者を統合し、アイコン本体は24 x 24 px～50 x 50 pxの間とし、タッチエリアは44 x 44 pxを最小値とするのがよいでしょう。</p>
<h2>5. その他</h2>
<h3>5-1. イメージ</h3>
<p>必然性のある自然で具体的な画像</p>
<p>Googleのみ、画像は飾りではなくツールである、という考え方が述べられています。厳密や制約事項はありませんが、目的に対して明確に機能する自然で具体的な画像であるべきという考え方は、一つの指針にできるでしょう。</p>
<h3>5-2. レイアウト</h3>
<p>左上が起点。グルーピングと階層化を活用。8がグリッドの最小値</p>
<p>Apple、Googleともに、それぞれ異なる視点からレイアウトに関する言及があります。双方を統合して参考にするのが良いでしょう。</p>
<h3>5-3. ライティング</h3>
<p>ユーザの知識に合わせた簡潔な表現</p>
<p>Appleでは術後を用い、Googleでは簡潔さを満たすいくつかの基準が示されています。いずれも普遍的なことであり、UIに載せるコピーの参考にできるでしょう。</p>
]]></content:encoded>
			<wfw:commentRss>https://baigie.me/sogitani/2015/07/apple-google-design-guideline/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>スマートフォン用サイトで動画を扱う時のポイント</title>
		<link>https://baigie.me/sogitani/2011/07/smart-phone-movie/</link>
		<comments>https://baigie.me/sogitani/2011/07/smart-phone-movie/#comments</comments>
		<pubDate>Fri, 01 Jul 2011 02:17:16 +0000</pubDate>
		<dc:creator><![CDATA[枌谷 力]]></dc:creator>
				<category><![CDATA[モバイル]]></category>
		<category><![CDATA[技術]]></category>

		<guid isPermaLink="false">https://baigie.me/sogitani/?p=53</guid>
		<description><![CDATA[最近スマートフォン用サイトの引き合いが増えてきていますが、そこで培ったノウハウもこのブログで紹介していこうと思 [&#8230;]]]></description>
				<content:encoded><![CDATA[
<p>最近スマートフォン用サイトの引き合いが増えてきていますが、そこで培ったノウハウもこのブログで紹介していこうと思います。今回は、スマートフォン（およびタブレット）用サイトでの動画の取り扱いについて。</p>
<p>スマートフォンで動画というと、真っ先に思いつくのはYoutubeにアップしてリンクを張り付ける方法ですが、企業の内規や動画の性質によっては、Youtube上に動画をアップすることができない場合もあります。先日担当したキャンペーンサイトもまさにそうでした。というわけで、ここではYoutube貼り付けじゃない方法での、スマートフォン/タブレット端末用サイトで動画を掲載する際のポイントをご紹介します。違ってるところがあればコメントでご指摘いただけると幸いです。</p>
<p>ちなみに、プラットフォームやOS毎の実装状況をひとまずまとめると以下の通り。なお、スマートフォン/タブレット版はデフォルトブラウザでの利用が前提です。</p>
<p><img class="alignnone size-full wp-image-74" title="図" alt="" src="https://baigie.me/sogitani/wp-content/uploads/da9c8fe340571bb3c3001d536a63234d2.gif" width="730" height="220" /></p>
<h3>MPEG4</h3>
<ul>
	<li>MPEG4であれば全てのプラットフォームで再生が可能。</li>
	<li>ただし、動画の中に含まれるメタデータが異なると、同じMPEG4でも環境によって再生ができない。</li>
	<li>そのため、MP4BOX（<a href="http://www.videohelp.com/tools/MP4Box" target="_blank">http://www.videohelp.com/tools/MP4Box</a>）のようなアプリケーションでメタデータを書き換える必要あり。これを行うと、iPhone/iPadでも、Androidでも、PCの各種OSでも再生できる動画になる。</li>
	<li>ブラウザ上でMPEG4の動画をクリックすると、スマートフォンでは専用アプリケーションが立ち上がり、タブレットではブラウザ内で再生される。（PCと同じ挙動）</li>
</ul>
<h3>FLV</h3>
<ul>
	<li>FLVは再生するためにFLASH（SWF）で作成されたFLVプレイヤーが必要になる。必然的に、FLASHの実行を許していないiPhone/iPadといったiOS系端末では再生できない。</li>
	<li>Android系でFLVを再生する場合、専用アプリケーションではなくブラウザ内で実行される（PCと同じ挙動）。ただし、スクリーンサイズが小さいと見づらくなるので、Android系スマートフォンでもMPEG4で専用アプリケーション内で閲覧させるのがいい。</li>
</ul>
<h3>Videoタグの設定方法</h3>
<ul>
	<li>MPEG4をHTMLに埋め込むにはvideoタグを用いる。</li>
	<li>動画を複数表示する場合には、デフォルトでの読み込みを停止する「preload=&#8221;none&#8221;」は必須。そうしないと、全ての動画を読み込みに行ってしまう。CPUが非力なスマホではロード中に挙動が極端に悪くなる。</li>
	<li>poster属性を設定しないとサムネイルがなく真っ黒の状態になる。</li>
	<li>「onclick=&#8221;this.play();&#8221;」がないとandroid系端末で再生できないことがある。</li>
	<li>iPadでは「controls」を設定しないとブラウザの動画再生用UIが表示されず、再生のコントロールができなくなる。</li>
	<li>videoタグ内にvideoタグ未対応端末へのメッセージを入れる。</li>
	<li>上記を踏まえると、各種プラットフォームに対応した基本フォーマットは以下のようになる。 &lt;video src=&#8221;xxxxx.mp4&#8243; preload=&#8221;none&#8221; poster=&#8221;xxxxx.jpg&#8221; onclick=&#8221;this.play();&#8221; controls &gt; &lt;source src=&#8221;xxxxx.mp4&#8243;&gt; &lt;div&gt;動画を再生するには、videoタグをサポートしたブラウザが必要です。&lt;/div&gt; &lt;/video&gt;</li>
</ul>
<h3>MPEG4とFLVの切り替え</h3>
<ul>
	<li>MPEG4であればプラットフォームに依存しないで再生できる。ただ、タブレットでは基本的にPC版と同じサイトを見せることがほとんどだろう。PC版サイトではデザイン性やJSを使ったブラウザとの機能連携などの観点から、FLVでの再生が望ましいことも多い。そこで、スマホとiPadはMPEG4、PCとAndroid系のタブレットはFLVというのが、現状での最適解か。</li>
	<li>PC/タブレット共通サイトにおける、iPadの振り分けはJSで行う。ユーザエージェントがiPad以外の場合FLVを表示し、iPadの場合にはvideoタグを使ってMPEG4を表示する。</li>
</ul>
<h3>その他注意点</h3>
<ul>
	<li>3G回線を考慮すると、動画のビットレートは200kbpsあたりがよい。</li>
	<li>iPhone/iPadの場合、ThickboxなどのJSライブラリを使って、動画の上にフロートウィンドウを表示させると、フロートウィンドウの下にある動画が優先的にタップされてしまう。つまり、フロートウィンドウ内にあるリンク要素をタップしても、その下にある動画が再生されてしまう。スマホやiPadをターゲット環境に含めるサイトは、動画の上に何かを被せるようなUIにしないほうがよい。</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>https://baigie.me/sogitani/2011/07/smart-phone-movie/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
