{X(旧 Twitter)はなぜライトモードを捨てたかったのか K#F85E/0758-FB71}
宇田川浩行昨日,X(旧 Twitter)のダークモード以外の配色モードを廃止するとイーロン・マスク氏が表明し,反対意見が殺到するという騒動があった。結局,ダークモードをデフォルトにしてライトモードも一応残すという方向に軟化させたようだ。
デライトでは,今年2月にダークモード(ダークテーマ)対応を実現したばかりなので,個人的に色々思うことがあった。前回予告した KNS についての文章に時間がかかり過ぎているため,今回の一日一文はつなぎとして,開発者の視点からこの騒動の背景について書いてみたい。
デライトは元々明るい配色,いわゆるライトモードのみでやってきた。大きな理由の一つに,イメージの問題がある。白背景を基本としたデザインにはやはり明るく清潔な印象がある。サービスがメディアで紹介される時など,イメージ戦略を考えるとこれは馬鹿にできない。
個人的には黒背景が好きだが,この種のネットサービスではどうしてもアングラ感が出てしまう。背景色を微かな灰色にすることも試したが,白背景と比べるとちょっとくすんだような,地味な印象になってしまう。なるほど,ダークモードが流行しても大手サービスの多くがデフォルトで眩しい白背景を採用している理由はこれかと思ったものだ。
今年2月,満を持してダークモード対応を完了し,私もテストがてらダークモードを常用していた時期がある。最初は新鮮さもあって,それこそダークモードだけでやっていけそうな気がしたが,慣れてくると,眠気が強くなったり,いまいち調子が上がらないことに気付いて,結局ライトモードを常用する生活に戻った。
ライトモードもダークモードも,どう感じるかは個人差や環境差によるところが大きい。どちらかが万能だと思ってしまうのは,単純な経験不足なのだろう。今回の騒動は,ソフトウェア開発におけるマスク氏の経験不足と,新しいロゴに象徴される偏った趣味に起因する出来事とも言える。
ただ,もう少し踏み込むと,マスク氏をこの拙速に追い込んだ X の切実な開発事情が見えてくる。
配色モードの追加や維持というのは,見かけよりずっとコストがかかる。例えば,外観に絡むような機能追加をした時,それぞれの配色モードで問題が生じていないか確認する必要があるし,問題があれば個別に調整する必要がある。そして,このコストは,既存のコードの保守状況が悪ければ悪いほど,変更の程度が多大であればあるほど高くなる。
{希哲17年6月3日の日記 K#F85E/E74C-A84A}
宇田川浩行{希哲17年5月15日の日記 K#F85E/E74C-66BB}
宇田川浩行pdftoppm
}{譜類添付機能調整}{譜類添付機能}(116){希哲17年4月5日の開発 K#F85E/E74C-3148}
宇田川浩行譜類添付機能調整など。
細かい挙動の調整を終えてから PDF 埋め込み対応を完了,譜類添付機能も全体として完成形と言える状態になり,ようやくエクスポート機能実装に移れる。
3月24日の開発時点では,添付ボタンと埋め込み記法でラスター画像(JPEG, PNG, GIF, WebP)が扱える程度で機能実装の一段落としたが,SVG,動画,音声までの埋め込み含めての対応,その他主要文書譜類対応,添付代置子の導入,貼り付け・ドロップ対応,更に PDF 埋め込み対応と,現時点でやりたいことは一通りやってしまった。一段落とは言ったものの,中途半端感が残りいまいちすっきりせず,デライト公式での機能紹介も出来ていなかった。
PDF 埋め込み対応に関しては,PDF.js と pdftoppm
が優秀だったおかげで意外とあっさり実装出来た。特に PDF.js は viewer.html
の場筋と PDF 譜類の場筋を組み合わせて <iframe>
の src
属性に渡せばいいだけで,スクリプト側の対応も簡単だった。
最初のページを pdftoppm
で JPEG に,cwebp
で WebP に変換,その画像をクリックで縦サイズを合わせた <iframe>
に置換し viewer.html
を読み込む。読み込み中の進捗表示も viewer.html
が行ってくれるので,これだけで違和感なく軽快な PDF 埋め込みが実現出来た。一応,「(.pdf
添付ファイル)」の形で小書き輪結も添えるようにしておいた(PDF 埋め込みの様子)。
一つ,添付譜類の握接権限の課題は残した。現状,場筋が分かっていれば誰でも握接出来るが,デライトの性質上大きな問題ではない。エクスポート機能で譜類の握接制御を実装するのでそれを応用することにした。
cwebp
}(187){希哲17年3月24日の開発 K#F85E/E74C-A57A}
宇田川浩行いくつか課題は残ったものの,これで譜類添付機能の基礎が出来た。輪郭選り手の領当てもほぼ完成形と言っていいだろう。本当努を通して,関連仕様検討や,中途半端だった libxtd の譜類操作関連交度の整備なども大きく進んだ。
用合いとしては,録入り中の描写選り手左下に譜類添付ボタンを置き,譜類選択と同時に上信を開始,完了したら埋め込み記法で +[拡張子]
を追記,下見を開く(開いている場合は更新する)という形になった。すでに同拡張子の添付譜類が存在する場合は上書きする。予定通り,描写内の参照を消して描き出し・描き直し,または輪郭削除で削除されるようにした。
当初,譜類選択後に専用の下見機能付き小窓を開き,確認してから送信,という用合いを考えていたが,素早く描き出したい場合に煩雑になり,交度の複雑化に見合わない可能性があるため見送った。「送信中...」,「+[拡張子]
を追記しました。」,「.[拡張子]
で保存しました。」(上書きの場合)の3種類のメッセージを @msg
で表示し,下見に関しては既存の下見機能を利用すれば十分なことに気付いた。描き出し前には上信せずスクリプトで保持することも検討したが,これもページ遷移などへの対応も考えると無駄な複雑化を招く可能性があるため見送った。
対応形式はとりあえず JPEG,PNG,GIF,WebP のみ。WebP 以外の場合は長辺が1920px以下の WebP に変換する。WebP の上信に関しては,ImageMagick の未対応パッケージがまだ多いことなどから,1MiB のサイズ上限のみで対応することにした。その他譜類のサイズ上限は原則として5MiB。サイズ上限以外は基本的に kn upl
の仕様に合わせたが,cwebp が ICC プロファイルも捨ててしまう問題に気付いて kn upl
ともども -metadata icc
を加えた。
埋め込み記法では,拡張子のみ,知番と拡張子の組み合わせに加えて,輪符と拡張子の組み合わせにも対応した。
下見機能を利用するために添付譜類の舞覧隠し戦略も見直した。結局,譜類の更新時印から隠し破りを付与出来るようにし,隠し破りの有無で Cache-Control
の public
と no-cache
を切り替えられるようにした(5歩。これまでは一律 no-cache
だった)。Dex が実譜類に依存するのは水平拡大を考えるとどうかと思ったが,そのうち KNEST 隠し化すればいいと判断した。
最後の最後で,領下手定め環境で問題なかった新規描出フォームの添付譜類が本番環境では 404 Not Found
になるという問題にはまったが,これは systemd の PrivateTmp
による問題であることが分かり,一時的に無効化してから問題無いように修正し,元に戻した。新規描出フォームでは無駄に永続譜類を残さないように /tmp/
を利用していたことが原因だった。最終的に,これが大して意味を持たない設計になったので再描出フォームと同じ自我台録を利用することにした。