← All work

Case study · 01

Android App

URL Memo

残して、探して、読み返せる

リンク切れや内容変更が起きても、保存した時点の情報を振り返れることを目標にしたAndroidアプリです。共有・取得・整理・再読という一連の流れを、できるだけ少ない操作で完了できるよう設計しました。

URL Memoの画面
FIELDAndroid App
TOOLSKotlin · Android · HTML解析 · ローカル保存
FOCUS本文抽出 · オフライン閲覧 · 検索・タグ設計
01

What it does

できること

URLから本文を保存の画面
01

URLから本文を保存

URLを貼り付けるとページを取得し、ナビゲーションや広告などを除いた本文候補をメモとして保存します。URLだけを残す一般的なブックマークと違い、あとから本文そのものを読み返せることを重視しました。

  • タイトル・取得元URL・保存日時を本文と一緒に管理
  • 通信失敗時はURLだけでも残せる設計
  • 取得結果を保存前に確認し、不要な部分を修正可能
タグと全文検索で再発見の画面
02

タグと全文検索で再発見

保存件数が増えても目的の記事へ戻れるよう、タグによる分類とキーワード検索を用意しました。一覧ではタイトルだけでなく本文冒頭も表示し、開く前に内容を思い出せるようにしています。

  • 複数タグでテーマを横断
  • タイトル・本文を検索対象にする
  • カード全体を押せる大きなタップ領域
03

共有から直接追加

ブラウザやSNSで見つけたページを、URLのコピーとアプリ切り替えを繰り返さず保存できる導線を想定しました。見つけた瞬間に保存できるため、後回しによる取りこぼしを減らします。

  • Androidの共有導線からURLを受け取る
  • 保存画面では主操作をひとつに絞る
  • 完了後は一覧へ戻り、保存結果を確認できる
02

Why I made it

きっかけと課題

気になった記事をブックマークしても、時間が経つとページが削除されていたり、内容が更新されていたりすることがありました。また、リンクだけが大量に並ぶと『なぜ保存したのか』を思い出せませんでした。

そこで課題を『URLを保存すること』ではなく、『未来の自分が必要な情報を再発見できること』と定義しました。取得時点の本文を残し、短い説明とタグを添え、検索できるところまでをひとつの体験として設計しました。

03

Process

進め方・実装手順

  1. 01

    保存体験を分解

    入力、取得、確認、保存、検索、再読の6段階に分け、各画面で必要な情報と操作を洗い出しました。

    OUTPUT — 画面遷移図と保存データ項目
  2. 02

    ページ取得を実装

    URLへ通信し、文字コードとレスポンスを確認してHTMLを取得します。取得失敗・タイムアウト・リダイレクトも通常の状態として扱います。

    OUTPUT — 通信処理とエラー表示
  3. 03

    本文候補を抽出

    articleやmainなど意味を持つ要素を優先し、見つからない場合は段落量やリンク密度から本文候補を段階的に絞ります。

    OUTPUT — 抽出ルールと除外ルール
  4. 04

    端末内へ保存

    本文、タイトル、URL、日時、タグをひとまとまりで保存し、一覧表示に必要な要約は先頭部分から生成します。

    OUTPUT — 保存モデルと一覧UI
  5. 05

    実ページで検証

    ニュース、ブログ、企業サイトなど構造の異なるページで、本文が欠ける例と余計な要素が混ざる例を記録し、ルールを調整しました。

    OUTPUT — 失敗例リストと回帰確認項目
04

Problems & decisions

苦労したこと

01サイトごとにHTML構造が違う
PROBLEM

固定のCSSセレクターでは、あるサイトで成功しても別のサイトで本文が空になる問題が起きました。

APPROACH

意味のあるHTML要素、段落の長さ、リンク比率という複数の判定を優先順位付きで適用し、最後は編集できる確認画面へ渡しました。

RESULT

自動処理だけに頼らず、人が修正できる逃げ道を設けることで保存失敗を減らしました。

02動的・ログイン必須ページ
PROBLEM

JavaScript実行後に本文が現れるページや、認証が必要なページは通常の取得では内容を読めません。

APPROACH

取得できないページを無理に保存せず、理由を表示してURLと手入力メモだけを保存できる状態にしました。

RESULT

対応範囲を曖昧にせず、失敗時にもユーザーの作業を失わない設計になりました。

03保存後に見つからない
PROBLEM

本文保存が成功しても、一覧に情報が増えるほど目的の記事を見つけにくくなりました。

APPROACH

タグ、検索、本文冒頭、保存日時を一覧に出し、検索結果が0件のときは条件を解除する案内を表示しました。

RESULT

保存機能ではなく、再読まで含めて価値を判断する視点を得ました。

05

Reproduction guide

再現するための手順

未来の自分や、同じものを作りたい人が迷わないように、最短の再現手順を残します。

1. 保存するデータを先に決める

本文、タイトル、元URL、保存日時、タグ、メモを定義します。最初にデータ構造を決めると、一覧と詳細の作り直しを減らせます。

2. 通信と解析を分離する

ページを取得する処理と、HTMLから本文を取り出す処理を別にします。保存済みHTMLで抽出ルールだけを繰り返し検証できるため、改善速度が上がります。

3. 失敗例をテスト資産にする

本文が空、メニューが混ざる、文字化けする、といったURLをカテゴリ別に残し、抽出処理を変えるたびに確認します。

4. 共有・検索まで通して試す

単体機能だけでなく、ブラウザで発見してからアプリで再読するまでを実機で確認します。片手操作と通信が遅い状況も確認対象にします。

06

Reflection

振り返り

WHAT I LEARNED

  • 自動化の精度だけでなく、失敗時に修正できるUIが品質を支える
  • 保存数ではなく再発見できたかを価値の基準にする
  • 取得元の利用規約や個人情報を考慮し、私的利用の範囲を明確にする
NEXT STEP

本文抽出ルールのテストケースを増やし、重複URLの検出とエクスポート機能を追加することで、長期間使える個人アーカイブへ育てたいです。

NEXT PROJECT

Android App

共有からカレンダー

→