RSS Habrとユーザビリティについて...

記事の発行日と記事がRSSフィードに入った日付との間に矛盾があるとRSS Habrをonceったことがあったため、ここに招待されました。 開発者は、Habrの使いやすさのこの問題を排除できます。 今日、Habr RSSフィードの使いやすさに関するもう1つの問題を説明したいと思います。これは、奇妙なことに、排除すべきであり、私たちは記事とメモの作成者です。 それは写真についてです...



RSS経由でHabrahabrを読むのは便利です。 まず、前回滞在した場所を覚えておく必要はありません。 第二に、前回から個人的に興味のあるものが現れていないことを理解するために、本格的なHabrをロードする必要はありません。 Habréに表示された新しい情報の簡単な説明とそのフルバージョンへのリンクを提供することは、HabrのRSSフィードのタスクです。 ただし、RSS Habrはこのタスクをできるだけ実行しません。 なんで?



RSS Habrahabrは、新しい情報の簡単な説明として、著者がhabracatの前に置いたすべてのものを取得するように設計されています(著者がhabracatを使用しなかった場合、メモ全体が短い説明として使用されます)。 これは、一度に言うために使用される1つの文字として-一度...

さまざまなインターネットサイトで、成功しているあまり良くないブロガーやジャーナリストは、投稿(記事、メモ)に写真を提供することをお勧めします。写真がなければ、少し新鮮で「キャッチされない」と言います。 これは、同じキャラクターが言うように、2 ...

最初と2番目をまとめると、かなり不快な効果が得られます。RSSHabrahabrでは、新しい記事の意味を理解できないことが多く、その魅力を完全に失います。 そして、その理由はまさに、Habrの素材を活性化するために設計された写真です。 例を挙げましょう...



個人的には、ニュースやメールなどを読むためのオフラインアプリケーションを好みます。 特に、私はShrookを使用してRSSを読んでいました。 そして、これが私のシュロックに来たニュースの一つです(すべての写真はクリック可能です):



オウムはもちろん、クールで、言葉はありません。 素敵で面白い。 しかし、残念ながら、このオウムは私が記事の内容を理解することを大いに妨げました。オウムはニュースのためにShrookのために確保されたスペースのほぼ全体を占め、「新しい情報の簡潔な説明」を読むことができません。 そして、これは別のRSSリーダーの同じ強盗です:



これはGoogleリーダーです。 Shrookと比較して、オウムはちょうどそのようなものではないことが判明したことに注意してください! オウムには、謎の数字が輝く特定のディスプレイがあります。 ただし、ここでさえ、作者は数字でオウムのポイントをすぐに理解することを許可していません-最初にニュースを下にスクロールして水平スクロールに移動し、それを使用して写真を見る必要があります。 さて、またはHabrahabrを開いてニュース自体を読んでください。 そのため、この場合、殺人者のオウムはすべてのRSSをスミレとシュレッドにつつき、そのすべての機能を完全に使い尽くし、マティーニで洗い流したことが判明しました。



同じGoogleリーダーの別の例を次に示します。



このニュースを見たときに私に最初に起こったのは神でした。Office'97はどこか他の場所で本当に生きているのでしょうか。 しかし、ニュースは彼に関するものではありません-私は推測しませんでした。 ニュースは、肥大化したインターフェースと戦うことに関するものであることが判明しました。 確かに、画面の境界をはるかに超えて爆発したのは、法外に宣伝されたRSSからのこの重要な情報でした。 なんとなくぎこちない、正しい言葉...



RSSに分類される大きな画像は、一般的に最近、インターネットの一種の惨劇になります。 ここに、たとえば、別のオプションがあります-犯罪者は少なくなりますが、それでも:



ここで、写真はニュースのテキストを読むことを妨げませんが、どういうわけかあなたは楽しむことができず、結果に感心することができません-バグは画面に収まりませんでした。 それは取るに足りないように見えますが... ...彼らは、ブラウザが水平スクロールをするべきではないとすでに何度も書いています-Artemy Tatyanovichは、この点で非常に鋭く自分を表現しました。 カブトムシは水平方向にスクロールする必要があります。 そして、これは私のブナであるという事実にもかかわらず-そのような小さなモニターではありません。 しかし、2つのスクロールホイールを備えたマウスは持っていません。-歯類には慣れていません。指を突く方が好きです。



上記の例は、ユーザビリティがリソースの開発者だけでなく、その直接の作成者であるコンテンツジェネレータにも依存することを明確に示しています。 投稿者は、自分の投稿を復活させたり説明したりするために写真を挿入します。この写真は、RSSまたはポータブルデバイスからサイトを読む人の生活を台無しにします。 作者がこれらの人々について考えなかったからといって、世界にはそれほど多くはいない。 一方、大きな写真のクリック可能な小さなサムネイルを作成するのは簡単なことです。 私が使用しているPicasaだけでなく、他の多くの画像ホスティングサイトでもこれを行うことができます。 しかし、何らかの理由で、誰もこの機会を利用していません。



ただし、小さな写真でも追加の問題が発生し、まったく理解できない問題が発生します。 簡単な例:



すべてのニュースに当てはまるように見えますが、何らかの理由で読むのは簡単ではありません。 なんで? テキストの行を走る目は、常に明るい絵につまずくからです。 これは、この場合ルールが違反されているために発生します。これは、ほとんどすべてのHTML教科書が古代から繰り返してきたものです-写真を挿入してテキストで囲むことにより、テキストを読みやすくするために写真とテキストの間のインデントに注意してください

一般的に、写真の周りにテキストをラップすることは、かなりおもしろくて、装飾的で面白いものです。 しかし、これは、どの画像にも適用する必要があるという意味ではありません。 たとえば、この場合、このフローはやや不適切に見えます。



同時に、ニュース自体のテキストは、理解するのに十分なボリュームで表示され(スクロールする必要はありません)、インデントがあるようですが、ここでは、1つの単語の先頭の行がその場で殺され、画像の左側のテキストとすべての注意が入る写真の下での継続。 たとえば、これと比較してください:



またはここでこれ:





上記から、シンプルで本質的かつ明白なルールが続きます-Habréで(Habréだけでなく)記事を公開するときは、誰かがRSSアグリゲーターであなたの記事を知り、ポータブルデバイス。 お気に入りのRSSアグリゲーターを開き、記事のRSSバージョンが表示されていると想像してください。 テキストの先頭に挿入された1600 x 1200の画像は、ニュースに割り当てられたウィンドウに収まるでしょうか? そこに到達した(または収まらなかった)後、ウィンドウ内にテキスト用のスペースがあると確信していますか? 彼に知られていない小さな画像を見ると、読者はすぐにあなたの記事を理解し、興味を持ちますか?

他の場所と同様に、インターネット上で、彼らは衣服で会います。 しかし、インターネットはまさにあなたの記事がいくつかの服を試着している環境です。 Shrookは、ニュースを水平方向に30%、垂直方向に85%の大きさの画面に残します。 RSS Owlは、同じニュースに対して同じ75%の画面と90%の画面を残します。 ただし、Thunderbirdは、画面サイズのニュースを水平方向に70%、垂直方向に45%だけ残すように提出する傾向があります。 1600 x 1200の3枚の写真を含む記事の「短い」コンテンツは、3枚すべての服で同じように見えることを確認してください。 また、全員の画面も異なることを忘れないでください。ワイド画面に収まるものは、通常の画面には収まりません。 これについて考えた後、habracatの下にフルサイズの画像を配置する方が良いかどうか、そして簡単に説明したい場合-本当にしたい場合-サイズ50から50のプレビューまたは象徴的なエンブレムを配置しますか?



All Articles