{希哲17年4月16日6歩 K#F85E/E74C-0FC3}
宇田川浩行インポート機能仕様検討,エクスポート機能の CSV 対応検討で終了。
待欄の閲覧性(迷惑行為対策)や時印指定がある場合の扱いが課題となってインポート機能実装の見通しは立っていなかったが,前者は未公開状態を使うこと,後者は編注記法で末尾に追記すること(実際の時印はインポート時のものになる)を思い付き,一気に実装イメージが固まってきた。どちらの課題も待欄がある KNS 特有のものだった。
輪数上限はエクスポート機能同様10,000輪,サイズ上限は譜類添付機能同様 5MiB の CSV が適当だろう。
これに合わせてエクスポート機能でも早期の CSV 対応を決めた。oln.csv
を ZIP 書庫化することになるだろう。
インポート・エクスポート機能の対応形式は輪郭譜類と CSV で当面は十分そうだ。あれもこれもと考え出すとキリがない。
{希哲16年11月6日の日記 K#F85E/E74C-5CA2}
宇田川浩行非常に収穫の多い気分転換として輪郭整備に時間を割くようになったが,やっているうちに,むしろこれこそ今やるべきことなのではないかという気がしてきた。
もともと輪郭量に対して輪括量・描写量が少な過ぎるという問題があったが,優先順位の問題でなかなか本格的な輪郭整備は進まなかった。第二次快調期を経て描出効率も発信能力も飛躍的に向上し,十分な時間対効果が期待出来るようになっている。
もう一つ,他用者への波及効果が意外と大きい感触がある。やはり,私自身が活発に描出しているかどうかで他用者の賑わいも違う気がする。この用者の少なさで一番の重用者なので,当然といえば当然だ。
開発に没頭していた期間,大きな収穫があっても用者の反応に乏しいということがよくあり,違和感を覚えていた。一つの理由として,そういう時期は待欄が進捗記録などの事務的な記録で埋まりがちで,献典として面白くないということがあったのかもしれない。
先日の日記では,Twitter の騒動を利用することに関して消極的な見方をしていたが,よく考えると,そもそも「Twitter ではない Twitter のようなもの」が失敗してきた理由は,Twitter との差別化が出来ていなかったからだ。この場合,KNS としてのデライトの革新性は,障害ではなく近道として機能するかもしれない。積極的に利用することを考えるべきか。
面白いのは,デライトのキャズムについて最近考えていたこととの対比だ。個人知識管理通類の用者層は意外と保守的であり,大きな変化を望んでいない人が多い。それはメモと自己保存欲求の相性の良さから来ているのではないか,と考えていた。先述の用者の反応に乏しい問題にも通じるが,新機能を追加しても意外と喜んでもらえない。こうした層向けには,印迫よりも安心感を与える施策が必要なのだろう。
この二方面への売り込み方を上手く使い分け,組み合わせることで新しい道が開けそうだ。
{待欄の役割について K#F85E/E74C-BEBC}
宇田川浩行利用者が本格的に増えてきた時にデライト上での交流がどのように行われるか,というのは未知のことだが,もともと「待欄」と呼ばれているところは「デライト上でどんな投稿があるかをちょっと眺める場所」以上の期待はしていないし,最初から期待のしようがない。
そもそも第一に自分のメモを書くところであって,それが偶発的に他人のメモと繋がることがある,というサービスなので,それが問題だとも考えていない。「破綻する」ものも「機能しなくなる」ものも,私の中には最初から無い。関心の近い人同士は検索などで発見しあうだろうし,引き入れやリンクなどで一定のクラスタリングというか,動線の最適化はされるだろう。リンク集のようなものを作っておいてもいいし。
{希哲15年2月26日5歩 K#F85E/E74C-FC19}
宇田川浩行全ての輪郭一覧で RSS を取得出来るようにする方針をまとめいったん終了。
PWA の通知機能は日本で普及率の高い iOS が対応していないという日本を足掛かりにしたいデライトにとっては無視出来ない問題があった。
それを抜きにしても,相振り側で通知に関する登録情報や状態を管理することは現時点で避けたい。
実装・運用の容易さ,枯れた技術であり応用範囲が広く応用技術も多いことなど,かつて月庭で機能していた RSS が意外に合理的だったことに気付いた。独自の通知機能を実装するよりも総合的に勝る。
上部ページャーの右端にでもフィードボタンを追加する。RSS 非対応ブラウザが増えているため,先日考案した共有ボタンと同じ方式で,独自のメニューを挟む。このメニュー上なら Feedly 等のボタンを置いてもいいだろう。
KNEST の仕様として求頼文字列で除外する自我知番などを指定出来るようにし,録入り中の自我を反映させる。その他,自由に除外したい知番を指定出来るような用合いも検討しておく。
特定の用者の待欄を登録しておけば SNS のフォローに近いことが出来る。デライト公式で不具合報告や要望用の輪郭などを登録しておけば運営の効率化にもつながるだろう。
この検討を通して久しぶりに「待っ読」という翻訳語を思い出した。
{希哲14年12月26日の日記 K#F85E/E74C-0D3C}
宇田川浩行{希哲14年9月15日のデライト運営 K#F85E/5B28-3A36}
宇田川浩行この日分(実際の記録は翌日から遡及)からデライト運営記録を付け始める。
デライト宣伝をする上で厄介な問題だと感じていたことに,自分自身(K#F85E)の描出があった。
ほとんどの時間帯,デライトの最新待欄は私の描出で埋め尽くされていることが多く,我ながら非常に入りにくいだろうなと思っていた。非表示にしてしまうことも考えたが,最初の用者達とは待欄上でやりとりしていることも多く,これはこれで混乱を招く。自分で一般用者のフリをして描出する「自作自演」も流石にやりたくない。
ここでもデライト公式(K#9-C7C6)が活用出来ることに気付いた。
宣伝活動の前にデライト公式で見本になるような描出をして,K#F85E の描出が目立たないようにする「待欄調整」をすれば大分待欄の癖は薄まる。宣伝活動終了後も1時間程度は K#F85E での描出を控えることにした。食事や散歩,雑用などで潰せる時間帯でもありちょうどいい。
やはり深夜から早朝にかけても私の描出だけで待欄が動いていないことが多いため,就寝前にも同じように待欄調整をしておくことにした。
{希哲14年8月22日4歩 K#F85E/5B28-9223}
宇田川浩行K#9-D657,K#9-EDD2 両氏との対話から,全知検索窓横の自我アイコンの役割について整理。
暫定的に,アイコンからは自輪郭検索へ,名前(知番)からは自我ページへ飛べるようにし,メニューの末尾に「設定」の項目を置いて自我設定へ飛べるようにした。
元々,アイコンからは自我設定に飛ぶようにすることを想定していたが,しばらく実装出来なかったため,一時的に全輪郭検索(/)に飛ぶようにしていた。最近,自我設定実装の見込みが立ったことで,輪郭一覧で邪魔だった録落ちボタンの置き場にし,輪結を復活させていた。
ただ,アイコンから待欄に飛ぶという挙動は直感的でもあり,このあたりの仕様には迷いが生じていた。
K#9-EDD2 氏の案のように,アイコンから自我ページに飛ぶのも直感に適っており,Twitter などでもプロフィールとして採用されていることから慣れやすい。
しかし,現状,自我ページは自我知番での検索結果で代用している都合上,検索窓に知番が入ってしまい再検索の邪魔になるという問題がある。
そこで,アイコンからは自輪郭検索に輪結しておき,自我ページへはアイコン下の名前・知番の表示部分から輪結することにした(後者は従来案)。
用者が増えてきたとき,全輪郭検索に素早く握接する機能にどこまで需要があるか分からないが,必要になった時は左端のデライトのロゴ濁点にあたる輪っかが活用出来そうだ。