このイラストの生成は指示が噛み合わずにそこそこ苦労した

最近Webというものについてよく考えている。

というのもHTMLは本質的にドキュメントであるということに対して、ブラウザはそのドキュメントを閲覧するための手段である。

それがいつの間にやらドキュメントにフォームがあり、そのフォームのボタンが意味をもってJavaScriptでインタラクティブに操作できるようになった。

それからAjaxという技術が生まれて、非同期処理もできるようになって、WebAssemblyなる技術も登場してきた。

そうHTMLはただの文章に留まらないことはもはや誰もが認めるところである。

例えば私が昔買ったAmazonのFireタブレットではAndroidでアプリケーションを作成しなくても、Railsで作成したページは開ける。

そしてUptime Kumaなどのようなアプリケーションは事前に登録したアプリケーションをリアルタイムに監視することができる。

デバイスの壁を取り払い、オープンな規格であるHTMLが私はずっと好きだった。

ただしHTMLは進化し続けている。

厳密にはHTMLよりもはるかに早く、ブラウザが進化し続けている。

この進化は本来迎合すべきものであるが、例えばGoogle ChromeはYouTubeや自社の検索エンジンに有利に働くためのManifest 3を発表したし、MozillaはFirefoxの利用規約とプライバシー通知を改悪した。

そしてまもなくWindows 10はサポートが終了するため既存のユーザーはWindows 11の移行を強要されるか、あるいは別の手段を模索しなければならない。

そう、本来であればただの「ドキュメント」を「ブラウズ」するための手段は絶えず変化しつづけていて、それは必ずしもユーザーにとって好ましいものとは限らないのだ。

その点「紙」や「本」という媒体はどうだろうか?

経年劣化は避けられないが、基本的には一度作り出されたものは容易に変更できるものではないし、破棄しない限りは所有し続けることができる。

この問題はオンラインゲームでも起こっているので、自分の所有しているはずのゲームはいずれ遊べなくなってしまう。

そんな世界的な潮流を感じつつ、最近は新しいものを追いかけ続けることよりも、失わないように守り続けることに気持ちが変わりつつある。

ただの文章がサーバーを経てアクセスできる以上は今まで以上に「保存すること」を意識しなければならない。1

そんなこともあって若い頃はブラウザの技術に関心を向けていたが、最近は昔ながらのデスクトップアプリケーションあるいはGUIについてよく考えている。

最初はブラウザのアドレスバーやタブを取り払いたいというささいな願望から始まった。

そして実際にデスクトップアプリケーションを作ることにも着手し始めている。

まずはPythonから始めた。

Pythonの場合はデスクトップアプリケーションを作る選択肢としてはおそらくかなりポピュラーで、チュートリアル動画も多そうだ。

ただしプロプライエタリな選択肢も多いので、なかなか難しい。

GladeやGnome Builderなどのアプリケーションも試してみた。

さらにはEclipseやJavaのSwingなどをインストールしてみたりもした。

意外と盲点だったのだがEclipseにはGUIのデザイナーが付属しているので、実はVisual StudioのようにJavaで作るという選択肢も案外悪くはなさそうだ。2

そしてこの文章を公開した日のあとにはRustを使ってみたが、Vibe Codingですらうまく動かせられなかった。

残念ながら頭の中に「作りたい」という意思があって、いざ作れる環境が揃っていても、案外思うように作れないものだと実感させられた。

これは自分が若い頃からあるもので、例えば絵を描きたいから紙とペンを買っても何を描いていいのかわからなくなる現象とでも言うべきだろうか。

普通の人であれば絵の描き方を習ったりするだろうし、あるいは本能に任せてただ描いたりするだろう。

そのいずれもできない場合はやはり頭の中にイメージを構築するしかない。

もともと古いデスクトップの動画、例えばWindows XPの動画を当時を懐かしむ気持ちで観ていたのだが、最近はそのUIに注目している。

それからWindows 98、Windows 95やもっと前のWindows 3.1、それからMac OSやそれ以前の動画も観ている。

このあたりの話題もいつかは触れたいと思っているが、最近はブラウザが必要なドキュメントから単体で動くシンクライアントアプリケーションを目指している。

ずいぶん前置きは長くなったのだが、今回残しておきたかったのはそこから見えてきたものの2つである。

  1. ウインドウが重要であること
  2. デスクトップがある前提のデザインが必要であること

ウインドウが重要であること

まずはデスクトップアプリケーションが現在のウェブアプリケーションをそのまま置き換えることはできないということである。

厳密には機能的に寄せることはできるかもしれないが、それをデスクトップアプリケーションでも実現しようとはするべきではない。

どういうことか。

例えばよくウェブアプリケーションというとまずサイドバーという概念があり、それから各ページのテーブルであったりフォームが存在している。

よくPMが連呼するモーダルという概念もドキュメントとして暗い背景を追加してダイアログの表示に注目させるような作りである。

しかしこれがWindowsのようなUIを想定するとどうだろうか。

典型的なWindows XPのメッセージウインドウ

当然ウインドウが表示されるだけである。

これはウェブアプリケーションがデスクトップアプリケーションの挙動を模倣していることもあるのだが、決定的なのはデスクトップという概念が存在するかしないかだと思う。

デスクトップがあるのでユーザーはこのメッセージボックスを自由に移動させることができる。

HTMLで作ったモーダルはどうだろうか。

私の知る限りではそのようなドラッグでウインドウを動かす処理を加えればこのページ上に表示されたdiv要素の塊を移動させることができるようになるが、そのような処理を入れているアプリケーションは少ない。

OSが表示しているウインドウはキーボードショートカットの動作も考慮されているし、フォーカスしたときにボーダーが表示されているので、この状態でスペースキーを押すとユーザーはこのウインドウを閉じることができることは想像に難しくない。3

もちろんBootstrapのような古くからあるライブラリを使っていてもこの様子である。

Reactを含め様々なUIライブラリを見てきたが、どれも見た目の優劣が多くてそれ以上に操作とかけ離れていることがある。

デスクトップがある前提のデザインが必要であること

初期のMac OSなどのデスクトップアプリケーションを見ると、もともと最大化というWindowsには当たり前の機能はなかった。

今でこそFull Screen APIなどとしてMacもフルスクリーンで使われる前提があたりまえになってしまったが、もともとはアプリケーションはデスクトップ上にウインドウを配置するものに過ぎなかったのだろう。

つまりフルスクリーンを前提とするデザインが決定的な違いなので、Webのようにレイアウトをして作るという概念は薄いと思っている。

必要な機能、フォーム、メッセージは然るべきサイズのウインドウを個々に表示すればよい。

だからこそ画面全体をおおうようなダッシュボードを表示するのであればWebアプリケーションがよい。

逆に言えばフォームひとつとってもブラウザの小さい画面を強要させる必要はないと思っている。

かつてのWindowsやMac OSはデスクトップをユーザーが自由にカスタマイズすることができた。

それが今ではユーザーもOSのカスタマイズができない環境を当たり前に受け入れるようになりつつあるのではないだろうか。

それもブラウザで画面が覆いかぶさる前提なのであればデスクトップをカスタマイズさせる必要はないだろう。

コンピュータは所有するものから拝借するものになりつつある。

月某ドルでそのサーバーの機能を使わせていただくものである。

コンピュータそのものはどんどん小型になっているが、それだけ個々のコンピュータが計算をする必要性が薄れているのだろう。

個人開発においてはバックエンドやRailsサーバーの開発をしている身からすればすべてをC#ないしJavaで書くわけにもいかない。

ブラウザもデスクトップもシンクライアントが好ましい。

サーバーはHTTPないしネットワーク上で繋がっていれば問題ない。

だけどブラウザは前述のように変わってしまうものだから、それぞれの領域を大事にすべきなのだと思う。

ただしデスクトップに密接につながっているアプリケーションは当然ブラウザだけのドキュメントに比べると危険が伴うのも事実である。

典型的なWindows XPのジョーク

Windows XP時代は大量にウイルスプログラムが大量のウインドウで画面を覆い尽くすようなプログラムが定番(?)だった。4

最近はマイニングウイルスは耳にしなくなったが、コンピュータ内部に侵入して情報を収集するような悪意のあるプログラムは今でも警戒しなければならない。

互換性の問題もある。前述のFireタブレットもそれ専用のapkファイルを用意しなければならないだろう。

これまで当たり前のようにウェブブラウザから得られていた恩恵を失うか、あるいは別の手段でカバーすることは頭にいれておくべきである。

まとめ

久々の投稿ともあり長くなってしまった。

しかし私が長らく言語化できなかった投稿だった。

私は前にも何度かデスクトップアプリケーションの作成を試みたり、入門を宣言したのだがおそらくこのことを知らなかったので挫折してしまったのだろう。

デスクトップアプリケーションというよりはTUInewpostも公開してみた。

今後はデスクトップないし、OSと密なプログラムを書いていきたい。

  1. Twitchが膨大な過去の動画のアクセスを遮断するようになったことも忘れてはいけない 

  2. 現在はSwingはもう古いということで、Java FXが推奨されているが私はうまく動かせられなかった 

  3. ダイアログをEscキーで閉じる挙動はサポートされていることが多いが、逆にデスクトップにこの挙動はない 

  4. 私は当時遭遇しなかったが、BonziBuddyは有名である