distrochooser / distrochooser

An orientation guide for Linux newbies
https://distrochooser.de
GNU Affero General Public License v3.0
725 stars 57 forks source link

Improve UX on mobile devices #143

Open cmllr opened 2 years ago

cmllr commented 2 years ago

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

ghost commented 2 years ago

Hi cmllr!

I have an idea to help: What if there was no sidebar? As here:

image

?

Would it be possible to do something like this?

image

RokeJulianLockhart commented 2 years ago

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.

ghost commented 2 years ago

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.

cmllr commented 2 years ago

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.

RokeJulianLockhart commented 2 years ago

@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:

https://user-images.githubusercontent.com/42837531/187422661-9594862d-bce4-47d4-8bbb-4cf40f73fe42.mp4

https://user-images.githubusercontent.com/42837531/187422674-90f8dee4-553a-44e7-8084-009980eb4ab8.mp4

Consequently, I believe that we should consider different placement of what invokes the menu rather than solely how the menu is presented.

ghost commented 2 years ago

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:

  1. We can make a script to check the screen size with screen-size-detector-js or vue-screen-size or vanilla-js.
  2. With this we can direct an address or mobile link to the entire cell phone, link here: demo: OnsenUI-Todo-App and source-code here: OnsenUI-Todo-App.
  3. For example, "http://distrochooser.github.io/" for desktop and "http://distrochooser.github.io/mobile" for mobile: ios/android.

4. Screenshoot

4. 1 Screenshot

image

4.2 Screenshot

image

ghost commented 1 year ago

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>
cmllr commented 1 year ago

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.

ghost commented 1 year ago

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?

cmllr commented 1 year ago

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.

ghost commented 1 year ago

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:

  1. The use of some css framework may not be adopted because the site has its own style.
  2. Things like Screen Size Detector don't make sense because it's against user privacy.
  3. A mobile version like react-native or vue-native or onsen-ui doesn't make sense either because it should be the same code for the website.
  4. The distrochooser website style is not mobile responsive. There would then have to be a distrochooser update on a mobile device. But if there is a greater amount of access on desktop than on mobile device, solving this problem may not make sense for the scope of the project.

My questions are:

ghost commented 1 year ago

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
image image

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.

ghost commented 1 year ago

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;
  }
}
RokeJulianLockhart commented 1 year ago

@raphaellouisandress, it should really be dynamic, shouldn't it?