#1481: Apple Watch の画面交換、Apple Music ウェブアプリ、TidBITS 2019 読者アンケートの結果、Apple による省略記号の過度の多用

もしもあなたのアルミニウムモデル Apple Watch Series 2 または Series 3 の画面の縁の部分に特定のタイプの亀裂があれば、良い知らせがある。Apple が、その画面を無償で交換してくれるからだ。Apple は次のように発表した：

ごくまれに、Apple Watch Series 2 または Series 3 のアルミニウムモデルの画面の縁の丸みを帯びた部分に亀裂が生じる可能性があることが判明しました。亀裂は画面のいずれか一辺から始まって外周に広がっていく可能性があります (下図参照)。

この画面交換プログラムは、すべてのアルミニウムモデルの Apple Watch Series 2 および Series 3 を対象としており、そこには GPS、GPS+Cellular、Nike+ の各モデルも含まれる。お持ちのモデルが対象であるかを確認したければ、Apple の説明書に従ってあなたの Apple Watch を識別できる。

もしもあなたの Apple Watch が対象に含まれていて、この種の画面の亀裂があれば、Apple Store 直営店で予約するか、Apple 正規サービスプロバイダに連絡するか、または Apple Support に連絡するかして、Apple Repair Center への郵送サービスの手続きをすることができる。

討論に参加

Apple がひっそりと Apple Music ウェブアプリのベータ版をスタートさせて、Apple Music 購読者が現代的なウェブブラウザからならば自分の Apple Music コンテンツのすべてにアクセスできるようにした。あなたが期待する機能がすべてそこにあるが、ただし楽曲のアップロード機能、スマートプレイリスト、一部のミュージックビデオ、最近再生したカスタムラジオ局、それから奇妙なことに、Beats One ラジオが欠落している。

Apple はこれまでさまざまのプラットフォームにそれぞれネイティブな Apple Music クライアントを提供してきた：

• Mac: iTunes と、 macOS 10.15 Catalina で登場予定の Music アプリ
• iOS、watchOS、tvOS: Music アプリ
• Windows: iTunes
• Android: Music アプリ

しかしながら、Linux と ChromeOS のユーザーは締め出されていたので、今回のウェブアプリはそういう人たちにとって嬉しいニュースだ。現行の Mac ユーザーで iTunes が嫌いな人たちも、Apple Music のウェブクライアントの登場を歓迎するだろう。より一般的には、このリリースは iTunes 亡き後の世界における Apple の Windows に対するプランを示すものでもあるのかもしれない。

このウェブ版の Apple Music がどの程度クロス・プラットフォームであるかをテストするため、私は Ubuntu Linux の走る Lenovo ThinkPad の上でこれを Firefox にロードさせてみた。メディアキーが見つからないというエラーが出たことを除いては、期待通りに動作して、私のライブラリをブラウズし、Apple Music カタログを検索し、楽曲を再生することができた。

この Apple Music ウェブアプリは Catalina の Music アプリのインターフェイスを真似ている。あなたの Apple Music ライブラリとプレイリストへのアクセスを提供し、それに加えて Apple コンテンツ、具体的には編集者の手でキュレートされたプレイリストと、アルゴリズムにより生成されたプレイリスト、例えば New Music Mix や My Chill Mix などもある。さらには Up Next さえもある。

当然ながら、現代的なウェブブラウザならば必ずやあの「クリックしてくれれば何やらかんやらが開く」省略記号ボタンが、たっぷりあるはずだと言わざるを得ない。(2019 年 8 月 30 日の記事“省略... はもっと？ Apple の統一性のない省略記号がユーザーの混乱を招く”参照。)

Mac の上で Apple Music ウェブアプリを使えば、いくつか追加の素敵なことを享受できる。例えば Dark Mode 対応 (これは Firefox の中でさえ働く) や、メディアキー対応 (これは少なくとも Safari の中では働く) などがある。

報道によればこの Apple Music ウェブアプリは Android でも働くとのことだが、私は Android デバイスを持っていないのでテストできていない。iOS デバイス上でロードさせようとすると、代わりに Music アプリが開く。

Apple が引き続きビジネスの重点をサービスへと向けようとしていることを考えれば、将来には News アプリや TV アプリのウェブ版が登場してもおかしくないかもしれない。もしもそれが実現すれば、現行の Apple News+ と、登場予定の Apple TV+ との聴衆を拡大することができるだろう。

あなたはウェブ版の Apple Music をお使いになりたいだろうか？ Apple がもっと多くのウェブアプリを出してくることをお望みだろうか？ ご意見をどうぞコメントに書き込んで頂きたい。

討論に参加

私たちのアンケート結果を分析する際に、私はいつもある程度の怖れを感じてしまう。自分たちの仕事をどう思われるかを何万人もの人たちに尋ねていれば、そこにはやはり自信喪失の不安感が潜むものだからだ。嬉しいことに、今回の TidBITS 2019 Reader Survey の結果は概して好意的で、助けとなるものであった。(アンケート質問へのリンクは 2019 年 8 月 16 日の記事“TidBITS 2019 読者アンケートに投票お願いします！”をご覧頂きたい。) 残念ながら、今年のアンケートには 1094 通の回答しか寄せられず、これは 4 年前に実施した前回のアンケートでの 2267 通の半分以下だった。(2015 年 12 月 7 日の記事“TidBITS 2015 読者アンケートの結果”参照。)

この種のアンケートがとうてい科学的なものと言えないことは十分に承知している。回答するか否かは回答者自身の選択によるものだからだ。けれども、回答者の 56% が私たちを財政的に支えて下さっている TidBITS 会員であったので、読者層の一部分を成す今回の回答者の皆さんの声を私たちは導きの手として喜んで受け取りたいと思う。(以下で「TidBITS 読者」あるいは「読者」と書くのはこの「アンケート回答者」を意味することがある。両者が同じ意味でないことは承知しているが、この記事の中ではそのように考えることとしたい。投票する者が、将来により多くの発言の機会を得るからだ。)

皆さんについて

アンケートの質問の最初の数問は私たちの読者についてもっと知り、今後の記事を考える際に正しい読者層を念頭に置くことができるようにするためのものだった。驚くには当たらないことだが、29 年間にわたって TidBITS を出版してきて多くの忠実な読者の皆さんが長い年月を共にして下さっていることもあり、私たちは皆、年を取った (そしてもちろん賢くなった) ようだ。回答者の 90% が 50 歳以上であった。Tonya と私ももうじき 52 歳になるので、まさにその年齢層にいる。

私たちがもっと多くの若い読者層を開拓すべきだという声も聞こえているけれども、息子 Tristan と彼の友人たちを見る限り、その方向で私たちが成功できる可能性があるとは思えない。私たちは若い世代が考えるやり方でものを考えないし、そもそも彼らは文章を読むことが学びの主たる方法だとは思っておらず、メディアブランドへの忠誠心もあまりない。彼らは問題が出現する度にそれに応じてビデオを観たり Google 検索結果からいろいろな記事をつまみ読みしたりして解決しようとするので、定期刊行物を購読するという考え方がピンと来ない。それは仕方がないことだ。TidBITS も永遠に生き続ける訳ではなく、私たちの主たる関心は私たちの仕事を支えて下さる TidBITS 会員の皆さんのニーズに応えることにある。

技術的熟練度についての質問の結果が、私には興味深かった。1 から 5 までから選んで頂き、1 には「私は初心者、あるいは自分の Apple デバイスを使っていてトラブルに遭うことが多い」という説明、5 には「私は自分の周囲のどんな人のためにも Apple デバイスの問題を解決できる」という説明を付けた。85% の方々が平均以上、つまり 4 か 5 という回答だった。3 という回答はたった 13% で、1 か 2 を選んだ方々はほんの数人ずつだった。この結果には安心できた。つまり、私たちは今後も引き続き、記事にどこまで細かいことを書くかを決める際に TidBITS 読者の皆さんがある程度以上は技術的だという前提の下で判断してよいと思えたからだ。

インターネット基盤構造

今回のアンケートに回答して下さった方々、つまり最も積極的に関与して下さる方々の多くが TidBITS を電子メールのニュースレターの形で読んでおられることは明白だろう。回答の 79% が、記事を読んでいる方法の一つが電子メールだとしていた。(TidBITS は複数の手段で読むことができるので、結果のパーセンテージの合計は 100% より多くなる。) 私たちのウェブサイト上で記事を読んでいるという回答はたったの 31% で、その他はさらにもっと少なかった。ただ、14% の方々が TidBITS を Apple News で読んでおられるという事実は心強いものだった。全体的に、これらの数字は 2015 年の結果とあまり違っていなかった。

ウェブサイトについては、これは 2018 年 4 月に大きなデザイン改訂をしたものだが、全体的な評価はかなり良く、1 から 5 の評価で回答者の 72% が 4 か 5 を選んだ。1 が「好きになれない」で、5 が「大好き」だ。

自由形式のコメント欄への回答で最も多く使われた形容詞は「easy (使いやすい)」で、第２位が「clean (すっきりしている)」だった。(もちろん、その形容詞の前に否定詞が付いているか否かもきちんとチェックした。) 古いサイトの方が良かったという回答もいくつかあったが、古いサイトは大嫌いだった、デザインが改訂されて嬉しいという回答も同じくらい多くあった。すべての人をいつも満足させることはできないということだ。

ウェブサイトを「一度も/ほとんど使ったことがない」という回答や、さらには「ウェブサイトがあったなんて知らなかった」という回答さえあったのには少しびっくりした。私たちはほとんどすべての記事を電子メールで発行しているけれども、私たちのウェブサイトを訪問して下されば記事へのコメントが読めて、追加情報が書かれていたり、その記事の内容を拡張する説明が書かれていたりすることが多いし、時には私たちが古い記事で扱った製品やサービスについての最新情報をその記事へのコメントとして書いたりすることもある。

また、このウェブサイトには 29 年分の過去記事も保存されていて、その中には今日でも有用なものも多い。(例えば、TidBITS Talk での議論の中で、私はついさっき 2015 年 11 月 30 日の記事“File メニューに Save As を戻す”へのリンクをポストしたばかりだ。) 過去記事を見つけるには、まずサイト内検索機能が使える。およそ 37% の読者がこの方法を使っていた。あるいは他の 6% の読者のように Google 検索を使い、検索語句に +site:tidbits.com を付けて検索を絞り込む方法もある。けれども、53% の方々が古い記事などまず検索したことがないと認めているので、これは皆さんの大多数が時を遡ることなどに興味がないということなのだろう。それからまた、もし電子メール号のどれかを見直したければ、ウェブサイトの中で過去号をブラウズすることもできる。

電子メール号のデザインについては、ウェブサイトのデザインよりも好意的な回答が多かった。回答者の 82% が 4 か 5 を選んでいて。1 が「好きになれない」、5 が「大好き」だ。

自由形式のコメント欄への回答の多くは、ここでもやはり相反する意見が同じくらいに集まった。「冒頭の要約部分が好き」と「最初の要約部分は不要」という意見だ。すべての人をいつも満足させることは... また、技術的サポートに関する意見もかなり多くあったので、これについては別の記事にまとめた上で対処したいと思っている。

けれども直ちに返答すべきと思われるコメントが２種類あった。まず、かなり多くの方々が、電子メール号の冒頭近くにある目次部分の記事へのリンクをクリックしても何も起こらないことが多いという苦情を述べていた。それは事実だけれども、私たちが悪いのではない！ 責任は Apple やその他の電子メール開発者たちにある。私たちのデザインは、named anchor (名前つきアンカー) を正しい形式で使っているからだ。Apple は iOS の下でもう長年にわたってこの問題を無視し続けてきている。私はこの問題を 2018 年 1 月 5 日の記事“El Capitan と iOS 9 での Mail、named anchor タグを無視”で報告した。Apple は私のバグ報告を重複とだけマークして何のコメントも付けずかなり以前に閉じていたが、Mac 用の Mail ではその後問題を修正した。私は iOS 13 にそのバグが依然として残っていることを確認して、もう一度バグ報告をしておいた。もしあなたが iOS 13 のベータ版を使っておられるなら、ぜひあなたも Feedback Assistant アプリを使ってバグ報告を重ねて頂きたい。

次に、Gmail のネイティブなウェブインターフェイスでの問題点について書いて下さった方々も多かった。メッセージが 102 KB を超えるテキストを含んでいた場合、Gmail は一番下に「[メッセージの一部が表示されています] メッセージ全体を表示」と表示する。その「メッセージ全体を表示」リンクをクリックすると予想通りに働くけれども、余計な手間を掛けさせられるのが苛立たしい。なぜなら、それをクリックした後で、読んでいたところまでいちいち手でスクロールしなければならないからだ。問題はその 102 KB という上限が必要な HTML マークアップも含んでいることで、HTML 電子メールには効率の悪い table ベースのコーディングとインライン CSS も含まれる。これはその号の中の読めるテキストの分量とはあまり強い関係がなく、回避するのは困難だ。(例えば、Cornell 大学の同窓生や保護者向けの月刊ニュースレターは、ほんの数画面分のテキストと画像しか含んでいないのに、いつも 102 KB の上限を超えている。)

このように苛立たしい点はあるけれども、短い要約のみから成っていてウェブサイト上のそれぞれの記事へのリンクを載せた電子メール号を希望する方々は 30% だけであった。その種の電子メール号を作るためには相当量の開発の努力が必要で、購読のためのインターフェイスも複雑化し、私たちのサポートの負担も増すだろう。そういう訳で、要約のみの電子メール号は私たちの開発の願い事リストには載せておくけれども、実現するか否か、実現するならばいつになるかをお約束することはできない。

現状でのコンテンツ

私たちが何について書くかに関する意見に目を移せば、私たちの直感が概ね正しかったことが分かって安心できた。ただし２つだけ、特記すべき例外があった。記事内容のカテゴリーごとにそれぞれ 1 から 5 までで評価して頂いたので、それぞれの加重平均を計算してカテゴリー同士を比べてみた。

どの製品についての記事を読みたいかという点については、いつも通りに Mac が首位となった。そして、誰もが予想する通り、iPhone と iPad が僅差でそれに続いた。次の Apple TV では興味の度合いがぐっと減り、Apple Watch がそれとほぼ同レベルで続いた。AirPods と HomePod にはそれほど人気が集まらないだろうと予想していて、結果はその通りだったが、この両者はそもそもあまり取り上げる必要がない。

興味深かったのは、2015 年に同じ質問をした結果と比較してみたところ、Mac が 0.06 ポイント減り、iPhone が 0.24 ポイント増え、iPad が 0.13 ポイント増え、Apple TV が 0.24 ポイント減り、そして Apple Watch が 0.49 ポイントも急増したことだった。この結果はうなずける。iOS デバイスはあれ以来さらに柔軟で強力になったので、そちらの魅力が増して、Mac が少しだけそのあおりを食らったということだろう。前回のアンケートの数カ月前に第四世代 Apple TV と初代の Apple Watch が出荷されていたが、今回の結果を見ると Apple TV はあまり期待に応えることができず、その一方で Apple Watch は期待を上回ったと言っても差し支えないだろう。

記事が扱う話題の内容や記事のタイプについては、たくさんの異なる項目それぞれに評価をお願いしたので、ここではそれらの項目を加重平均の順に並べて人気の度合いを４つの層に分けてみた。少々恣意的なところもあるけれども、記事のアイデアを検討する際にそれがどの層に属するかを見ておくのは一つの方法となるだろう。

• 第 1 層： ここに属する 6 つのカテゴリーは、最も人気を集めたものたちだ。トラブルシューティングとメンテナンスが加重平均 4.30 で断然首位となった。セキュリティとプライバシーが 2 位に食い込んだのにはちょっと困惑したが、それは純粋に私たちがこれほどまでの重要性を正当化するような世界に住んでいなかったら良いのにという願望から来るものだった。ニュースと分析が第 3 位となったのは嬉しい。私たちは重要なニュース項目を無視したくないと思っているからだ。その後の３つ、つまりハードウェアやアクセサリーのレビュー、Mac 用アプリのレビュー、実用的なハウツー記事の３つは、どれもとても価値あるもので、今後も優先的に取り上げたいと思う。
• 第 2 層： この層の最初に来た TidBITS Watchlist (TidBITS 監視リスト) は、予想通りの高順位だった。Agen Schmitz が担当している、Mac 用アプリのアップデートを簡潔に紹介するこれらの記事は、多くの方々に気に入って頂けているようだ。残りの３つ、つまりインターネットサービス、iOS 用アプリのレビュー、Apple オートメーションの３つは、この第 2 層にぴったり相応しいと思う。つまり、魅力的な内容ではあるが TidBITS を読む際に核心的な内容とまでは言えない。
• 第 3 層： この層には ExtraBITS、テクノロジーと政治、読者お気に入りのアプリアンケート、そして意見記事の４つがあるが、これらの投票結果をどう解釈すべきか私にはよく分からない。外部記事を短く要約した ExtraBITS を書くために私たちが多くの時間を費やして調査したり執筆したりしているのは、毎週の TidBITS に幅広さを与えてくれると思うからだ。業界の興味深い発展をすべてもれなく伝えることはできないかもしれないが、皆さんの目を他の場所にある記事へも向けられるサービスだと私たちは考えている。ひょっとするとそれに費やしている時間をもっと第 1 層の記事を書くために振り向ける方が良いという考え方もあるかもしれないが。テクノロジーと政治、それに意見記事の２つが低く評価されるのは予想できた。なぜなら、そう、インターネットにはその両者が溢れ返っているからだ。私たちはこの２つのカテゴリーについては最も重要なもののみに限るように自らを戒めたいと思う。最後に、読者お気に入りのアプリアンケートのカテゴリーの評価が低かったのは私には驚きだった。特定の種類のアプリをクラウドソースの意見によってランク付けするこの種の記事はかなり多くの労力を必要とするものだが、これまではもっと人気があるだろうと思ってやってきたのだった。
• 第 4 層： IT/企業のカテゴリーの評価が比較的低いことは予想できた。その種の仕事をしている読者の割合は少ないだろうからだ。また、Terminal に関する記事も多くの読者にとって興味の度合いが低いだろうと思っていた。でも、残りの２つが低いのはなぜだろうか？ あ痛っ！ ホームオートメーションとエンターテインメントの２つが、断然最下位の２つとなった。私たちはこれまで、Apple の HomeKit プラットフォームのため、また間もなく登場するはずの Apple TV+ と Apple Arcade のプラットフォームのため、それらを伝える記事にかなりの重点を置いてきたのだが。これは明らかに、その種の記事で重視の度合いを下げるべきであるようだ。

最後にもう一つ、いくつかの記事の終わりのところに付けたことがある超簡潔版のアンケート調査についても質問してみたが、これについては概して好評のようで、回答の 66% がこれをもっと増やして欲しいというものであった。今後も記事を出すごとに、この種のアンケートが意味を成すかどうか考えてみたいと思う。

記事そのものについて

個々の記事に関しては、およそ 90% の回答が TidBITS の記事はその長さ・深さ・技術レベルで「ちょうど良い」というものであったので、嬉しかった。それと違う意見の人たちは、それぞれの両側の選択肢にほぼ均等に分かれていた。今後は、記事の長さをもう少しだけ短くするように試みてみたいと思っている。

個々の記事の冒頭に掲げられる見出し画像については、「どうでもいい」という声がはっきり聞こえた。1 から 5 までの評価で、52% がこれらの画像を 3 と評価し、33% が 4、10% が 5 であった。［訳者注： TidBITS 日本語版ではウェブサイトと電子メール号のいずれもこの見出し画像を付けていません。］

電子メール号のみを読んでおられる方々は、これらの見出し画像を記事タイトルの右側に見える小さなサムネイル画像としてしかご覧になっていないはずだ。フルサイズの画像では場所を取り過ぎるからだ。けれどもウェブサイトでは、加えて TidBITS 会員が受け取る個々の記事でも、記事の冒頭にフルサイズの画像が表示され、読者の気持ちを引く魅力的なビジュアル要素として働く。これはウェブ出版においてはごく一般的なことで、ソーシャルメディアのプラットフォームでも、また Apple News でも、トラフィックを呼び込むために不可欠のものと見なされている。

けれども、これらの画像を見つけてきたり作成したりするためにとてつもない膨大な労力が必要であることは否めない。そこで、これから一・二週間は実験的に、見出し画像を取り除いてみたいと思っている。それで何か影響がありそうかどうか、特に Apple News で何が起こるかを見てみたい。Apple News は画像を強く欲しているからだ。妥協案として、あらかじめ Apple News にいくつかの画像を蓄えておいて、そこから画像をフィードするようにすれば個々の記事ごとに余分の労力をかける必要がなくなるかもしれない。

コメントについて

基盤構造の移行のお陰で、Glenn Fleishman と私がデザインした従来の軽量のコメントシステムから、Discourse と呼ばれるオープンソースのシステムに移ることができた。それは、柔軟性の意味でも機能の多彩さにおいても、まるでカヌーから航空母艦に乗り換えるようなものであった。全体的に見て、私はユーザーとしても、また管理者としても、Discourse を心から好きになった。WordPress とうまく統合されているので記事の下にコメントを埋め込むこともでき、それと同時に TidBITS Talk の討論フォーラムを駆動することもできる。

そのコメントに関しては、回答数の 52% が少なくとも記事の下のコメントを斜め読みすると答えていたが、いつでもコメントを読む、あるいは討論が進むに従って読み続けるという回答はたった 21% ほどであった。コメントは全く読まないという回答は 27% ほどだったが、電子メール号を購読している人がコメントを読むためにはクリックしてウェブサイトへ行ってから読まなければならないことを考えれば驚くには当たらないだろう。

コメントを書き込むと答えた 30% の回答のうち、ほとんどすべての回答が書き込むのは年に数回程度という答で、それよりも頻度が多いという答はわずか 4% ほどであった。たぶんこれらは十分予想できる数字なのだろうが、記事への建設的な情報提供を私たちがいつも歓迎しているということは、どうかお忘れにならないで頂きたい。記事へのコメントから議論が起こり、その話題が有用な方向に大きな進展をみたことも何度かあった。

新たなコンテンツ

時々、私たちもポッドキャストや短時間のビデオなど人目を引くコンテンツの世界から取り残されたかのような気持ちになることがある。けれども、Apple 関係のポッドキャストや定期投稿の YouTube シリーズがあれば購読したいかという質問に対して、答は双方とも同じようにはっきりしていた：

• 20% よりほんの少し少ない回答が、購読したいという答であった。
• 40% よりほんの少し少ない回答がどちらとも言えないという答で、私の予想で言えば、これはエピソードを一つか二つ試してみた後でたぶん結局は購読しないということだろうと思えた。
• 40% を超える回答が、購読はしないと答えた。情報過多だから、またはオーディオやビデオのコンテンツに気を引かれないからというのが理由だった。

いずれにしてもここで何かの約束をすることはできないが、私たちが一番訴えたいと思っている人たちからは特に断固たる要求がなかったということだろう。

最後のコメント

今回のアンケートには自由形式のコメント欄を全部で５つ設けておいたが、その最後のものは本当に自由な「何か他に TidBITS についてコメントしたり、提案したり、その他私たちに言いたいことはありませんか？」という質問であった。５つの自由形式コメント蘭に合計 1375 件の記入があったので、私はそれらを全部取り込んで一つの長い書類として保存し、順々に読み進めているところだ。親切にも褒めて下さる言葉が多く、優しい言葉をかけて頂いたことにお礼申し上げたい。私たちにとって、本当に大きな意味を持つことだと思う。批判の言葉もやはりありがたいと思った。どんなところを気に入らない人がいるかを知ることで初めて、私たちは物事を改善することができるからだ。頂いたご意見は、今後の前進のために取り入れて行きたいと思っている。

質問の一つとして電子メールアドレスをお伺いしなかったことを後悔している。かなり多くの人たちが、簡単に解決可能な問題点について苦情を述べたり、あるいは私がお返事したいと強く思うようなコメントを書いたりしておられたからだ。そういう人たちに直接お返事を差し上げることができないので、それらの疑問やコメントに対しては今後の記事の中でお答えしたいと思っている。なぜなら、一人の人が何かについて混乱に陥ったのなら、必ずや他にも同じことで困っている人たちがいるだろうからだ。だから、私が記事としてその答を書けば多くの人を助けられることになる。それにほら、たくさん記事があるのは良いことだ！

今回のアンケートに回答して下さった皆さん、どうもありがとうございました。ほんのちょっとカーテンの裏を覗き込むこの体験を、少しでも楽しんで頂けたならば幸いに思います。

討論に参加

リリースされたばかりの Take Control of iOS 13 and iPadOS 13 を書くために iOS 13 を探求していて、私は iOS ソフトウェアデザインにおけるあるやり方が益々増えてくる傾向にあると思え気になり始めた。この記事を書かねばならないと思わせられたのは、Wallet における Apple Card のユーザーインターフェースを記録していてである ("Apple Card 特典を最大限に活用する方法" 14 August 2019 参照)。何故ならば、私は同じ文字を繰り返し繰り返しタイプしていることに気づいたからである...

そう、私が言っているのは iOS にやたらと目に付くようになっている省略記号 ... ボタンのことである (技術的に言うと、我々は見易さを強調するため、ユーザーインターフェースの省略記号を中黒を三つ続けたものとして表現している)。

言っておくが、私は別に省略記号に恨みがあるわけではない；それは、作家が色々な興味深いそして柔軟性のある方法で使える全く正当な文字である。最も正式な使い方はおそらく、単語、文、或いは文の集まりをより大きな本文から意図的に省略することを示すものとしてであろう。例えば、Apple はファイル名が与えられた場所に収まらない程長い時に省略記号を挿入する。しかし、省略記号はまた、Wikipedia にある様に、"未だまとまっていない考え、誘導表現、短い間、こだまする声、或いは神経質な、或いはぎこちない沈黙を指し示すものとして使われることもある。... 文の始め又は終わりに置かれた時には、省略記号はまた憂鬱や憧れの感情も喚起することもある。" 我々の技術がその様に繊細であり得るのであればいいのだが。

これは書き物の場合である。Macintosh のインターフェースでは、この省略記号は長いこと特定の意味合いを持っていた。メニュー項目に続く省略記号は、それを選ぶと直ぐにアクションが取られるのではなく、ダイアログが出てくることを意味する。File > Save を選べば現在の書類が保存される；File Save As... は Save ダイアログが現れ、そこで新しいファイル名やファイルの置き場所を入力出来る。技術的な書き物の中でメニュー項目名を書く場合は、省略記号を省略して省略記号のより伝統的な使い方と混同しないように心掛ける。

しかし iOS では - そして一部の Mac アプリでも - Apple はこの省略記号を統一性なく使い始め、その意味を混乱させている。例を見てみよう。

省略記号、Apple の使用と乱用

まず、この Wallet アプリを見てみよう。ここでは、省略記号ボタンをタップしてクレジットカードと設定に関する情報にアクセスする。

この例では、省略記号ボタンは、Mac 上で File > Get Info を選択して Get Info ウィンドウを開かせるのに似ている。このウィンドウは選択したファイルについてのメタデータを表示する。興味深いことに、Wallet がこの省略記号ボタンを使い始めたのはつい最近のことで、以前は、小文字の i の様に見えるボタンに依存していた。ひょっとすると、このインターフェースを他の言語やスクリプトシステムにローカライズする時に i は収まりが悪かったのかもしれないが、でもそれは ISO の標準シンボルの一つに定められている。

ここで、何か音楽を聴くために Music アプリに切り替えるとしよう。曲を再生していると、別の省略記号ボタンが目に入ってくる。それをタップすればその曲に関する更なる情報が見られるのかなと思われるかもしれない、iTunes で Edit > Song Info を選択した時の様なものを。しかし、答えはノーで、iOS Music アプリの省略記号ボタンは、その曲を自分のライブラリに追加する、それをプレイリストに追加する、それに基づいて Apple Music ステーションを作成する等々のトラックに固有のアクションのリストを引き出す。強いていえば、Add to Playlist や Share Song のメニューコマンドは、次もダイアログが現れることを指し示す省略記号の標準的な使い方を守っているとは言える。

この二つの例は、タップすれば情報と設定を提供する省略記号ボタンとしての役割と、選択した曲に関して使えるアクションの内容対応メニューとしての役割とを示している。これは跳躍としか言えない。

もう直ぐ消えゆく運命にある iTunes の話をすれば、それは省略記号の使い方では遥かに上を行っている。とりわけ、音楽を Artists でブラウズしている時に。

これ程多くの省略記号ボタンを使うのは - しかも二つの違ったタイプがある - 過剰に見えるが、少なくとも Apple はここでは徹底して使っている：どの省略記号ボタンをクリックしてもその項目に対する内容対応のメニューが表示される。しかし、視覚的には、このインターフェースは頂けない。残念なことに、これは macOS 10.15 Catalina の現在のベータでの Music アプリでも同様である。

ベータといえば、iOS 13 ベータは Apple の最新のデザイン思考を反映しているはずである。Apple は現在 iOS 13.1 をベータテストしている最中なので、iOS 13.0 の視覚インターフェースはもう固定されているであろう。(もし iOS 13 経験を先に試したいのであれば、Take Control of iOS 13 and iPadOS 13を見て欲しい。)

iOS 13 は Music での省略記号ボタンに少し手を入れたが、それで使いやすくなったわけではない。

まず、Apple はその位置を変えたが、より重要なのは、それをタップすると iOS 12 で使っていたアクションシートの代わりに、アクティビティビューを開く。インタフェースの言葉で言うと、省略記号はアクティビティビューとアクションシートのどちらを開くべきか？ 大した違いはない様に見えるかもしれないが、インターフェースが予期したことと違うことをやる度に、ユーザーはその能力に対する信頼を失う。

これらのインターフェースの混乱は iOS 13 の Files アプリにまで及んでいる。Wallet の場合と同様、Apple は完全に理解出来る Edit リンクを省略記号ボタンで置き換えた。今度これは何をやるのであろうか？ 設定であろうか？ それとも、共有オプションなのかも？

違う。今回それは、書類をスキャンする、サーバーに接続する、そして場所、お気に入り、そしてタグを編集するオプションに対するコマンドを提供する。これらは、かなり違ったアクションである。編集コマンドは、その下にある項目のリストを操作するためには意味があり、そしてサーバーに接続すると言う新機能もしっくりくるが、書類をスキャンするのはどうであろうか？ Files にあるもので書類を作成することに関係するものは他に何もない。

所で、省略記号ボタンの私のお気に入りの乱用例は iOS 13 の Shortcuts アプリにあり、ショートカット上にある省略記号をタップするとそのショートカットアクションに行くが、ショートカットアクションを見ている時にタップするとそのショートカットの設定に行く。そのシートには "詳細" のラベルが付いている。

最初の例では、省略記号ボタンは "編集" を意味し、二つ目では "設定" を意味する。これは繰り返しになるが iOS 12 の Shortcuts アプリからの一歩後退である。iOS 12 では、ショートカット設定に対しては、はっきりと分かる設定アイコンとトグルスイッチが使われていた。Apple は何故視覚的によく分かるアイコンを汎用のもので置き換えたのであろうか？

それがまさに iOS における省略記号ボタンの役割となった：汎用アイコンで、他にも見るものあることを示唆しているが、何が出てくるかは全く分からない。これだと省略記号を Clarus the Dogcow に置き換えても全く問題なく、しかもその方が視覚的にもはっきりするではないか (そして、もっと面白い)。

事態を更に悪くしているのは、上記の例それぞれで、同じ省略記号ボタンが異なる種類のインターフェースを呼び出すことである。時には別画面が、時にはアクションシートが、そして時にはアクティビティビューが出てくる。行動に統一性がなく、方向性が失われてしまう。

そして勿論、省略記号に対する他の全く違った意味づけもある、Messages における受信メッセージ表示である。

それをタップしようと思わないこと - 何も起こらない。

残念なことに、Apple の悪癖はサードパーティ開発者にも伝染している。Slack からの以下の iOS アプリを見て欲しい。

単一の View Files オプションだけのための省略記号ボタンである！ 他のボタンの隣に View Files ボタンを置けばいいだけなのに？

"もっと" とは何か？

皆さんは、省略記号ボタンとアイコンは単に "もっと" を意味するのは明らかではないかと思われるかもしれないが、そうであることを確実に知る方法はない。

良い知らせは、 Apple が次期オペレーティングシステムで SF Symbols と呼ばれるアイコンの標準ライブラリを導入したことである。これ迄、開発者は自分のアイコンを作り出すか、或いはサードパーティから借りるかしかなかった。

不幸なことに、この説明書は一般的にアイコンが どの様に見える かは記載しているが、それらが何を意図して 意味する かは記していない。従って、開発者は名前からはこれらのアイコンを何故使うのかの感触を掴めない。分かるのはどの様な形をしているかだけであり、それは説明書きがなくとも自明である。

(SF Symbols は標準の Unicode フォントではないので、技術的な書き物をする人が Mac や iOS アプリを記述する時にそれらを使う術はない。更に事態を悪くしているのは、Apple がライセンス文書の中でのそれらの使用を禁止している様に見えることで、次の様に言っている、"Apple の SF Font から得られる Symbols の使用は、Apple の iOS, macOS そして tvOS オペレーティングシステム上で走るソフトウェア製品のためのユーザーインターフェースの雛形を作成するための使用に限定される。")

ellipses.bubble や ellipsis.circle の様な名前は助けにはならない。興味深いことに、あるアイコンがどの様に使われるべきか Apple が記述出来ないというわけではなさそうなのである。同社は、特定の Apple 機能を指し示すためだけに開発者が使うことを許されるアイコンに対してはそうしている。

開発者もユーザーも icloud アイコンは Apple の iCloud サービスを指し示すことにしか使えないことは言われるまでもなく分かるが、では ellipsis.circle が何を意味するのかを解読するのは運任せとしか言えない。ひょっとすると、"もっと" を意味するのかもしれないが、そうでないかもしれない。Apple は意図的にここら辺を曖昧にしている。

ここでの有用性に関するより広範囲な問題は、"もっととは何か" の哲学的問題ではなく、"もっと" がユーザーに何を意味するのかの実用上の問題である。上記の例で見た様に、省略記号ボタンをタップすることでひどくかけ離れた種類のユーザーインターフェース要素が起動され得る。Share アイコンを例にとれば、これは共有に関係する選択肢を含むアクティビティビューを首尾一貫して提示するが、省略記号ボタンの振る舞いは予測可能でも、首尾一貫もしておらず、結果としてユーザーを混乱させる。少なくとも私は混乱させられている。これでも、私は iOS を何年にもわたって記述してきている！

"もっと" に関する競合者のアプローチを見てみよう。

Google が助けに？

意外に思われるかもしれないが、この様なデザインに関しては Google は Apple を打ち負かしていると思われる。Google は開発者に Material Design と呼ばれる明快なデザイン標準を与えている。そこには色パターン、テンプレート、そしてアイコンが含まれる。それぞれの Google オープンソースアイコンはその目的を明確に記述している。

大抵の場合、Material Design はそのアイコンをどの様に見えるかで名前を付けておらず、どの機能をそれが代表すべきかに依存している。Apple と違って、 Google は歯車アイコンを "歯車" とは呼ばない。代わりに、それは "設定" と名付けられていて、それをタップすると設定へのアクセスを提供することが求められている。 Material Design はまた、他のことに対しても一連の設定アイコンを提供している、例えば Bluetooth や明るさの様な。

公平のために言うと、Material Design にも省略記号ボタンがあるが、それには "もっと" という名前がつけれており、それをタップすれば何かのもっとが提供されることになっている。

では、Google が省略記号ボタンをその iOS アプリでどの様に使っているか見てみよう。Gmail は、省略記号ボタンを入れ子にして使うという iTunes の悪癖を共有している。そして iTunes の様に、それは内部的には首尾一貫したやり方で使っている。

メールスレッドに関連する省略記号ボタンをタップするとそのスレッドに対するメニューが現れる。メッセージに関連する省略記号ボタンをタップするとその特定のメッセージに関するメニューが現れる。iTunes でと同様、それは美しくはないが、首尾一貫しており、役目を果たしている。

YouTube での省略記号ボタン (ここでは縦位置、恐らくビデオ題名から水平方向のスペースを取らないようにするためであろう) も同じ様に働く：それをタップすれば Gmail が提供するのと同様の更なるアクションのメニューが見られる。唯一の違いは、それぞれのアクションにはその左側に個別のアイコンが付いていることである。Gmail にも同じことが望まれる。

Gmail と同様に、メニューは画面の下から飛び出してくる。嬉しいことに、ここには入れ子のものはない。

Google Docs でも、省略記号は同じ様に働く：タップすれば、隠れているアクションのメニューが現れる。ファイルのビューでは、メニューは Gmail や YouTube の場合と同様、画面下から飛び出してくる。

しかし、書類を見ている間に省略記号ボタンをタップすると、メニューは画面の横から現れる。メニューの長さを考えると、この小さな一貫性のなさは理解出来るが、"ハンバーガー" ボタン (Material Design では "メニュー" ボタンと呼んでおり、Google アプリもそれをアプリレベルのメニュー選択肢として使っている) の方が適していると私には思える。

Google Maps はこのしきたりから少々外れる。Explore Nearby ペーンで More をタップすると、場所カテゴリの全ページメニューを開く。

しかしこれは完全に公平な比較とは言えない。と言うのも、この省略記号ボタンはその他の多くの省略記号ボタンの様には見えないからである - それは周りの色付きのアイコンと釣り合いが取れていて、かつテキストのラベルも付いている。私はこの使い方が好きである。何故ならば、その More とはっきり記されたボタンを押せば何が起こるか直感出来るからである。

勿論、皆さんの好みは主観的な選択であり、Android 開発者は (Google も含んで) Material Design ガイドラインをその通り踏襲していると言うわけでもない。しかしながら、省略記号ボタンの Google の使い方の方が Apple のものよりも明快で首尾一貫していると私には思える。

インターフェースデザインのリーダーと思われる Apple が、このアイコンに関して、その様に感動に欠ける、そして敢えて言わせて貰うが、怠惰なデザインに甘んじているのは情けない。私は、自分が有用性の権威だなどと言うつもりはないが、アイコンは明快な意思を代表し、首尾一貫したアクションに裏打ちされるべきものと私には思える。Apple の Human Interface Guidelines を引用すると：

首尾一貫したアプリは、システムが提供するインターフェース要素、よく知られたアイコン、標準のテキストスタイル、そして統一された専門用語を使うことで、よく知られた標準と枠組みを実現する。アプリは人々が期待する方法で機能や振る舞いを組み込む。

省略記号ボタンはシステムが提供しているかもしれないが、Apple ですら、アプリ機能を起動するために人々が期待する方法でそれを使っていない。

討論に参加