{希哲16年5月の一日一文}{囚われたくない}{狭苦しい}{よく使っている}{閉じた}{満たしたい}{知的探究心}{好きなだけ}{遠慮する}{他人に}...=}(96)

{デライトに“参加しにくさ”を感じている人へ K#F85E/E74C-E681}

デライト新規利用者増やすにはどうすればいいか,と考えてくれている利用者達もあまり触れないことに,私自身のアカウント問題がある。デライト普及にとって最大の障害か,といえば,あまりに癖の強い私の輪郭溢れかえっていること,というのが開発者として常に感じていることだ。自分が訪問者でも入りにくいな,と思う

実際最初の頃は,自分の輪郭目立たせないように,宣伝活動をした後しばらく描き出し避けるなんてことまでしていた。それはそれで使いこなし方分かりにくくなるので,あまり作為的なことはしないようになった。だから,初期利用者入ってきた時は,世の中には変わった人がいるものだな,としみじみ思ったものだ。そうは思いつつ,私も私で失礼気がして言いにくかった

利用者達が活発描き出ししてくれるようになったおかげで,だいぶ入りやすい雰囲気になったとは思う。それでも,客観的に見れば,まだ「変わった人達の集まり」なのかもしれないし,コミュニティとしてのデライトに“参加しにくさ”を感じている多いだろう。

デライトは,極力誰でも好きな時にて,好きなこと好きなだけ書けるように設計している。もちろん挨拶必要もないし,他人に遠慮する必要もない。個人情報どころか,名前すらいらない。私自身,狭苦しいクラスタ」だとか閉じたコミュニティ昔から嫌いだ。

あまり先入観持たず,まずは触ってみてほしい,というのが開発者としての願いではあるが,もしデライトコミュニティとしての特徴があるとすれば,自由に知的好奇心探究心満たしたい人達の集まりとは言えるかもしれない。「希哲フィロソフィー」という言葉よく使っているように,知的探究心以外のなにものにも囚われたくない人間にとって,機能的にもデライト最高の場所だ。


=}
{賢くないデライターに俺はなる}{新生デライト}{知能増幅メモサービス}{一日一文}{希哲16年4月の一日一文}{森を見て木を見る}{向けた}{研究期間}{科学的な}{粘り続ける}...=}(327)

{第四次宣伝攻勢に向けて K#F85E/E74C-668D}

デライトは,黄金週間初日となる明日29日4度目の宣伝攻勢第四次宣伝攻勢始めるこれを機に中断していた一日一文」の日課再開することにした。

デライトはいま,包括的な改良構想によって「新生デライト」に生まれ変わろうとしている。今回の宣伝攻勢コンセプトは“新生デライト開発実況”だ。この一日一文含めて開発状況開発者考えなどについて積極的に発信していきたい。

森を見て木を見る

3度宣伝攻勢から得た教訓色々とあるが,4度目の宣伝攻勢目前にしてつくづく感じていることは,結局やってみなければ分からない,ということだ。

ソフトウェア開発やっていると,ここが悪い,あそこが分かりにくいなどといったことばかり考えてしまいがちだ。とりわけデライト新奇見える代物なので,開発者利用者も,“デライトの問題点”について考え込み過ぎる嫌いがある。

問題点地道に改善していくのは当たり前のことだが,問題点ばかり見ていると,「問題があることが問題」であるかのような錯覚に陥りがちだ。問題のないソフトウェアなど存在しないので,これは「木を見て森を見ず」でもある。広く使われている全てのソフトウェアは,それぞれに問題抱えながらそれぞれの役割を果たしている。その全体像見ず問題の大きさ正しく見ることは出来ない

そもそも使いやすい UI分かりやすい文書……などと全て兼ね備えた優等生的なソフトウェア世の中どれだけあるだろうか。使いにくかろうが分かりにくかろうが,バグだらけであろうが,“使う必要”があれば使われる。それが現実だ。ツール文書も,必要ならユーザー作り始める昔からそうやってソフトウェア共有されてきた。

そこに革新性があればなおのことだ。誰でも戸惑いなく使える革新的なソフトウェア──そんなものは夢の中にしか存在しないデライトがそうであれば,私はとっくに世界一の有名人にして世界一の大富豪になっている。冷静に考えれば馬鹿馬鹿しい話だが,知らず知らずのうちにそれに等しいことを考えてしまうのが認知バイアス怖さだ。

最大の課題

デライト普及させる上で最大の課題換言すれば,最も手っ取り早い道筋は何かといえば,デライト目指していること理解してもらい,共感してもらい,必要としてもらうことに他ならない。またこういう文章書き始めた理由だ。

デライトは,よくあるメモサービス出来るだけ近付けた知能増幅(IA)サービス名付けて知能増幅メモサービス」だ。一時期「最も使いやすいメモサービスを目指す最も使いやすい知能増幅サービス」表現していたこともあるが,研究室臭いものになりがちなこの種のソフトウェアとしてはすでに驚くほど簡易的で,その点の達成度決して低くないはずだ。

とはいえ,全く新しい領域目指している以上,新しいやり方理解して慣れてもらうしかない部分どう頑張っても残るデライト初心者戸惑いがちなところは,デライトの目的のためにあえてそうしていることが多い多くの人にとっての分かりやすさだけを基準にして最終的に出来るのは,微妙に使いにくいよくあるメモサービスだ。レーシングカー難しさだけを問題視してオモチャの車にするわけにはいかない。

2年ほど前に公開してから,デライトにはそれなりに多くの人来てくれた例に漏れず大半の人黙ってり,一部の人サービスの問題点指摘して去っていった。私が開発者として一番痛切に感じていたことは,そうした問題点大きく感じさせるほどの利用動機小ささだった。「ここが使いにくい」などと言い残して去っていった人達本当に言いたかったことは,「それでもと使うほどの意義見出せなかった」ということなのだと思う

事実デライト使いにくさ分かりにくさ改善して利用者が増えた試しがない。いま日常的に利用してくれているのは,あらゆる面でいまとは比べ物にならないほどデライト貧弱だった時期に,どこかで私がデライトについて語っているのを見て,その可能性興味を抱いてくれた人達だ。

デライトの意義理解したにとってデライトの問題決して大きくない開発者として,そう確信出来る地点ようやく来られた気がしている。あとは伝え方問題なのだろう。

結局は運

もう一つ,商売において陥いりがちに,「生存者バイアス」としてよく知られた認知バイアスがある。成功例背後にある屍の山に,気付きにくい。そして,成功失敗要因として語られることは,結果論でしかないことが多いデライト成功するもしないも,結局は「」によるところが大きい,ということだ。

例えば,売れっ子芸能人がみんな親しみやす万人受けするタイプかといえば,全くそんなことはない。癖が強く,とっつきにくそう多い。彼らは売れたから「それが良い」と言ってもらえるけれども,同じ特徴持っていても売れずに「だから駄目なんだ」と言われているごまんといる万人受けしそうなタイプならタイプで,売れなければ無個性つまらない」などと言われる。そのは,巡り合わせとしか言いようがない

勝てば官軍ではないが,デライトの“とっつきにくさ”とされていることも,何かのきっかけ話題になってしまえば“面白さ”になりうる。その程度のことでしかないのかもしれない。

結局は運」というのは投げ遣りなようでいて,実は非常に前向き覚悟必要な考え方でもある。粘り強く試行繰り返していくこと以上に成功確かなものにするはない,ということだからだ。奇跡のような偶然も,サイコロ振り直し続ければ必然近付いていく

そしてこのデライト自体,すでにソフトウェア開発における奇跡的な生存例だ。ソフトウェア開発世界では,デライトよりずっと低い目標掲げていても,成功どころか動く物すら出来ず頓挫していくプロジェクトごまんとある。その中にあって,これだけの大風呂敷を広げ,この品質実装運用され,少ないながらも利用者がいて,ちょっとした収益化まで出来ている。こんなサービス世界見渡しても他にない

そんな奇跡がなぜ起きているのか。それはやはり,「粘り続けたから」としか科学的な説明のしようがない。デライト自体は公開から2年越えたばかりのサービスだが,研究期間含める20年近い歴史がある。その全て無駄なくデライト結実している。

味方に付けデライトの成功という奇跡起こすために,ひたすら粘り続ける。これを新生デライトの完成向けた宣伝攻勢所信表明としたい。


=}(1){あれ}
{HTML}{駒手記法}{進捗記録}{あれ}{希哲16年2月20日13歩}{神秘的な}{別に}{実装した}{付けた}{階層区切り}...=}(248)

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

進捗時限記録中略

不意に閃いた階層区切り線」についての方針まとめて終了

従来の見出し未満区切り線記法に,見出し階層越えられる階層区切り線」を加える。以下のように,唯一通常の区切り線区別出来る見出し記号 #全角 使う

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落(# の数でも調整出来る)。

持ち辺モチベーション

従来の区切り線記法は,HTML において対応する <hr>性質上見出し未満区切りにしか使えなかった

見出し階層作った後で描写全体に対するフッター的なものを書こうとする第1階層見出し作る必要があるが,しばしば大袈裟感じられることがある。

検討過程

空見出し」の挫折

今回検討当初は,「空見出し」という概念主に考えていた区切り線長さ任意であるべきなので,どうっても自然な形階層調整出来そうになかった。その点,見出し内容出来れば手っ取り早い

しかし,等号星号区切り線使う予定なので,== のように第2階層以降で内容空にする衝突することになる。

区切り線の方を見直しても,--区切り線なら == はやはり二重区切り線であってほしい。直感性下線形見出しとの整合性考えるとこれは捨て難い星号による区切り線はそれに比べればまだ転用余地があったが,その代わり *使う Markdown の区切り線記法との互換性損われる

そもそも,「空見出し」という概念にも無理がある文字を書くから見出しなのだし,実質的に区切り線なのだから,直感的とは言い難い

階層区切り線」の閃き

ここで,唯一区切り線記法被らない見出し記号である番号記号思い出した

番号記号による見出しは,ハッシュタグ駒手記法との衝突避けつつ atx 式見出しある程度互換性持たせるため,## のように2個以上条件対応していた個人的に好きな記法ではなかったこともあり,おまけのような扱いで,ここまで気付かなかった

すでに「空見出し」に感じていて,区切り線記法での対応立ち返っていたことで,この ##特殊な区切り線みなせる特徴持っていることに気付いた記号2個以上繰り返す区切り線見える記法で,実際普文枠線的な装飾使われることが多い記号でもある。

特に,区切り線記法としての統一感直感性保てる2個第1階層表せるということは決定的に重要な点で,見出し記号個数階層関係一致しないとどうしてもちぐはぐ見えてしまう。これは,衝突回避したとしても等号星号では解決出来ない問題だ。区切り線記号としての最短形見出し記号としての第1階層対応しうる唯一記号番号記号だった。

ただし,通常の区切り線記号異なり,個数階層対応するため,普文装飾兼ねられないという問題があった。上位階層区切り線普文上で目立つように書けない

これは,最新の区切り線記法下線形見出し記法検討9日17歩19歩踏まえ見出し階層対応する4種区切り線組み合わせる解決することにした。つまり,第1階層から順に最短形#==##--##- -##. .# というように区切り線組み合わせることが出来るようにする。これがまた都合が良いことに,よくある装飾見える

9日15歩以後,見出し下線区切り線長さ区別出来るようになっているため,区切り線装体にはある程度多様性持たせ問題ない一方見出し下線階層表す装体になっているため,一定制限必要になる。この点でもぴったり噛み合った

別に2個以上良いだろうと実装した区切り線記法おまけ感覚付けた番号記号による見出し記法最近の拡張方針……何気ない全てパズル要素だったかのように思える神秘的な閃きだった。

番号記号見出し仕様厳密化

この階層区切り線考案に,番号記号による見出し常に2個最上位階層とすることにした。つまり,*=##始まる見出しはともに最上位階層表す

これまで異なる見出し記号併用することは特に想定しておらず,実際使われていないはずなので,記号個数単純に計算していた。見出し階層相対的な個数決まるため,*始まる見出しがあると ##第2階層になる。これは階層区切り線整合しない。

特に仕様として決めていたことではないため,ここで厳密化することにした。

実装上の課題

仕様完璧思えるが,実装上の課題残った

HTMLCSS機能的には,可接性ちつつ見出し要素隠すことは造作もないが,SEO 上の懸念多少ある。今の検索演心評価理積みはそこまで単純ではないだろうが,伝統的に見出し要素隠すべきではないとされてきただけに,どこまで不利になるか分からない出来るだけ行儀の良い実装方法見つけたい

そもそも見出し要素にしてはいけないのか,<section> あたりを使って上手く誤魔化せないか,など色々考えてみたが,どれも多かれ少なかれ怪しさ残る

見出しの無い階層区切りというのは HTML想定外だったのだろう。

{HTML}{::after}{文字サイズ}{進捗記録}{目立ってしまう}{制御しにくい}{double}{果した}{調整余地}{font-weight}...=}(121)

{希哲16年2月6日12歩 K#F85E/E74C-06F4}

デライト装体調整終了

見分けにくかった見出し装体視認性大きく向上した修正前修正後

見出し装体固定化

まず,これまで中景輪符<h1>始まる<h2> で始まる前後景輪一覧かで描写内見出し装体1階層ずつずれていたが,これはいったん固定することにした。

ずれるのも HTML文書構造からみれば間違った表現ではなく,中景輪符表現も少し変えるべきかと考えていたが,これもなかなか難しい中景輪符知名部は,現状 <h1> でも <h2> でも font-size: 1.4emfont-weight: boldletter-spacing: 0.05em という装体になっている。輪郭という情報単位粒度考えた時,これ以下は小さ過ぎ,これ以上は大き過ぎという所だ。

他の要素も,要素同士の対比考えて細かく装体調整しているため,それらまで見出し装体変化合わせる保守性悪影響を及ぼす。将来的にどうかはともかく,現時点でそこまでする利点は無いだろう。

CSS では h1 ~ .dln h2, h2 ~ .dln h3 のように兄弟結合子使えば簡単に実装出来る。

装体調整

あくまでも描写内での見出し階層装体固定することにした上で,第1階層から第4階層までの描写内見出しには二本線一本線破線点線4種類下線を付けることにした。これまでは第1階層2px第2階層1px一本下線のみだった。

二本線border-styledouble では制御しにくいため ::after使い,1px2px間隔をあけた。また,点線舞覧によって破線より目立ってしまう場合があるため,調整することにした。

最初は,第1階層二本線第2階層一本線があれば十分かと思ったが,結局文字サイズだけの変化ではぱっと見分かりにくい。各描写内見出し図形的特徴があった方が良い。

文字サイズは,これまで 1.3em1.2em1.1em1.05em1em だったのを 1.3em1.2em1.15em1.1em1.05em とした。

1.3em から 1.1em まで0.05em刻みの方が数字的には綺麗かと思ったが,下線特徴を付けても,特に第1階層第2階層一見して見分けにくかった画面撮り。それ以下は使用頻度も低いので0.05em刻みでも大きな問題はないだろう。

letter-spacingfont-weight調整余地はもう少しありそうだが,視認性改善という目的十二分果したのでここで一段落とした。

2px一本線よりも1px二本線の方がすっきりした印象になるのが意外だった。

{コマンド プロンプト}{駒手記法}{進捗記録}{場筋}{採用しにくい}{\>}{ドライブレター}{C:\>}{:>}{PS>}...=}(37)

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

進捗時限記録中略

駒手記法コマンド プロンプトPowerShell 対応について検討して終了

以下のような形で実装していくことにした。

:> [コマンド プロンプトの駒手]
C:\> [〃]
PS> [PowerShell の駒手]
PS C:\> [〃]

以前から対応については考えていたが,Windows 系の駒手欄特徴をどう掴むかが難しかった

PowerShellPS> でいいとして,コマンド プロンプトC:\> では明らかに冗長だ。ドライブレター場筋情報必要ないことの方が多いだろう。越化記法との兼ね合い考える\>採用しにくい。となったら,:> しかないだろうということになった。ドライブレター場筋任意付加出来ることにする。

{開発}{デラング}{開発記録}{希哲16年1月31日13歩}{デラング文書}{知番}{デライト文書}{書き進められる}{目立たせ方}{デラングとは?}...=}(78)

{希哲15年6月26日の開発 K#F85E/E74C-F080}

ここからデラング文書整備最優先にすることにした。

デラング文書の導入

デラングとは?」が大分良い感じまとまってきた。

軽量マークアップ言語に関する予備知識の無い入門者にもその意義を伝えつつ,デラング特徴表現する難しさがあった。

ここで「軽量マークアップ言語」という翻訳語の限界を感じ「簡易マークアップ言語」を使うことにした。

前日に思いついた時は,独自用語のようになるとかえって理解が難しくなるかもしれないと思ったが,英語版 Wikipedia では〈simple markup language〉〈lightweight markup language〉同義語として掲げられていることもあり,こちらの翻訳語として採用することにした。

閲覧専用模動多重輪括弧

寝る前になって閲覧専用模動についての考え急速まとまった

輪郭を,閲覧専用に余計な装飾機能無し輪郭であることを意識せずに読めるような形)表示出来るようにする。デライト文書のために考え始めたが,広く有用なものなりそうなので汎用的設計にしておく。

(「公式模動」や「正装模動」という名前も考えたが,翌日のまとめ時点で,平たく「閲覧専用模動」とした)

いまデラング文書を K#F85E の描出として書いているが,これをどう公式文書として見せるかという課題があった。

kind() の技法で描写埋め込むこと自体は簡単だが,輪符の扱いが面倒だった。

ここで,デルン最初期構想ってきた。もともと,デルンでは通常の輪括弧二重輪括弧輪符目立たせ方を変え,ズームするようにボタンで表示水準切り替えられるようにする,という機能の構想があった。アイコンには {} や {{}} といった記号を使うことを考えていた。

この考え方が閲覧専用模動にそのまま使えた。この時のために取っておいた二重輪括弧をようやく使える。閲覧専用模動では,通常の輪符無視し,強調輪符多重輪括弧のみを輪結にする。

最近,輪符輪括弧を表示させる記法として二重輪括弧を使おうかと考えていたが,全知検索では二重輪括弧を括弧付きで表示する。閲覧専用模動でも括弧付きで表示したい場合のために三重輪括弧も使えるようにし,これを「多重輪括弧」と呼ぶことにした。

さらに,輪結先も閲覧専用模動にしたい自我指定出来るようにしたり,特定知番を別 URL に変換出来るような仕組みがあれば,任意の自我で描いた輪郭を違和感なく公式文書にすることが出来る。

全知検索から閲覧専用模動への移行は,各輪郭中景部丸みのある部分に三角形アイコン輪結を置くのが分かりやすそうだ。

これで K#F85E で心配せずデライト文書を書き進められる

{特徴}

{}