{描出公開原則}{制限}{公開}=}(3)

{公開制限 K#F85E/A-E74C-A52F}

五段階

0:無し(無制限公開)
1:デライト向け(サービス内公開)
2:仲間向け(仲間向け公開)
3:相手向け(相手向け公開)
4:自分向け(自分向け公開)
11:デライトだけ(サービス内公開)
12:仲間だけ(仲間向け公開)
13:相手だけ(相手向け公開)
14:自分だけ(自分向け公開)

アイコンは丸枠

{一日一文}{課金}{金次第}{基本的な機能}{旨み}{事務負担}{支払い手続き}{主要機能}{ビジネス模体}{知識情報}...=}(91)

{フリーミアムからフリーソフィーへ K#F85E/A-E74C-E366}

デライトでは,「フリーソフィーfreesophy提唱している。無料フリー哲学フィロソフィーの意だ。

いわゆるフリーミアムよりも無料であることに重きを置く考え方だが,「哲学」と言うだけあって,ビジネス模体モデルに留まらず,経営思想でもあり設計思想でもある。


フリーソフィーの考え方を端的に表すため,「無料は品質」という言葉を私はよく使う。つまり,無料であるかどうかは,単に価格設定問題ではなく,サービス品質直結する問題でもあるということだ。

当然ながら,デライトにもサービスとしてどのように収益を上げていくかという課題があり,フリーミアムも含めて様々な選択肢があった。検討を重ねた結果として,全ての主要機能を無料で提供し続けるを選ぶことにした。

大体無料にした方が,サービス設計単純化出来,可接性アクセシビリティ可使性ユーザビリティ向上するからだ。

まず,フリーミアムを採用している多くのサービスにあるような「料金表」をデライトには掲げたくなかった。これは美的でもないし,こんなものと用者ユーザー睨めっこさせたくない。支払い手続きで煩わせるのも嫌だ……等々と,サービスをいかに握接アクセスしやすく,使いやすいものにするかということを追求していくと,結局無料にせざるを得ない。


無料が理想なら,課金必要悪だ。用者から直接金を取らずに問題なく経営していけるなら,課金サービスに意味は無い。

課金しないとなると頼りは広告くらいだが,デライトでは広告もかなり抑制している。少なくとも,用者体験を損うような広告は付けないようにしている。

もちろん,大抵の企業にそんなことは出来ない。しかし,超高効率経営を実現している希哲社には出来る。先日書いた文章ネットサービスにおける「成功」とは何かでも少し触れているように,デライト開発運営には驚異的に金がかかっていない。

もっとも,あまりに開発体制梱薄コンパクトにまとめてしまうと,課金に関する事務負担が馬鹿にならず,あまり旨みが残らないという問題もある。そういう意味では,超高効率経営とフリーソフィーは切り離せないのかもしれない。


困ったのは,無料であることを経営思想設計思想にまで深めた考え方を表現する言葉が無い,ということだった。

フリーミアムでいう「基本的な機能」と「高度な機能」に明確定義は無く,提供者側の都合で割とどうとでもなる。顰蹙を買っている Evernote は分かりやすい例だが,個人知識管理サービス長期的用者知識情報を預かるものだ。金次第で将来的に利用制限されるかもしれない,という不安はサービスの根幹に関わる。

しばらく悩み,ある時ふと閃いたのが「フリーソフィー」だった。

単純に音の響きもフリーミアムに負けず劣らず良いが,ことフィロソフィー看板にしている希哲社にとってこの上無い語感の良さ,意義的確新規性十分,「無料哲学」と和訳しても分かりやすい,と満点だった。

こんな文章を書いているのも,正直,あまりにも出来過ぎた造語なので自慢したかっただけかもしれない。フリーソフィー……とにかくやたら言ってみたくなる魔法の言葉だ。

=}
{希哲15年3月27日の開発}{期間指定}{1,000輪}{デライトのエクスポート機能}{希哲15年3月27日の進捗時限}{希哲15年3月27日の進捗}{希哲15年3月27日}{下信}{仕様検討}{握接}...=}(19)

{希哲15年3月27日9歩 K#F85E/A-E74C-09F4}

デライトのエクスポート機能仕様検討で終了。

現実的実装を考えると,最大1,000輪までの制限を設け,前後景輪もそれぞれ1,000輪まで含める,その代わり,期間指定出来るようにする,ということになりそうだ。

本人のみが握接出来る譜類として,KNo.XXXX.%Y%m%d-%Y%m%d.zip を下信出来るようにする。譜類の個数と時印から利用制限をかける。

=}
{共有用 URI}{埋め込み交度}{注意表示}{希哲15年3月14日の進捗時限}{希哲15年3月14日の進捗}{希哲15年3月14日}{Dex}{allow-scripts}{スクリプト禁止}{自輪郭}...=}(49)

{希哲15年3月14日4歩 K#F85E/A-E74C-7B1F}

デラング整備HTML タグ切り替えについて再検討

iframe 要素sandbox 属性を使い,自輪郭については allow-scripts を加えてスクリプトもある程度使えるようにし,他輪郭についてはスクリプト禁止しつつ注意表示をした上でタグを有効化出来る,という方向で考えていた。

ただ,自輪郭はこれでいいとして,他輪郭については用合いとして少し煩雑かという気もしていた。例えば,ちょっとしたタグが1つ使われているだけでも切り替えて見なければならない。読み手にとってはもちろん,柔軟表現のためにタグを使いたい書き手にとっても好ましい用合いではない。

そもそも HTML安全性についていちいち検査したくない,というのが動機だったが,Dex によってそれも大した問題ではなくなってきた。

他輪郭についても,ある程度制限はした上で安全なタグは普通に利用出来るように軌道修正することにした。


YouTubeTwitter 等の埋め込み交度にもある程度対応することにした。

これも検査が面倒という点で避けていたが,よく考えると,それらしい入力から最小限パラメーターだけ拾って,予め用意しておいたテンプレート置換して出力すれば安全性は容易に担保出来る。

共有用 URI の先頭に + を付けるだけという渡括記法もあった方が良いが,慣れない人は埋め込み交度を貼り付けてくる可能性が高い。

可読性を考えると,描出時に渡括記法に置換してしまうのが良さそうだ。

=}
{デライト高速化}{希哲15年3月11日の開発}{保存方式}{譜類添付機能}{希哲15年3月11日の進捗時限}{希哲15年3月11日の進捗}{希哲15年3月11日}{自我アイコン設定機能実装}{描出公開原則}{上信}...=}(40)

{希哲15年3月11日11歩 K#F85E/A-E74C-8A64}

デライトではこれまで意図的に避けてきた譜類添付機能について検討

1MB未満程度の比較的小さな譜類であれば許容してもいいかもしれない。

自我アイコン設定機能実装を通して libxtd はある程度整えてあり,拡張子を利用した保存方式は個人的にも使い慣れ,捌き手の対応も出来ている。

後は,kn sync で実現している上信フォームで出来るようにすれば良いだけで,実装自体はすぐにでも出来る。

残る問題は,用合い運用だ。用合いはどうとでもなるとして,特に運用上の問題を解消しておきたい。

そもそも現状,描出自体はいくらでも出来るので,用者毎に制限をかける必要は特にない。

描出公開原則があることと無料であること,デライト高速化が視野に入っていることも大きい。倉庫のような使い方はされにくいだろうし,契約ではないので,手に負えなくなればその時点で無効化するなり出来る。

出与え URI のようなものを使われるくらいなら,上信してもらった方が効率的でもある。

それによって良い献典になるのであれば積極的に使ってもらった方がいいくらいかもしれない。

1輪郭につき1MB未満,拡張子制限付きで検討しておく。

{渡航}{制限}=}(2)
{譲渡}{制限}=}(2)
{制限}
{}