raysan5
raylib.com updates and qol additions
Problem: -there was no way to quickly go back to the top of the page on mobile or desktop with a simple click.
Solution: -added a go to top of page button that auto hides itself when at the top, and auto shows when the page is scrolled down a bit.
Problem: -The nav bar was cut off on mobile, and although it could be side scrolled, it was not fully visible.
Solution: -Made the nav bar take the full available width when either on mobile or on android tablet device.
Problem: -On mobile, there was a forced width that ignored the screen size, causing some dom elements to disrupt the page layout
Problem: -The search box had an issue where it would alter the layout whenever a search was being made. It also had no place holder text and no aria-label accessibility. It was also not responsive or centered.
Solution: -Place holder text has been added. -Aria label has been added for text readers. -The search box has been styled to look more aesthetically pleasing & to provide the user with some visual cue. -The search box now adapts to the screen size due to newly added responsiveness. -The search results are now underneath the search box, keeping the flow of the layout consistent.
Problem: -The module boxes were not responsive and disrupted the page flow.
Solution: -Added responsiveness to the modules container, and reworked how the module boxes are styled for better flexibility when styling.
Problem: -The cheatsheet had no form of navigation outside of manual scrolling, resulting in a less than ideal user experience.
Solution: -A modules menu has been added. Now users can click on any of the entries, and be auto scrolled to that section. -This menu auto hides when print mode is enabled. -The menu is responsive.
Problem -Navigation links were mission aria-labels.
Solution -Added aria-labels to navigation links so that screen readers can tell what they are.
Problem -A navigation menu was missing for mobile.
Solution -Mobile navigation menu implemented entirely
A small note: I've added a js file, uiManager, that holds some logic regarding the go to top button. This will be used for future improvements where js is needed.
@treblig-punisher Thanks for the review! I'm afraid some conflicts arise when reviewing some previous PRs. Please, could you review them?
I was testing the page and I noticed some things to review:
- Is it possible to move the top-menu-icons to the right side, like it was previously. It looks quite overloaded on the left side.
- Is it possible to review menu item names spacing? On current implementation it is spaced to fit the full page content and stay aligned.
- There seem to be double-line spaces betweent paragraphs. I'd prefer to keep the simple spaces like current version.
Thanks again for the improvements!
@treblig-punisher Thanks for the review! I'm afraid some conflicts arise when reviewing some previous PRs. Please, could you review them?
I was testing the page and I noticed some things to review:
* Is it possible to move the top-menu-icons to the right side, like it was previously. It looks quite overloaded on the left side. * Is it possible to review menu item names spacing? On current implementation it is spaced to fit the full page content and stay aligned. * There seem to be double-line spaces betweent paragraphs. I'd prefer to keep the simple spaces like current version.Thanks again for the improvements!
Sure thing, I'll implement all changes and take a look at the conflict.
Hey Ray, I have a couple of questions, some updates, and a suggestion regarding the navbar. I have already reverted back all the spacing related issues I introduced, and have adjusted the socials container so that it remains on the right and slides along with the the resizing of the window. I'll be adding those changes to my current branch shortly, but before I do that, there's this other topic regarding the menu names spacing.
I have previously made changes so that the page, along with the navbar react responsively to the window size. The original spacing for the menu items adds 20px of padding for each element, and this works fine if you have a forced size for the nav bar an d page, meaning this ignores reacting to changes to the window size, which keeps the navbar at that size while the view is smaller causing the current issues on mobile and desktop. Since I've modified how these two behave to accommodate for a more fluid and flexible design, this is what using the old padding-inline: 0px, 20px makes it look like:
The only compromise is having that scrollbar due to the current size of the page, which I am sure it's a big no no. I have a suggestion, and this includes your current suggestion regarding the padding to keep the spacing the same, but making the horizontal overflow hidden. Now, this suggestion requires having a hamburger menu ready, which I can get done and implemented in a day, so you might have to go ahead and not merge my changes yet. I'll deal with any conflicts after.
Now regarding the merge conflicts, is there a way i could solve them in vscode? most of these conflicts are present because I have things properly formatted to make it easier to read while working on it, but the same html code/css styles are long one liners in master. that's all I need to fix these and better spot new additions.
One more thing, would you be ok with having all the css in css files separate from the html files? It makes working with everything a bit more convenient. Let me know, and I'll work on that.
The only compromise is having that scrollbar due to the current size of the page, which I am sure it's a big no no.
@treblig-punisher Sincerely, I'd prefer to avoid it. Is not possible to slightly reduce padding, i.e. to 18px, to avoid that bar despite not getting the menu elements perfectly aligned?
Now, this suggestion requires having a hamburger menu ready
Is this menu is for mobile only? Or will this menu also be for desktop mode? If only for mobile/responsive, that's ok to me.
Now regarding the merge conflicts, is there a way i could solve them in vscode?
I don't know, but they could be reformated if required. At the moment there are no coding-conventions defined for the web and that's something I'd like to do. I like to keep all the files and code very organized and following some conventions.
One more thing, would you be ok with having all the css in css files separate from the html files?
Yes, that's ok. Actually, as commented, the files structure and code conventions should be reviewed. Just one exception, I'd like to keep the cheatsheet as self-contained as possible, including the styling on the .html, at least for the moment.
@treblig-punisher Sincerely, I'd prefer to avoid it. Is not possible to slightly reduce padding, i.e. to 18px, to avoid that bar despite not getting the menu elements perfectly aligned?
Yes that's a great solution too. I'll implement that.
I don't know, but they could be reformated if required. At the moment there are no coding-conventions defined for the web and that's something I'd like to do. I like to keep all the files and code very organized and following some conventions.
That's great to hear. For the most part, I'll work on a way to keep things better organized, and concise. so far everything is well structured, except for some of the css styling for some pages being on the html files themselves.
Yes, that's ok. Actually, as commented, the files structure and code conventions should be reviewed. Just one exception, I'd like to keep the cheatsheet as self-contained as possible, including the styling on the .html, at least for the moment.
Alright, will do so. I'll keep that exception as needed 🫡
Is this menu is for mobile only? Or will this menu also be for desktop mode? If only for mobile/responsive, that's ok to me.
That is correct, only mobile will have that.
One last thing, I will update my PR with all the changes, so you might have to give that a go, after, to see any if there are any new merge conflicts. I'll make sure to solve them.
@treblig-punisher Nice! Thanks for the review! It seems there are still some conflicts that prevent merging...
@treblig-punisher Nice! Thanks for the review! It seems there are still some conflicts that prevent merging...
I'll be taking a look at these soon. So far the good changes that wee needed have been added.
Did you pull my latest changes? It seems like the conflicts are the same old ones and not with the newly added features. Let me know.
I just double checked, everything's up to date, my apologies. I'll work on fixing what's causing conflicts.
Alright Ray, I have resolved the conflicts in those two files. I added whatever was missing to mine, and removed anything that had been replaced. Let me know how it goes. It should work normally.
Edit: Just tested on my branch and it seems to be working just fine so far.
Changes:
-minified both path_to_raylib.html and timeline.html files. This was an unintentional format change that has now been reverted back to how it was.
-
renamed uiManager.js to ui_manager.js and updated all references.
-
deleted both hamburger svg, and x-icon svg. Their code has been moved to the ui_manager.js file.
-
updated back-to-top-button's position on the page to prevent covering important page details when reaching the end of the page.
-
added better mobile reposiveness to both classic games and standard games buttons. These will keep their full size when on desktop, and switch to a smaller width on smaller devices with less space.
-
One change made to the social media links is the new support for aria-labels. Now screen readers can tell where the links lead instead of saying just "link." More aria-label changes in the near future to make raylib.com more accessible.
-
Renamed disable-arrow-scroll.js to disable_arrow_scroll.js. I didn't remove the file since whoever is making changes or using the file might need for future feature updates.
These are all the changes Ray. Let me know what you think. This should cover almost everything you suggested except for the thing I explained.
@treblig-punisher I'm trying to review this PR but I'm afraid it's TOO big, could it be splitted in smaller PRs, please?
Also, I see many formatting changes that make it very difficult to see the real changes, could be the previous formatting maintained?
@treblig-punisher I'm trying to review this PR but I'm afraid it's TOO big, could it be splitted in smaller PRs, please?
Also, I see many formatting changes that make it very difficult to see the real changes, could be the previous formatting maintained?
I'll have to see how to split it to make it more manageable. Could you tell me what exactly changed regarding the format of the pages? what browser are you seeing these changes from?
Could you tell me what exactly changed regarding the format of the pages?
Actually I was referring to code tabs spacing, as it changed it's difficult to see the what changed exactly for the PR.
It's a quite big PR and it's difficult to track review all changes in case something won't work as expected, so it's easier if it is split in smaller PRs, maybe by feature or modified pages. Code formatting is better to be maintained for the moment for changes readability.
Could you tell me what exactly changed regarding the format of the pages?
Actually I was referring to code tabs spacing, as it changed it's difficult to see the what changed exactly for the PR.
It's a quite big PR and it's difficult to track review all changes in case something won't work as expected, so it's easier if it is split in smaller PRs, maybe by feature or modified pages. Code formatting is better to be maintained for the moment for changes readability.
I totally understand. At the moment I am having a bit of a big issue given that the site has been updated again, and I am sure my changes will cause conflicts, since they are from 4 months ago, so here's what I propose:
I will clone the latest version of the repo, and try to implement my changes, and submit smaller PRs as you suggested. This is gonna take some time as I have to keep in mind what should change and what needs to remain minified. The minified portions are meant to be like that for footprint purposes I am assuming, right?
The other thing regarding some of the changes is that I had to modify the nav bar elements to accommodate for the responsiveness of the site on tablets and mobile.
Some the changes also include quality of life improvements for screen readers. This is aimed to help those with visual problems navigate the site with ease.
About SVGs:
I use svgs for some icons used by the updates I implemented like the go to top button, and the hamburger menu bar for mobile. I have these directly where I need to use them, in my case, I have them in the JS file that comes with the repo. This way I can just reuse it and not have to copy paste it in all pages they're used.
On a final note:
I am interested in also helping you create the new look for the site whenever you feel ready. You already shared a pretty good sketch of what you have in mind, so I'd love to further discuss this outside of github. Could be discord, or google meet, whichever works best for you.