{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}{ウェブ利用者}{影響しない}{設定しておく}{最初以外}...=}(92)

{希哲16年5月30日の開発 K#F85E/E74C-DB91}

自動ページ展開機能実装一段落した細部に課題はあるが,実用出来る水準に達した出振るい手定め済み

これに伴い正式離立前試していた全知検索窓新規描出フォームの固定表示復活させる検討大きく進んだ。また,輪郭一覧動的追加仕組み整えたことで,検索新規描出時にも応用出来るようになった。輪郭一覧の更新効率的に行えるようになり,高速化にも大きく貢献するだろう。


AutoPagerize 対応どうするかというのが難しい問題だったが,これは挿入監視して削除注意書き表示する方向落ち着いた最初以外 .autopagerize_page_elementdisplay: none設定しておくことで表示には影響しない

AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者使っているのを見て私自身使うようになったというのもあり,用者層重なり小さくない出来るだけ混乱させないようにしたかった。


今後広告の調整重要になってくるため,ここで運営者開発者向けダミー広告表示する仕組み整えたダミー広告の様子

AdSense は,設置者によるクリックもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた


機能的に自動ページ展開機能似たところがある描写後略機能実装方針検討ほぼ完了

内容の高さ高さ制限足りない場合どうするか最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した


=}
{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{Aejs_DG_rev}{長期的視野に立って}{更新方法}...=}(224)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

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

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

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

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

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

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

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


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

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

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

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


=}
{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

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

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{進捗記録}{選り手}{希哲15年3月10日の開発}{閲覧模動}{編集模動}{実用上の問題}{中止ボタン}{希哲15年3月10日の進捗時限}{希哲15年3月10日の進捗}{希哲15年3月10日}...=}(40)

{希哲15年3月10日11歩 K#F85E/E74C-C3D3}

描出フォーム仕様について検討

現状,知名欄描写欄が離れている描出フォーム装体について,両方開いている場合は合体させることにした。

美観上の問題も感じており,この自体は当初からあったが,もともと両欄は個別に開けるようにしていたため,挙動との整合性などを考えると難しい問題だった。

個別に開ける仕様自体は,閲覧模動編集模動区別明確にしつつ,出来るだけ操作感WYSIWYG に近付けたいという考えから編み出したもので,作業対象が絞り込みやすいこともあり維持したい。

少しずつ実装が変わり,最近では両欄が開いている時は一つの選り手とみなすようになっているため,合体させても違和感がなく,中止ボタン導入などを考えるとむしろ合体していた方が直感に適う。

これに関連して,中景部中景輪符描写部以外の部分を [Ctrl] + ダブルクリックして両欄を開くようにすることにした。これ以前から最近考えていたことだが,丁度良い。

現状,同操作は中景輪符描写部に対してのみ有効で,中景部の他の部分では反応しなかった。これは直感に反する挙動でもあり,描写部が空の場合の代置語を削除した最近の実装では同操作で描写欄が開けないといった実用上の問題もあった。

{開発}{デラング}{開発記録}{Dex}{難しい問題}{〈dexterity〉}{Dex_T}{カラーテーマ}{交度部区}{稲妻形引用部区}...=}(29)

{希哲15年3月9日の開発 K#F85E/E74C-0817}

一日,ほぼデラング整備で終わった。

ひとまず交度対応を目指し,デラング換配系現実解として構想が出来つつあった「Dex」の実装に入る。

一日の終わりには見事Dex_T として基礎的な構造化成功デラングにとって大きな足掛かりが出来た。

最小限の機能でなかなか拡張出来ずにいたデラングも,今後は自由自在拡張出来るだろう。現実解のつもりで始めたが,出来てみると最適解,まさに〈dexterity〉という感じだった。これまで余計な手を加えなかったことすら大正解に思えてくる。


装体調整でも,稲妻形引用部区完成3歩),微妙に難しい問題だった交度部区カラーテーマが決まる(11歩)など小さくない収穫があった。

{難しい問題}

{}