Create Public Facing Document on How to Request Games #38

New issue

Closed

opened 2024-01-14 14:39:54 -06:00 by jimmyb · 2 comments

jimmyb commented

2024-01-14 14:39:54 -06:00

Owner

Copy link

Originally submitted by Veilor: the game request area covers a wide range of platforms and request types, so users need clearer public guidance about what can be requested and which section/platform those requests belong under. The original example called out the Mobile section specifically: Mobile requests may include iOS, Android, older cell phone systems, Alexa, and Oculus/Meta Quest titles.

The current Laravel checkout has public support navigation for /support, /support/knowledge-base, and /support/contact-us, plus a reusable support card that sends users to the service desk. This issue tracks creating that public guidance and aligning any staff/job documentation with it so users and staff share the same request expectations.

Scope

Public-facing documentation explaining how to request games.
Clear descriptions of what users can request and what information makes a request actionable.
Platform/category guidance for broad buckets, especially Mobile and any other categories that combine multiple device families or storefronts.
Explicit Mobile examples including iOS, Android, older cell phone systems, Alexa, and Oculus/Meta Quest where appropriate.
Guidance that helps users choose the right platform/category before submitting a request.
Links from relevant support or knowledge-base surfaces so users can find the document.
Staff/job documentation alignment so internal handling of requests matches the public wording.
Preserve existing support/service-desk flows unless a request form is intentionally added in a separate issue.

Acceptance Criteria

A public user can access a “How to Request Games” document from the support or knowledge-base area.
The document explains what kinds of game requests are accepted.
The document explains what details users should provide, such as title, platform, release information when known, publisher/developer when known, and helpful source links.
The document gives clear platform/category examples for broad sections, including Mobile.
The Mobile guidance states that Mobile can include iOS, Android, older cell phone systems, Alexa, and Oculus/Meta Quest-style titles if that remains the desired taxonomy.
The copy distinguishes public user guidance from staff/job-processing guidance.
Any staff-facing job documentation that describes game request handling is updated or linked so it does not contradict the public document.
The document follows existing site layout, typography, and light/dark mode patterns.
The support navigation or knowledge-base entry point makes the document discoverable.
The page avoids stale references to unavailable forum threads unless those thread contents are recovered and intentionally incorporated.

Test Coverage Required

Feature tests confirming the public “How to Request Games” page or knowledge-base entry renders successfully.
Feature tests confirming the page is discoverable from the support or knowledge-base navigation path chosen for implementation.
Content assertions for key guidance, including Mobile examples and required/requested submission details.
Regression tests confirming guests can read the public guidance without authentication.
Authorization tests if any staff-only job documentation route or admin surface is touched.
Route tests confirming missing or renamed support/documentation routes do not leave broken navigation links.
Tests should use Pest and focused feature coverage.
Run the focused affected tests, then run vendor/bin/pint --dirty --format agent before closing the issue.

Progress Checklist

Support navigation includes Overview, Knowledge Base, and Contact Us links
Reusable support card links users to the external service desk
Admin dashboard references game requests and pending game work
Platform routing includes Mobile and Meta/Oculus Quest platform handling
Decide the public route or knowledge-base location for “How to Request Games”
Draft public request guidance with accepted request types and required details
Add clear platform/category examples, including Mobile
Link the document from support or knowledge-base navigation
Align any staff/job documentation with the same request taxonomy
Avoid relying on unrecovered forum-thread content unless it is found and reviewed
Add tests for page rendering, discoverability, guest access, content expectations, and any updated staff-only surfaces
Confirm the final copy gives users enough clarity to choose the right platform/category before submitting a game request

**Originally submitted by Veilor:** the game request area covers a wide range of platforms and request types, so users need clearer public guidance about what can be requested and which section/platform those requests belong under. The original example called out the Mobile section specifically: Mobile requests may include iOS, Android, older cell phone systems, Alexa, and Oculus/Meta Quest titles. The current Laravel checkout has public support navigation for `/support`, `/support/knowledge-base`, and `/support/contact-us`, plus a reusable support card that sends users to the service desk. This issue tracks creating that public guidance and aligning any staff/job documentation with it so users and staff share the same request expectations. ## Scope - Public-facing documentation explaining how to request games. - Clear descriptions of what users can request and what information makes a request actionable. - Platform/category guidance for broad buckets, especially Mobile and any other categories that combine multiple device families or storefronts. - Explicit Mobile examples including iOS, Android, older cell phone systems, Alexa, and Oculus/Meta Quest where appropriate. - Guidance that helps users choose the right platform/category before submitting a request. - Links from relevant support or knowledge-base surfaces so users can find the document. - Staff/job documentation alignment so internal handling of requests matches the public wording. - Preserve existing support/service-desk flows unless a request form is intentionally added in a separate issue. ## Acceptance Criteria - A public user can access a “How to Request Games” document from the support or knowledge-base area. - The document explains what kinds of game requests are accepted. - The document explains what details users should provide, such as title, platform, release information when known, publisher/developer when known, and helpful source links. - The document gives clear platform/category examples for broad sections, including Mobile. - The Mobile guidance states that Mobile can include iOS, Android, older cell phone systems, Alexa, and Oculus/Meta Quest-style titles if that remains the desired taxonomy. - The copy distinguishes public user guidance from staff/job-processing guidance. - Any staff-facing job documentation that describes game request handling is updated or linked so it does not contradict the public document. - The document follows existing site layout, typography, and light/dark mode patterns. - The support navigation or knowledge-base entry point makes the document discoverable. - The page avoids stale references to unavailable forum threads unless those thread contents are recovered and intentionally incorporated. ## Test Coverage Required - Feature tests confirming the public “How to Request Games” page or knowledge-base entry renders successfully. - Feature tests confirming the page is discoverable from the support or knowledge-base navigation path chosen for implementation. - Content assertions for key guidance, including Mobile examples and required/requested submission details. - Regression tests confirming guests can read the public guidance without authentication. - Authorization tests if any staff-only job documentation route or admin surface is touched. - Route tests confirming missing or renamed support/documentation routes do not leave broken navigation links. - Tests should use Pest and focused feature coverage. - Run the focused affected tests, then run `vendor/bin/pint --dirty --format agent` before closing the issue. ## Progress Checklist - [x] Support navigation includes Overview, Knowledge Base, and Contact Us links - [x] Reusable support card links users to the external service desk - [x] Admin dashboard references game requests and pending game work - [x] Platform routing includes Mobile and Meta/Oculus Quest platform handling - [x] Decide the public route or knowledge-base location for “How to Request Games” - [x] Draft public request guidance with accepted request types and required details - [x] Add clear platform/category examples, including Mobile - [x] Link the document from support or knowledge-base navigation - [x] Align any staff/job documentation with the same request taxonomy - [x] Avoid relying on unrecovered forum-thread content unless it is found and reviewed - [x] Add tests for page rendering, discoverability, guest access, content expectations, and any updated staff-only surfaces - [x] Confirm the final copy gives users enough clarity to choose the right platform/category before submitting a game request

jimmyb added the

labels

2024-01-14 14:39:54 -06:00

jimmyb added this to the Laravel 13 + TailwindCSS project

2026-06-03 23:54:50 -05:00

jimmyb added the

Rows
Columns