0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

コレクション管理アプリで、「未分類」は全部同じなのか考えた話

0
Posted at

はじめに

前回、

「あとで整理」は何のための機能なのかを、

改めて考えました。

やりたかったことは、

未整理のデータをなくすことではありません。

登録と整理を分けること。

分類先を今すぐ決められなくても、

登録だけはできるようにする。

そのための「あとで整理」でした。

では、

分類先を決めずに登録したデータは、

アプリの中ではどこに置けばいいのでしょうか。

最初は、

「未分類」に入れておけばいい。

そう考えていました。

でも、

実際にデータを当てはめてみると、

「未分類」という一つの言葉だけでは、

少し足りないことに気づきました。


具体的なデータを置いて考えてみる

ここでは分かりやすくするため、

本を管理しているとして考えてみます。

すべて整理されていれば、

たとえばこんな構造になります。

本
│
└─ 技術書
    │
    └─ プログラミング
        │
        └─ 入門書A

SLXの構造に当てはめると、

Collection:本
    ↓
Folder:技術書
    ↓
Category:プログラミング
    ↓
Title:入門書A

ここまで決まっていれば、

何も問題はありません。

Titleが、

どこに所属しているのかも分かります。

では、

この「入門書A」を登録するとき、

まだ分類先を決めていなかったらどうなるでしょうか。


何も決めずに登録したい

本を一冊登録したい。

でも今は、

どこに分類するかまで考えたくない。

決まっているのは、

「入門書A」というTitleだけです。

???
  │
  └─ ???
      │
      └─ ???
          │
          └─ 入門書A

Collectionも、

Folderも、

Categoryも決まっていません。

こういうときのために、

「あとで整理」を用意しました。

あとで整理
    │
    └─ 入門書A

これなら、

分類先を考えなくても、

ひとまず登録できます。

ここまでは、

それほど難しくありません。

でも、

別のケースを考えると、

少し事情が変わってきます。


Collectionまでは決めている

「入門書A」は、

少なくとも「本」として管理する。

そこまでは決めたとします。

でも、

技術書なのか、

別の分類にするのかまでは、

まだ決めていません。

すると、

状態としてはこうなります。

本
│
└─ ???
    │
    └─ ???
        │
        └─ 入門書A

これも、

分類は終わっていません。

つまり、

「未分類」です。

でも、

先ほどとは少し違います。

???
  └─ ???
      └─ ???
          └─ 入門書A

だったものが、

本
  └─ ???
      └─ ???
          └─ 入門書A

になっています。

「本に属する」ことは、すでに決まっています。

同じ未分類でも、

すでに確定している分類情報が違います。


Folderまでは決めている

さらに、

「技術書」までは決めていたらどうでしょうか。

本
│
└─ 技術書
    │
    └─ ???
        │
        └─ 入門書A

Categoryは、

まだ決めていません。

これも、

分類が完了していないという意味では、

やはり「未分類」です。

でも、

今度は、

本
  └─ 技術書

まで決まっています。

先ほどより、

さらに一つ、

確定している分類情報が増えました。


Categoryまで決まれば、分類が完了する

最後に、

「プログラミング」というCategoryまで決めます。

本
│
└─ 技術書
    │
    └─ プログラミング
        │
        └─ 入門書A

これで、

通常の分類済みTitleになります。

ここまでの状態を、

一度並べてみます。

① 何も決めていない

???
  └─ ???
      └─ ???
          └─ 入門書A


② Collectionまで決めた

本
  └─ ???
      └─ ???
          └─ 入門書A


③ Folderまで決めた

本
  └─ 技術書
      └─ ???
          └─ 入門書A


④ Categoryまで決めた

本
  └─ 技術書
      └─ プログラミング
          └─ 入門書A

こうして並べてみると、

①〜③はすべて、

「分類が終わっていない」

という点では同じです。

でも、

どこまで分類先が決まっているのかが違います。


全部まとめて「未分類」でいいのか

ここで、

最初に考えていた方法に戻ります。

分類が終わっていないなら、

全部「未分類」に入れる。

未分類
│
├─ 入門書A
├─ 入門書B
└─ 入門書C

見た目は、

とても単純です。

でも、

これでは一つ問題があります。

たとえば、

入門書Aは、

何も決めていなかった。

入門書Bは、

「本」までは決めていた。

入門書Cは、

「本 → 技術書」まで決めていた。

それでも全部、

未分類
  └─ Title

にしてしまうと、

どこまで分類先を決めていたのか分からなくなります。

せっかく、

「ここまでは決めた」

という情報があるのに、

一つの未分類にまとめた瞬間、

その情報まで失ってしまいます。

それは、

少し違う気がしました。


「未分類」は0か1だけでは考えられなかった

ここで、

自分の中の「未分類」の見え方が変わりました。

それまでは、

分類済み
    or
未分類

という、

二つの状態で考えていました。

でも、

実際のデータを見てみると、

何も決めていない
      ↓
Collectionまで決めた
      ↓
Folderまで決めた
      ↓
Categoryまで決めた
      ↓
   分類完了

という違いがあります。

分類が完了しているかどうかだけなら、

最後以外は全部「未分類」です。

でも、

そこに至るまでに確定している分類情報は同じではありません。

「未分類」という一つの言葉だけでは、

この違いを表せませんでした。


同じ「未分類」でも、持っている情報が違う

図にすると、

もう少し分かりやすくなります。

【何も決めていない】

[???]
   │
[???]
   │
[???]
   │
[入門書A]


【Collectionまで決めた】

[ 本 ]
   │
[???]
   │
[???]
   │
[入門書A]


【Folderまで決めた】

[ 本 ]
   │
[技術書]
   │
[???]
   │
[入門書A]


【分類完了】

[ 本 ]
   │
[技術書]
   │
[プログラミング]
   │
[入門書A]

上から見ると、

少しずつ分類先が決まっていきます。

「分類が完了していない」

という点では同じでも、

すでに決まっている情報は違います。


では、これを全部ユーザーに見せる?

ここで、

もう一つ問題が出てきました。

内部では、

この違いを残しておいた方がよさそうです。

だからといって、

その構造をそのまま画面に出したら、

どうなるでしょうか。

たとえば、

本
├─ 技術書
├─ 小説
├─ Folder未分類
└─ Category未分類

のように表示する。

内部的には、

何を表しているのか分かります。

でも、

ユーザーからすると、

Folder未分類?

Category未分類?

何が違うの?

となるかもしれません。

アプリ内部の都合を、

そのままユーザーに見せているだけです。


内部では必要。でも、そのまま見せる必要はない

ここで、

以前考えたことに戻ってきました。

内部のデータ構造と、ユーザーに見せる構造は同じでなくてもいい。

内部では、

何も決めていない

Collectionまで決めている

Folderまで決めている

という違いを残す。

一方、

ユーザーに見せるときは、

もっと自然な形にする。

内部で必要だからといって、

その構造をそのままUIに出す必要はありません。

むしろ、

内部では必要な情報を保持しながら、

ユーザーには考えなくても使えるようにする。

その方が、

これまで考えてきたSLXの方向にも合っています。


「あとで整理」と「未分類」も少し違う

ここまで考えると、

「あとで整理」と「未分類」の違いも、

もう少しはっきりしてきました。

「あとで整理」は、

登録するときに、

今は正式な分類先を決めない

と選ぶことです。

つまり、

あとで整理
    │
    └─ 入門書A

は、

まだCollectionすら決めていない状態です。

一方、

本
  │
  └─ 未分類
      │
      └─ 入門書A

なら、

少なくとも、

「本に入れる」ことまでは決めています。

さらに、

本
  │
  └─ 技術書
      │
      └─ 未分類
          │
          └─ 入門書A

なら、

CollectionとFolderまでは決まっています。

全部、

分類が完了していないという意味では同じです。

でも、

すでに確定している分類情報は同じではありません。

「あとで整理」と、

各階層にある「未分類」。

同じように見えていたものが、

少しずつ別のものに見えてきました。


では、この違いをどうやって持つ?

ここまでで、

必要なことは見えてきました。

ユーザーには、

できるだけ単純に見せたい。

でも内部では、

何も決まっていない

Collectionまでは決まっている

Folderまでは決まっている

という違いを残したい。

つまり、

ユーザーから見える構造

        シンプル
           ↑
           │
           │
           ↓

    アプリ内部の構造

  必要な情報は保持する

この二つを、

分けて考える必要がありそうです。

では、

この「分類先が途中まで決まっている状態」を、

実際のデータ構造では、

どう持てばいいのでしょうか。


おわりに

最初は、

分類先が決まっていないなら、

一つの「未分類」に入れればいいと思っていました。

でも、

具体的なデータを置いてみると、

そう単純ではありませんでした。

何も決めていない

Collectionまでは決めた

Folderまでは決めた

どれも、

まだ分類は完了していません。

でも、

すでに確定している分類情報は同じではありません。

その違いは、

内部では残しておきたい。

一方で、

内部構造をそのままユーザーに見せる必要はない。

ここでも、

データ構造とUIを分けて考える必要が出てきました。


前回の記事

第18話では、

「あとで整理」は何のための機能なのかを、

原点に戻って考えました。


シリーズ一覧

このアプリを作りながら考えてきたことを、

開発の流れに沿ってまとめています。


次は、

この「分類先が途中まで決まっている状態」を、内部ではどうやって持てばいいのか。

そこを考えてみようと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?