Nexus 4を最近更新すると、ブラウザに新機能が追加され、下にスクロールするとアドレスバーが消え、ウェブページが全画面表示になります。上にスクロールすると、アドレスバーとオプションが表示されますバック。
これは、ログイン時にLinkedIn Webサイトにも表示されます。下にスクロールすると「navbar」が非表示になり、次に少し上にスクロールすると再び表示されます。
このような機能をWebサイトに実装する利点と欠点は何ですか?
私が考えることができるいくつか:
ユーザーを混乱させる
デバイス間で一貫して実装するのが難しい
これはかなりスマートなパターンだと思います。
用語を明確にするために(私はTwitter Bootstrapを参照として使用しています):
静的なメニューの場合を考えてみましょう:-下にスクロールすると消えます。 -もう一度表示するには、一番上までスクロールする必要があります。 -コンテンツが狭くて長いモバイルデバイスでは特に迷惑です。
これとは対照的に、Autoshow Fixed Menuは、ユーザーが上にスクロールする必要をなくします(かなりの数の手のジェスチャーになる可能性があります)。コンテンツは上から下に読み込まれ、X回下にスクロールした後にメニュー操作が必要であると想定しています。
おっしゃったように、これにより画面上により多くのコンテンツが表示されるようになります。これはモバイルデバイスにとってより重要です。
現在、ユーザーはメニューを表示するために一番上までスクロールすることに慣れているため、この動作に深刻なフローを見つけることは困難です。さらに、ユーザーは、メニューがスクロールダウンで消えた場合、メニューがスクロールアップで表示される(反対のアクション)と簡単に結論付ける必要があります。
私のポイントは、どのようにそれを見るかに関係なく、このパターンの振る舞いを学ぶことは簡単で瞬時であるべきだということです。
このパターンは、問題のテンプレートに長いコンテンツが含まれており、メニューの操作が頻繁にスクロールされる場合に適しています。
私の想定では、コンテンツが豊富なアプリケーションでこれをますます目にすることになります。 1つの極端な例はPinterest-コンテンツ中心のアプリケーションとして、追加のユーザーアクションの後に多くの対話コントロールが表示されます(たとえば、クリックすると、さまざまな対話オプションが表示されます)。モバイルPinterestは、トップメニューだけでなく、下部のメニューも表示/非表示にします。
ブラウザーのこの機能とWebサイトのこの機能を比較しないように注意してください。これは、人々が(通常)単一のWebサイトよりもはるかに多くブラウザーを使用するため、新しいブラウザーの動作をより速く習得し、慣れる傾向があるためです。ウェブサイトでの行動。別の混乱する要因は、異なるWebサイトが異なる方法でこの動作を実装することです。個人的には、ほとんどの場合、この動作は(ウェブサイトで)気が散ります。スクロールすると、上部に予期しない変化が見られると、注意を引き、調査を開始し、上にスクロールし、下にスクロールして理解しようとしますが、私の職業の危険である。
この動作でブラウザに表示されるWebサイトでのこの動作も考慮してください。混乱する可能性があります。
下にスクロールしたときにアドレスバーを非表示にするこの機能は、Pinterestアプリで初めて見た習慣であり、最近Chrome(両方のiOS)の最新のアップデートの1つで)見ました。モバイルデバイスの場合、これはスペースを減らして画面をクリーンにし、「フルスクリーン」のエクスペリエンスを提供するので非常に理にかなっています(Pinterestの場合、ドックも消えます)。
どちらの場合も、ユーザーはしばらくの間スクロールして、Pinterestページを閲覧するか、ブラウザーで記事を読みます。
デスクトップでは、変更するのはブラウザではなくページであるため、慣行は少し異なります。今日では、大きなヘッダーと大きなロゴのあるサイトがよく見られ、スクロールするとライトバージョンに変わります。これは非常に便利で、画面のより多くのスペースを使用します。
LinkedInの場合、メニューバーのオプションは「タイムライン」をブラウジングするために実際には必要ないので、私は同じようなものだと思います。この場合、メニューをスクロールするか、固定ヘッダーにカーソルを合わせるとメニューが表示されます。
しかし、この種の「スティッキーヘッダー」は、Pinterest、LinkedIn、Facebook、Twitterなどの「長いスクロール」を行うサイトに適していると思います。メニューの非表示/表示モバイルデバイス用に残しておきます。