Startpage redesign into 2 columns

[moWerk]

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)

Tablet:

Phone

[FlorentRevest]

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]

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

[moWerk]

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.

[moWerk]

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]

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 ?

[moWerk]

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.

[moWerk]

https://user-images.githubusercontent.com/15074193/223581801-f2254174-7d9e-4589-8481-1b205065f127.mp4

[FlorentRevest]

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.

[moWerk]

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)

[moWerk]

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?

https://user-images.githubusercontent.com/15074193/223735087-d32865f8-cab2-4bac-b34c-850c9a343e7a.mp4

[moWerk]

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.

[moWerk]

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

https://user-images.githubusercontent.com/15074193/230661855-18dd81fa-8890-4abe-9e53-3bd5d73799e9.mp4

[MagneFire]

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

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.