{『希哲日記』}{日記}{}{}{希哲17年7月25日}{希哲17年7月24日}{痛いほど}{生かされてきた}{安らかに眠れる}{覆い隠さず}(120)

{希哲17年7月24日の日記 K#F85E/0758-7805}

明日から長期安定体制仕上げ後半戦だが,旧雑務想定より早め片付きそうで,早速気持ち弛緩し始めている


長期安定体制の完成まであと一息という希哲館事業デライトとは対照的に,Twitter崩れ落ちる音が聞こえそうなくらいの混乱ぶりで,ついにTwitter名称語体を「X」に切り替えるそうだ。既存用者気の毒なくらい,ブランディングデザイン観点からは明らかな悪手だが,色々考えさせられた

イーロン・マスクが,センスの権化のような存在だったスティーブ・ジョブズ一部並び称されることにずっと違和感があったのだが,やはりこの人には根本的にセンスがない

X」になんとなく既視感があるなと思ったら,14歳くらいの自分も,「X」のような意味深名前で,漠然と万能凄い司組作りたいというようなことを考えていたからだったことに気付いてしまったイーロン・マスクというは,本当にその辺中2感性何のひねりもなく50過ぎまで持ち続けているのだなと思う難解理解出来ないのではなく,幼さ痛いほど分かってしまう

司組大きく改変されて,Twitter というブランド根想辛うじて表面的に Twitter らしさ保っているだけだなと思っていたところなので,この変更をもって事実上Twitter の終焉」とすべきなのかもしれないとも考えたしいて言えば用者献典依然として残る遺産だが,それも,所有者感性がこれだと腐っていく気しかしない

もっともとっくの昔ゾンビ化していた Twitterそのまま健全化するなんてことは最初から無理な話だったわけで,マスクはその現実覆い隠さず世間突き付けただけとも言えるゾンビになっても騙し騙し生かされてきた Twitter にとっては,ようやく安らかに眠れる良い機会かもしれない。

28日Twitter について追記

{『希哲日記』}{}{}{}{日記}{}{}{}{}{テキスト向き}(401)

{希哲17年7月15日の日記 K#F85E/0758-279C}

激化する SNS 戦国時代の中で,サービス文化について考えさせられること多い今日ちょっと面白い発見もあった。

以前にも SNS におけるオタク文化について考えたことがあるが3月1日の日記依然としてその影響力強い感じる例えばMisskey猫耳機能などは私の価値観からすると完全にありえないものだが,そういう部分があることでオタク層からの信頼得ているはあるだろう。誰かにとっての「居心地の良さ」を提供することは SNS核心であって,Misskeyまだ小規模ながら興味深い事例ではある。

最近でいえば,Threads急速な台頭によって,キラキラした Instagram 的な対するドブ川」としての Twitter に,想像以上に多くの Twitter 用者想像以上に強い愛着持っていることが分かってきた。「陽キャ」に対する陰キャ」のコミュニティであるという意識やはり根強いようだ。それは単なる自虐というより,昔から言う明るい人気者ほどつまらない」とか「面白い奴には根暗多い」とか,その種含みがある。

確かに自分が好きだったお笑い芸人なんかを振り返ってみても,根暗ひねくれていたばかりだ。そういう人が,業界一定の地位いて妙に社交的な「明るい人」になったりして,つまらないこと笑うようになり,かつての面白さ失っていく,という哀しい現象よく見てきた

明るい人というのは箸が転んでもおかしいというなので,日常そこまでひねりの効いた刺激求めていないのだ。Twitter 用者Instagram 的SNS感じるつまらなさとは,こういうことなのだと思う

幼稚なデマ煽られやすいなど,全体としては知的脆弱さ目立つ Twitter ではあるが,役立つ投稿面白い投稿比較的多いことは認めざるをえない学問文芸も,多少ひねくれていたり,オタク気質だったりするくらいが丁度良いからだろう。その点で,Twitter 文化にはマイクロブログ型 SNS における確かな優位性がある。

そういう観点からデライト文化について考えてみたら,対 Twitter 戦略なんて無理筋じゃないかと一瞬思いかけた。というのも,デライト文化種子たる私自身が,人間の限りない可能性限りない成功対して限りなく楽天的性格であって,その実現のためにデライト開発してきたからだ。サービス名〈delight〉歓喜かけているくらいなので,そもそもデライトこの上なく明るい気分から生まれているそういう意味では,インスタグラマー真っ青キラキラ志向なのだ。

単純な話Twitter陰キャ寄りオタク寄りSNS だとして,デライトそうでないとすると,どうやって用者移行させるのかという問題があるここまでのデライト運営実感としても,Twitterはじめとするマイクロブログ型 SNS からの訪問者は,明らかにデライト文化引いている

読み込み中...
{『希哲日記』}{日記}{}{サービス}{希哲17年7月2日}{恵まれていた}{ちょっとだけ}{デライト経営}{いかに}{思い浮かばない}(73)

{希哲17年7月2日の日記 K#F85E/0758-A9B7}

昨日の日記にも書いたように,ほとんど世界史上最大の成功言えるデライトの完全な成功」を果すには環境ぬるま湯過ぎるのかもしれない,とちょっとだけ考えていたところで,Twitter では閲覧制限巡って大騒動になっていた。騒動大きさ過去最大級かもしれない。

Twitter 危機は,サービス開発難しさ非業界人にも分かりやすくしてくれたというやはり意義深いものがある。なぜデライトが「完全な成功」と「不完全な成功」を概念化しているのか,ぐっと理解してもらいやすくなった

Twitter のように人気は集めていても問題山ほど抱えていて,経営者に「地獄」と形容されるようなサービスもあれば,デライトのように閑散としていてもほぼ完全に理想的な状態にあって開発者経営者にとっては天国そのものというサービスもある。考えてみれば,「完全な成功」と言えるサービスなんて一つ思い浮かばないし,それに限りなく接近しているデライト到達点いかに高いかということでもある。

ほとんどのサービス集客代償として様々な問題抱え込んでしまうわけで,集客ここまで後回しにしてこれた,それだけ環境恵まれていた,というのがデライト経営特異性であり,優位性なのだろう。

3日振り返り日記

{進捗記録}{}{HTML の要素}{一対一}{}{進捗}{希哲17年5月7日の進捗}{希哲17年5月7日の開発}{希哲17年5月7日}{一番楽}(87)

{希哲17年5月7日5歩 K#F85E/E74C-BDDE}

動的引連 SVG アイコン実装

途中で終了

SVG スプライトbackground-image などでも利用出来るようにする実装について考えていたが,ここは割り切って原則SVG アイコン引連 SVG としてのみ扱う方針決めた

実装上の都合background-image使っているだけのアイコンとして,現状背景アイコン二つ役割持たせている二輪鎖念頭に置いた検討だったが,背景としての二輪鎖特定要素端っこ置いているだけなので,一番楽方法ではあるが background-image使う必要は無い

<view>舞覧対応状況不安があることはさておきフラグメント識別子付ける多重立求発生する舞覧があることがどうしても気になる手元Linux 版 Firefox でも発生するbackground-image使いたいのが二輪鎖だけだったのでまだ問題小さいが,SVG スプライト十分に軽量フラグメント識別子での参照十分に少ないという状況でしか効率的ではない手法範枠化出来ない

スクリプト補完した要素background-image設定することも検討したが,そうすると実装コスト動的引連 SVG変わらない上に,より柔軟性の低い参照方法でしかなくなる。

結局アイコンアイコンらしく要素一対一扱うものと割り切った何かとすっきりする

{進捗記録}{十分}{進捗}{希哲17年5月6日の開発}{希哲17年5月6日の進捗}{希哲17年5月6日}{制御したい}{1つの}{座標指定}{当面は}(91)

{希哲17年5月6日10歩 K#F85E/E74C-DDBB}

進捗時限記録中略

動的引連 SVG アイコン実装

途中で終了

SVG スプライト手法取り入れSVG アイコン定義icn.svg集約することにした。

SVG 出与えAejs組み込んで直接挿入してしまうことを考えていたが,舞覧隠し適切な分離出来なくなる要素の再利用必要な id 属性使いにくい,といった問題があった外部 SVG<use>利用すれShadow DOM になるので,id 属性衝突などを気にせず要素整理しやすくなる

スプライト画像として background-image利用しやすいというのも大きい:targetフラグメント識別子利用して表示要素変化させる技術があることを知ったが,舞覧によっては効率的に隠し出来ないことがあるらしく,今回は見送った<view>使えればいいが,Safari対応難がある当面は古典的な座標指定行くことにした。

アイコン制作では,アイコン並べて全体ばら成し見ながら調整することが多いため,見本兼ねられるのも便利だ。

SVG スプライトだけで十分かもしれないと思いかけたが,<use> 1つでも若干冗長な上に,1つのアイコン要素細かく制御したい場合<use>複数必要になるため,やはりスクリプトでの補完欲しい

{進捗記録}{}{十分}{知番}{意味符号化}{抜控}{進捗}{デライト}{👍}{希哲17年4月17日の開発}(148)

{希哲17年4月17日13歩 K#F85E/E74C-3416}

進捗時限記録中略

デライト全体における添付譜類方針検討終了

添付譜類あくまでも添え物として最小限の役割留めエクスポート機能でも実譜類出力には今後対応しない方針固めた

元々添付譜類添え物として設計しているが,実際に譜類添付機能出来エクスポート機能実装しようとしてみると,実質的な役割落とし所意外に難しい意図に反して,変に使われ過ぎるのも問題だ。

エクスポート機能では,とりあえずは代替 HTML などで済ませゆとりが出来た実譜類にも対応するか,などと考えていたそもそもどんな大企業クラウドであれ消えて困るような譜類唯一の保管場所にすべきではないし,そこまで神経質な人手元抜控持っていないということも考えにくいので,実はさほど必要性の高い付徴ではない。とはいえエクスポート時負荷帯域だけが問題なら金で解決出来るのだから,将来的に対応しないというほどの動機もない

しかし添付譜類エクスポート出来てしまうことで譜類倉庫的な利用増え,それに伴い譜類保全責任が増せば,将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた描出公開原則同様,ここは割り切った用者文化育てていくべきだろう。

これに気付いてみて,最近添付譜類役割広げようとし過ぎていたことにも気付いた譜類添付機能サイズ上限拡張子制限緩和考えていたが,これも最小限留めることにした。拡張子制限制危面もあるが,献典として非効率だったり無意味だったりする譜類上信抑止といった効果望める例えば .bmpそのまま上信して欲しくはない

デライトの強みは,知番による意味符号化文字献典情報密度極限まで高め,その軽さ最大限に活かせることだ。譜類倉庫的な方面消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降,その微妙揺らいでいることはうっすら感じていた今日は妙にもやもやしていると思ったら,どうもがそれを訴えていたらしい。気付いたら非常にすっきりした

描出公開原則のように何かこの方針名前を付けたくなったが,「譜類添付機能」という名前趣旨表現出来ているので,それに立ち返るということで十分だろう。

{考えていた}

{}