Review activity-creation affordance against p'a semana — reduce low-effort posts #53

New issue

Open

opened 2026-05-07 11:22:56 +00:00 by padreug · 1 comment

padreug commented

2026-05-07 11:22:56 +00:00

Owner

Context

The activities standalone currently exposes a top-right + Create Event button (ActivitiesPage.vue:81-88) that's one tap away from the main feed. Combined with the form being relatively quick to fill, this makes it too easy to create low-effort or duplicate activities — diluting the signal in the feed.

The reference app p'a semana has a different model that's worth studying: activity creation is somewhat hidden / requires more deliberate intent, which seems to act as a quality filter without blocking power users.

Scope

Audit p'a semana's activity-creation flow end-to-end — entry point, form length, required vs optional fields, any cooldowns or rate limits, social proof / accountability cues. Document findings in docs/.
Compare to our current Sortir/Activities flow — CreateEventDialog, ActivitiesPage create button, the form schema in the activities module.
Propose changes — could be: move the create entry point off the top-right corner (into a profile-sheet item, a long-press gesture, or behind a "+ More" menu); add a confirmation step; require a minimum description length; add per-user creation rate limits; etc.
Implement the agreed-upon changes in a follow-up PR.

Why now

Surfaced while solving HubPill collision with the top-right Create button (#41 fix). Rather than perpetually arbitrate top-right real estate between the launcher icon and the Create button, the better question is whether Create should live in the top-right at all. We're moving HubPill to bottom-left for now to unblock; this issue captures the deeper Create-flow rethink.

Out of scope

The HubPill repositioning itself — already done as part of the bottom-left move.
Activity moderation tools (separate issue if needed).

Acceptance

docs/ has a short comparison doc: p'a semana vs. our flow.
Decision recorded on the new Create entry point + any guardrails.
Follow-up PR implements the change.

## Context The activities standalone currently exposes a top-right `+ Create Event` button (`ActivitiesPage.vue:81-88`) that's one tap away from the main feed. Combined with the form being relatively quick to fill, this makes it too easy to create low-effort or duplicate activities — diluting the signal in the feed. The reference app **p'a semana** has a different model that's worth studying: activity creation is somewhat hidden / requires more deliberate intent, which seems to act as a quality filter without blocking power users. ## Scope 1. **Audit p'a semana**'s activity-creation flow end-to-end — entry point, form length, required vs optional fields, any cooldowns or rate limits, social proof / accountability cues. Document findings in `docs/`. 2. **Compare to our current Sortir/Activities flow** — `CreateEventDialog`, `ActivitiesPage` create button, the form schema in the activities module. 3. **Propose changes** — could be: move the create entry point off the top-right corner (into a profile-sheet item, a long-press gesture, or behind a "+ More" menu); add a confirmation step; require a minimum description length; add per-user creation rate limits; etc. 4. **Implement the agreed-upon changes** in a follow-up PR. ## Why now Surfaced while solving HubPill collision with the top-right Create button (#41 fix). Rather than perpetually arbitrate top-right real estate between the launcher icon and the Create button, the better question is whether Create should live in the top-right at all. We're moving HubPill to bottom-left for now to unblock; this issue captures the deeper Create-flow rethink. ## Out of scope - The HubPill repositioning itself — already done as part of the bottom-left move. - Activity moderation tools (separate issue if needed). ## Acceptance - [ ] `docs/` has a short comparison doc: p'a semana vs. our flow. - [ ] Decision recorded on the new Create entry point + any guardrails. - [ ] Follow-up PR implements the change.

padreug commented

2026-05-07 11:30:57 +00:00

Author

Owner

Two more design directions to incorporate:

1. Reconsider whether Create belongs on the bottom navbar at all.

We just moved Create into the activities standalone bottom nav as a stopgap (it was overlapping with HubPill in the top-right header). But the bottom nav's primary purpose is high-frequency navigation — and the typical user is consuming activities, not creating them. Creators are a smaller subset and creation is an infrequent act even for them. Burning a thumb-zone slot on Create may be miscalibrated.

Alternative homes worth weighing:

A "+ Create" item inside the profile sheet (already paired with identity = creator context)
A dedicated route /activities/create that's only reachable from a low-key entry on the empty/feed states, OR from the activity detail page ("+ Add similar")
A FAB-style overlay that's visible only on the Feed view (not the Calendar/Map sub-views)
Combination of the above with the explainer page (next point)

2. Tapping Create likely shouldn't go straight to the form.

When auto-approval is off (curated/moderated feed), Create should first land on an explainer page that covers:

How submission works (review queue, approval timing, what gets rejected)
Quality guidelines / examples of strong vs. weak posts
Any rate limits or per-user caps

Only after the user reads (or dismisses) this does the form open. This is the second guardrail beyond just hiding the entry point — it's friction at the moment of intent, not a barrier to access.

When auto-approval is on, the explainer can be skipped (or shown once with "don't show again").

Worth verifying whether p'a semana does either of these in their flow.

Two more design directions to incorporate: **1. Reconsider whether Create belongs on the bottom navbar at all.** We just moved Create into the activities standalone bottom nav as a stopgap (it was overlapping with HubPill in the top-right header). But the bottom nav's primary purpose is *high-frequency navigation* — and the typical user is **consuming** activities, not creating them. Creators are a smaller subset and creation is an infrequent act even for them. Burning a thumb-zone slot on Create may be miscalibrated. Alternative homes worth weighing: - A "+ Create" item inside the profile sheet (already paired with identity = creator context) - A dedicated route `/activities/create` that's only reachable from a low-key entry on the empty/feed states, OR from the activity detail page ("+ Add similar") - A FAB-style overlay that's visible only on the Feed view (not the Calendar/Map sub-views) - Combination of the above with the explainer page (next point) **2. Tapping Create likely shouldn't go *straight* to the form.** When auto-approval is off (curated/moderated feed), Create should first land on an **explainer page** that covers: - How submission works (review queue, approval timing, what gets rejected) - Quality guidelines / examples of strong vs. weak posts - Any rate limits or per-user caps Only after the user reads (or dismisses) this does the form open. This is the second guardrail beyond just hiding the entry point — it's **friction at the moment of intent**, not a barrier to access. When auto-approval is on, the explainer can be skipped (or shown once with "don't show again"). Worth verifying whether p'a semana does either of these in their flow.

padreug referenced this issue from a commit

2026-05-07 11:31:49 +00:00

feat(activities): move Create entry from page header to bottom nav

padreug added the

app:activities

enhancement

labels

2026-05-17 21:23:31 +00:00