I find it refreshing that a webpage can give such joy, to the point of having people talk about it in the same way you talk about books and movies. You know, being able to enjoy it for the first time and so and so.
Woah, slow down there. One of your requirements to a code editor is video preview?
I didnt even know this existed.
Gonna spin up VSCode at home and find out.
A lot of web "design" is about how it looks rather than how usable it is. At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl". Never mind the text that is at 50% opacity until you scroll to the exact intended point, because nobody actually attempted to read it.
> At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl".
Actually that's exactly what they do. They like the animations while some people, especially devs, do not. But they don't use it multiple times, because they would be able to see how it gets annoying after the first time.
Masonry layout fixes one of the dimensions. That means either portrait or landscape images will look visibly smaller than those of the inverse aspect ratio, because their longer side must be the same length as the latter’s shorter side.
Masonry works well if you have different aspect ratios of the same orientation.
Just curious, what algorithm is good for laying out images of arbitrary orientations, sizes, and aspect ratios? That seems like a pretty difficult problem. Some sort of variation of knapsack problem maybe?
I dont know what would be the best way, but I personally want each image to be represented correctly in relation to all other image. This means that the way images are laid out will looked jagged. However, as a consequence of that, it is easy to find back to a specific image. Its like when you are coding, you look at the "shape" of the code when scrolling to find that specific function definition etc..
Here is an example of the layout of a photostream that I was satisfied with.
The defining feature of masonry is that it supports mixed aspect ratios. That's its whole thing. If you aren't mixing landscape and portrait images, you shouldn't be using masonry layout.
Masonry layout fixes one of the dimensions. That means either portrait or landscape images will look visibly smaller (less detailed, more ignorable, etc) than those of the inverse aspect ratio, because their longer side must be the same length as the latter’s shorter side. This has real UX consequences. What masonry works best with is images of different aspect ratios but the same orientation.
Pointing out that masonry isn't as good with mixed-orientation content as it is with uniform-orientation content is all well and good, but we still need a way to display mixed orientation content. What alternatives to masonry do you propose?
- If you stretch all images into a uniform aspect ratio, they get all squashed and look terrible.
- If you crop all images into a uniform aspect ratio, you lose potentially the majority of the content in some images.
- If you display all images at their natural aspect ratio and their full size, there will be huge swathes of empty space in between them because they don't pack tightly.
Masonry layouts allow you to preserve aspect ratio without wasting a massive portion of your user's screen space. It's not perfect, but it's the best layout mixed-orientation content that I know of.
If you know of a better method to handle mixed orientations, I'd love to hear it and would gladly rescind by remarks.
Danbooru[1] and Danbooru-derived image boards handle this perfectly, and are a genuine pleasure to browse relative to the awful experience that is pinterest. There is empty space between images, and that is fine. You don't need to occupy every pixel in the screen to begin with, that's why we have these magical things called "margins", elements need room to breathe in the first place.
[1]https://safebooru.donmai.us/ (note: this is a "safe" subset of danbooru for reference, but it is still not safe for work)
How is that better? It's still a grid of images that seem to be constrained to a more or less rectangular grid. I'm thinking more of a dynamic grid where there is a mix of sizes of horizontal and vertical images.
The point being raised is that dynamic image grids don't actually make for a good UX. They might look more visually interesting at a superficial glance, but when you're actually using the interface to browse images, predictability wins out. Even having mixed-orientation images, where there is some degree of extra whitespace between images, does not change this. It is way easier to digest the content when your eyes can reliably scan one line at a time without having to bounce around everywhere to track the flow of the dynamic grid.
What is it with commenters in this thread and wanting to "reliably scan one line at a time?" When users use image galleries, they generally do jump around because they're looking at all the options on screen all at once. The eyes absorb everything and then they pinpoint what looks good. I've never seen or heard anyone go line by line in an image gallery or a newspaper layout and doing so I'd find to be highly abnormal to average users.
I suspect if data from eye-tracking tests were available, there would be an extremely clear revealed preference from users. I read image galleries the exact same way I skim text, in an ordered fashion that allows me to "read" every image without reading an image twice, stopping if my attention is caught by something in particular. Splotting garbage over the screen haphazardly makes it blend together annoyingly and results in my eyes traversing the same areas multiple times both to try to pick out details and to try to keep my place in what I have/haven't skimmed yet. It is a layout that itself demands my attention, rather than letting my attention be absorbed naturally by the actual images.
From actual eye tracking data via Hotjar and similar, people do skip around the page. Those that scan linearly are in the minority but probably are more highly represented on HN, just as a matter of course.
Well I think this is a great step forward but it would be great if we could mix aspect ratios even better...
Consider a similar layout to OP but the landscape images will span multiple columns as well as everything it already does.
The thing about masonry is that it adapts to the size of the images. You could already do masonry using flexbox if you know the image sizes (https://github.com/hannasm/masonflexjs). Doing it as a true mosaic layout would be a step above current capabilities. At that point it's probably pretty easy to create configurations that don't fit perfectly/ require lots of empty space to layout nicely though.
With Masonry and using the bin packing algorithm/layout, according to your visual requirements, you can (should?) use a system for sizes for the sizing element and get different widths for the underlying columns of the ‘grid’; ie: if the sizing element is a quarter of base width, you scale down some of the widest image to bring more homogeneity-or on the contrary balance it with some enlarged elements that brings some rythm.
Edit: doc has this first example https://masonry.desandro.com/layout that you could use but have to imagine images to be twice the size, similar to a Müller Brockmann grid
Yeah, even the official Rust book points it out and if my memory serves me right (not punintended) also gives an example in the form of creating a memory leak (not to be confused with memory unsafe).
As "unsafe". An example would be of how AMD GPUs some time ago didn't free a programs' last rendered buffers and you could see the literal last frame in its entirety. Fun stuff.
That is not a memory leak though! That's using/exposing an uninitialized buffer, which can happen even if you allocate and free your allocations correctly. Leaking the buffer would prevent the memory region from being allocated by another application, and would in fact prevent that from happening.
This is also something that Rust does protect against in safe code, by requiring initialization of all memory before use, or using MaybeUninit for buffers that aren't, where reading the buffer or asserting that it has been initialized is an unsafe operation.
It's a security hole. Rust doesn't prevent you from writing unsafe code that reads it. The bug wasn't that it could be read by a well conforming language, it was that it was handed off uninitialized to use space at all.
I remember modding my Xbox and putting XBMC on it.
One of my fondest memories is actually playing games directly off the hard-drive.
One of the great "side-effects" of that was basically cutting loading times almost in half.
I especially remember the loading animation in the game Crash Bandicoot - Wrath of Cortex. Crash Bandicoot himself would keep falling during the loading screen. (note: PS2 version had another looking version).
The game loading screen for Xbox was designed so that the camera movement nicely panned throughout it during the time the loading took, but due to the loading time being shorter the "animation" was cut short.
..just a fun little thing that stuck with me. :)
EDIT: Oh! I found videos on youtube demonstrating the "difference".
The original cc was just a wrapper like this Python example around a bunch of external programs, calling c00, c01, until something could be fed to as and then linked using ld.
reply