Open cmllr opened 2 years ago
Hi cmllr!
?
None of this appears to be necessary anymore; my smartphone appears to be able to access the website perfectly, albeit unable to observe the textual labels of each item of the lefthand sidebar.
Hi BEEDELLROKEJULIANLOCKHART!
None of this appears to be necessary anymore; my smartphone appears to be able to access the website perfectly, albeit unable to observe the textual labels of each item of the lefthand sidebar.
thank you for feedback. I was wondering if I could hide the sidebar. But with your feedback, I don't think that would be a good idea anymore.
None of this appears to be necessary anymore; my smartphone appears to be able to access the website perfectly, albeit unable to observe the textual labels of each item of the lefthand sidebar.
Just for completeness: I am hiding the labels currently to save some horizontal space.
@codehangen and @cmllr, I agree that the labels of the sidebar should not be permanently hidden. Rather, the menu should automatically hide as is necessary by default, but remain able to be invoked.
However, I've actually a superior solution. Google has recently begun to transition away from left-invoked menus to vertically-invoked menus. The difference is that this provides superior adaptability, because less horizontal space is utilized:
Consequently, I believe that we should consider different placement of what invokes the menu rather than solely how the menu is presented.
Hi cmllr BEEDELLROKEJULIANLOCKHART! how are you all?
@codehangen and @cmllr, I agree that the labels of the sidebar should not be permanently hidden. Rather, the menu should automatically hide as is necessary by default, but remain able to be invoked. However, I've actually a superior solution. Google has recently begun to transition away from left-invoked menus to vertically-invoked menus. The difference is that this provides superior adaptability, because less horizontal space is utilized:
I think I found the ideal solution to solve this problem:
Hi everyone.
In my opinion we can do something easy, add a screen redirector.
<script src="https://unpkg.com/screen-size-detector@latest/dist/screen-size-detector.min.js"></script>
<script>
const screen = new ScreenSizeDetector(); // Default options
console.log(screen.width); // Then use screen anywhere in your project
</script>
The UX of distrochooser requires major overhaul. The current version does not use any CSS frameworks, so breakpoints need to be implemented by hand. I think before significantly improving the UX, the whole CSS needs to be properly reworked. This will delay the correction for this issue quite I lot, I am afraid.
The UX of distrochooser requires major overhaul. The current version does not use any CSS frameworks, so breakpoints need to be implemented by hand. I think before significantly improving the UX, the whole CSS needs to be properly reworked. This will delay the correction for this issue quite I lot, I am afraid.
Wouldn't it be better to create a mobile version with react-native or vuejs-native just for this purpose?
The UX of distrochooser requires major overhaul. The current version does not use any CSS frameworks, so breakpoints need to be implemented by hand. I think before significantly improving the UX, the whole CSS needs to be properly reworked. This will delay the correction for this issue quite I lot, I am afraid.
Wouldn't it be better to create a mobile version with react-native or vuejs-native just for this purpose?
I don't think so. The web version should still be based on the same code.
Wouldn't it be better to create a mobile version with react-native or vuejs-native just for this purpose?
You don't need react-native or vue-native or onsen-ui or ScreenSizeDetector, an alternative for that would be to adopt some css framework. A good part of some css framework like: bootstrap, bulma etc works both on mobile and desktop. But I must warn you all that this is just a suggestion that should be considered by everyone here.
I don't think so. The web version should still be based on the same code.
There are several types of css frameworks that work on mobile and desktop: boostrap, bulma, unity-css etc. So I wonder if there wouldn't be a need to simply use some visual css framework that works on both desktop and mobile like: bootstrap, bulma etc.
But thinking about it another way, since there is a default style for distrochooser, maybe adopting some css framework like: bootstrap, bulma etc for that doesn't make sense. And maybe because that's not what everyone wants here.
So I don't know how this could be resolved or if it can and should be resolved. For example, if there is a greater amount of website hits on desktop devices such as computers, it would not make sense to think in an website responsive on mobile devices. Another example, Screen Size Detector uses certain device information to tell the screen size. Some users might think this is a data inversion or something.
As we can see, maybe there is no complete or partial solution for the problem reported here. Here we have the paradox of choice:
My questions are:
Hello everyone!
I hope to contribute some ideas to help solve this problem.
How can we resolve this paradox?
So, we can in theory support general or specific screens for desktop and mobile devices. There is an interesting survey that talks about the most common screen types on desktop or mobile. Based on this information, we can have a better distrochooser user experience on desktop and mobile devices.
Please see this: https://gs.statcounter.com/screen-resolution-stats
and this: https://gs.statcounter.com/vendor-market-share/mobile
img 1: screen-resolution-stats | img 2: vendor-market-share/mobile |
---|---|
idea-img-1: the most common screen sizes are:
idea-img-2 We can search for the most common mobile device screens by hardware manufacturer. For example: Apple, Samsung, Xiaomi, Oppo, Vivo, Huawei - by analyzing these brands we can see which is the most used, most common type of screen.
an idea: we can add a css file with the most common screen sizes on mobile devices.
/* set desktop, on screens that are 1920px or less, set the background color to blue */
@media screen and (max-width: 1920) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 1080px or less, set the background color to blue */
@media screen and (max-width: 1080) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 1366px or less, set the background color to blue */
@media screen and (max-width: 1366) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 768px or less, set the background color to blue */
@media screen and (max-width: 768) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 1280px or less, set the background color to blue */
@media screen and (max-width: 1280) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 720px or less, set the background color to blue */
@media screen and (max-width: 720) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 1440x900 or less, set the background color to blue */
@media screen and (max-width: 1440) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 900 or less, set the background color to blue */
@media screen and (max-width: 900) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 1536 or less, set the background color to blue */
@media screen and (max-width: 1536) {
body {
background-color: blue;
}
}
/* set desktop, on screens that are 864 or less, set the background color to blue */
@media screen and (max-width: 864) {
body {
background-color: blue;
}
}
@raphaellouisandress, it should really be dynamic, shouldn't it?
Describe the bug
Improve UX on mobile devices. The welcome text is larger than 100% of the viewport height. Remove need for scrolling.
To Reproduce Steps to reproduce the behavior:
Open on mobile devices
Screenshots https://twitter.com/AliveDevil95/status/1476536322475048964