ひなたの雑記帳ひなたの雑記帳ジャンル問わずにまとめるブログ。・なぜ午前5時でログがリセットされるの?投稿された内容がいつでもどこまででも遡れるのは確かに便利ですが、全部見れてしまうのは不都合が生じることもあります。個人情報に関わる投稿、性癖にまつわるやや他人には理解されにくい発言、他人の悪口等、こういったものは自分で一つ一つチェックして削除していかないと消えないのは逆に不便なことも多いです。一定期間以上は保存されない、という仕組みがあったらいいんじゃないか、という発想で作りました。・なぜフォローが常に承認制で相互フォローのみなの?ツイッターなどでは相手が自分の知らないうちに自分をフォローすることができます。全ての投稿を責任を持って世界中の誰でもいつでも閲覧できるということを常に念頭において発言していれば問題は生じないでしょうが、ほとんどの人はそうではありません。あるならば、投稿を見れるのは「自分が承認したユーザのみ」であるべきです。いった考えに基づいて、フォローを承認制のみとしています。「相手がフォローリクエストして、自分が承認したなら、相手が自分の投稿を見れるだけでなく自分も相手の投稿を見れなければフェアではない」という考えに基づいています。・なぜフォローリクエストを「してきたユーザがリクエストした先のユーザのタイムラインを見れる」のではなく逆にしているの?これは人間関係という観点からこういう仕様にしています。フォローリクエストを行った人間が承認を得る前にリクエスト先の投稿を見れてしまうのは仕様的に整合性がとれていないのも理由です。自分の投稿をまず相手に公開するべきだという考えです。「リクエストが承認されないまま24時間が経過したら見れない状態に自動的に戻る」仕様にしています。・なぜRTの機能がないの?RTの機能を搭載する場合、フォロー外ユーザからのRTの閲覧権限の扱いが問題となります。フォロー承認制の仕様に従うなら「RTもフォローしているか自分がフォローリクエストを送っているユーザからしか見えてはいけない」べきですが、これだと「自分をフォローしているが自分がフォローしているユーザをフォローしていない」ケースで、後者のユーザのRTを自分をフォローしているが後者のユーザはフォローしていないユーザは見れないことになります。後者のユーザも自分もフォローしているユーザにはRTも見れます。結果何が起きるか?「自分をフォローしているユーザ同士でRTが見れるユーザと見れないユーザ」が出てきます。なると、見れないRTに対してタイムライン中で言及したりしだして、会話の流れがわかりにくくなります。リプライであれば(いわゆるエアリプは別ですが)@にIDが続いていることで他人に対して何かを言っているということがリプライ先の投稿が自分のタイムライン上で見えなくても察することができますが、RTに対するリプライでない言及は意味不明です。いった理由から、RTの機能をあえてつけないことにしました。・なぜフォロー外ユーザへのリプライが見えるの(リプライ先は見えません)?RTの機能を外した結果、フォロー外ユーザとの繋がりができにくい問題が生じます。「何か知らない人に話しかけているな?」ということがわかるようにしました。することで、その話しかけている相手に対して興味を持ってもらい、ユーザのプロフィールを表示してフォローする、という流れが生じる可能性が生まれます。・なぜ投稿をお気に入りに入れる機能がないの?ログが一日しか保存されない仕様で、お気に入り機能があってもあまり意味がないので、こういう仕様にしました。5時で前日の投稿全てがリセットされるミニブログです。あなたがフォローリクエストを送っている相手にしか見えません。フォローは承認制で、フォローリクエストを投げられたユーザが承認して初めて成立します。※この時点で自動的に相互フォローとなります。文字は楽に読めるサイズに。小さくても14pxまで。ブラウザのデフォルトの縦スクロール機能を活用する。UIの使い方は極力、見た目で直感的にわかるように。見た目だけでわからない操作はヘルプに書かず、UI自体に説明を組み込む。一画面内にUIが入りきらない時はフリックスクロールかスタック式のウィンドウに分割する。»フォローは常に相互フォローの承認制、毎日午前5時でログがリセットされるツイッター風SNS、todays!をリリースしました。「ネットで過去の情報がどこまでも遡り放題、検索し放題なのは確かに便利だけど、なんでもかんでも”見えてしまう”のは逆に不便なんじゃない?」という思いから、「毎日午前5時で前日までの書き込みがリセットされる」という発想のSNSを作りました。フォローは常に相互フォロー、フォローリクエストを承認した時点で自動的に相互フォローが成立。フォローリクエストを送るとリクエストを「送られた側が送った側のタイムラインを24時間だけ」リクエストを承認するまでの間見ることができるようになります。世の中には「タッチイベントもマウスイベントもサポートしている端末」というものがあります。いう端末はマウスでクリックすると「touchstartに続けてmousedownイベントが自動で発火する」という困った特徴があったりします。windows8もその一つです。マウスでもタッチでも操作できるのがこういう端末のUIとしては理想ですが、実装が難しく、タッチのみに対応させるのが関の山でした(タッチをサポートしてる端末を判定してタッチで処理させる実装)マウスのみサポートだと、スマートフォンで動きませんからね。この問題をどうにかクリアできる実装を考え出せたっぽいので、ここに公開します。イベントはtouchstart⇒mousedownの順で発生するっぽいなので、まずイベントハンドラの一つ外側のスコープに即時関数を定義して、そこにイベントタイプ記録用の変数を用意してnullで初期化します。イベントタイプを判定するイベントハンドラ先頭で保存したイベントタイプ文字列がtouchstartで、かつ現在のイベントタイプがmousedownか判定する。判定処理を先に書いて判定結果が真なら何もせずにreturnする(必要に応じてpreventDefaultも実行)現在のイベントタイプ文字列を保存するイベントハンドラの引数にeを書いてe.typeで取れます。保存したイベントタイプをnullクリアここが重要です。クリアしないと次回以降正常動作してくれませんが、クリアをすぐに行ってはいけません。クリア後にmousedownが発生してしまいます。setTimeout!はい。「300ミリ秒後」かそれ以上後の時間を設定してsetTimeout内でクリアします。これで最初のイベントだけを処理対象にできます。応用フリックスクロールをタッチ、マウス両方で行う方法です。イベントタイプの保存は同じですが、touchstart、mousedown時に保存したイベントタイプを「touchendかmouseup」でnullクリアします。※タッチ、マウスの座標の取り方の違いを吸収する実装も忘れずに!さらに、touchmoveでは保存したイベントタイプがtouchstartである場合だけ、mousemoveでは保存したイベントタイプがmousedownである場合だけ処理を行います。touchend、mouseupも同様に保存したイベントタイプを見て対応するデバイスのイベントだった場合のみ処理を行います。僕の公開しているSNSのタイムラインクリック時にメニューを開く実装で利用しています。(ブラウザのウィンドウ内の高さが狭くなって「返信」ボタンが消えてる状態で機能します)SNSは以下。アーカイブを閲覧中です。