Let me mark it on your map.
7 posts • joined 18 Jul 2018
The post text will now wrap around the comment-icon image on the right which means the post content will stretch to 'fullwidth' beneath the image.
Along with that we've also done a few margins and sizes tweaks to make better usage of the horizontal space for Forum posts, this then means you'll be able to see more of a Forum post content in a viewport (specially in the case of mobile) than you used to.
Agreed, the 'Top Stories' unit has now a more compact look to it, we've dropped the top image for smaller devices and reduced font-sizes and margins, the result being you should now see in the vast majority of mobile devices, at least, the headline for the first Top Story without the need for scrolling.
On a technical note, we're looking into optimising that image markup, as right now we're simply hiding it with CSS 'display:none' which doesn't prevent the browser from loading the image.
But wheels are being spun and whips are being lashed to deliver a solution where the image is not loaded at all for those devices where it's not meant to be shown.
We have a few other changes in mind to "clear up" some space to fit actual article content into those mobile devices as well which we'll be addressing through the course of the week.
Thank you for the feedback so far.
The new homepage "loading" behaviour follows a mobile-first approach.
A particular concern was how the new behaviour would affect users bandwidth and overall page loading time. If ALL the images are loaded in the raw HTML we are:
a) slowing the page load;
b) forcing users to download images that they may never see (specially for the articles further down the page), or in the case of mobile devices matching certain breakpoints, they would load an image that we would later HIDE in the CSS as don't want the image to show on those small devices this then means the image would be loaded as it was part of the document but would be entirely useless to the user.
To avoid this wastage of bandwidth (and avoid the slow page load) we opted for a lazy-load solution via JS, where images are not requested UNTIL the time a user has "shown intent" of seeing them, this is done via a JS function which determines said intent based on the users scrolling behaviour, the parameters for WHEN to trigger a given row articles image request are something we're still fiddling with.
This lazy-load technique means that the raw HTML can not contain the article images as doing so would defeat the purpose of the lazy-load enhancement (and bandwidth saver) and as a result users with JS disabled get no images on the majority of the articles.
If the page scroll is stuttering for you, my guess is that you're scrolling "too fast" OR experiencing poor network conditions. If you can provide us with your device details, we'll try to replicate the stuttering.
Thanks for the feedback so far.
The 'MOST READ' unit style has been updated and it should be easier to understand its delimitation and which articles it agglomerates.
Other raised concerns in this comment section are being considered internally and we'll be addressing the identified issues.
Biting the hand that feeds IT © 1998–2020