4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Qiita投稿記事のインデックスサイトをつくってみた

Posted at

はじめに

Qiitaに記事を投稿する時に、せっかくなので(?)以前に書いた記事も読んでもらえたらいいなと過去記事の中でもオススメっぽいもののリンクをつけていたのですが、「長い」とコメントを頂きまして。

どうせなら、ただオススメ記事リンクを作るのではなくて、検索やいいね順表示なんかも対応してついでにソース公開したらいいのではと思い、そんなサイトを作りました。

QiitaのAPIを用いてデータを取得して、簡単な html + js + css で表示しているだけですので、データの差し替えを行えば、汎用の投稿記事のインデックスとしてもご利用いただけると思います。

  • 図:そんなサイト
    投稿記事インデックス.png

本稿では、Qiita投稿記事のインデックスサイトを制作するにあたって検討したことなどを書いておこうと思います。

課題:長いおまけ

コメントを頂いたのは、以下の「おまけ」となります。
確かに長いのでなんとかしたいです。

  • 図:長いおまけ
    長いおまけ.png

要件定義

さっくりとサイトを作るので、以下の通り要件を定義しました。

  • メンテナンス性が高いこと
    今後記事追加を行った時のメンテナンス作業が大変であると更新されなくなります。
    メンテナンス作業は簡単であることが望ましいでしょう。

  • Qiita 側の負荷を上げないこと
    API を用いてユーザーに対する記事一覧を取得できます。
    ただ、そのAPIの呼び出し回数が多くなりすぎないようにした方がいいでしょう。

  • 費用が発生しないこと
    営利目的ではないので、収入がなくても運用を継続できることが望ましいです。

  • 最小のページ遷移であること
    リンクによるページ遷移毎にユーザーの離脱が懸念されます。
    最小のページ遷移でなるべく多くの記事の一覧を見られるようにしたいです。

設計検討:全体構成

そんなに頻繁に更新する必要もないので、Qiita API で自分の記事一覧を取得して、json を保存する方針としてみました。
取得した json を読み込んで、検索やリスト表示をできる簡単な html を作成するのがよいかなと考えました。

以下に構成図を載せておきます。

  • 図:構成図
    設計.drawio.png

    • 素の html ファイルでは json をそのまま読み込めないので、js ファイルとして保存としています
    • 取得には nodejs + axios を利用しましたが、好みの言語でよいと思います
    • GPT先生に要件をざっくり伝えると大体作ってくれると思います

設計検討:タグ

記事の検索用にキーワード検索も作成しますが、わたしの記事について能動的にキーワード検索を行うユーザーがいるとは考えにくいです。
それよりは、何らかのキーワードを入力することなく、画面上に何か気になるキーワードが配置されていて、それをクリックすることで『何らかの記事一覧が表示される仕組み』があるとよさそうです。

1. タグをベタで表示

Qiitaの記事には最大5つまでのタグをつけられるので、そのタグを表示する事を考えます。
タグの横にその記事がついているタグの件数も表示してあげたら大分親切でしょう、という仮定で試作をすることにしましたが、仮説はまったく的外れでした。

試作したデータを確認すると、100種類を超えるタグがついているが、そのほとんどのタグが 1記事でしか利用されていないというカオスな状況になっていました。

  • 図:ほとんど一度しか使われていないタグ
    タグ一覧.png

このタグを辞書順でソートして表示して『お好きなものをクリックしてください』と言ってもなかなかクリックしてもらえないでしょうし、クリックしてくれたとしても、1件しか結果が出てこないのはユーザー体験としては微妙で、クリックしてもらえなくなりそうです。

2. タグをグループ化

ということで、タグをある程度意味のあるグループでグループ化することにします。(上図の色のついた帯の単位)

このグループ化ですが GPT4o に、『いい感じにグループ化して』 とお願いしてさっくりグループを作ってもらいました。(特に難しいプロンプトは指定していないです。)
若干微妙なところもあったので手で修正しましたが、大体はいい感じでした。こういうところこそ人間が考えるべきと思っていたのですが、そうでもないのだなあと思いました。

3. アコーディオンUI化?

100種類を超えるタグを縦に並べると1画面に収まりません。
アコーディオンUIにすれば収まりもよくなりますが、タググループをクリックしてわざわざ中身を見てもらえるかというとそんなこともないような気がしました。

4. タググループの一覧を表示

であれば、左メニューとは別にページの上部にタググループ一覧を表示する欄を設けるのがよいのではと考えました。

タググループ一覧.png

タググループに件数をつけたい気持ちにもなりましたが、ユーザー的には「興味のあるトピックをクリックする」のであって、「10件記事のあるトピックをクリックするのではない」という整理にして件数をつけるのは見送りました。

『思いついたものをすべて実装しない』 ことも個人開発では大事かなと思います。

設計検討:おすすめ記事・いいね順・ストック順

このサイトを作る元々の目的は「おまけ記事リンク」の表示なので、この記事リストがファーストビューに入ることが優先順位としては高いです。ひょっとしたら検索ボックスやタググループよりも上に表示された方がよいのではということも検討しましたが、更新頻度も高いわけではないので現在の配置順序としました。
2回以上訪問される方が、すぐに新しい情報にアクセスできたらいいなという整理です。

そして、ここは仮説の域を出ませんが、いいね数やストック数の多い記事程読みたくなる可能性が高いと思われたのでそれらの値も表示するようにしてみました。であれば、いいね数やストック数のランキングも近くに配置した方がよいという考えで、タブUIで配置してみました。
ランキングは、Top20も見ると飽きるかなというところで、ページャーなども設けず、Top20が表示されるだけのUIとしました。

おすすめ記事.png

設計検討:タブUI

『全体的にデザインには凝らない』というコンセプトで作っていますが、ここだけ「あまり見かけないUI」にして気を引けないか試してみることにしてみました。

クリックしてほしいので。

タブUI.png

地味にタブの重ね合わせをしました。
css だけで簡単にできるかな?とGPT先生に聞いたらサクッと教えてくれました。

まとめ

今回のUI設計では、100種類を超える多種多様なタグを並べてもクリックされないのでは? という仮説を立てました。
こういう仮説自体は今のところAIは立ててくれない気がしています。
ただ、「タグをまとめたら便利になるハズなのでまとめて」と問いかければ、複雑なプロンプトなどを書かなくても、かなりいい感じの回答をくれる実感もあります。

そうしてみると、人間としては、仮説を立てたり、やりたいことを明確にしていくなど能動的に動くことの重要度が上がっていくのかもなとぼんやり思いました。

おまけ

よろしければどうぞ。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?