スキップしてメイン コンテンツに移動

ユーザ体験に基づく、漫画Viewerの分析

漫画 Viewer について

ここ数年、インターネット漫画は大きく様変わりした。 新都社という素人がツギハギして作っていた漫画サイトから、出版社の公式漫画サイトが乱立するという状況になっている。 色々な漫画 Viewer が登場したが、最終的にはある程度の種類に落ち着いた形になっている。

自分は基本的に PC で漫画を読んでいるが、スマホから漫画を読む人も多いだろう。 アプリをインストールして読むというスタイルが今は普通なのかもしれない。 自分は、アプリを入れるのが死ぬほど嫌なので、基本 PC で読める漫画のみ読むようにしている。 面白ければ、電子版書籍を購入して、一応ある程度は還元するようにしているつもり。 まあ、でも実際には企業プロモーションにタダ乗りしているというのが実情だ。

漫画 Viewer に関しては、はてなが作っている GigaViewer が一番読みやすいと感じている。 しかし、漫画 Viewer にも色々タイプがあるので、個人的な分析と感想をまとめたいと思う。 多分、Twitter か何かに書いたかもしれないけれど、ブログに書いておきたいなと思ったので、書く。

GigaViewer スタイル

まず、王道の GigaViewer スタイル。 これはとにかく読みやすい。PC の見開きに対応、スマホでの表示にも対応、過去話へのリンクが画面下部にまとまっている事や、コメントを見る事が出来るなど、機能面での充実も素晴らしい。 唯一、ダサいなと思うのはスマホ版で全画面表示した後に出てくる ✕ ボタン。あれはマジでダサい。 CSS の border で表現してると思うのだが、やたらと左下に長く表示される(一瞬だが)。 データ量が増えるかもしれないが、svg に置き換えて欲しいというのが本音だ。

GigaViewer スタイルの一番良いのは、単話へのアクセスが早いこと。すぐに読み進められるのが良い。 ページめくりにはクリックが必要だが、それがそこまで気にならないので、全部の漫画がこのスタイルになってくれたら良いのにといつも思っている。 独自の漫画 Viewer を作ってメンテナスするより、GigaViewer を導入したほうが絶対に良い。

あと、GigaViewer は地味に画像をバラバラにして表示するという技術を採用しているので、画像を直接抜き取られても大丈夫(?)な仕組みになっているのもポイントが高い。まあ、適当に切って並べ直したら元の形に戻るけれど、その手間をやってくれるのはノウハウがない人たちにとってはありがたいんじゃないかな?

索引+スクロールタイプ

各話へのリンクがあり、漫画部分はスクロールで表示されるタイプ。 ニコニコ静画などがこのスタイルだ。 単話を読むまでに 1 クリックという手が掛かるものの、その後はスクロールで読み進めることが出来るので、実はそこまでストレスは無い。 ただ、いきなり漫画が読めるわけではないので、そこが若干使いづらいなと感じる。 この形式を上手く改善すれば、漫画をすぐに読めて、その上で各話数へのジャンプも容易という Viewer ができそうな気がするが、今のところ、それへの回答は出ない気がする。 そもそも、スクロールと漫画との相性は難しく、特にスマホで読む場合、縦スクロールの Web トゥーンのような形式以外では読みにくいことこの上ない。 現在は、PC で見る人よりも、スマホで見る人の方が圧倒的に多いので、PC 特化でそんな Viewer を作ってもニーズが少なすぎるという致命的な欠点を抱えている。 ただ、この索引+スクロールというのは、非常に簡単な HTML 構造で実現出来るので、素人に開発させても行けるというメリットがあり、こういうのを採用しているサイトは、あんまりお金ないんじゃないかなと不安になる。 新都社のほとんどがこのスタイルなので、ある意味伝統的なスタイルとも言える。 不名誉な気もするけど。

索引+クリックによるぺーじめくりタイプ

各話への索引があり、そこから漫画ページへ移行、その後クリックしてページめくりしていくという、非常に読書体験が悪い Viewer がある。自分が知っている所だと、ComicWaker がこのスタイルを採用している。他にも幾つかのサイトがこのユーザ体験を損ねる Viewer を採用している。 要するに、直ぐに漫画が読めない上に、ページをめくるために何度も何度もポチポチしなければならないのは、マジでしんどい。 この形式を採用するくらいなら、スクロール形式にした方が絶対にストレスが少ない。 この形式にするメリットは過去話の視認性の高さなのだが、それ以外メリットが皆無だし、多くの漫画は GigaViewer 形式で十二分に必要な機能を満たしていると言える。 GigaViewer 形式に合わないのは、100 話を超えるような話を掲載する場合に限り、それ未満で完結するような短い漫画ならば、GigaViewer 形式を積極的に採用した方が良い。 ちなみに、GigaViewer 形式だと 100 話を超えたあたりから過去話へのアクセスが著しく悪くなるので、これに関しては将来的にどうにかして対応して欲しい所。 索引形式だと、この辺を 1 ページにまとめてざっと見れるので、ストレスは多少減る。

まとめ

まとめると、索引(過去作一覧)を同じページにするか、別ページにするか、クリックでページめくりさせるか、スクロールするかの違いくらいなのだが、読書体験にかなりの違いが出る。 索引+スクロールという UI は、古からのフォーマットで、非常に確固たるものであり、馬鹿でも実装できるという利点があり、小さなスタートの場合は、こういう形式の Viewer はありなのかもしれない。 しかし、現代の Web 漫画サイトを生み出していく所としては、GigaViewer 採用が圧倒的にユーザ体験が良く、漫画だけに集中出来るので、もし新しく漫画サイトを立ち上げようと考えている編集部の方がいらっしゃったら、ぜひ GigaViewer を採用して欲しい。

僕は別にはてなの回し者ではないのだが、1 ユーザとして、現状 GigaViewer を超えるユーザ体験を与えてくれる Viewer には出会えていないので、GigaViewer をゴリゴリにおすすめしたいと思う。

コメント

このブログの人気の投稿

EFIブートローダを移動した話

EFIブートローダを移動した HX90に環境を整え終わってから、アホな事をしたので、その記録を残す。 SSD: Cドライブ SSD: Dドライブ(データストレージ用) + ESP※ SSD: Eドライブ(データストレージ用) ※ESP(EFI System Partition) インストールした時、こんな構成だった。 ESPがDドライブにあるのが気持ち悪かったので、これを削除した。 そしたら、BIOS画面が出るだけになり、Windowsが起動しなくなった。 移動手順 この時の自分はMBRをふっ飛ばした時と同じ現象だと思ったので、MBRというキーワードで検索したが、今はEFIブートローダーと呼んでいるらしい。 【Win10】任意のディスクにEFIブートローダをインストールする 色々検索した結果この記事が参考になった。 Diskpartを使って、パーティションを新たに分割し、bcdbootを実行して、無事に事なきを得た。 パーティションの分割はこんな感じ Diskpart Select volume 0 shrink desired = 200 Select disk 0 Create partition EFI size=200 Format quick fs=fat32 label="ESP" Assign letter=P exit EFIブートローダーのインストールはこんな感じ bcdboot C:\Windows /s P: /f UEFI ちなみに、自分の環境だけの問題なのだが、コマンドラインで、「\」を入力するのができなかった。我が家のキーボードはHHKBだけなので、日本語配列を無理やり適用されると、バックスラッシュが入力できないという不具合が生じる。 結局、コマンドプロンプトからマウスで範囲選択してコピーして貼り付けるという荒業でクリアした。 普通の人は、何も考えずに、\を入力すれば良い。 最終的に SSD: Cドライブ + ESP※ SSD: Dドライブ(データストレージ用) SSD: Eドライブ(データストレージ用) ※ESP(EFI System Partition) という構成に切り替えることができた。

Windows版gVimをアンインストールした日

Windows 版 gVim をアンインストールした話 以前に、 Windows11 on WSL2 + wezterm + Neovim = 最強開発環境 という痛々しい記事を書いたのだが、その続きの記事と言っても過言ではない。 この記事は Vim 駅伝 の 3 月 1 日の記事である。 前回はぺりーさんの netrw を使うために という記事だった。 次回は kuuote さんの Vim 側の組み込みプラグインを無効化するハック という記事である。 gVim との付き合い 思い返してみると、gVim との付き合いは大分長くなった。エディタとしては 自分の人生の中で最も長く付き合ってきたエディタ と言える。Vim のインターフェースとして gVim を何度も使ってきた。自分の手持ちのマシンは Windows なので、必然的に gVim を選択肢として選ぶ必要があった。 gVim の良さは何か。それは、Windows とのシームレスな関係であり、Windows OS の機能をそのまま使いたい場合に有用である。かつての自分にとってこの部分は非常に重要であった。具体的には、印刷機能と画面半透明化機能であり、これが無いとやってられないという認識であった。 しかし、時代が進み、自分の技術力の向上や考え方の変化、さらに Vim 周りのプラグインの更新が進むと gVim で運用していく事がだんだんと億劫になっていったというのが事実である。故に、 WSL2 上で動く Neovim の快適さに心が打ち震えた のである。 技術力の向上に伴う考え方の変化 かつての自分は 何でも gVim で処理したいな と考えていた。メールを見たり天気を見たり、Twitter を見たりするのに、gVim を活用していた。かつての Emacs 使いの guru のような立ち位置を目指していたというのがある。2000 年代初頭にインターネットに多少なりとも触れていた人ならば、「それ Pla」という古の単語を思い浮かべるかもしれない。この概念を持ち出すのはあまりにも古すぎるが、結局言いたいのは、 1 つの手法で全部をこなす という考え方だ。ネットを見るのにわざわざブラウザに切り替えるのはもったいないという今となっては情熱に似た何かを当時は多くの人が持っていた。 しかし、自分自身の技術力

javascriptは外部ファイルにした方がいいの?それとも、インラインの方が良いの?

事の発端 os0xさんのブログコメント で、javascriptの書き方について、面白いやり取りがありましたので、それについての私見を書きたいと思います。 結論から言いますと、プログラマ的な立場から言わせて頂くと、外部ファイル管理が望ましく、コーダ的な立場から言わせていただくとインラインが望ましいです。 なぜそのような結論に至ったのか、まずは経緯を御覧ください。 コメント欄でのやり取り os0xさんのブログコメント欄を引用しています