Qiitaで考えるWebサイトのサービス設計/UI/UX/REST – URLリソースの単位を明確にして、ユーザーの混乱を防ごう。

 # 注意

- URLとかリソースとかいう言葉を、曖昧に使っている部分があるしれない。
- 「リソース位置」などという造語も使っている。(現状、自分のUI/UX的な語彙が少ないため、言い方が分からないものがあった)


# まとめ

- ユーザーが今どんなリソースを参照しているか、インターフェイス的に分かりやすい状態を作っておこう。
- ユーザーが今どんなリソースを参照しているかを、URLの状態に適切に反映させよう。
- URLとインターフェイスを適切に関連付けて、矛盾が生じないようにしておこう。

# それはとある日のこと。

どんぶらこっこ。

# あるエンジニアがQiitaで、いつものように新しい記事を書いておりましたとさ。

[Qiitaと炎上問題。ユーザー努力によるコミュニティ改善は可能だ。 - Qiita](https://qiita.com/YumaInaura/items/27a766acfb42c1203a11)

# そして、参考記事へのリンクを貼りましたとさ。

[全ての開発者がQiitaへのアウトプットをやめるべき理由 - Qiita](https://qiita.com/qiitadaisuki/items/2160a390ce91283707a1)

実際には少し違うURLに対してのリンクだった。詳しくは後述する。

# すると？

どうした。

# な、なんじゃこりゃー。

リンク先の「コメント」に対して、僕の記事へのリンクが付いている！

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/cb3d552f-b0e6-d946-82f0-7eac63eb50d3.png)

(既に修正済み)

# 何が起こったか分からない。

ありのまま今起こったことを話すぜ‥以下略。

# 以下、URLの例はサンプル。

実際には「他の人のコメント」に対してリンクが付いていたわけだが、このままスクリーンショットやURLを載せるのも迷惑だと思うので、ここからは自分のコメントを例にする。

# 理由が判明する。

`URL#comment-b9814fc749d2958ca350` というような、コメントに対してのリンクを、知らずに使ってしまっていたらしい。

`https://qiita.com/qiitadaisuki/items/2160a390ce91283707a1#comment-b9814fc749d2958ca350`


# なぜ気付かなかったのか？

記事にコメントがあった時の「新着通知」からコメントへ飛んで、そのままそのURLを使っていたと思われる。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/89c42623-3e46-10b8-0030-f93281cb186b.png)


# よく見ると

コメント単位でもリソースの「位置」が割り振られる仕様になっていた。

実は、ユーザーから使える状態にもなっていた。


![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/c3ed5a2e-4612-fda6-4044-712b3f688a59.png)

# これは裏技レベルじゃないか


「確かに通知が飛んでくる時は、コメントに直接飛べたのは気付いたいたけれど」。
「ふだん、まったく気付かないようなインターフェイスじゃないか」。

と思った。

# 気付いていないのは「存在しない」のと同じこと

つまり僕にとっては「コメント単位でのリソースURL」は「使えないもの」「存在しないもの」だった。

ちなみに @YumaInaura のQiita歴は3年半。

# 何が問題あったのか

これはわりと色々な問題を含んでいると思う。

考えてみる。

# 「日付部分」がコメントへのリンクになっているのは良い。

スタンダードな作り。

# ユーザーはコメントが「選択状態」であることを知れない。

コメントが選択状態であっても、ハイライトなどがされず、選択状態であることが分からない。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/5f6c8cd5-3e87-2d0f-2a6d-cfe74f521a79.png)

# ページを上下に移動しても、URLのリソース位置が変わらない。

URLは「コメント」を指しているけれど、ページの位置は「他の部分」にいる、という齟齬が起こる。

特に、ページを上下に移動すると、サイドバーの「目次の選択状態」は切り替わって見えるが、実際のURLは切り替わらない。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/73b4c466-5084-6e17-e7e4-a9f8d9122d99.png)

ちなみにモダンなUIだと、ページを移動すると自動的に `#` 以降の「リソースの位置」を、動的に切り替えてくれるサービスもある。


# 「URLによる参照」のインターフェイスが統一されていなくて中途半端

「自分の記事」に対して「他の記事からリンク」が貼られた時は、専用のURL+リソース単位が割り振られて、それがページ上でもハイライトされる。

https://qiita.com/kai_kou/items/df87ebf338389a39062c#_reference-eed5b9e73f9d7fc157a6

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/2a87a3f8-24f0-8ad4-5221-59d47fcc03f7.png)



![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/fb8a6cf4-0547-ddd8-a0f2-a10e0025399e.png)

だが、こちらは

- 参照元の記事がハイライトされる
- 表からは普段、使えないURL=リソースである

と、コメント機能とは挙動が異なる。不揃いな感じ。

# そもそも不具合か何かで、日付部分を押しても何も起こらない。

GoogleChromeでは、ページ上で日付を押しても何も起こらなかった。ページの位置移動が起こらない。Mac版でもiPhone版でも同じ。

(2018-11-12現在)


# そもそも「コメント」に対しての「参照」には需要があるのか。

新しい記事を作る時、記事本体ではなくて、そのコメントに対してリソース参照をさせたい時が、どれぐらいあるのだろうかと考えた。

かなりのエッジケースではないだろうか。

この機能自体は悪くないとして、開発的に考えるならば、いま現状あまり需要がなく、逆にユーザーに誤解を与えるインターフェイスになってしまっているのであれば、トレードオフで機能を無効化しておくのも良いかも知れない。(余計なお世話だろうが、もし自分が開発者だったとしたら、そう考えるかも知れない)

既にコメントに対してリソースが割り振られているので、それに対して「参照を付けられる」ということは自然だし、止められるものではない。


やはり「ユーザーが、今参照しているリソースがなんだか分からない」ということが問題のような気がした。

# 機能的に「コメント」から「記事」への逆参照は必要なのか。

読者は「このコメントが、他の場所から参照されている」ということが知れるので、これ自体は悪くないように思える。

だがそもそもコメントに対してコメントを付けるときというのは、元の記事のコメント欄に書くというのが99%のように思う。

実際に、僕自身も「コメント」からの「逆参照リンク」をはじめて見たような気もする。ちなみに僕はQiita歴さんねんは‥以下略。

# まとめ

- コメント単位でURLリソースが割り振られていること自体は悪くないと思う。
- コメントに対して参照ができること自体は悪くないと思う。
- ユーザーが「今自分が参照しているリソース」が分かりづらいインターフェイスになってしまっているということが、問題だと思う。
- 他のインターフェイスとの統一感もなく、分かりづらいものになってしまっている。
- 機能的にも「コメントからリンク元記事への逆参照」は、エッジケースではないだろうか。


# あわせて読みたい？

[Qiitaはなぜ炎上するのか。「コメント通知」の解除手段がないとどうなるか。サービス設計/UI/UX/仕組み/システム面/ユーザー行動から考えてみる。 - Qiita](https://qiita.com/YumaInaura/items/e6c60d3e80239ad48377)









<!-- Update From Qiita API -->

# チャットメンバー募集


何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。

https://line.me/ti/g2/eEPltQ6Tzh3pYAZV8JXKZqc7PJ6L0rpm573dcQ





# Twitter


https://twitter.com/YumaInaura


<!-- Update From Qiita API -->