Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Startpage redesign into 2 columns #266

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

eLtMosen
Copy link
Member

@eLtMosen eLtMosen commented Mar 5, 2023

While trying to update the 2x2 screenshots in light of 2.0 release i became aware of several issues:

  • The 2x2 images are much too tall for the few text and result in very large margins between the paragraphs in any viewport width
  • The images do not have any direct context to the headlines/paragraphs they are placed next to.
  • The images wrap unfortunate into huge 4x2 clusters in mobile view
  • The text is hard to read since its text flow is very wide.

This PR

  • Introduces a 2 column order for the 4 paragraphs, min-height of the about-text divs adjusted to current text length so that the titles line up horizontally and vertically.
  • Remove old screenshots.

Pushing this as a draft for now. This PR misses a replacement for the screenshots. Which is highly desirable to keep the informative function of those screenshots.
It is planned to add an automatic slide show in size of one screenshot. Where many screenshots get slid-in from the side (to imitate or hint at our UI gesture possibly) or fade-over in place in fashion of a carousel.

Desktop (max content width is capped at 990px)
grafik

Tablet:
grafik

Phone
grafik

@eLtMosen eLtMosen marked this pull request as draft March 5, 2023 23:30
@eLtMosen eLtMosen changed the title Startpage redesgin into 2 columns Startpage redesign into 2 columns Mar 5, 2023
@FlorentRevest
Copy link
Member

This is very cool, thanks! :D

Regarding the carousel, it seems like the location of the current 5 watches would be an ideal fit for a carousel (and they could/should be part of the carousel)

@FlorentRevest
Copy link
Member

Regarding your point on Matrix on the "Proven building block" paragraph being too technical, maybe we should move it to be the last paragraph?

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 6, 2023

Regarding your point on Matrix on the "Proven building block" paragraph being too technical, maybe we should move it to be the last paragraph?

Done! Good idea.

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 6, 2023

This is very cool, thanks! :D

Regarding the carousel, it seems like the location of the current 5 watches would be an ideal fit for a carousel (and they could/should be part of the carousel)

yeah, sometimes things come together like puzzle pieces. I'll try to implement that. Sounds not much harder than slice the banner into 5 watches (we could only show 3 for mobile then) and playing a slide show above each individual watch.
Famous last words

@FlorentRevest
Copy link
Member

Sounds not much harder than slice the banner into 5 watches (we could only show 3 for mobile then) and playing a slide show above each individual watch. Famous last words

This sounds like a rabbit hole (changing the content of the watches in web ?). Maybe an easier approach could be to just have a bunch of static images of watches with pre-integrated screenshots and cycle through these instead ?

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 6, 2023

That sounds a bit easier. But than we could only have fade-in/over transitions. My goal was to have a masked area for the screens and then slide images to the left or right. To hint at out UI gestures :P
But always good to have an acceptable fall back when i get stuck in the rabbit hole.

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 7, 2023

startpage-slider-2023-03-08_00.48.58.mp4

@FlorentRevest
Copy link
Member

I find it a bit too fast now, I feel that with a little bit more time it would get a bit less overwhelming to the user.

nit: Our screenshots have a black ring leftover from the asteroid-launcher CircleMaskShader https://github.com/AsteroidOS/asteroid-launcher/blob/master/qml/compositor/compositor.qml#L258 on a nice it smooths out the borders of the screen (kinda like an antialiasing) but on screenshots this creates an undesirable artifact. I wonder if there's something simple we could do about this like post-processing screenshots by reducing their circle a tiny bit ?

Now that we are no longer using the nice top picture you had done, I feel it would be good to have screenshots for AoD (the one you had selected was perfect for this) and I feel that the screenshot of the homepage should be the default style, with the watchface that comes in stock.

One thing that's unclear to me (I should test it but it's getting late and I won't get to it tonight) is when the slideshow stops. eg: on your video, on a small screen, it stops at the Music app and one never gets to see the weather app.

Also the "extreme" apps (far right and left) like timer or agenda here are only visible for such a short amount of time that it makes it very hard to see them. I think the carousel should wait a bit longer when getting to an edge.

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 8, 2023

Yepp, Agreed. I should have stated what is to evaluate in this state of the draft :P
The screenshots are "just" place holders where i was happy enough to get shots of all apps at all. I was sure planning to and will mix some AoD and WF shots among them.
But as elaborated on matrix. The order is what gives relevance to the screenshots. Since on mobile, not all of them will even be shown. (Edit, this is outdated since i found out how to achive equal scroll length. Action plan in next comment)
So imo it is about

  • find ~10-12 screenshots that really matter and put them in positions "everyone" sees.
  • But still add like 5 more to have 20 to prevent wide high res screens to show a boring snake of all images.
    I can adapt the speed to different viewport sizes. (Edit, action plan outlined in next comment)
    Also it might be worth a try to make the slides smaller on mobile. So not only 2 of them are shown at a time. (Edit, commited and next comment bases on that)

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 8, 2023

Ok, this has gotten 4x more complicated due to the 4 sensible viewport sizes we (and everyone else in the industry) uses to switch between

  • => than 1200 px width (usual to large desktop)
  • < 990px (shrunk desktop/large tablet)
  • < 768px (tablet/phablet)
  • < 520px (phone)

My hardcoded pure css implementation now needs to have those four cases in each class. And manually adaptively set (smaller) values as the screen gets smaller. I might at some point be able to refactor the whole code to "group" the four @media
viewports and move the classes into those. But not sure if that would make the code any better. and having 4 @media per class somehow makes it easier to develop currently.
I have now achived a state where:

  • the phone view does display more than one full screenshot, the next one was already cut at 220px size. Lowered to 195px and made the overlap larger. By making the slide size smaller. The rewind happens at shot number 12
  • the tablet view is scrolling up to the 13th (weather) icon here it rewinded at ~9 before. Also due to making the images smaller too 210px with 180px slide with, Resulting in 30px overlap. Larger overlap than in desktop view to fit more screenshots into the slide duration.
  • Same for <990px, with 215px images, 195px slides = 20px overlap of the images. This viewport width rewinds at shot number 14 now.
  • The < 1200 is equal to >= 1200 currently. But we will want to differentiate there too in next step. Currently The <1200px width reveals all 15 screenshots and is what i firstly built the non responsive proof of concept for. For very large screens, the 15 images are not enough currently and all are seen always, just scrolling.
  • Free your wrist slogan has adaptive margin to top per VP from the absolute-space class

Now, what is not adapted to the 4 viewports yet

  • In All VP sizes, just one screenshot should scroll at a time (adapted to slide size).
  • is the duration of the animation. Which has influence on the "end point" of the animation and might be a value to adapt to the 4 sizes to regulate equal amount of screenshots shown until rewind.
  • And most importantly, the "Curve" you mentioned that influences which screenshot at which position is shown how long.

This curve is defined by actions at percentage values over the runtime of the animation. And by the width the aformationed action "pushes" the slides to the left.
To have all vp sizes only scroll one shot at a time, this needs to be adapted.

To not spend hours testing stuff back and forth, we would no need to agree on the amount of screenshots. Because most of the things depend on that. On that is done, i can adapt all viewport sizes to scroll to the correct length. And adapt the curves to behave the same.
This is how the curve is generated in the current state, Same for all VPs.

@-webkit-keyframes slide {
  10% {margin-left: -0px;}
  20% {margin-left: -200px;}
  30% {margin-left: -400px;}
  40% {margin-left: -600px;}
  50% {margin-left: -800px;}
  60% {margin-left: -1000px;}
  70% {margin-left: -1200px;}
  80% {margin-left: -1400px;}
  90% {margin-left: -1600px;}
}

Mind that the negative margin-left on all slides is what slides/pulls the whole cue of floating screenshots to the left. Out of view.
This needs adaption per VP to have one shot per scroll.
The percentages define the curve of how long to "sit" at which position in the animation.

This is how the above mentioned implementations look currently when quenching a browser window:

  • Are we ok with the size differnces per VP?
startpage-slider-2023-03-08_15.11.16.mp4

@eLtMosen
Copy link
Member Author

eLtMosen commented Mar 8, 2023

I find it a bit too fast now, I feel that with a little bit more time it would get a bit less overwhelming to the user.

Will be adressed in next commit, after having added 5 more shots. For a total of 20.

nit: Our screenshots have a black ring leftover from the asteroid-launcher CircleMaskShader https://github.com/AsteroidOS/asteroid-launcher/blob/master/qml/compositor/compositor.qml#L258 on a nice it smooths out the borders of the screen (kinda like an antialiasing) but on screenshots this creates an undesirable artifact. I wonder if there's something simple we could do about this like post-processing screenshots by reducing their circle a tiny bit ?

Jupp, agreed. Will cut one or two pixels more narrow. The originals i took are 400px from catfish. So i got lots of margin for that.

Now that we are no longer using the nice top picture you had done, I feel it would be good to have screenshots for AoD (the one you had selected was perfect for this) and I feel that the screenshot of the homepage should be the default style, with the watchface that comes in stock.

Absolutely! The upside now is that we got the rainbow complete :P But i agree, a more informative order with black AoDs and such mixed is to be prefered. How about removing the Alarm Clock. its not really pretty still imo

One thing that's unclear to me (I should test it but it's getting late and I won't get to it tonight) is when the slideshow stops. eg: on your video, on a small screen, it stops at the Music app and one never gets to see the weather app.

That is mitigated in last comment/commit. where the shot/slide sizes are a bit adapted to viewport size. I would not a make them any smaller or give more overlap than now. Next step to achive uniform behaviour over all viewport sizes is to agree on amount of shots, max duration of the animation (=not to slow on large VP but not too fast on small VP. Since Duration will be adaptive to help show all shots on much narrower screen) and the "Curve".

Also the "extreme" apps (far right and left) like timer or agenda here are only visible for such a short amount of time that it makes it very hard to see them. I think the carousel should wait a bit longer when getting to an edge.

Yepp, needs decision on how it should look on one VP, then unifiy that behaviour over all VPs. As described in explaining what produces that "curve" in last comment.

@eLtMosen
Copy link
Member Author

eLtMosen commented Apr 7, 2023

After polishing the slideshow according to above discussion

  • Added more screenshots to make up 25 in all
  • Adapt scroll length to different screen width and harmonize speed
  • Add shadow below the screenshots

This is how it behave now

start-page-2023-04-07_20.46.20.mp4

@eLtMosen eLtMosen marked this pull request as ready for review April 7, 2023 18:51
- Remove invisible shadow
- Remove screenshots and add about-container class div to wrap the paragraph divs
- Add two column layout and adaptively set about-text min-height
- Sort Proven building blocks paragraph to last position

Signed-off-by: Timo Könnecke [email protected]
- Add 24 screenshots
- Add Slideshow CSS components
- Remove banner and add slideshow to index.md
- Adapt screenshot sizes to 4 viewport sizes
- Unify length and speed of slideshow over all viewport width
- Add shadow to screenshots

Signed-off-by: Timo Könnecke [email protected]
@MagneFire
Copy link
Member

@FlorentRevest @eLtMosen Given that the carousel is still under discussion, would it make sense to split this PR into one for the carousel and one for the 2 columns? Especially since the 2 columns seems to be agreed upon?

@FlorentRevest
Copy link
Member

Oh I'm sorry I dropped the ball on this one! 😔 it completely slipped my mind.

Among the comments I would have left for the carousel would be that we never get to see the rightmost images unfortunately, and that I would prefer if when the carousel hits the rightmost images, it would stop there for a second and then jump back to the beginning rather than slowly circle in the opposite direction

With that being said, this is bike-shedding and it's been going on for too long, so if you guys disagree, feel free to just go ahead and merge it anyway. If it ends up bothering me way too much, I'll figure something out ahah.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants