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

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

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

描写拡縮ボタン

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

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

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

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

輪郭複製機能

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

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

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

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

{新生デライト}{希哲16年5月の一日一文}{順調に行って}{“知能増幅メモサービス”はなぜいま最も重要なのか}{受け付けている}{解決したい}{緩やかに}{保証する}{一事業者}{起こしている}...=}(135)

{新生デライトとは何か K#F85E/E74C-AEC2}

最近デライトでは「新生デライト」という表現多用している簡単に言えば使いやすく生まれ変わったデライトのことだ。

デライトの使い方の考え方」や「“知能増幅メモサービス”はなぜいま最も重要なのか」でも書いたように,前例のない目的持ったデライトには,どうしても特有の難しさがある。

それでもシステムの実用化から10年以上サービス公開から2年以上ち,その有用性十分に実証されている多くの人様々なメモツールブログSNS などを行ったり来たりしながらやってきた情報蓄積発信を,私は10年以上前からほとんどこのシステムだけで実現しているサービス公開後は,デライトでしか出来ないこと見出して使い続けてくれる利用者もいる。

使える人には使える”ことは分かっている残る問題は,使える人少なさだ。そこでいま,多くの人親しめる快適なサービスにするため,文書整備機能整備高速化,そして独自の軽量マークアップ言語デラング」の整備といった包括的な改良構想推し進めている。その完成形を「新生デライト」と呼ぶ

順調に行って6月中,ずれ込んでも7月中には完成見通しだ。


機能整備という点では,すでに使いこなしている利用者にとっての利便性向上もちろん,他のメモツールなどに慣れ親しんだ初心者戸惑いがち機能不足補うことを意識している

例えば,輪郭非公開近い未公開状態」に出来る公開設定機能編集中にリンクしたい輪郭を検索出来る機能全文検索機能検索語提案(サジェスト)機能ファイル添付機能輪郭を削除する機能自動ページ展開機能インポートエクスポート機能高度なアカウント管理機能などの追加予定している

これまでにない密度人の頭の中保存するようなサービスの性質上いわゆる非公開機能導入特に難しい問題だった。AppleGoogle のような世界最大級の企業でも個人情報流出事件起こしているわけで,一事業者安全性保証することは不可能考えている。これに関しては,他の利用者からの閲覧緩やかに制限する未公開状態」の導入と,知番ファイル名として利用したローカルでのファイル管理手法広めることで解決したい

質問要望常に受け付けているので,“世界を変える新生デライト開発どんどん参加してほしい。


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

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

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

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

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

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

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


=}
{出力する}{漠然と}{こまごまとした問題}{キーボード操作}{簡潔な表現}{ダブルクリック操作}{意味が分かりにくかった}{誘導効果}{見えやすくなった}{戻り方}...=}(100)

{希哲16年3月31日の開発 K#F85E/E74C-FB1F}

こまごまとした問題片付けた


就寝前閲覧専用模動に関して閃きがあり,また脳爆発始まってしまった

漠然と中景部角丸周辺ボタンとして使えそうだとは思っていたが,これで吹き描き長方形にして前後景部し,さらに中景輪符波括弧角括弧変えれば吹き描き意味ともデラングとも調和する詳細はまだ練る必要があるが,かなりの有力案になりそうだ。

{希哲16年3月22日の開発}{希哲16年3月22日の進捗}{タブ式}{#BBEEBB}{使わずに}{縦に並べる}{下見表示}{目障りにならない}{右端}{最小限の変更}...=}(76)

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

{希哲16年3月3日}{『希哲日記』}{輪郭整備}{気ままに}{臨時半休}{気が休まらない}{全休}{気楽に}{過ごせた}{多くなった}...=}(38)

{希哲16年3月3日の日記 K#F85E/E74C-74B3}

予定通り臨時休業にした。久しぶりに気楽に過ごせた

ここのところ半休にすることが多かったが,のように過熱しがちな時期には全休有効なようだ。半休では進捗が出るまで気が休まらないし,進捗が出だすと熱中して止まらなくなる

そもそもなぜ半休多くなったのかといえば,脳過熱定休日前に臨時半休にすることが増え,その代わり定休日半休にして……と調整していたからだ。

臨時半休仕方ないとして,今後定休日常に全休とすることにした。


休日の過ごし方として,気ままに輪郭整備をするのはやはり良い娯楽のようなものでもあり,頭の整理にも献典整備にもなる。

=}
{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想定外だったのだろう。

{進捗記録}{廃止}{希哲15年12月17日の開発}{kn+/}{持たせた}{将来的に}{バイナリ実装}{スクリプト実装}{無拡張子}{必要に応じて}...=}(63)

{希哲15年12月17日2歩 K#F85E/E74C-7E64}

知機駒手実装整理終了

+ 接尾子使った台録構造について見直した結果これまで必ず置いていた実行譜類への疎輪結のみ「必要に応じて」とすることで概ね現状維持となった。

アンダースコア略記法の廃止により,今後kn+/foo+/bar.sh のような台録構造副駒手管理することになる。いっそのことこの + 接尾子廃止していいかと思ったが,kn+/foo という無拡張子疎輪結使うことでスクリプト実装.shバイナリ実装.x切り替え容易になるという狙いがあり,これはこれで捨て難い設定譜類より直接的分かりやすいし,最上位knkn+/ になるのが自然なのでそれに整合的でもある。

将来的に膨大な副駒手追加することを考えて持たせた柔軟性だが,これまでの実装では無拡張子疎輪結を通して副駒手探索していたため,常に副駒手疎輪結しておく必要があり,スクリプト実装しかない現状ではただ煩雑なだけだった。これを省けるようにすれば柔軟性維持しながらかなり見通しが良くなる

=}
{常に}

{}