infrastructure/extensions-website
4
7
Fork 8
Code Issues 15 Pull Requests 1 Projects Releases Wiki Activity

Broken/obscure navigation #210

New Issue
Open
opened 2024-07-16 13:30:17 +02:00 by Oleg-Komarov · 6 comments
Oleg-Komarov commented 2024-07-16 13:30:17 +02:00
Owner
Copy Link

This is a collection of known issues with navigation on the website, such as links that lead to 404, missing or hidden affordances, any other confusing elements or flows.
While some of these can be tackled individually, looking at them together may lead to better ideas on organizing the navigation.

  • 404 pages (in awaiting review state)
    • If only a single version has been uploaded and the extensions is yet to be approved, clicking Version History leads to 404. (link is to /add-ons/{name}/#versions which doesn't exist yet)
    • If multiple versions are uploaded, you can click on Version History, but if then click on About from the Version History page you get 404. (link is to /add-ons/{name}/ which doesn't exist yet, but the /add-ons/{name}/#versions does
  • obscure/missing affordances
    • draft state
      • uploading new version while in draft state is not obvious:
        possible via "version history" by clicking on version link in sidebar, but no "version history" tab in draft
      • iterating on the first upload in general - deleting/replacing the first upload
      • deleting individual files for multi-platform versions
This is a collection of known issues with navigation on the website, such as links that lead to 404, missing or hidden affordances, any other confusing elements or flows. While some of these can be tackled individually, looking at them together may lead to better ideas on organizing the navigation. - 404 pages (in awaiting review state) - If only a single version has been uploaded and the extensions is yet to be approved, clicking Version History leads to 404. (link is to /add-ons/{name}/#versions which doesn't exist yet) - If multiple versions are uploaded, you can click on Version History, but if then click on About from the Version History page you get 404. (link is to /add-ons/{name}/ which doesn't exist yet, but the /add-ons/{name}/#versions does - obscure/missing affordances - draft state - uploading new version while in draft state is not obvious: possible via "version history" by clicking on version link in sidebar, but no "version history" tab in draft - iterating on the first upload in general - deleting/replacing the first upload - deleting individual files for multi-platform versions
Oleg-Komarov added the
Type
Enhancement
Type
Report
 labels 2024-07-16 13:30:17 +02:00
Dalai Felinto commented 2024-07-18 17:23:08 +02:00
Owner
Copy Link

Related to this: it would be nice to have a link (for moderators) to go to the Approval Queue from the extension page.

Related to this: it would be nice to have a link (for moderators) to go to the Approval Queue from the extension page.
Pablo Vazquez commented 2024-07-27 23:35:05 +02:00
Owner
Copy Link

Adding a few of my own:

  1. That red download button is kind of confusing. It's too big so it feels like the main action, and it's red so "dangerous", but I'm uploading to my own extension so I know. I think it's fine to have maybe the name of the file, and a smaller button to download, although I've literally just uploaded it in the previous screen so it's less useful. Good to have but more minimal. image

  2. After uploading (by pressing Save on the bottom right), I'm redirected to the public "Versions" list (/add-ons/{ extension-id }/manage/versions/). Since I'm the maintainer, the Extension is "under review", and my next step would be to Request Review again. Maybe we should redirect to the Review page (/approval-queue/{ extension-id }/)

  3. This is also kind of weird. I made the changes and now want to request review. So I need to Set it as Awaiting Review. It would communicate better if it was "Request Review" or similar. image

Related to this: it would be nice to have a link (for moderators) to go to the Approval Queue from the extension page.

Good point. I had it for admins but not for mods. Done in ba63ac9e2f

Adding a few of my own: 1. That red download button is kind of confusing. It's too big so it feels like the main action, and it's red so "dangerous", but I'm uploading to my own extension so I know. I think it's fine to have maybe the name of the file, and a smaller button to download, although I've literally just uploaded it in the previous screen so it's less useful. Good to have but more minimal. ![image](/attachments/65074f3d-3deb-47a9-b218-80d5621e58eb) 2. After uploading (by pressing Save on the bottom right), I'm redirected to the public "Versions" list (`/add-ons/{ extension-id }/manage/versions/`). Since I'm the maintainer, the Extension is "under review", and my next step would be to Request Review again. Maybe we should redirect to the Review page (`/approval-queue/{ extension-id }/`) 3. This is also kind of weird. I made the changes and now want to request review. So I need to **Set it as Awaiting Review**. It would communicate better if it was "Request Review" or similar. ![image](/attachments/3ffcb03b-6f6c-4897-bf5b-2d074bec358f) ---- > Related to this: it would be nice to have a link (for moderators) to go to the Approval Queue from the extension page. Good point. I had it for admins but not for mods. Done in ba63ac9e2f
image.png
518 KiB
image.png
209 KiB
👍 1
Oleg-Komarov pinned this 2024-08-02 11:00:13 +02:00
Oleg-Komarov commented 2024-08-02 12:04:31 +02:00
Author
Owner
Copy Link

We are getting more reports about top tabs leading to 404 for extensions in Awaiting Review state.

@pablovazquez @martonlente what do you think is the best solution?

I see two approaches:

  1. on all pages that display tabs use the same template component that checks extension status and changes hrefs for "About" and "What's new" accordingly.
  2. use a tabs template component, but don't reuse the "About" and "What's new" tab for different hrefs in different statuses, instead of that define a list of all possible tabs for all statuses, and then filter the list based on status, e.g. have a data structure like this (example is not complete):
tabs = [
	{"name": "About", "href": extension.get_absolute_url(), "show_in_status": {"APPROVED"}},
    {"name": "Approval", "href": extension.get_absolute_url(), "show_in_status": {"AWAITING REVIEW"}},
    {"name": "Version History", "href": extension.get_versions_url(), "show_in_status": {"APPROVED", "DRAFT", "AWAITING REVIEW"}},
    ...
]
We are getting more reports about top tabs leading to 404 for extensions in Awaiting Review state. @pablovazquez @martonlente what do you think is the best solution? I see two approaches: 1. on all pages that display tabs use the same template component that checks extension status and changes hrefs for "About" and "What's new" accordingly. 2. use a tabs template component, but don't reuse the "About" and "What's new" tab for different hrefs in different statuses, instead of that define a list of all possible tabs for all statuses, and then filter the list based on status, e.g. have a data structure like this (example is not complete): ``` tabs = [ {"name": "About", "href": extension.get_absolute_url(), "show_in_status": {"APPROVED"}}, {"name": "Approval", "href": extension.get_absolute_url(), "show_in_status": {"AWAITING REVIEW"}}, {"name": "Version History", "href": extension.get_versions_url(), "show_in_status": {"APPROVED", "DRAFT", "AWAITING REVIEW"}}, ... ] ```
👀 1
Márton Lente commented 2024-08-02 12:40:10 +02:00
Owner
Copy Link

We are getting more reports about top tabs leading to 404 for extensions in Awaiting Review state.

@pablovazquez @martonlente what do you think is the best solution?

I see two approaches:

  1. on all pages that display tabs use the same template component that checks extension status and changes hrefs for "About" and "What's new" accordingly.
  2. use a tabs template component, but don't reuse the "About" and "What's new" tab for different hrefs in different statuses, instead of that define a list of all possible tabs for all statuses, and then filter the list based on status, e.g. have a data structure like this (example is not complete):
tabs = [
	{"name": "About", "href": extension.get_absolute_url(), "show_in_status": {"APPROVED"}},
    {"name": "Approval", "href": extension.get_absolute_url(), "show_in_status": {"AWAITING REVIEW"}},
    {"name": "Version History", "href": extension.get_versions_url(), "show_in_status": {"APPROVED", "DRAFT", "AWAITING REVIEW"}},
    ...
]

I'm not sure I understand the root issue of 404s, but to me both outlined improvements make sense from an architectural perspective. This is what I see:

  • Currently approved items use the hero_tabs block from the base template, while awaiting items use the hero_tabs block from the extensions_review_detail template.
  • hero_tabs could receive its own template component. It could replicate the current behaviour with nested conditionals.

Either if we go with option 1) or 2), creating a dedicate template component could be a first step.

> We are getting more reports about top tabs leading to 404 for extensions in Awaiting Review state. > > @pablovazquez @martonlente what do you think is the best solution? > > I see two approaches: > 1. on all pages that display tabs use the same template component that checks extension status and changes hrefs for "About" and "What's new" accordingly. > 2. use a tabs template component, but don't reuse the "About" and "What's new" tab for different hrefs in different statuses, instead of that define a list of all possible tabs for all statuses, and then filter the list based on status, e.g. have a data structure like this (example is not complete): > ``` > tabs = [ > {"name": "About", "href": extension.get_absolute_url(), "show_in_status": {"APPROVED"}}, > {"name": "Approval", "href": extension.get_absolute_url(), "show_in_status": {"AWAITING REVIEW"}}, > {"name": "Version History", "href": extension.get_versions_url(), "show_in_status": {"APPROVED", "DRAFT", "AWAITING REVIEW"}}, > ... > ] > ``` I'm not sure I understand the root issue of 404s, but to me both outlined improvements make sense from an architectural perspective. This is what I see: - Currently _approved_ items use the _hero_tabs_ block from the _base_ template, while _awaiting_ items use the _hero_tabs_ block from the _extensions_review_detail_ template. - _hero_tabs_ could receive its own template component. It could replicate the current behaviour with nested conditionals. Either if we go with option 1) or 2), creating a dedicate template component could be a first step.
Oleg-Komarov commented 2024-08-02 12:52:32 +02:00
Author
Owner
Copy Link

In these terms, what I propose in option 2 is to stop redefining hero_tabs logic in individual templates, but introduce a centralized place that controls the tabs list based on the extension status, and not on the template that includes the block.

In these terms, what I propose in option 2 is to stop redefining `hero_tabs` logic in individual templates, but introduce a centralized place that controls the tabs list based on the extension status, and not on the template that includes the block.
👍 1
Oleg-Komarov commented 2024-08-02 13:00:32 +02:00
Author
Owner
Copy Link

Such a decision would ensure predictable and consistent navigation, but will limit the flexibility to some extent. Please let me know if you see a potential problem with this approach and its limitations:

  • the tabs can only be "switched on" and off based on predefined conditions, e.g. checking for extension status, or some other property like the presence of reviews
  • it will be possible to include the same tab for multiple statuses (e.g. version history)
  • the order in which the "on" tabs will be shown will always be the same, and the generated markup will be the same
  • it may still be possible to manually add more hard-coded tabs in a template markup for particular templates if needed

If this sounds reasonable, I can prepare a PR demonstrating this approach some time next week.

UPD (2024-08-12) Sorry, this hasn't happened yet, I am still working on some other project.

Such a decision would ensure predictable and consistent navigation, but will limit the flexibility to some extent. Please let me know if you see a potential problem with this approach and its limitations: - the tabs can only be "switched on" and off based on predefined conditions, e.g. checking for extension status, or some other property like the presence of reviews - it will be possible to include the same tab for multiple statuses (e.g. version history) - the order in which the "on" tabs will be shown will always be the same, and the generated markup will be the same - it may still be possible to manually add more hard-coded tabs in a template markup for particular templates if needed If this sounds reasonable, I can prepare a PR demonstrating this approach some time next week. UPD (2024-08-12) Sorry, this hasn't happened yet, I am still working on some other project.
👍 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Normal
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

  
Type
Breaking
Breaking change that won't be backward compatible

  
Type
Documentation
Documentation changes

  
Type
Enhancement
Improve existing functionality

  
Type
Feature
New functionality

  
Type
Report
Something is not working

  
Type
Security
This is security issue

  
Type
Suggestion
New ideas and proposals

  
Type
Testing
Issue or pull request related to testing

No Label
Priority
Critical
Priority
High
Priority
Low
Priority
Normal
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Type
Breaking
Type
Documentation
Type
Enhancement
Type
Feature
Type
Report
Type
Security
Type
Suggestion
Type
Testing
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/extensions-website#210
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?