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

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

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

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


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

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

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

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

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

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

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

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

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

=}
{「描写」}{心理}=}(2)
{未公開非共有}{希哲15年8月18日の開発}{補える}{鍵マーク}{閲覧権限}{実装しやすい}{実装方針検討}{希哲15年8月18日の進捗時限}{希哲15年8月18日の進捗}{希哲15年8月18日}...=}(39)

{希哲15年8月18日5歩 K#F85E/A-E74C-D5E4}

公開設定実装方針検討終了

公開設定に関しては,まず「自分だけ未公開非共有のような実装しやす重要性の高いものから,出来るだけ早く部分的実装することにした。

輪郭選り手はもちろん,他要素の設計にも影響を与える部分なので,早期見通しを良くしておきたい。


閲覧権限によって描写内の輪符扱いを変える鍵マークでも付けるか輪結無効化するか)ということも考えていたが,これは効率上問題が大きいため見送り,とりあえずは書き手配慮に任せることにした。未公開状態輪符が多いと無駄輪結を踏ませてしまうという懸念からだったが,その点は輪郭小窓である程度補えるだろう。

=}
{自動ページ展開機能}{希哲15年7月29日の日記}{一応の解決}{舞覧手定め環境}{LambdaTest}{正式採用}{描きかけ}{希哲15年7月29日}{輪郭選り手}{無限スクロール機能}...=}(37)

{希哲15年7月29日の開発 K#F85E/A-E74C-3FD4}

主に輪郭選り手抜控機能整備Aejs 整備も多少進んだ。

まだ荒削りながら,とりあえず描き直しでも描きかけ描写復元出来るようになった。

先日の違了処理整備と併せて,違了誤遷移出与え消失が生じやすいというデライトの課題一応の解決をみて,信頼性大きく向上した。


抜控機能によって自動ページ展開機能無限スクロール機能単純化にもなりそうなことに気付いた。

新規描出フォームをどう見せるかが課題だったが,複数窓で同一画面に同期された新規描出フォームが表示されることに慣れてみると,同一ページにあっても不自然ではないと思える。とりあえず,単純に10輪毎に表示するだけの実装でも良さそうだ。


舞覧手定め環境整備一環として,LambdaTest正式採用決定した。

{デラング文書}{知番}{デライト文書}{書き進められる}{目立たせ方}{デラングとは?}{公式模動}{閲覧専用模動}{三重輪括弧}{多重輪括弧}...=}(77)

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

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

デラング文書の導入

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

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

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

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

閲覧専用模動多重輪括弧

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

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

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

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

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

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

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

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

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

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

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

{デライト}{希哲15年6月21日の開発}{希哲15年6月20日の日記}{:only-child}{輪符}{強調輪符}{破線密度}{視線の流れ}{薄い色}{結論付けた}...=}(160)

{希哲15年6月21日9歩 K#F85E/A-E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

どちらの問題も,少し前までは自動的解決出来るのではないかと考えていた。例えば,前景輪にある輪符自動的強調表示したり,知名と異なる名前で参照された輪符斜体にするなどということを考えていた

ただ,これは描出経験を積むにつれ無理がある感じるようになった。

まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪限定するのも不自然見え方になるだろう。輪符参照名をいちいち照合するのも軽い処理ではない。

描写隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与え一貫性保守性深刻な影響を及ぼすことは目に見えている。

それ以前に,自動装体スタイリング適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中目立たせたい輪符引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても,例えば,「知る」という輪郭を「って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。

最近では,デラング整備進展もあり,これは手動装体,つまり何らかの記法対応すべきなのではないか,と考えるようになっていた。

今日の進展

こうした問題解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体伊体依存した装体は避けたかった。ここで,強調輪符下線調整することを考え始めた。

強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体軽い参照重い参照表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短いでは破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線破下線一本下線輪結の強さ表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い視線の流れを遮ることなく,視線を止めれば容易に輪結と視認出来る按配理想として,破下線を極力薄くすることにし,白背景なら lightgray引用部区など WhiteSmoke 背景の上では silver最適結論付けた

Firefox調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)

強調輪符一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的下線を引きたい場合のために下線記法導入することも考えているため,兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るいonly-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。

総括

開発記録に書いておく。

{「描写」}
{}