Make public pages mobile friendly (responsive)

[luistoptal]

User story

As a website user
I want the public pages of the website to be responsive across devices
So that I enjoy a smooth, consistent experience regardless of screen size

Acceptance criteria

Given: The current home page layout
When: Viewed on mobile, tablet, and desktop devices
Then: The layout adjusts gracefully without horizontal scrolling or layout breakage

Given: The common header and footer components
When: Displayed on varying screen sizes
Then: They resize and reorganize as needed to remain legible and fully functional

Given: The dataset page content
When: Viewed on different devices
Then: It provides a responsive layout, matching the improvements on the home page and common elements

Additional Info

• Focus on low-hanging fruit first: Home page, header, and footer.
• Secondary focus should be dataset page
• Lastly, focus on other public pages
• Validate with common breakpoints (e.g., 320px, 768px, 1024px).

Product Backlog Item Ready Checklist

• Business value is clearly articulated
• Item is understood enough by the IT team so it can make an informed decision as to whether it can complete this item
• Dependencies are identified and no external dependencies would block this item from being completed
• At the time of the scheduled sprint, the IT team has the appropriate composition to complete this item
• This item is estimated and small enough to comfortably be completed in one sprint
• Acceptance criteria are clear and testable
• Performance criteria, if any, are defined and testable
• The Scrum team understands how to demonstrate this item at the sprint review

Product Backlog Item Done Checklist

• Item(s) in increment pass all Acceptance Criteria
• Code is refactored to best practices and coding standards
• Documentation is updated as needed
• Data security has not been compromised (with particular reference to the personal information we hold in GigaDB)
• No deviation from the team technology stack and software architecture has been introduced
• The product is in a releasable state (i.e. the increment has not broken anything)

[rija]

In 2024, visitors to gigadb.org, by resolution and device types:

[luistoptal]

@rija thanks for these analytics

okay I see 10% of users access the site via smartphone

I am going to conjecture that the data is biased in favor of the editors who primarily use the admin panel which does not need to be responsive, also I could imagine if a user visits the site from a mobile device and the site looks broken maybe they will leave immediately and access the site via desktop, if that is true then the "importance of the user intent" on visiting the site on mobile would be larger than the raw numbers suggest, so I would say this task is worth doing

[luistoptal]

@rija before trying to update any of the public pages (first only homepage and dataset page), to avoid wasting time, since I know that some pages will be served from a wordpress editor eventually, I would like to know

• will the home page and the dataset page be served from wordpress?
• if yes, is there any kind of timeframe / rough plan when this will happen approximately? for example if this will happen within the next 3 months, maybe updating the current pages would be a waste of time, but if it is one year, maybe it isn't

the home page and dataset page a relatively complex and making them fully responsive will take a few of hours

[rija]

Hi @luistoptal,

I am going to conjecture that the data is biased in favor of the editors who primarily use the admin panel which does not need to be responsive,

The admin area is and will indeed exclusively be used by the curators, and none of them use (and they don't want to anyways, at least for now) their smartphones to access it.

also I could imagine if a user visits the site from a mobile device and the site looks broken maybe they will leave immediately and access the site via desktop, if that is true then the "importance of the user intent" on visiting the site on mobile would be larger than the raw numbers suggest, so I would say this task is worth doing

We do notice that users coming from smartphones leaves immediately, I assume their experience is suboptimal.

After discussing with @only1chunts, we also realise a common use case of mobile use: conferences.
we have gigadb posters and slides in most conference any one us attends and those posters and slides contains QR code to Gigadb website, which means a smartphone will almost always be the device people interested in us will reach first.

So yes, making the public area of gigadb.org responsive is important.

Regarding Wordpress involvement:
On gigadb.org, we will never serve pages with Wordpress directly.
If we use Wordpress it is going to be as a back-office CMS to manage the content published under the /static/ path (at least in its first implementation and pending happy adoption of the tool).
So, homepage and dataset pages remain dynamic PHP served pages as they are today.
The pages under /static/ needs to remain static for now, and JS enhanced whenever we are ready to integrate data from a back office CMS API (definitely not within the next 3 month).

Also, with @only1chunts, I've curated ticket #152 which is adjacent to the work to do here. It's a different user story but the underlying implementation has potential commonalities, so you may want to be aware of it.

When we get to File Upload Wizard and Submission Wizard work stream, we will need to discuss wat's the responsive story is going to be, but this ticket is not appropriate for such discussion.

Hope that helps.

[luistoptal]

Hi @rija I think #152 can be interesting when thinking about how to display the information mobile friendly. The tabular data could be a challenge, but at least the rest is easy to fix

I will create about one PR per page

[luistoptal]

Hi @rija @pli888 As I move forward I think the easiest way to handle this is to make all the public site mobile friendly first, and then create a PR with all the changes and have it reviewed, do you support this? Because mainly the review involves looking at the pages and giving the OK and it's gonna be way less annoying to review all pages in one go

[only1chunts]

from someone that is likely to be doing the reviewing, I think thats a good idea :-D

[rija]

Hi @luistoptal

Hi @rija @pli888 As I move forward I think the easiest way to handle this is to make all the public site mobile friendly first, and then create a PR with all the changes and have it reviewed, do you support this?

Just to check if I understood what you are proposing: you will be making the changes to make the public site mobile friendly on a branch and deploy it on your AWS environment. After rounds of reviewing form the curators , you will make the PR allowing tech team to do the technical review.
That's right?
If so, that's fine by me.

[luistoptal]

Hi @rija deploying so that curators can review the changes sounds like a good plan, I will do that