はじめに

前回の記事では、

「画面の状態」と「データの状態」は別物だった。

そんなことを書きました。

タイトルや画像、所持状態は、

利用者が残したいデータです。

一方で、

検索している。

フィルタを選んでいる。

どこを開いている。

そういったものは、

画面を使うための状態でした。

ここまで考えた時、

自分の中では、

それなりに整理できたつもりでした。

でも、

実際にアプリを何度も使っていると、

また気になることが出てきました。

アプリを閉じる。

もう一度開く。

最初の画面に戻っている。

「ああ、またここからか」

ほんの数回の操作です。

でも、

毎回となると、

地味に面倒でした。

動作としては、何も間違っていません

例えば、

Collectionを開く。

Folderを開く。

Categoryを開く。

Titleを見る。

その状態で、

いったんアプリを閉じます。

そして、

しばらくしてからもう一度起動する。

最初の画面が表示される。

別に、

バグではありません。

データも消えていません。

もう一度、

Collectionから辿ればいいだけです。

最初は、

それでいいと思っていました。

でも、

自分で何度も使っていると、

だんだん思うようになりました。

いや、さっき見ていたところから始めてほしい。

数回のタップが、だんだん面倒になる

目的のTitleまで戻るために、

Collectionを選ぶ。

Folderを選ぶ。

Categoryを選ぶ。

それだけです。

一回だけなら、

何とも思いません。

でも、

アプリを開くたびに、

毎回同じことをする。

昨日もここを見ていた。

さっきもここを見ていた。

なのに、

アプリは毎回、

何も知らない顔で最初の画面を出してくる。

使っているうちに、

これが少しずつ気になるようになりました。

機能としては、

ちゃんと動いています。

でも、

使っていて気持ちよくない。

こういう違和感は、

作っているだけでは、

なかなか気づきませんでした。

じゃあ、最後に開いていた場所を覚えておけばいい

そこで、

最後に開いていた画面を、

覚えておくようにすればいいのではないか。

と思いました。

最後に見ていたCollection。

Folder。

Category。

Title。

次にアプリを起動した時、

そこから再開する。

考えてみれば、

特別なことではありません。

利用者としては、

ただ、

「さっきの続きから使いたい」

だけです。

実装する側では、

画面遷移だとか、

状態保存だとか、

復元だとか、

いろいろ考えます。

でも、

使う側からすれば、

そんなことは関係ありません。

前に見ていたところを、

覚えていてほしい。

それだけでした。

ここで、前回の話がまた戻ってきました

最後に開いていた画面を覚える。

これは、

タイトル名や画像のような、

コレクションそのもののデータではありません。

明らかに、

画面側の状態です。

前回の記事では、

画面の状態と、

データの状態は分けて考えた方がいい。

そんなことを書きました。

でも、

ここで少し困りました。

画面の状態なのに、

アプリを閉じても残しておきたい。

「あれ？」

となりました。

画面の状態は、

その画面を表示している間だけ持てばいい。

何となく、

そんなふうに考えていたからです。

でも、

実際に自分で使ってみると、

残してほしい画面の状態もありました。

だったら、全部覚えておけばいい？

一瞬、

それなら画面の状態も、

できるだけ保存しておけばいいのではないか。

とも思いました。

最後に開いた場所。

検索文字。

フィルタ。

展開していた場所。

選択していたもの。

開いていたダイアログ。

全部保存して、

次回起動時にそのまま戻せば、

完全に続きから使えます。

でも、

想像してみると、

それも何か違います。

例えば、

確認ダイアログを開いたところでアプリを閉じた。

翌日、

アプリを起動する。

いきなり昨日の確認ダイアログが出てくる。

たぶん、

「いや、これはもういい」

となります。

検索についても、

昨日調べていた言葉が、

今日もそのまま残っている方がいいとは限りません。

覚えてくれることは便利です。

でも、

何でも覚えていれば親切というわけでもない。

また同じところに戻ってきました。

「全部見せない」と、少し似ていました

少し前の記事で、

「全部見せること」が親切ではない。

という話を書きました。

情報を持っているからといって、

全部画面に出せばいいわけではない。

必要な時に、

必要なものだけ見せればいい。

今回も、

少し似ている気がしました。

状態を持てるからといって、

全部覚えておけばいいわけではない。

次に使う時にも意味があるものだけ、覚えておけばいい。

最後に開いていた場所は、

続きを始めるために役立ちます。

でも、

一時的に開いたダイアログまで、

次回に持ち越す必要はありません。

こうやって考えると、

少し分かりやすくなりました。

技術から考え始めると、私は迷いました

Jetpack Composeには、

状態を扱う方法がいろいろあります。

remember

rememberSaveable

ViewModel

そして、

アプリを閉じても残すなら、

さらに保存する仕組みが必要になります。

最初は、

「これはどこで持つべきなんだ？」

と、

実装方法から考えていました。

でも、

それをやると、

だんだん分からなくなってきます。

これは remember なのか。

ViewModelなのか。

保存するのか。

DBなのか。

考えることが、

いきなり技術の話になります。

でも、

その前に考えることがありました。

これ、次にアプリを開いた時にも必要なのか？

まず、

それだけでした。

必要なら残す。

その場だけなら残さない。

そこが決まってから、

どう持つかを考えればいい。

私の場合は、

その順番の方がずっと考えやすかったです。

階層を作ったからこそ、気になったのかもしれません

SLXでは、

Collection、

Folder、

Category、

Title、

という階層でデータを整理しています。

大量のコレクションを整理するには、

この階層が役に立ちます。

でも、

階層があるということは、

目的の場所まで辿る必要もあります。

整理しやすくするために作った構造が、

毎回そこを辿らせることで、

逆に面倒さを生んでいました。

内部では、

きちんと階層で整理したい。

でも、

利用者には、

毎回その階層を意識させたくない。

ここでも、

以前考えた、

内部の構造と、利用者が見る画面は同じでなくていい。

という話につながりました。

別々に考えていたことが、

作っていくうちに、

少しずつつながっていきました。

「覚えていること」も使いやすさでした

これまで、

使いやすい画面を考える時は、

ボタンの位置だったり、

表示する情報量だったり、

タップ数だったり、

目に見える部分を考えることが多かったです。

でも、

今回気になったのは、

目には見えないところでした。

アプリが、

前に何をしていたか覚えている。

次に開いた時、

自然に続きを始められる。

逆に、

もう必要のないものは忘れている。

これも、

使いやすさなんだと思います。

ボタンを一つ減らしたわけでもありません。

画面を綺麗にしたわけでもありません。

でも、

アプリを開いた時に、

「ああ、ここだった」

となる。

こういう小さなことが、

毎日使うアプリでは、

思っていたより大事でした。

おわりに

最初は、

アプリを閉じたら、

画面の状態が消える。

それを特に疑問には思っていませんでした。

アプリなんだから、

そういうものだろう。

くらいに考えていました。

でも、

自分で何度も使っていると、

「またここからか」

と思うようになりました。

そして、

最後に開いていた画面を覚えるように考え始めると、

今度は、

何を覚えて、

何を忘れるのか。

という話になりました。

結局、

今回も、

全部ではありませんでした。

全部見せなくていい。

全部保存しなくていい。

全部覚えていなくてもいい。

でも、

利用者が「覚えていてほしい」と感じるものは、ちゃんと覚えておく。

作っている側からすると、

状態管理の話です。

でも、

使っている側からすると、

もっと単純でした。

「さっきの続きから使いたい」

ただ、

それだけだったのだと思います。

前回の記事

コレクション管理アプリで、「画面の状態」と「データの状態」は別物だと気づいた話

シリーズ

このシリーズでは、個人開発しているコレクション管理アプリ SLX（StockLedgerX） の設計思想が、どのように変化していったのかを時系列でまとめています。

シリーズ一覧はこちらです。

▶ SLX開発録〜設計思想ができるまで〜

次回は、

こうして使いやすさを考えていく中で生まれた、

「最初から綺麗に整理しなくてもいい」という考え方

について書いてみようと思います。