{デラング}{希哲15年3月23日の開発}{ややこしい}{見え方ボタン}{閉じるボタン}{最有力候補}{難しかった}{ボタンラベル}{大きな理由}{多機能化}...=}(72)

{希哲15年3月23日7歩 K#F85E/A-E74C-66D7}

デラング整備,「描き方ボタン」について仕様をまとめて終了。

デラング多機能化に伴い,学習宣伝等の観点から,他輪郭描写素文をもっと閲覧しやすくする必要が出てきた。

現状,Ctrl + ダブルクリックで閲覧することは出来るものの,ボタン自輪郭描き直しボタンのみ表示しているため,説明されなければどのように素文を見るのか初心者には分からない。

描き直しボタン追加時からしばらく全ての輪郭でそのまま表示していたが,紛らわしく,用合いもずっとごちゃごちゃしている時期だったため他輪郭では非表示にするようになった。

調整して復活させることは度々考えてきた。そのたび見送っていた大きな理由に,良い表現が見つからないということがあった。特にボタンラベル等に使う文言難しかった

簡潔かつ直感的ということで最有力候補は「覗く」だったが,漢字を使うと少し印象が硬い,平仮名で「のぞく」では「除く」と紛らわしい,語感もあまり良くない,そもそも何を覗くのか初見分かりやすいとも言えない,と一番マシな案が難点だらけだった。

今回の再考で,「描き方」が使えることに気付いた

描き直しボタンアイコン領当てはそのままに,ボタンラベルは「描き方」に変える。機能描写部Ctrl + ダブルクリックした時同様,描写欄のみ開く。

知名欄でも一部デラング記法を使えるようにする予定はあるが,利用頻度を考えると余計に感じることが多いだろう。従って,描写部が無い他輪郭では引き続き非表示とする。見る手段がないわけではないので困ることは少ないはずだ。

描き方ボタンで開いた場合,完了ボタンはもう少し自然に閉じるボタンにする。「見え方ボタン」にするのも面白いかと思ったが,かえってややこしいかもしれない。

「〜で描き直す」「〜で完了」から変えていなかった通注も「〜で描き方を見る」「〜で閉じる」とする。

=}
{希哲15年3月22日の日記}{引用内改行}{数式内改行}{理想形}{段落内改行}{初回出振るい}{希哲15年3月22日}{Markdown の段落記法}{段落記法}{Dex}...=}(36)

{希哲15年3月22日の開発 K#F85E/A-E74C-6103}

デラング整備新デラング実装初回出振るい

これにより,数式対応に続き交度対応実現,各部区間の区切り改行自然に扱えるようにもなった。

これまで単純に各行を p 要素にしていた段落記法は,Markdown段落内改行を加えた形になった。また,2つ以上連続する改行br 要素置換する。素文直感的に書けるという軽標記言語意義を考えると,これがほぼ理想形だろう。

引用内改行数式内改行なども同様に上手く扱えるようになった。

何より,Dex によって保守性拡張性原始時代近代くらいの差を付けて向上したのが大きい。

一通り眺めて概ね問題なさそうだが,当分は機能追加不具合修正その他調整が続くだろう。

{希哲15年3月16日の開発}{共有アイコン}{くの字形}{試作共有アイコン}{アイコン制作}{希哲15年3月16日の進捗時限}{希哲15年3月16日の進捗}{希哲15年3月16日}{フィードボタン}{共有ボタン}...=}(37)

{希哲15年3月16日5歩 K#F85E/A-E74C-38AF}

アイコン制作続き。

共有ボタンフィードボタン用のアイコンを作っていったん終了。

フィードボタン用のアイコンはごく一般的なものだが,一応自作しておいた。

共有ボタンの方は少し悩んだが,三点をくの字形に結ぶアイコンを少し修正し,矢印が伸びるようにした。より拡散イメージが掴みやすい。

一点から二本の矢印が伸びるという共有アイコンの形は初期 Android採用されていたが,なぜか現在の形に修正された。

拡散というよりはネットワーク結合というイメージ強調したかったのかもしれないが,直感的とは言えない。

iOS では基本的に四角から矢印が飛び出すような徹案になっているが,正直これは更に色々な意味で分かりにくいと感じる。

デライト試作共有アイコンは,結果的に両者の折衷案になった。


主力機記憶器をしっかり使ったまま24時間安帯を越え,きびきびよく動いている。

=}
{正規表現}{padding-left: 1em}{text-indent: 0}{text-indent: 1em}{メール文化}{独自実装}{非英語圏}{希哲15年3月14日の進捗時限}{希哲15年3月14日の進捗}{Markdown の段落記法}...=}(50)

{希哲15年3月14日3歩 K#F85E/A-E74C-5DCE}

デラング整備段落記法についての検討で終了。

もともと段落記法については,空行を挟んで段落を分け,段落内では改行br 要素置換する,という仕様想定していた。やはりこれが一番直感的だろう。

現状は単に各行を p 要素にしているだけ。

Markdown の段落記法も空行を使うが,強制改行について仕様上は行末にスペース2つという記法を採用している。後者は特に日本など非英語圏では悪評の多い仕様らしく,独自実装修正されていることも多い。

一見不可解Markdown強制改行は,英語圏メール文化Markdown.pl 実装時の技術的制約によるものと思われる。

メール掲示板などでは適当な長さで改行されることが多い日本語に対して,英語では段落はしっかり分けるが段落内で改行を使うことは少ない。

Markdown.pl 実装当時,をまたいだ処理を苦手とする正規表現でそこまでする意義を見出せなかったのだろう。


改行を含む段落の場合,現状の text-indent: 1em は若干不格好なので,p.no_idt として text-indent: 0; padding-left: 1em を加えることにした。

本当は text-indent: each-line が使えれば良かったが,現時点で対応ブラウザが無い。

=}
{希哲15年3月11日の開発}{位置調整}{iOS 13}{mask-image}{スクロール可能}{諸場ブラウザ}{-webkit-scrollbar}{デライト装体調整}{希哲15年3月11日の進捗時限}{希哲15年3月11日の進捗}...=}(43)

{希哲15年3月11日9歩 K#F85E/A-E74C-21E2}

デライト装体調整

諸場ブラウザではスクロールバーが常時表示されないため,描写部スクロール可能なことが分かりにくいという問題があったが,これは続きがある方向に内容溶暗するような効果を付けることで上手く解決しそうだ。線を引く,印を付けるなどよりもさりげなく直感的分かりやすい

諸場でなくても,内容が途中で切れるのが美観的に気になっていたので丁度良い。

これなら描写後略機能透過的実現出来る。用者は普通にスクロールを続ける感覚で続きを取得することが出来る。

最初は -webkit-scrollbar 等を適当に設定して済ませるつもりだったが,iOS 13 以降の Safari では無効らしく,代替手段を探していた。結果的にはより洗練された手段が見つかった。

mask-image を使えばこの手の効果を付けるのは簡単だが,スクロールバーにまでマスクがかかってしまうのが気に入らなかった。

linear-gradient()背景にした独自のマスク要素を作り,位置調整スクリプトで行うことにした。

急ぐことではないため装体のみ作っておいて終了。

{通注}{希哲15年3月5日の開発}{kbd 要素}{希哲15年3月5日の進捗時限}{希哲15年3月5日の進捗}{希哲15年3月5日}{@tip}{四辺}{2px}{1px}...=}(21)

{希哲15年3月5日5歩 K#F85E/A-E74C-1ACF}

通注 @tipHTML を使えるようにし,「[Ctrl] + ダブルクリック / [Enter] で描き出す」などと表示していたのを kbd 要素 で「<kbd>Ctrl</kbd> + ダブルクリック / <kbd>Enter</kbd> で描き出す」とした。

ただ,通注では一箇所でも 2px 以上のがあると無駄に注意を奪われるため,四辺 1px装体にし,文字の太さも標準にした。

ちょっとしたことだが直感的に読みやすくなり,少しお洒落な感じにもなったので満足した。

=}(1){所感}
{耳慣れない}{良し悪し}{希哲15年3月1日のツイスト}{能否}{希哲15年3月1日}{面倒臭い}{ツイスト}{直感的}{情技}{拡大解釈}...=}(18)
{迷いをなくしておく}{ご回答ありがとうございます。}{輪括}{引き入れ}{立体階層構造}{子輪郭}{親輪郭}{輪郭構造説明図粗描}{輪括記号}{輪結}...=}(33)

{後景記号 =} について K#F85E/A-E74C-1BB1}

ご質問ありがとうございます!

記号 =} は,輪郭間の関係を表す記号で,「後景記号」と呼んでいます。逆向き {= は「前景記号」ということになります。

以下の図を見て頂くと分かりやすいのではないかと思いますが,「立体階層構造」とも言える輪郭同士の入れ子関係は遠近関係でもあります。つまり,親輪郭前景(手前)で,子輪郭後景(奥)に配置されているというイメージです。

親子というのは便宜上の表現で,正式な用語としては前景・後景といいます。一覧では三層になっていますが,中間のものは中景と呼びます。

この記号は,どちらかというと不等号集合記号のような数学記号イメージで昔考案したものです。単純に連想関係を表す矢印のようにも見えるので分かりやすいだろうと思いました。

ちなみに,引き入れ関係は「輪括」(リンクルージョン)と呼びます。希哲館訳語輪結リンク)と引括インクルージョン)の合成です。この二つの性質を合わせ持っていることを表現しています。

後景記号前景記号を総称して「輪括記号」とも言えます。

このあたりの用語記号はまだ整備途上なので,将来的には変わる可能性もあります。

逆向きの方が直感的というのは新鮮ご意見だったので参考になりました。今後の検討材料に加えさせて頂きます。

{投稿頻度}{実装難度}{心理的障害}{削除機能}{変更履歴}{目障り}{デライト}{輪郭}{優先順位}{空欄}...=}(28)

{削除機能について K#F85E/A-E74C-C699}

厳密に言うと,削除機能は優先順位に対して実装難度が高いだけで,実装しないと決めているわけではありません。簡単にアクセス出来,邪魔にならず,間違って削除しにくいような UI を今のデライトのどこに置くか,というのが難しいのです。

だったら「空欄で上書き」というのは簡単で直感的で,別に悪い代替手段じゃないんじゃないか,ということですね。

一般的な掲示板と比較しても,匿名性が高く,変更履歴を残さす自由に書き換えられるシステムで特別「下手なこと書き込めない」ということはないと個人的には思うのですが,全体の雰囲気としてそう感じさせてしまっているのだとしたら,それはそれで考えなければならないことだと思います。

それとは別に,削除機能が無いことが,特に不慣れなユーザー心理的障害になっている,というのは確かにあると思います。

それは書き込みにくいというより,単純に投稿頻度が低いと余計な輪郭目障りなのではないか,と考えています。これは,名前も内容もない輪郭は非表示にするような工夫で対応出来るかもしれません。

アンケートというのは良い案だと思います。個別の課題について意見を集めるということは,結果にかかわらず,ユーザーがどうデライトを見ているか,ということを可視化する良い機会になりそうです。早速実施方法を考えてみます。

=}(1){あれ}
{希哲14年10月26日の開発}{希哲14年10月26日の進捗時限}{希哲14年10月26日の進捗}{希哲14年10月26日}{輪符写し改良}{選択化}{進捗記録}{進捗時限記録}{進捗時限}{直感的}...=}(15)
{直感的}
{}