web-dev-qa-db-ja.com

ユーザーを404ページまたはランディングページに誘導する必要がありますか？

2ページあります。 1つは、ルート/regionで指定されたランディングページです。もう1つは、特定の地域の詳細ページであり、ルート/region/summary/{id}によって提供されます。ランディングページは、ユーザーが詳細ページに移動する通常の方法です。

ユーザーが中間ルートregion/summaryにアクセスしたとします。技術的に有効なルートではないため404ページにリダイレクトするか、regionページにリダイレクトする必要があります。主な問題は、ルートにIDを指定しなかったためです。ランディングページのあちこちに有効なリンクを見つけますか？

website-designusabilityuser-behaviorlanding-pageerrors
20
Peter Majeed

これはもともとコメントでした。この質問が投稿される前に検討され、使用されなかったと思っていたからです。

現時点では、これらはあなたのURLです（「要約」はおそらくアクションの一種です）：

/region
/region/{action}/{id}

あなたの質問は、誰かがIDなしでそれにアクセスしようとした場合、次のように何をすべきかです：

/region/{action}

私は言います：そもそもそれを許してはいけません、そしてあなたのURLを概念的に次のように形作ってください：

/region
/region/{action}
/{region}
/{region}/{action}

したがって、このマッピング{region} -> region/{id}を使用すると、URLを取得できます。

/region
/region/{action}
/region/{id}
/region/{id}/{action}
  • /regionは、引き続き意図した場所に行きます。ランディングページ。
  • /region/{id}/summaryはあなたの/region/summary/{id}と同じことをします
  • /region/{id}は、基本的に「リージョン{ID}に関する情報を取得する」を意味し、302から/region/{id}/summaryへ、または単にそのページを返すことができます。
  • 同様に/region/summaryの場合-ユーザーはランディングページについての情報を求めています。 /regionと同じものを返す必要があります（または、302に返すか、/regionをここに302にする必要があります）。

RESTful URLs このようなものはWeb APIで使用されており、非常に直感的であるため、それらを使用できるサイトに適したモデルです。

StackExchange API からの2つの例のセット（これは、付与されていますが、/tags/{tags}は含まれていません）：

/badges                   Get all badges on the site, in alphabetical order.
/badges/{ids}             Get the badges identified by ids.
/badges/recipients        Get badges recently awarded on the site.
/badges/{ids}/recipients  Get the recent recipients of the given badges. 

/tags                   Get the tags on the site.
/tags/{tags}/info       Get tags on the site by their names.
/tags/synonyms          Get all the tag synonyms on the site.
/tags/{tags}/synonyms   Get the synonyms for a specific set of tags.

そして、この[回答を編集]ページの1つ（残念ながら/edit...なしでは機能しません）：

http://ux.stackexchange.com/posts/39273/edit
12
Izkata

ユーザーがどこに行こうとしているかを推測しても問題ないと思いますが、常に正しい HTTP応答コード を指定して、アイテムが見つからなかったか「永久に移動」したことを示し、単純な表示を検討してくださいユーザーが本当に正当な場所に移動しようとしていて、リダイレクトした理由が混乱している場合に備えて、ページ上のメッセージ。

8
sirtimbly

役立つ可能性のあるページにフォールバックする機能がある場合は、404エラーではなくそれを実行する必要があると私は主張します。

あなたの例では、誰かが/regionを入力したときに/region/summaryにフォールバックすると、ユーザーは探していたものを選択する機会が与えられます。これにより、404エラーページを提供した場合よりも、フローの中断が少なくなり、より優れたUXが提供されます。

人と一緒に作業しているときは、ユーザーの意図を考慮して、できる限り柔軟に対応する必要があります。マシンでは、それは正確であることの詳細であり、それはあなたが持っている最も近い情報にフォールバックする代わりにエラーを与えるべき場所です。

一方、誤った{id}を提供した場合は、提供できる最も有用な情報を含む404エラーページに戻る必要があります。

3
JohnGB

404エラーは非常に役立ちます。

誰もが自分のサイトが直感的であることを望んでおり、すべてのユーザーがより少ない作業を行うよう努めています。そうは言っても、統計とログの404エラーは、ユーザーインターフェイスの欠点がどこにあるかを判断するのに役立ちます。ユーザーエクスペリエンスの観点からユーザーインターフェイスが非常に悪く、ユーザーがそのインターフェイスを使用して「スキップ」しようとしている場合は、修正が必要です。 Googleおよび検索エンジンはハードリンクのみをたどるので、通常、サイトで404エラーに到達することはありません 。 Googleのウェブマスターツールのバックエンドでは、ウェブサイトに不良リンクまたはデッドリンクを見つけたかどうかに関するフィードバックを提供します。Googleを検索して、リンク元を特定できます。

誰かに盲目的に301（永続的な）リダイレクトを与えて、間違った情報を提示すると、サイトの訪問者を遠ざける危険があります。存在しないページにアクセスしようとした場合にすべてのトラフィックをランディングページにリダイレクトすると、自分のミスであるのか、ページが存在しなくなったのか、またはサイトが壊れている場合はさらに悪いことを知る方法がありません。

訪問者が意図していた可能性の高いリンクを表示するためにリクエストを解析すると便利だと思いました。これらは、複数のアクションが実行される可能性があるため、他のアクションが必要であることを示す300リダイレクトとしてリストに表示されます。リクエストのトピックにリモートでさえレコードがない場合、404エラーを提供します。これは、検索エンジンまたは訪問者が私のサイトを失敗したクエリ、キーワード、またはコンテキストに関連付けたくないためです。これは、サイトのトラフィックを維持するだけでなく、サイトに関連アイテムがあることを検索エンジンに通知するのに役立ちます。

2
AbsoluteƵERØ