FreshRSS
FreshRSS copied to clipboard
General layout improvement: Top level navigation + structure
The first draft was presented in #5966. This is now the implementation.
close #4224
This PR is still in draft but I am happy about each comment or feedback
- [x] Roughly fine with Origine theme (wide screen)
- [x] Roughly fine with Origine theme (small screen/mobile devices)
- [x] introduce a new break point 1200px
- [x] Fine with each theme
- [x] Origine
- [x] Origine compact
- [x] Alternative dark
- [x] Dark/Dark Pink
- [x] Ansum/Mapco
- [x] Flat design
- [x] Nord
- [x] Pafat
- [x] Swage
- [x] Install routine page
- [x] views
- [x] normal view
- [x] global view
- [x] reading view
- [x] Anonym. reading
- [x] login page
- [x] about page as guest
- [x] TOS page as guest
- [x] check extensions
- [x] Colorful List
- [x] Custom CSS
- [x] Custom JS
- [x] Image Proxy (not relevant, but works fine)
- [x] Quick Collapse
- [x] ReadingTime
- [ ] Share By Email <== buggy
- [x] Sticky Feeds (not necessary anymore)
- [x] Title-Wrap
- [x] ShowFeedID
- [ ] ThreePanesView <== buggy
- [ ] any other important extension, that needs to be checked?
- [x] navigation buttons
- [x] invisible buttons
- [x] visible buttons
- [x] left button
- [x] right button
- [x] up button
- [x] options for less buttons in the header
- [ ] Update screenshots of the themes
known issues
- [x] Tested the shortcuts for switching the views
- [x] offset of mark read while scrolling
- [ ] extensions
- [ ] Share By Email <== it will break the layout. But there is another bug: https://github.com/FreshRSS/Extensions/issues/210
- [ ] ThreePanesView <== mark reads while scrolling does not work
- [ ] ....... please leave feedback and your testing results here in the comment sections ....
(more screenshots + description will follow)
Out of scope
(not so important, discussion needed, PR could follow):
- [ ]reorganize the navigation side bar (aside_config.phtml, aside_subscription.phtml), following the new dropdown menu structure
I like the fixed bar at the top 👍🏻
I am more neutral about the left bar. But it is nice with an update 🙂
The improvements of the mobile view are what I am most looking forward to.
A couple of notes, which you probably already have spotted:
- The "plus" button (to add feeds) leads to a dead link
- With the option "auto mark as read during scroll", the vertical cut before which articles should be marked as read should be adjusted a bit (at the moment, it is about ~2 articles off).
A couple of notes, which you probably already have spotted:
* The "plus" button (to add feeds) leads to a dead link
✅
* With the option "auto mark as read during scroll", the vertical cut before which articles should be marked as read should be adjusted a bit (at the moment, it is about ~2 articles off).
at the moment in this PR: wide screen: 2 articles off mobile screen: 4 articles off
Current state: Origine and Origine compact theme should work fine. A great base to test this PR
Testing and feedback are very warm welcome before I start to work on the themes
@Frenzie @Alkarex @aledeg
That looks very polished overall.
The login page doesn't look finished yet all off to the left (not to mention cut off), but it has a checkmark? :-)
On the smaller/mobile view the touch targets for the top buttons seem to be significantly smaller than they used to be and they always stay visible (fixed). The latter might explain the former, but wasting the space while being really tiny targets is not my favorite. Perhaps the scrolling behavior is intended to be a setting?
As an aside, on my phone it does this. I think you'd probably want to set display: flex on #nav_menu, similarly to .nav-header, and group those final three together. Not visually but for next line purposes. (I.e., just another <div> around it so they're one for flex purposes.)
That looks very polished overall.
Thanks for your feedback. I appreciate it very much.
The login page doesn't look finished yet all off to the left (not to mention cut off), but it has a checkmark? :-)
Thanks for finding this issue. It is now fixed. And yes, there was already a checkmark in the login form ;)
On the smaller/mobile view the touch targets for the top buttons seem to be significantly smaller than they used to be and they always stay visible (fixed). The latter might explain the former, but wasting the space while being really tiny targets is not my favorite. Perhaps the scrolling behavior is intended to be a setting?
Smaller than current?
As an aside, on my phone it does this. I think you'd probably want to set
display: flexon#nav_menu, similarly to.nav-header, and group those final three together. Not visually but for next line purposes. (I.e., just another<div>around it so they're one for flex purposes.)
That is a great idea. I will try it
Smaller than current?
Yes, it's definitely smaller. I can post some screenshots tomorrow if you like but I think it's also easy enough to see on desktop side by side. They're a decent enough size for desktop use though; it's with fingers that it's small. ;-)
The buttons in the nav menu are improved now. Please check if it is good enough now
Quick test on my side, with only minor details so far:
- When you open the user labels menu of an article, and close this menu again, then scrolling down with arrow key does not work anymore
- The scroll as read still seems to have a little wrong offset
- The search field shows truncated text, e.g. in French (the i18n could be shortened, instead of enlarging the field)
Something else: I think I would rather remove the help button (and put its content for instance in the settings menu), because there is so little there, rarely used, and it appears a bit too prominent
@Alkarex Would this be a good solution?
I think, that the help button could be a great piece for onboarding new users. Experienced users could disable the buttons.
When you open the user labels menu of an article, and close this menu again, then scrolling down with arrow key does not work anymore
✅ Done
The scroll as read still seems to have a little wrong offset
Which offset do you like? What is your suggestion?
The search field shows truncated text, e.g. in French (the i18n could be shortened, instead of enlarging the field)
✅ Done
Which offset do you like? What is your suggestion?
This is for the mark as read during scroll. We need to make sure that articles are marked as read as they disappear from the view.
Most themes are updated now. It is a great time to have a look again on this PR. Check it out and give me feedback please.
Note about the release process: as it is a relatively big change for users, I suggest that we release FreshRSS 1.24 in the coming days, and then merge this PR in edge so we get longer time for feedback. Ok? I will re-check this PR shortly :-)
Note about the release process: as it is a relatively big change for users, I suggest that we release FreshRSS 1.24 in the coming days, and then merge this PR in edge so we get longer time for feedback. Ok? I will re-check this PR shortly :-)
yes, please. I was not aware of this quick release.
I was not aware of this quick release.
It was also not really planned, but mostly to accommodate this PR, which I would rather merge at the start of a new edge version
P.S. Sorry for the conflicts... I believe most are due to the changes made in https://github.com/FreshRSS/FreshRSS/pull/6052 so you can see the changes there if needed
Which offset do you like? What is your suggestion?
This is for the mark as read during scroll. We need to make sure that articles are marked as read as they disappear from the view.
✅fixed for "normal" screen and "mobile" screens. @Alkarex Please check it. Does it have a good offset or is it to tight? Current: if the article disappear behind the menu then it will be marked as read immediately (0 pixel offset).
Does it have a good offset
I think the offset is fine, now 👍🏻
Here are three regressions from some quick tests:
-
Keyboard navigation: when landing on FreshRSS homepage without doing anything, I used to be able to click on the keyboard ↓ (down arrow) to scroll down the articles. That does not seem to work anymore in the current PR, as it first requires clicking somewhere in the article section for the scroll to work.
-
Closing user labels: in this PR, closing the drop-down menu requires clicking again precisely on the menu link, instead of being able to click anywhere
-
Loading: The current layout has its "flush" optimised so that the loading period has a proper UI:
But with this PR, the equivalent is blank:
- Loading: The current layout has its "flush" optimised so that the loading period has a proper UI:
But with this PR, the equivalent is blank:
Strange. I did not change anything regarding the flush or can you find where I broke it? ob_flush(); is untouched by this changes I guess.
How can I reproduce it?
The complexity with the flush is that it depends on some buffering / size of content, at more than one place in the pipeline all the way to the screen of the user.
You can reproduce it by adding a sleep(10); for instance around:
https://github.com/FreshRSS/FreshRSS/blob/01eaaed9bb2268bc1d0509ca4f33d4b075634c9a/app/Controllers/indexController.php#L77
Here are three regressions from some quick tests:
Keyboard navigation: when landing on FreshRSS homepage without doing anything, I used to be able to click on the keyboard ↓ (down arrow) to scroll down the articles. That does not seem to work anymore in the current PR, as it first requires clicking somewhere in the article section for the scroll to work.
Closing user labels: in this PR, closing the drop-down menu requires clicking again precisely on the menu link, instead of being able to click anywhere
@Alkarex This feedback was very valuable. It gave me the kick to finde a better solution as display:grid for the main layout. Now a lot of issues and workarounds are fixed (hopefully). The handling should be as it was before :) Please check it.
I would like to have feedback from you @Alkarex and @Frenzie
Feel free to ping me again in a few days if I forget; it's a bit too late now. :-)
I am giving it a try
-
[ ] Mark as read during scroll does not seem to work in mobile view
-
[ ] In mobile view, buttons become too narrow, despite the fact that there is a lot of remaining margin available
-
[x] When opening the user labels drop-down menu, the interface moves a bit up and down
In mobile view, buttons become too narrow, despite the fact that there is a lot of remaining margin available
The buttons have the same size like the buttons below in normal view (filter buttons). It is not simple to have the best size for a responsive window. Could you check it on your mobile phone with its screen resolution?


