このガイドラインは、よくある問題を回避し、高品質の Glassware を作成するプロセスについてご案内するものです。
呼び出し
Glassware が承認済みの音声コマンドを使用していることを確認します。
Glassware が承認済みのコンテキスト コマンドを使用していることを確認してください。
Mirror API は、ユーザーからリクエストを受信し、リアルタイムまたは低レイテンシで応答するようには設計されていません。これが要件である場合は、GDK を使用します。
たとえば、Mirror API Glassware は、「take a note」や「post an update」コマンドと適切に連携します。これは、ユーザーがコマンドを呼び出した後に Glassware からの応答を待つ必要がないためです。
一方、「タイマーを開始」や「楽器をチューニングする」は、Mirror API Glassware ではうまく機能しません。ユーザーがエクスペリエンスがすぐに開始されることを想定しているためです。
ユーザーが Glassware とその機能を呼び出す主な 2 つの方法は、[ok glass] メインメニューの音声コマンドまたはタップコマンドを使用する方法と、タイムライン カードのコンテキスト メニューを使用する方法です。
Glassware を起動する目的で、メニュー項目を含むタイムライン カードを固定するようユーザーに強制してはなりません。Mirror API は、ユーザー構成に基づく定期的な通知、または連絡先とコンテンツを共有するように設計されています。
GDK Glassware の起動や Mirror API の呼び出しのためのメニュー項目は、エクスペリエンスが定期的な通知設計パターンと一致し、 即時の対話性のための Mirror API を使用しない限り、提供しても問題ありません。
たとえば、ペットの引き取り用 Glassware がタイムライン カードを挿入して、後で機能にアクセスするためにユーザーにそのカードを固定するよう強制するべきではありません（「犬を検索」、「猫を検索」、「鳥を検索」など）。代わりに、グラスウェアでは、ユーザーが希望するペットの条件を設定し、この条件を満たすカードを定期的に配信できるようにする必要があります。これらのカードには、「プロフィールを読む」や「ペットを引き取る」などのアクションを実行するためのメニュー項目を含めることができます。
Glassware を明示的に呼び出した場合は、その動作をユーザーに明示する必要があります。
デザイン
Glass は、適切なタイミングで提供される少量の情報向けに設計されています。モバイルアプリからすべての機能を移植すると、Glass ではうまく機能しません。代わりに、Glass でうまく機能する主なユースケースを見つけて、魔法のような機能を提供することに重点を置きます。アイデアを得るには、Design for Glass をご覧ください。
- ライブカードをタップすると、常に Glass メニューが表示されます。ライブカードをタイムラインで非表示にするには、ライブカードすべてに [停止] メニュー項目が必要です。
- ライブカードが没入が開始されると、前回終了したイマーシブの時点まで移動されます。これは理にかなっているからです。
- 没入型でスワイプやタップを行うと、常にジェスチャーが使用されなかったというアクションまたはフィードバックが生成されます（水平方向の引っ張りなど）。
- Glass システムのように動作しないジェスチャーには、使用方法を明確に説明し、結果を明確に示す必要があります。
- Glass システムが提供する UI 要素と同様の UI 要素を作成する場合は、代わりに Glass システムが提供するものを使用してください。たとえば、独自のビューを実装する代わりに、カード スクロール ビューを使用します。
- 没入型の機能は、集中して行う必要があるタスクに使用します。それ以外の場合は、ライブカードや静的カードなどの他のオプションを使用することをおすすめします。
可能な限り、承認済みのカードデザインを使用してください。これらの設計の一部では、Mirror API と GDK のテンプレートを利用できます。
- Mirror API を使用している場合は、base_style.css のスタイルを使用します。
- パディングとスペースについては、組み込みテンプレートの一般的なルールに従ってください。
バンドルとページ分けを使用するとカードをグループ化できますが、次の状況では正しく使用する必要があります。
注: 分類機能とページ分割機能は、Mirror API に組み込まれています。GDK で同じ機能を実現する場合は、Mirror API でバンドルとページネーションが可能な限り近い形で示される方法を模倣してください。スタック インジケーター、メニュー項目、カード スクローラーを使用してカードを表示します。
バンドル
- 類似したカードのグループには、バンドルを使用します。ただし、同じカードに含めてはいけません。
- バンドルの表紙カードは、バンドルに含まれるカードとは視覚的に異なるダイジェストとなるようにデザインします。
- バンドルごとに 1 回だけ通知音でユーザーに通知します。
バンドルが適しているケース:
- メールのスレッドまたは短いメッセージ
- 同じ人間での 3 件の SMS メッセージ
- 1 時間以内に撮影された 5 枚の写真
- 関連記事が一度に挿入されました
- 進行中のスポーツ試合のキーイベントとスコアの最新情報のリスト
バンドルがうまく機能しないケース:
- サービスのすべてのコンテンツ
- 1 日の間に多数の見出しが Glass に送信されます
ページネーション
スペースの制約により 1 枚のカードに収まらないが、それ以外の場合は同じカードに配置する必要があるタイムライン アイテムにページ分割を使用します。
ページ分けが効果的なケース:
- 1 枚のカードに収まらない 1 件のメール、ニュース、または同様のコンテンツ
ページ分けがうまく機能しないケース:
- 複数のニュース記事やメールなど、個別のカードのグループ
Glassware が、Glassware のその他のベスト プラクティスに準拠していることを確認します。
ウェブ プロパティ
- ウェブから Glass にコンテンツを送信する場合は、[Glass に送信] アイコンを使用します。
- Glassware をダウンロードするためのリンクを提供する場合は、[Get it on Glass] アイコンを使用します。
- 文法の誤りや誤字脱字に注意してください。
- 認証ページまたはログインページが 3 ページを超えることがない。
- 設定は、妥当な期間（3 か月未満）内では再認証を必須としないでください。
- アカウントまたはコンパニオン アプリが必要な場合、サービスのアカウントを持っているユーザー、または持っていないユーザーの承認フローは明確です。
- 認証ウェブページの URL は、設定ウェブページの URL とは異なる必要があります。
- ユーザー アカウントが必要な場合、Glassware はユーザー アカウントに接続せずにユーザーを認証することはできません。
- 設定の変更が保存されたことを視覚的に示せます。
- コンテンツの関連性を維持するため、全体およびフィードごとに更新頻度を指定します（該当する場合）。次のスクリーンショットは、ユーザーが更新頻度とフィードタイプを設定できるようにする例を示しています。
Branding（ブランディング）
Glass ブランドとその関連アセットは独自のものであり、Google が慎重に設計し、使用しています。
- [アセット](/glass/tools-download/download) ページで提供されている場合を除き、いかなる方法でも、Glass 独自のロゴやアセットを使用、変更、模倣しないでください。
- 製品で使用するために Glass ロゴのフォントを使用、変更、模倣しないでください。
文章作成
Glassware とそれに関連する説明は、デフォルトでは英語で記述する必要があります。言語間で完全に同等の機能があれば、複数の言語を使用しても問題ありません。
Glassware の名前が、Glassware の機能やブランディングを正確に表していることを確認してください。「for Glass」というフレーズにならない限り、名前に「Glass」という文字列を使用しないでください。たとえば、「ガラスの猫に関する情報」は問題ありませんが、「ガラスの猫に関する情報」や「ガラスのような猫の写真」は使用できません。
制限とガイドラインについては、テキスト内のガラスのセクションをご覧ください。
該当する場合は、ガイドラインに沿って書いてください。
テスト
実際の Glass ハードウェアで Glassware を実行します。これは、ユーザー エクスペリエンスを正確に測定する唯一の方法です。また、GDK Glassware によって、ガラスの過熱などの予期しないパフォーマンスが発生しないようにします。