これらは、ヘブライ語サイトのカレンダーの2つの代替レイアウトです。ヘブライ語は右から左に書かれています。言語が記述されているのと同じ方法で日付を表示する必要がありますか(RTL)、または日付が通常表示されるのと同じ方法で曜日を表示する必要がありますか(LTR)。
問題は、カレンダーの上部にある緑色のバーに曜日が表示され、順序を逆にすることは、日付の順序を逆にすることと同じように、ネイティブスピーカーにとって混乱することです。
それは興味深い質問です。しかし、決定的な答えは、コンテキストと関係するいくつかの側面を単に無視することだと思います。
内訳は次のとおりです。
どちらかのパラダイムを使用するヘブライ語とアラビア語のカレンダーが見つかります。どちらの比率であるかはわかりませんが、オンラインですばやく検索すると(特に英語の翻訳を検索する場合)、両方がわかります。
あなたが提供した例は、ヘブライ語のタイトルを持つグレゴリオ暦です-月は1日から始まり、31日で終わります。これは、ユーザーがすでにグレゴリオ暦に慣れていることを示唆しています。
ヘブライ暦は、グレゴリオ暦ではなく、ヘブライ暦を中心に展開されます。これは(予想どおり)RTLになります。
(これを見つけるのは簡単ではありませんでしたが、グレゴリオ暦のすべてのコンポーネントが含まれています。)
私たちがイスラエルを例にとると、大多数の人々はヘブライ語の日または月が何であるかを知らず、ユダヤ人の新年の周りに宣伝されているのでその年だけを知っているかもしれません。ほとんどの人はヘブライ語の誕生日をあなたに伝えることができません。伝えられるほぼすべての日付はグレゴリオ暦です。
これの例外は正統派です:
どれが(驚き?)人口の10%にすぎず、まだほとんどが携帯電話を持っているので、(ある程度)グレゴリオ暦にさらされています。
それが次のポイントへと私たちを導きます。
主な言語がRTLである人々は、依然としてLTRコンテンツにさらされています。
おそらく最初に何よりも数字です(アラビア数字が使用されている場合でも、ヘブライ語とアラビア語の両方でLTRです)。数学-方程式のように、または試験でどのように教えられ、ソリューションを開発するか-もLTRです。
これらの人々の多くは、他のLTR言語(英語、北アフリカのフランス語など)にさらされています。
金融会議で-それがエジプト、イスラエル、またはレバノンで-スプレッドシートがRTLで、グラフの時間軸が同じ方向を向いているとしたら、私は非常に驚きます。しかし 例外はあります :
したがって、RTLであるにも関わらず、LTRの方向付けはほとんどのポーズです。
LTRの向きに関係なく、リストの方向反転に関しては、注意が必要です。これは、あまりトリッキーではありません。
最初の10の素数、RTLは次のとおりです。
29 23 19 17 13 11 7 5 3 2
5番目の素数はどれかわかりますか?リストがLTRだったとしたらもっと簡単でしょうか?
これは対照的です...
... sdrow ni srettel fo noisrevni ...
...ここで、脳は開始/終了のショートカットを失い、各文字を読むことに頼ります(少なくとも訓練されていない脳-これに関するいくつかの研究があります)。
ここでの議論は、人々がリストを逆の順序で読む必要がある場合は、曜日ではなく曜日(7がある)でこれを行うようにしてもよいということです。月(そのうち約30)。
別の重要な質問は、人々がこの月の視覚表現をどのように使用するかです。
繰り返しになりますが、重要な問題は、グレゴリオ暦が(非視覚的な)コミュニケーションの基礎であるかどうかです。
主に2つのユースケースがあると思います。
どちらがより一般的だと思いますか?
明らかにもっと多くのユースケースがあります-私は読者にこれらを理解させましょう。
ターゲットオーディエンスが単なる一般的なRTLであることを考えると、各セクションをもう一度読んだ場合、月次のLTR(英語のグレゴリオ暦の場合と同様)があり、日数がある方が合理的だと思います-週の「反転」。
インクの汚れを減らすために、言語はLTRに切り替えましたか? 回答
TL; DR:いいえ。グリッドカレンダービューでは、言語の方向性を考慮する必要はないと思います。そうは言っても、特定のユーザーベースが使用する主要なカレンダーがあり、それが特定のレイアウトを持っている場合(たとえそれが円形であっても)、それを使用することをお勧めします。とは言っても、すでに市場に出回っている特定のカレンディカルソリューションの普及により、曜日は左から右になる可能性があります。
カレンダーレイアウトをデザインするときに、言語の方向性を考慮に入れるべきかどうかはわかりません。それらは完全に異なる視覚化体験です。
ユーザーがカレンダーを操作するとき、ユーザーは連続してグループ化された一連のグリフを読んではありません。代わりに、彼らはグリッドを一周して日付を見つけようとします。日付をパンして、それが何曜日かを確認します。その日が最初か最後かはほとんど違いがありません。彼らはその日を探すことから始めるかもしれませんが、この場合も、注文は7つほどのオプションをスキャンして探しているものを見つけてそこから移動するので、ほとんど意味がありません。
ほとんどのアジアの書記体系は 水平または垂直 で書くことができますが、カレンダーは本ではありません本であり、それはデータのようなものです視覚化;完全に異なる経験。
MacOSのカレンダーに戻ると、別のカレンダーを表示するオプションがあります。それらのどれも曜日の順序を変更しません。
同じ問題(複数言語のカレンダー)の解決策をチェックして、もう一度macOSのカレンダーアプリで説明を終了します(Appleは、その顧客満足度評価を維持するためのUX。曜日の順序は決して変更されません...日付、月、年を表すグリフのみ(注:曜日の名前は変更されます)これらもユビキタスである可能性を示す変化もない、または少なくとも、地域とは無関係に簡単にマッピングできる)
その証拠と論理を考えると、私はノーと言うでしょう。言語の方向性は、カレンダーを作成するときに考慮する必要はありません。これは、書かれた単語ではないため、データの視覚化に似ているからです。したがって、UXの問題として、ユーザーが達成しようとしていることを検討してください。日のグリッドは本当に最良の選択ですか?または、ユーザーがすでに知っていることと一致しているだけですか?
たぶん、回転するセレクターのセットの方がいいでしょう。たぶんリスト。