{ハイブリッド式}{遊画用語}{割り切り}{Markdown 研究}{Dex::buf_T}{buf_T}{デライトの AutoPagerize 対応}{希哲15年3月13日}{HTML 部区}{次ページ}...=}(79)

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

デラング整備,特に Dex 実装作業没頭した。

28時までかけ,何度も書き直した Dex_T基本設計が一応の完成をみた。

模動応付を持てるバッファbuf_T)のスタックを中心に,模動切り替えながら処理振り分けていく。これにより部区入れ子も上手く扱うことが出来る。

最初はこのバッファを HTML 部区抽象化したものとして扱おうとしたが,杓子定規にすると非効率に,効率的に扱おうとすると不自然な部分が出てくるため,あくまで作業用バッファと割り切り柔軟に使えるようにした。

Dex::buf_T というのも語呂が良く,遊画用語っぽくて面白い


デラング研究一環として Markdown 研究も進み,Markdown利点欠点がよく見えてくるようになった。特に欠点の部分に関しては,最近 Markdown.pl をざっと読んでみて,技術的制約もあっただろうと推察する。

希哲前2年2004年)の Perl といえば,ちょっとしたサブルーチン呼び出しコストすら考えなければならない言語で,そこまで複雑なことは出来ない。

今の C++ 相当)に比べて,その遅さは軽く100倍を越えるだろう。

当時における見通しの良さ効率性バランスをとった結果が Markdown だったわけだ。


ある描出をきっかけに,デライトの AutoPagerize 対応を考え始めた(10歩)。

デライト上でも AutoPagerize検索してみるといくつか言及があった。

もともと無限スクロール導入は考えていたが,用合い広告SEO の様々な懸念から現状の全知検索ページャーになっている。

実際に試してみると,やはりこれはこれで便利で,検索演心でもあり SNS 的でもあるデライトにはハイブリッド式が向いていると確信した。

最近,次ページ輪結を押すとその場で追加されるという折衷案を考えていたが,これを体験すると中途半端霞む

独自の無限スクロール導入した場合,この種の拡張機能干渉しないように対策も考えておく必要がある。

{描き出しボタン}{ボタン}{初見}{見直し}{バランス}{投稿}{UI}{デザイン}=}(8)

{ありがとうございます K#F85E/A-E74C-7352}

ご意見ありがとうございます。描き出しボタンが分かりにくい,というのは初めてのご意見だったので良い見直しの機会になりました。

実は,もともとデライトにはボタンがほとんど無く,Ctrl + ダブルクリックまたは Ctrl + Enter で投稿するという UI でした。

流石にこれでは分かりにくいということで,後付けしたのが現在のボタンです。手慣れた人にとっても目障りにならないように,意図的に最小限の表現に留めたのですが,確かに,初見ではボタンとしての役割が分かりにくいかもしれません。

もう少しバランスの良いデザインはあると思うので,近いうちに再検討します。

{バランス}=}(1)
{あれ}{希哲14年7月29日}{希哲14年7月29日のツイスト}{『メリクリ』}{精神衛生}{ツイスト}{気分}{固定}{バランス}{支配}...=}(13)
{ばら成し}{希哲14年2月19日のツイスト}{希哲14年2月19日}{ツイスト}{意味合い}{微妙}{翻訳語}{バランス}{理論}{分析}=}(10)
{ばら成し}{希哲14年2月19日のツイスト}{希哲14年2月19日}{ツイスト}{取り成す}{分散}{バランス}{解釈}{調和}=}(9)
{ばら成し}{希哲14年2月19日のツイスト}{希哲14年2月19日}{ツイスト}{ばら}{希哲館訳語}{成立}{分散}{バランス}{意味}=}(10)
{バランス}
{}