In the process of making a Merge Request for the F-Droid website related to the language selector, and/or menu.
Do people want me to:
- include the full menu in the top corner with the language selector, or
- just change the language selector, where it currently is on the live site, for now.
I say “for now” because the landing page update that I’ll be doing will works with the language selector as presented in option 1. Therefore it would be easier, more future-proof and bring more functionalty to the end user of the website, for me to make a Merge Request of option 1.
It might even help to guide the Landing page update if people come forward to offer improvements based on the an early adoption.
So I put the question forward. I’ve actually already pushed the branch for option 1 and so all I’d need to do is create the Merge Request, but if people feel strongly about option 2 then I’ll do that.
Thanks and I look forward to knowing what people want.
PS. Please ignore the charcoal colour of the menu… its the color of the text. In the [2020 landing page update] that I’ve been doing the text colour and thus the menu colour will be the dark blue that people seemed to like.
(As an aside I’d like to briefly also use this opportunity, as an Australian, to thank my fellow Australian, Julian Assange for all the crimes against humanity that he exposed, all around the world including crimes in China and Russia and by corrupt Australian bankers. I wish him safety from the torturous conditions as described by the UN Rapporteur on Torture Nil Meltzer and that this extradition trial is thrown out immediately and freedom can finally be enjoyed by the renowned journalist and publisher.)
For those who might be interested (@Licaon_Kter), I’ve created the merge request:
If there are no comments, suggestions, objections I’ll move on to producing the landing page itself.
Mmh, I find the blending in of the button with the expanded menu unfortunate. The button changes from no highlight to light gray highlight when hovered over to very dark grey highlight when clicked and still hovered over, where it’s still a separate thing from the menu and then when you move the mouse the color changes to the menu backrgound color and the two things merge… and my brain is confused at what happened to the button…
What’s with me? I didn’t follow the website discussion at all… so I’m fairly uninvolved here.
Thanks @Bubu and @Licaon_Kter for your feedback.
The secondary-level menu close button (shown below) needed to have a shadow on the button because I felt that, being in a less conventional (side) position it needed to have greater emphasis on it.
The primary-level menu close button is in a more traditional top position so I felt it didn’t need it. On the mobile devices especially we cannot use any technique that brings out the outline of the button or we run into a margin problem where the design would appear cramped (I reduced the top-margin on tablet and smaller devices)
What I could do is on large screens have a background colour on the button. We would need to choose the colour to use because it can’t be the hover colour, and red will be too strong. Maybe if the hover colour is made lighter than it currently is then the button colour can be the current hover colour? On tablet and smaller displays I’d use a media query to preserve the clean look due to the smaller margin (on smaller devices of course we don’t have the mouseover colour to worry about either).
Tell me if you’d prefer the above done.
Btw I’ve just pushed a commit related to the Donate link buttons to the branch. So those links can be un-commented in header.html the moment they are needed.
EDIT: PS. Please ignore the first two commits, they are supposed to be on my master branch, I can redo the branch if needed.
How do I continue to push to gitlab without automatically triggering a new site build at gitlab.io and breaking the ability for Contributors to test this Merge Request?
Thanks @uniqx for your assessment!
Yes agree, I need to rebase. I’m trying to work out how I can continue to push changes to origin without breaking the staging site, either temporarily or permanently (ie. moving on to developing and pushing other branches while a merge request is being assessed).
Renaming [‘Browse’ menu item to ‘Apps’] has nothing to do with a language selection (…)
I should have been more explicit in my commit and Merge Request messages. The aim here was to have a holistic overhaul of navigation so it might be ready for the landing page update. This means people won’t get an extreme shock when the landing page changes.
The impression I had was Contributors were happy with the rename I put forward very early in the Landing Page design process. When I mentioned the renaming noone complained and I think I even got positive responses.
Remember @redplanet’s friend, who helped with a Communication Strategy early in the design process, got a tonne of positivity.
If people want to keep the “Browse” button for now (or debate it), maybe now is another time to do that. I’m not in rush myself to have this go through. The only thing that’s holding me back is I’ll break the staging site when I push other branches.
I’ll be happy to change it back to ‘Browse’ but I think it will just cause more setbacks.
I’ve “subsumed” those first two commits of that branch into my master branch (as promised) so they wouldn’t be included in the MR. Unfortunately, this seems to have reverted the staging site to another branch despite the fact that I re-pushed the ‘langSelect-includesMenu’ branch as the last thing I did.
EDIT: It seems that the MR commits section has not responded to the branch changes that I made either. The two commits at the bottom of the page should no longer be there.
The staging site is running again because a minor bugfix was pushed to the branch.
There doesn’t seem an option to remove those first two commits that don’t belong there, @uniqx, but I bet I’m just not seeing it.
I tried making a new MR just now because the old one has two commits that should not be there.
Unfortunately those commits (that are now in my master branch [see 12 Feb and 24 Feb commit] are still appearing in the list of commits that will go into the MR:
To move forward on this occasion, maybe cherry-picks are a possibility? If there’s any such issues in future I’ll contact the gitlab forums.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.