{新生デライト}{難しい質問}{超かんたん}{自由市場}{デライト(なんでもメモ)}{分からなかった}{デライト}{階層関係}{森羅万象}{あれ}...=}(55)

{引き入れについてのご質問から考えたこと K#F85E/E74C-C61D}

大変回答が遅くなってしまい申し訳ありません。色々なことを考えさせられるご質問で,デライトにとって非常に重要な宿題を頂いたように感じています。ありがとうございます。

だいぶ時間が経っているのでお考えが変わった部分もあるとは思いますが,他の方の参考にもなるように文章を残しておきます。まずは,ご質問の内容に沿って,出来るだけ端的に書けることを書いてみます。

引き入れについて

宇田川さんは、知名のみの輪郭をよく引き入れられ欄に引き入れているように見受けられます。

まず,「引き入れられ欄に引き入れる」という概念が私の中に無かったので,難しい質問でした。「引き入れる」というのは,ある輪郭の中に他の輪郭を文字通り「引き込むように入れる」,ただそれだけの極めて単純な操作で,それをする方にとっては「引き入れる」,される方にとっては「引き入れられる」ということになります。

例えば,フォルダの中にフォルダを入れる操作に相当します。ただ,多くのツールでは,データの内容とデータ同士の関連性は別々の画面に表示されます(別のウィンドウやサイドバーなど)。輪郭は,輪郭の内容と他の輪郭との関連性を一緒に表示させる仕組みを持っているのが特徴的です。これは,画面を切り替えたり視線を大きく移動することなく,内容と関連性を確認したり修正したり出来るようにする工夫です。

「輪郭をどの輪郭に引き入れたいか」というごく単純な考え方で使えるように設計したつもりでしたが,この見た目が「引き入れ欄に引き入れる」や「引き入れられ欄に引き入れる」という複雑な考え方をさせてしまっているのかもしれません。

このように、知名のみの輪郭を引き入れられ欄に輪括させるのは、主にどのような効果を狙ってのことなのか、ご教示いただけませんか。
あるいは、実際に効果があったと感じた出来事・体験をお伺いしてもよろしいでしょうか。

特に「知名のみの輪郭」という意識をしたこともありませんでした。その時に知名だけで十分なら知名だけの輪郭が出来ますし,当然その後描写に書き加えることもあります。知名があるか描写があるかということに固定的な意味はありません。私にとっては,この「知名のみの輪郭」という意味ありげな概念もどこから生じたのか不思議でした。

t_w さんも書いているように,アウトライナー項目をざっと書き出していく感覚に近いかもしれません。ある項目をある項目の下位に移動させることも引き入れに似ています。

平面的なアウトライナーに対して,各項目が独立していて,どの角度からでも階層関係立体階層構造を作ることが出来る。これがデライトを「立体アウトライナー」と呼ぶ理由です。大袈裟な言い方をすれば,私はこれを使って「(普通のアウトライナーでは不可能な)森羅万象アウトラインを書き出している」ところです。その単位をそのまま「輪郭アウトライン」と呼んでいます。

アウトライナーで最初にざっと書き出してみた項目も,ご質問にある「知名のみの輪郭」も,言ってみれば「情報の」です。どのようにでも成長していく可能性があり,何がどのように役立つかは予め分かりません。ひたすら蒔いてみるしかないわけです。


効果」というのも正直困った部分でした。私は息をするようにデライトを使っていて,その恩恵に依存して生きているようなところがあるので,「空気に効果があったと感じた出来事」を聞かれているような感覚でしょうか。

ある言葉に関連する言葉がこういう形で連なっていれば,日々気付かされることは枚挙に暇がありません。思い出せなかったことを思い出すこと,気付いていなかった概念同士のつながりを発見すること……これ自体はデライトのごく基本的な使い方です。

全知検索について

当方が同じ操作を行う場合、短期的には全知検索の検索語として、未来の自分が検索することを見込んでいます。

しかしながら、ただ検索に引っ掛かるためだけに輪郭を増やしていくと、描写のない輪郭が増え、デライトの持つ「同じ知名の輪郭を複数作れる」機能の恩恵を受けられず、形だけの輪括だけが増えていってしまうように感じてしまいます。

これも理解の難しい部分でした。「同じ知名の輪郭を複数作れる機能の恩恵」,「形だけの輪括」が何を指しているのか分かりませんでした。「描写のない輪郭が増えることで何らかの恩恵が受けられない」と感じたこともありませんでした。

そもそも,「同じ知名の輪郭を複数作れる機能の恩恵」というのは,「絶対的な名前のない情報を扱えること」以上でも以下でもない,極めて単純自然なことだと思っています。例えば,ツイートのような思いのまとまりにいちいち名前を付けていられませんし,同じ文字列で表現されていても異なる物事がたくさんあるのが我々が住んでいるありのままの世界です。ウィキなどでは全ての物事に固有の名前を付けるという極めて不自然なことをしてきたわけです。それを排し,文字通り「なんでも」記述対象に出来るようにしたのがデライトです。

「検索に引っ掛かるためだけに輪郭を増やしていく」という表現から,どうも全知検索の趣旨が上手く伝わっていないらしいということは分かりました。全知検索というのは,「検索に引っ掛かるように輪郭を増やしていく」こととデライトに知識を蓄積していくことを同一視し,それを促進するための仕組みなのです。

引き入れによってある輪郭からある輪郭への関係が作られるということは,脳内にある情報が輪郭として表現され,それがつながっていくということです。これは頭脳をデータとして再現するということであって,デライトが実現したいことそのものです。それはそのまま検索結果を充実させることにもなるわけです。

たまに「検索用の輪郭」という表現が使われることがありますが,「検索用の輪郭」「検索用ではない輪郭」という分類も全く本質的ではありません。それが有用な分類であればそういう機能にしています。デライトではそれをあえて排しているわけですが,この意図もあまり上手く伝えることが出来ていません。頭の中にある情報は全てが他の情報を引き出す鍵でもあり,その意味では全て検索用です。それをそのままデライト上で表現して欲しいというのが全知検索の趣旨です。

私はデライトを使って自分の頭の中にある全ての物事を紐付ける作業を日々しています。それによって,頭の中で情報を引き出すようにあらゆる情報を自由自在に引き出すことが出来ています。これ以上「恩恵」のあるメモツールを私は知りません。

考え過ぎないこと

どうせ輪括するのであれば、もっと長期的な効果を見込みたく(そこそこの信念を持って輪括したく)、輪郭法を長年使い込んでいる先輩のご意見を頂戴できればと思います。

一つ助言するとすれば,個人知識管理においては「書く前に考え過ぎること」が最大の障害です。

デライトはその障害を最大限排するように設計されています。例えば,名前を付けなくても体裁を考えなくてもまずは書き出してみて,後からいくらでも修正出来るように作られています。こういった点においてデライト以上のものはなかなか無いと思います。

引き入れについても同じで,そこまで思い悩んで使うものとして作っていないのですが,実際にはあれこれ考えさせてしまうことが多いです。これは明確に伝え方の失敗であり,日々反省しているところです。

計画し過ぎないこと

「知名のみの輪郭」「検索用の輪郭」「形だけの輪括」……こうした利用者によって再発明されがちな区別を排して輪郭という単位であらゆる情報を平等化している理由は,情報が持つ役割を決めつけず,「設計」よる破綻を防ぐためです。

近年,Notion のように情報を自由に設計出来るツールが人気を集めています。それもそのはずで,誰でも最初は自分が思い描いたように設計出来ると嬉しいものです。絵に描いた餅を見ているわけですから。ただ,その大半がまず間違いなく失敗していきます。これは Notion どうこうではなく,人間の計画性というのはそんなものだからです。

個人知識管理の実践を重ねていくと,計画というものがいかに破綻しやすいかということを学びます。したがって,経験豊富な人ほど計画に依存しない方法を求めるようになります。これは,差別がなく自由市場のある社会の方が発展しやすいことにも似ています。人と同じで,情報も成り行き任せに育てていった方が強くなります。デライトは,どのツールよりもそこに最適化されたサービスです。

デライトは簡単です

デライトは,その必要性分からなかった人にとっては「意味不明な用語が多くて分かりにくいサービス」だと思います。見慣れない UI や用語に慣れようという動機が無いからです。

一方で,本当に使いたいと思っている人にとっては実は簡単過ぎるくらいのサービスです。用語といっても小学生でも分かるくらいの表現しか使っていませんし,量も他製品に比べて特に多いとは言えません。登録するのも使うのも実際には「超かんたん」です。というのも,デライトは誰でも使えるようなサービスとして設計され,誰でも理解出来るように努めてきたからです。

ただ,この徹底した「簡単さ」が,デライトの高度な部分に惹かれてきた人ととの間にすれ違いを生んでいるのではないか,という気がしています。小学生でも分かる 1+1 について考え込んでしまう大人がいることに似ているかもしれません。デライトは難しいもの,という先入観があると,簡単さにも構えてしまいます。

デライトは簡単に使えるように作られていますし,簡単に使えるものです。

感謝

cat さんは,数少ない初期デライトの重要な貢献者です。

その方から頂いたこの質問を読んだ時,最初から最後まで意味が分からなかったことに頭を抱えました。自分は一体どれだけ利用者について理解していなかったのか,という感じです。それから毎日,開発者と利用者の間にあるについて考えてきました。回答にここまでの時間を要した理由です。

それと同時に,デライトの大きな課題を解決するヒントがここに隠されているのではないか,という気がしています。これも,率直な勇気ある質問がなければ気付けなかったことなので,本当にありがたいことだと思います。

いまデライトは,「新生デライト」に向けて文書整備を一気に進めようとしているところです。cat さんに限らず,皆様には,ふだん疑問に感じていることがあれば遠慮なく投げかけて頂きたいです。どんな疑問であれ,それと向き合うことがデライトの財産になります。

{違了処理整備}{出振るい}{踏み切れた}{radial-gradient()}{作れた}{理想的な陰影}{簡単なようで}{実験していた}{画段}{色々な場面}...=}(204)

{希哲16年3月28日の開発 K#F85E/E74C-5B9D}

KNEST 隠し実装の再開金風といった出来事中断していた昨年9月以来,初めての Aejs出振るい終えた最初微調整程度でとりあえず出振るい目指すつもりだったが,あっという間下見機能陰影付きスクロール形になり,一応の新輪郭選り手」が出来た

外観操作性ともに洗練された新輪郭選り手日々の描出がより快適になることはもちろん下見機能手定め領当て調整大幅に効率化することによりデラング整備加速するだろう。そもそも Aejs出振るい出来なかったことで前縁関して出来ること限られていたため,その障害無くなったことが大きい

新輪郭選り手

今回出振るい以前を「旧輪郭選り手」,以後を「新輪郭選り手」と仮に呼んでいる

新輪郭選り手では,@oln.bld詰め込んでいた選り手関連機能@oln.edr_dln.bld@oln.edr_knm.bld整理し,複雑な機能見通し良く管理出来るようになった。これにより,保守性もちろん全体として見触れ大きく改善した。

まず,これまで知名選り手角丸長方形で,描写選り手吹き描き合わせた眼形表示していたが,両方開いている場合は「合体選り手」として眼形になるようにした画面撮り新規描出フォーム再描出フォーム旧輪郭選り手では単独開いた場合外観変わらず調和感欠けていた画面撮り新規描出フォーム再描出フォーム挙動もより連動的になり,自然になった。

描写選り手右脇適当に付けていた取り消しボタンも,合体選り手では知名選り手描写選り手同時に閉じる機能分かりやすくなり,見た目洗練された

描出ボタン22日9歩方針まとめ目障りにならないデザイン保ちつつ初心者にも分かりやすいものに出来た

挙動面では,違了処理整備若干表示タイミングなどに出来ていたぎこちなさ解消出来た外していた選り手溶暗溶明動き付け復活させ,滑らか見えるようになった。

まだ様子見必要だが,違了処理整備のあたりから出来ていた不具合解消期待出来る。特に描写選り手二重いたり,デラング記法消去して再描出してしまう不具合稀に起こるのが気になっていた

今回目玉となった下見機能は,思わぬ形あっさりまとまった感触く,色々な場面活躍してくれるだろう。

陰影付きスクロール

26日14歩出来た陰影付きスクロール同時に出振るいした画面撮り下見機能にも有用気付いたことで実装踏み切れた

背景色溶暗していく「溶暗付きスクロール」として考え始めたのは昨年3月11日9歩だったが,空行続くこともあり閲覧性必要な描写部には不向き気付いてからは,薄い陰影付ける方向実験していた

これも簡単なようで調整難しかった陰影がかかる高さ濃さ画段微妙な緩急調整繰り返し,さりげなく,かつ分かりやすい理想的な陰影ようやく作れた一時linear-gradient() ではなく radial-gradient() を使って中央丸みのある陰影試したが,交度部区などに重なった時に視認出来なくなるためやめた

諸場舞覧などスクロールバー出ない舞覧スクロール可能であることが非常に分かりにくいという用合い上欠陥がこれで解消したスクロールバーの出る舞覧でもより直感的スクロール可能であることが分かるようになり,効果大きい

{希哲館事業}{デラング}{進捗記録}{希哲16年2月22日}{希哲16年2月22日の開発}{希哲16年2月22日の進捗}{担わせる}{4ja}{有名無実化}{意識しない}...=}(159)

{希哲16年2月22日9歩 K#F85E/E74C-BABF}

進捗時限記録中略

kitetu.comサブドメイン設計についての検討終了

今後デラングのように独立して参照出来るべき献典には積極的にサブドメイン与えていくことにした(例:dlng.kitetu.com


デラング的転回同時にデラング文書dlng.kitetu.com与えることを決めたが,これを機に知番SLFS 等々の公式文書にもサブドメイン与えることを考え始めた

これまでサブドメイン追加には消極的で,例えば技術系献典tech.kitetu.com集約することを考えていた。ただ,この手の URL 設計は,運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上,階層的な整理難しいことも多々あり,変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合対策として,経験上最短原則」が最善であることは分かっていて,最近駒手にせよ各種識別子にせよ知名最短知名原則にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業要素全て kitetu.com階層下にある,ということだけは確かだ。もちろん,これとは別に,階層的な情報源もあった方がいいので,そこは tech.kitetu.com などに担わせる

献典ドメインとしての独立性統一感同時に持たせられるのだから,むしろ,ここからがドメイン名統一本領発揮になりそうだ。

2文字サブドメイン問題解決

サブドメイン活用していく上で,一つ,「2文字サブドメイン問題」とでもいうべき問題があった

例えば,サブドメイン与えるなら cu.kitetu.com とするのが自然だが,CUキューバ国家符号だ。

ドメイン名統一によって ccTLD使わなくなっているため,将来的に地域別ドメイン欲しくなった時にはサブドメイン使うことになる。2文字サブドメイン使用避けるべきかもしれない,と考えていたキット*メーネmn.kitetu.comモンゴルMN被っているのが少し気になってはいた

ただ,その懸念も「もやもや」の域を出ていなかった明らかに紛らわしいサブドメイン最初から使わないので,被るとしたら普段意識しないようなものだ。被ったとして,ドメインハックccTLD有名無実化している今,そこまで神経質になることでもないだろう。そんなことのために,わざわざ不自然な表現もしたくない。とはいえ,サブドメイン選択肢多い越したことはない

そこで,国家符号表す何らかの接子導入考えたFacebook のように,ja-jp言語符号付きを基本として,言語符号がいらない場合は x-jp のように表記出来るようにするかとも考えたが,少し野暮ったい

最終的に4 接頭子導入する方向検討進めることにした。例えば,キューバ向けのドメイン4cu.kitetu.com として cu.kitetu.com区別出来るようにする。衝突しなければ 4 接頭子省略してもいいし,4ja のように言語符号に代えられてもいいだろう。4ja-jp のような表現が出来てもいい。これなら十分な簡潔性柔軟性兼ねられる

例えば 4jp.kitetu.com なら www.kitetu.com変わらない標準的な長さだし,むしろお洒落感すらあるので,これで統一して,4 接頭子無しは転送用にしてもいいくらいかもしれない。

いまのところ地域別ドメイン必要は感じておらず,将来的に必要になるかもしれない,という程度の問題なので,細かいこと追い追い決めるとりあえず理論上すっきりしたので良かった

=}
{進捗記録}{文字装飾記法}{<small>}{置き換えられる}{補足部区}{注意部区}{一段階目}{希哲16年1月24日4歩}{強調度}{注意記法}...=}(73)

{希哲16年1月24日16歩 K#F85E/E74C-1FEF}

注意記法補足記法についての再検討終了

4歩を以下のように修正した。強調度に応じて三段階となる補足記法同様

!--
小さな注意書き
--

!!--
通常の注意書き
--

!!!--
重要な注意書き
--

装体は,23日2歩下敷きに,境界線背景色無しで font-size: 0.8em 程度にした小書きのものを加える。この場合,一段階目注意部区補足部区装体的に区別出来なくなるが,そもそも小さな注意書き補足違い曖昧なものなので自然といえば自然だ。


そもそも注意書き目立つように書かれるものばかりではない,というところに引っかかっていた

二段階三段階かは迷ったが,二段階にして後から追加出来なくなるよりは,三段階にして一段階目無用の長物になる後悔の方が小さい


当初,記号の数で「重要度」を表すことにしていたが,内容重要性装体目立たせ方は必ずしも一致しないので,「強調度」程度の意味合いにしておくべきかもしれない。


ダッシュ記法への応用考えた

例えばデラング文書では,目次項目末尾<small>----輪郭記法</small> などと書いているが,これを ?----輪郭記法置き換えられるかもしれない。

23日12歩書いた小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあった」とはこのことだったが,あくまでも文字装飾記法の一種である文字サイズ記法フォント記法<small> 相当の表現完全に代替は出来ない。

{用者}{進捗記録}{認識しやすい}{兼ねている}{おまけに}{多々ある}{二段階方式}{下見ボタン}{確認ボタン}{最有力案}...=}(90)

{希哲16年1月23日1歩 K#F85E/E74C-27DA}

換配確認機能」についての再検討終了。なお,この検討から「下見プレビュー機能」に改称した。

下見機能は,輪郭選り手左下下見ボタンを置く形でほぼ確定か。


デラング整備進展とともに重要性増している下見機能だが,用合いをどうするかについてはまだ少し迷いがあった。

一応最有力案は,輪郭選り手左下に「確認ボタン」を置くというものだった。左上公開設定機能右上取り消しボタン使いたいので,左下置くのが自然ではある。

完了ボタン並べるという捨て切れなかったが,押し間違い多発しそうで用合いとしては難がある

今朝ふと,確認ボタンから描き出し完了ボタンへの二段階方式浮上してきた。つまり,必ず換配確認をしてから描き出し描き直しを行うことになる。

二段階方式利点には用合い単純化初心者にとっての流れ分かりやすさおまけに捌き手負荷軽減見込めるが,使い慣れた用者にとっては煩雑になり過ぎる懸念があり,採用見送った

ある程度複雑なデラング記法使う場合など換配確認をしたいこともなくはないが,確認するまでもない描き直し多々ある。また,公開設定機能導入によって気軽に描き出し描き直しが出来るようになると,役割重複してしまう。

一つ,輪郭削除確認機能を兼ねられるかとも思ったが,そもそも知名描写にして削除というのが確認作業兼ねているためこれもやはり煩わしい

やはり,換配確認選択的機能にしておくべきだろう。

これまで,完了ボタンに近い位置に置くことも考えていたため,描出流れの中で分かりやすいように「確認ボタン」「換配確認機能」などと「確認」をプレビュー日本語表現として採用していたが,ある程度独立した機能として認識しやすいように今後は「下見」とすることにした。

=}(1){あれ}
{デラング}{ラテン文字}{進捗記録}{パンくず記法}{注意記法}{補足記法}{折り畳み記法}{感じさせてくれる}{歴史的な意義}{今となっては}...=}(166)

{希哲16年1月20日8歩 K#F85E/E74C-2FC4}

進捗時限記録中略

ひょんなことから予てから課題だった折り畳み記法急速にまとまった

折り畳み記法は,他の部区記法組み合わせ使える汎用的な記法として実装していくことにした。以下のように,部区開始行末^加えることで,その部区見出しなら階層下内容折り畳まれるようにする。厳密に言えば見出し階層下内容含む部区ではないが,例外的に扱う

・リストの折り畳み ^
  ・折り畳まれる項目

* 折り畳む見出し ^
折り畳まれる内容

+{埋め込みの折り畳み K#XXXX} ^

検討中,これがネタバレNSFW のような閲覧注意内容使えそうなことにも気付いた

きっかけからまとまるまで

補足記法・注意記法についての検討で,終了記号区切り線--)も使えるようにすることを考えた時,以下のように区切り線亜種として ^^ を使って折り畳めることをしてもいいのではないかと思い付いたことがきっかけだった。

?? 補足
補足内容
^^

この終了記号のように,他の部区にも統一的に応用出来る記法があれば何かと可能性が広がる。そこであれこれ検討してみると,部区終了記号だけでなく開始記号側にも分かりやすい目印欲しくなった。むしろそちらの方が自然場合多い

^対応する記号なら v考えられるが, などと異なり自然言語扱うデラングラテン文字導入しにくい日本語はともかく外国語問題が起きないとも限らない

何より下向きの三角形一般に展開されていることを表す記号なので,折り畳まれている記号として v開始記号添えるのは直感的ではない。となると,<>デラングではある程度活用方向性決まっているので,矢印的に使えそうASCII 記号^ しかない。

ここで,「行末^」を思いついた。これなら折り畳み記号としての直感性もあり,他記法とも組み合わせやすいパンくず記法で「行末>」を採用する直前にあっただが,微妙な違和感があり回避していた。この直感大当たりだった。

そして終了記号^^ とも整合的見える……と考え出したところで,今度はこっちの問題気になってきた。まず,日本人感覚ではぱっと見顔文字見える。そこで,--亜種であることが分かりやすいように --^考えてみたが,空行挟まない特定の文字指しているような記号見える

そもそも開始行末1個あれば,特別な終了記号要らないことに気付くまで時間はかからなかった結果的に非常にすっきりしたになった。

他の検討案

昨年6月18日の開発時点からは,以下2案があった。

++ ラベル
折り畳まれる内容
--

? ラベル
折り畳まれる内容
!

前者がこれまでの最新案で,区切り線--対応させて,++使うツリー開閉記号しばしば +-使われることに引っかけただったが,埋め込み記法渡括記法との紛らわしさから現時点での採用考えにくい。特に最近では ++使った行内埋め込み記法有力視していることもあった。無理に区別出来なくはないが,意味的な整合性確保するのが難しい

後者は,補足記法注意記法方向性固まった今となっては採用余地皆無だが,当時から今回の検討きっかけになった補足記法との組み合わせ考えていたことを示すであり,歴史的な意義感じさせてくれるものではある。

{自然}

{}