iiab / iiab

Internet-in-a-Box - Build your own LIBRARY OF ALEXANDRIA with a Raspberry Pi !
https://internet-in-a-box.org
GNU General Public License v2.0
964 stars 75 forks source link

Front-End Redesign of IIAB home page (http://box) menus/customizability [iiab-menu.js etc] #1112

Open arky opened 6 years ago

arky commented 6 years ago

iiab-menu.js file(s) need complete overhauling. The JavaScript file does browser detection and makes font adjustments, these are now handled by Bootstrap 4.

@darkenvy Can you please help with this?

https://github.com/iiab/iiab-menu/blob/master/menu-files/js/iiab-menu.js#L59-L63

Refer: https://github.com/iiab/iiab/issues/1031

tim-moody commented 6 years ago

make sure community is OK with reduced browser support of bootstrap 4

holta commented 6 years ago

Related:

https://github.com/iiab/iiab-menu/issues/9 "Redevelopment Plans"

holta commented 6 years ago

This tkt (#1112) and #1031 and #1159 and iiab/iiab-menu#9 overlap a lot, so let's soon close those that are not actionable~

Let's nurture next-gen-realism design choices around the thoughts that've begun here iiab/iiab-menu#9

holta commented 6 years ago

I've closed #1159. Feel free to close further tkts so we can consolidate the best front-end UX ideas (Bootstrap 4 and/or others) around discussion (like) iiab/iiab-menu#9

Context: IIAB's existing home page (http://box) places Content Packs a.k.a. modules according to this JavaScript logic: https://github.com/iiab/iiab-menu/tree/master/menu-files/js

tim-moody commented 6 years ago

The problem is that bootstrap, even 4, does not scale fonts very well, so I wrote some js. BUT, I think this can be used instead (magic numbers 26 and 14 could still be adjusted).

:root { --base-font-size: calc(14px + (26 - 14) ((100vw - 300px) / (1600 - 300))); --base-line-height: calc(1.3em + (1.5 - 1.2) ((100vw - 300px)/(1600 - 300))); } body {
font-size: var(--base-font-size); }

h1 { font-size: calc(1.2 * var(--base-font-size)); }

tim-moody commented 6 years ago

Now I'm not sure even this is necessary.

holta commented 6 years ago

@tim-moody explained during todays's community/team call (http://minutes.iiab.io) how browsers can store local state that is private and protected from web servers (unlike web cookies!) in order to store personal preferences (like IIAB language/page verbosity) in the client:

function setLocalStore() {
    if (selectedLangs.length > 0)
      localStorage.setItem("selected_langs", selectedLangs.toLocaleString());
    else
        localStorage.setItem("selected_langs", "");
}

It seems this local storage / local state could even be used by a student's smartphone walking by different IIAB web servers, e.g. if a school has many different IIAB's in different classrooms?

The way this works is that client machines (i.e. most all browsers) can indeed store such key-value pairs (language and font/layout/verbosity preferences etc) while the browser "fully protects" these preferences within each browser. Such that web servers (apparently!) can never get access to these personal/linguistic/verbosity/layout preferences.

psiie commented 6 years ago

Why not scratch all the css calculation stuff and instead use media-queries? Web browsers are always dealing in 72dpi despite screen dpi of the device. Therefore a 3" (horizontal width) device is hardly different than a 3.2", 3.6", 4" device. eg: the media-query groupings are quiet well defined:

` / Smartphones (portrait) ----------- / @media (max-width : 320px) { / Styles / }

/ phablets, small tablets / @media (min-width : 321px) and (max-width: 767px) { / Styles / }

/ iPads (portrait and landscape) ----------- / @media (min-width : 768px) and (max-width : 1024px) { / Styles / }

/ Desktops and laptops ----------- / @media (min-width : 1024px) { / Styles / } `

All phones should fit under that 320px category. Large font it up! Desktop would be normal and the others would be interpolated.