{なおかつ}{制御しやすい}{握接出来る}{選り手を開く}{操作手順}{複製輪郭}{ボタンを押す}{ずっと考えていた}{視認出来る}{スクロール完了}...=}(116)

{希哲16年5月18日の開発 K#F85E/A-E74C-2BA8}

長い間課題だった描写拡縮ボタン輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発最大化アイコン出来たことをきっかけに,描写拡縮ボタン実装イメージ固まり,実装手定めまで概ね完了した想像以上に早く上手くまとまった下見機能との相性も良い。ただし輪郭選り手抜控機能整備途中であるため未出振るい

描写拡縮機能的には単純だが,用合い特に領当て難しかった最近描写部下境界重ねる形での実装考えていたが,描写部飛び出す他の要素干渉してしまう。かといって余白無駄に広げたくない。これは,下部陰影重ねつつ,初期化時点スクロール可能な場合は下余白追加することで解決した文字暗い背景色重なっても視認出来るように,半透明白背景付けた

拡大ボタンスクロール可能であることの目印としても効果的なので,これを活かしてスクロール完了時には透明度を上げ,それと分かるようにした。

これで,外観操作感ともにデライト調和した描写拡縮ボタン出来た描写部高さ固定一覧性確保するために必要なものだったが,用合い上弊害小さくなかった陰影付きスクロール最大化アイコン,そして描写拡縮ボタンによって,ようやくこの問題解決した

輪郭複製機能

輪郭複製機能課題としてずっと考えていたが,用合い上難しさがあった。

ボタンを押すことで複製輪郭出来る,というのは使用頻度考える誤操作懸念の方が大きい。となると,目立たないように置くしかない。かといって,操作手順増えると,選り手を開いて写し貼りするのと大差ない

簡単に握接出来て,なおかつ制御しやすい用合い必要だった。ここで,「知名描写複製して新規描出フォーム移動するボタン」があればいいことに気付いた。これなら,自輪郭常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置置けそうだ。

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

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

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

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

森を見て木を見る

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

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

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

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

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

最大の課題

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

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

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

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

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

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

結局は運

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

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

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

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

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

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

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


=}(1){あれ}
{新生デライト}{撮り逃していた}{待っていたら}{希哲16年4月21日}{発売日}{良い方向}{豊かにしたい}{上信する}{こまめに}{新しい写真}...=}(100)

{希哲16年4月14日の日記 K#F85E/A-E74C-8D6F}

輪郭整備兼写真整理始め大きな手応え得た

昨年11月30日から Galaxy S21 5G写真撮り始め写真上信環境整えたが,これをきっかけ第二次知番改良第二次快調期デライト開発急進展したため,11月30日最初の4枚しか上信出来ていなかった。写真よりも開発記録のための画面撮り上信活用することが多かった

最近良い春の写真溜まってきたこともあり,なんとかしたい思っていた大輪郭整備といいつつ輪郭整備もろくに出来ていなかったので,輪郭整備兼ねた写真整理という形が良さそうだと考えたものの,間もなく第四次宣伝攻勢という時期開発時間っていいものか,迷いがあった。

この日サイクリングという天気でもなく,姪達連れてくるので開発集中出来そうでもなく,とたまたま輪郭整備兼写真整理適した条件が揃った想像していたよりずっと手応えが良く,デライト豊か感じられる。やってみて,むしろこれは第四次宣伝攻勢前にやっておくべきことだと気付いた新生デライトが「仏作って魂入れず」になるところだった。

一日がかりでやれば S21 で撮った写真くらいは終わるかと思ったが,思いのほか量が多いので,開発作業合間少しずつやっていくことにした。過去の写真片付いたら新しい写真こまめに上信するようにし,デライトにおける日常表現をより豊かにしたい。また一つ停滞していた課題良い方向滑り出して清々しい気分だった。

日本では S22発売日今月21日になったが,一時考えたように待っていたらこの快調期は別の形になっていたかもしれず,良い春の写真撮り逃していただろう。そう考えると,あの機種変更奇跡的出来事思えてくる

15日振り返り日記

{需要がある}{地味ながら}{厳密に考える}{見分けが付く}{開いている時}{実装出来た}{現仕様}{万能ではない}{`resize: vertical`}{高過ぎず}...=}(115)

{希哲16年3月30日の開発 K#F85E/A-E74C-7061}

描写欄高さ問題きっかけ自動リサイズ機能字数計実装出来た。ほか装体調整など。

出振るい済み

自動リサイズ機能

旧輪郭選り手では,描写欄出放り高さ新規描出フォーム10em再描出フォーム15emとしていたが,新輪郭選り手ではたまたま15em統一されていた画面撮り10emでは長文書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォーム一言だけや知名だけの描出使うことも多いためこの高さでは邪魔臭い

ここで,予てからぼんやり検討していた自動リサイズ機能導入考えた一応 resize: vertical設定してあるが,万能ではない10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定字数計では字数情報必要になるため,一緒に行数保持させることにした。

実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みリサイズするようにした画面撮り初期状態最大自動リサイズ19emだと個人機でも低過ぎず高過ぎずスマートフォン縦向き柔品キーボード表示させてもちょうど収まる程度の高さになる。折り返し多い1行もありうるため,厳密にするなら字数考えるべきだが,とりあえずはこれで様子を見ることにした。

再描出フォームに関しては,さほど目立つものでもなく,描写部高さ合わせて描写欄開くようになっている現仕様悪くないので,現状維持様子見しておく。

字数計

字数行数保持出来たことで字数計難無く実装出来た描出ボタン時印左側邪魔にならないように表示させてみた字数計の様子

下見字数分けようかと思っていたが,下見開いている時下見字数置換すれば十分であることに気付いた一応見分けが付くようにに「」を付けるようにした。

これも,厳密に考える特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length による概算でよしとしておく。

字数計は,地味ながら意外に需要があることを市場調査通して知った自分でもたまに欲しくなることがあった。

{デラング}{進捗記録}{希哲16年2月19日}{希哲16年2月19日の開発}{本来の意味}{自サービス}{止めておく}{独自に}{見ていた}{いっそのこと}...=}(131)

{希哲16年2月19日11歩 K#F85E/A-E74C-D1B5}

進捗時限記録中略前後

何気なくマイクロブログサービス用者ユーザー示せる記法欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので,軽くまとめ終了

とりあえず分散型 SNS使われている記法拡張し,@[用者名]@[ドメイン名]汎用記法整備する方向進めることにした。


要は@user書いたTwitter輪結したり,@user@example.com書いた分散型マイクロブログ捌き手輪結してもいいのではないか,と考えたことがきっかけだった。

ここで一つ,@user@example.comhttps://example.com/@user必ず対応するのだろうかという疑問湧いた以前にもなんとなく考えたことはあったが,ActivityPub というか WebfingerURL引き出したり,面倒臭そう気がし進展しなかった。このあたりの仕様がどうなっているのか,いまだによく分からない

もっとも,ざっと見渡す限り分散型マイクロブログ捌き手は大体 https://example.com/@user になっているし,自分で Mastodon 捌き運営していた時も出放りはこれだったので,事実上の標準とみなしていいのかもしれない。


Twitter@user でいいかと思っていたが,いくら普及しているとはいえ,これは特定サービス寄り過ぎだろうということで,@user@twitter.com統一することを考えた。ただ,Twitterプロフィールページ正規 URLhttps://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ,若干気持ち悪い

さらに,この時点では @user@twitter.com と書けば @user表示されるという仕様考えていたため,いずれにせよ特定サービス向けの処理追加出来るようにする必要があった

ここまで考えたところで,いっそのこと @[用者名]@[ドメイン名] として,外部サービス用者指すための汎用的な記法にしてしまえばいいのではないか,と思えてきた。これは, 氏が独自に同様記法使っているのを見ていたことが大きかった

[ドメイン名] は,@[用者名]@twitter のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名解釈輪結先調整し,それ以外は https://[ドメイン名]/@[用者名]輪結する。


少し困ったのは,簡潔分かりやすい名前見つからないことだ。一応平たく外部サービス利用者記法」を仮称としておく。

異邦人記法」というのも面白いかもしれないと思ったが,一見して意味分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。


デライト使う予定が全くなかったため,@[用者名] という表示Twitter のために使うつもりだったが,これは止めておく

そもそも SNS などでは自サービス上の用者に対する言及メンションという意味を持つ記法から来ているデライト使わなかったとしても,この種の記法必要とするサービスにはデラング応用出来ないことになってしまう。

ここから @[用者名]本来の意味考え始め知番輪符などと組み合わせる可能性気付いた。これは「言及記法」として別途検討することにした。

{色見本}{色見本記法}{デラング}{進捗記録}{書く}{Markdown}{あれ}{特殊形}{交度埋め込み}{難があった}...=}(96)

{希哲16年2月15日18歩 K#F85E/A-E74C-E831}

進捗時限記録中略

交度コード記法埋め込み記法組み合わせた交度埋め込み記法仮称方針まとめて終了

例えばMermaid埋め込みたい場合,以下のような書き方になる交度部区コードブロック記法は「逆括点バッククォート2つ以上」にする予定

+``mermaid
...
``

あるいは

+mermaid``
...
``

最近デラングMermaid 対応についてぼんやり考えていたが,場当たり的拡張はしたくないので,「外部言語による表現埋め込む汎用的な記法」がまず必要だと感じていた

GitHubMermaid 対応という話題目にしたことがきっかけで,これが急速に進展した。GitHub も含め,Markdown での Mermaid 対応は,いわゆるコードフェンスをそのまま使った記法採用例多い。これは私が嫌だった場当たり的拡張そのものだった。

コードフェンスは,「交度提示する記法であって,単に交度が書ける記法ではない。そうでなければ従来用法矛盾が生じるのは明らかなので,これは言語設計として悪手としか言いようがない

ただ,その愚かさ瀕答ヒントにもなった。つまり,深く考えなければ,多くの人にとって交度記法違和感なくこの種の記法応用出来る,「直感的な記法」であるということだ。

もう一つ,逆括点代わりに埋め込み記法拡張として以下のように書けたらどうか,と考えていたことも瀕答になった。

++mermaid
...
++

これは何かと整合性難があったが,役割として埋め込み記法一番近いとは感じていた。この二つを組み合わせればいい,と気付いて出来たのが今回の「交度埋め込み記法」だ。


言語名逆括点の前でも後でも大きな違和感はない。前に付けられるようにした方が,行内交度記法応用しても一貫性がある。

交度埋め込み先例として KaTeX による数式記法があるが,これは以下のような交度埋め込み記法特殊形とみなすことが出来る。

+katex``
...
``

行内でも使える: ++katex`...`++

さらに,これは色見本にも応用出来る可能性がある。サービス通類ツールによっては,行内交度記法色符号カラーコード書く自動的に色見本付加するものがある。

流石にそれはお節介過ぎるが,「色見本記法」があるといいとはずっと思っていた希哲15年3月31日1歩。例えば,++`#000000`++色見本が出来てもいいかもしれない。

{進捗記録}{導入する}{文字装飾記法}{下線記法}{斜体記法}{太字記法}{打ち消し線記法}{希哲16年1月23日16歩}{微妙な要求}{たまにあった}...=}(94)

{希哲16年1月23日12歩 K#F85E/A-E74C-5AE3}

進捗時限記録中略

3歩きっかけ久しぶりに実装予定文字装飾記法について見直し,以下のように基本的方針整理した

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については,_下線_有効にすることも考えていたが,適当に書いた時の誤解釈増える懸念もあり見送ることにした。文字装飾記法2個以上記号統一した方が綺麗にまとまる簡潔な記法追加するより削除する方がずっと難しいので,使用頻度考えてもいまあえて導入する動機に乏しい

……ここまで考えて昨年6月23日10歩でも同じ結論を出していたことに気付いたが,再確認出来た。


太字記法については,昨年6月23日9歩では ++太字++検討しているものの,最近 ++行内埋め込み記法利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり,廃案脳裏をよぎった

分かりやすい代替記法がありうるのかと思ったが,意外と ##太字##悪くない。「くっきりした」という意味シャープにもかかっているし,見た目濃さ丁度良い後述文字サイズ記法同様,記号の数濃さ調整出来ても面白い


ついでに<<大きい文字>>>>小さい文字<< という文字サイズ記法思いついた大きさ小ささ記号の数調整出来てもいい。直感性申し分ない

あまり文字を大きくしたい思ったことはないが,小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。


斜体記法打ち消し記法については特に変更無し


上線記法検討していたが,ここまでで HTML の要素相当するものはい,軽標記言語としての表現力十二分なので,いったんここで一区切りとすることにした。

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

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

進捗時限記録中略

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

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

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

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

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

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

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

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

?? 補足
補足内容
^^

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

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

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

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

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

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

他の検討案

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

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

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

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

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

{きっかけ}

{}