文輪の概念データモデル
文輪のファイル出力・読み込み機能
OPMLでやろうかなと思ったけど、ほかのアウトライナーから読み込めるようにするのがめんどくさい。OPMLはあくまでエクスポート専用にしたほうが幸せになれる気がする。
sql.jsでDBにして保存…!なぜこのような危ない橋を渡ろうとしているかというと、セキュリティ的に安全にRDBの知見をためる必要性があるためです。
文輪の論理データモデル
@startuml
entity outline as "outline\nアウトライン" {
ulid
text
created_at_timestamp_ms
edited_at_timestamp_ms
}
entity outline_relation as "relation\n関係" {
ulid
parent_outline_ulid
child_outline_ulid
}
entity home_outline as "home outline\nホームアウトライン" {
outline_ulid
}
outline }-- outline_relation
outline ||--home_outline
@enduml
sql.jsで文輪のデータを保存
文輪の提供形態
- クラサバでサブスクで提供
- 一番儲かりそう。というか今っぽい。
- クラサバは開発が大変。
- データ吹き飛んだ時が大変。1,2回データ吹き飛ばして知見が溜まるまではサブスクしないほうがよさそう。
- WorkflowyやDynalistとガチンコ勝負になる。
- クラサバで広告モデルで提供
- デライトの劣化コピーを目指す形になってよろしくない。
- サブスクよりもデータに対する責任をあまりとらなくて良さそう。
- ペルソナとして作家のTak.氏があるので、利用者の注意を広告で煩わせるのはそれに沿ってない。
- ローカルアプリでサブスクで提供
- ビミョー。「商用利用は有料」みたいにして、本当に金払ってくれんの?みたいな疑いがある。
- 結局サブスクの管理機能が必要になるのでサーバー不要とはいかない
- Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
- ローカルアプリで買い切りで提供
- 一番儲からなさそう。というか古臭い。古いから悪いというわけではないということを肝に銘じていただきたい。
- でも一番楽。
- ライセンス管理とかは大変そう。そういうことをしだすと結局サーバーが必要。
- Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
- 寄付で運用
- 論外。寄付で回っているところをWikipedia以外で見たことがない。大体ヒーヒー言ってる。と思ったけど、Rustとかは寄付(というかスポンサー)でやっていってるらしい。
気持ち的には「クラサバでサブスクで提供」に傾いている。
あれ
正直、この先開発を進めるか悩むな。ノリと勢いで開発を始めてしまったので、どういう位置づけにするか決めていない。デライトの劣化コピーになるのは避けたいし、応用はしつつも別の山を登りたい。というか、KNSにまで作り上げる技術力がない。
進めるとして、WorkflowyかObsidianのような感じにするのがいいかもしれない。クラウド、もしくはローカル。
あれ
あれ
文輪は一旦、自分専用のツールにしたほうがいいかもしれない。設計がこなれるまでは他人のデータを持ちたくない。
収益についてはWordpressみたいにブログみたいにしてしまって、そこに広告を張れば良いだろうか?いや、よくよく考えればそれができるだけの文章力があって集客ができるのであれば、デライトの利用者を増やそうという試みがもっと成功しているはずで、そううまくはいかないだろう。
ブログ的な方向性で考えると、アウトラインを時系列順に並べたくなる。そうなるとデライトと方向性が似通ってしまう。輪郭法と同じ構造を用いて合理的に進めようとすると、どうしてもデライトと似通ってしまうのかもしれない。もしくは頭の中にデライトがあるために、つい真似てしまうのだろうか。
Dynalistのファイルみたいに複数のアウトラインを持てるようにして、そのファイルが時系列に並ぶみたいな形にしてもいいかもしれない。ただし実装を考えるとちょっとしんどい。後、個人的にファイル分割があまり好きではない。