We experimented with a bunch of masonry-style layouts while designing our new feed, and I shared some of our iterations in the blog post.

tl;dr: (we observed that) grid layouts where each block looked exactly the same were easy to scan but not engaging; when we added visual interest by varying the sizes, readability suffered. So we settled on something where cards have different sizes, but titles still line up.

We didn't do any fancy eye tracking tests, so I wonder if our personal anecdotes about some options being more "comfortable" and "interesting" than others have any foundation. What's your opinion, any observations that you could share?

Do Masonry layouts work well for text? Short answer: No. They work best for visual/photographic content with content of arbitrary sizes.

Digg.com actually uses a sorta masonry-type layout at the moment, but we're moving on from that in the next iteration. With 6 weeks to design and build the site and an iPhone app, we optimized for unpredictability.

Without knowing the quality and dimensions of images, story metadata, number of tweets attached to each story, etc. we created for a layout that would with work for all arbitrary combinations of elements for each story.

Depends on what kind of text. I think that Bygone Bureau does a great job of text-only content with a Masonry layout bygonebureau.com I works because the text in each item is fairly light, and it all fits in one fold. Your eye can parse the collection into columns, and then scan top-to-bottom across items, then left-to-right across columns.

That's interesting to hear, Justin! I was especially interested in your point of view. All the blocks in digg's homepage seem to have an image, so I wasn't quite sure if I could lump it as "textual content". Did you guys have images in each block when you launched, or did you decide to add an image to each later on?

@gem_ray We did not have images on every story at launch. Some stories had no tweets attached, some had up to three. Now, 6 weeks in, the content we have for each story is more predictable, so we are able to move to a regular grid layout.

@Dave: My personal experience with layouts that fit the fold is that I'm usually too impatient to sit and read everything and not scroll, infinite scroll works better with my ADHD :)

Offset grids are great for making super visual content easy to parse. The uneven gutters between images with different heights move your eye through the page.

With images, this active movement makes images more interesting. However, we read text and image differently. Pictures are easy to understand right away and have only one focal point. Text must be read directionally and having an additional strong flow formed by the gutters makes it difficult to keep your eyes going in the right direction.

I'm not a fan of masonry grids for text or visual content. They can serve as a visual table of contents, and sometimes that is useful. But overall there is a tendency for designer's to want to put everything in front of the user's face and leave them the job of parsing for relevant stuff. There is a fear that some information will be missed.

Print design has dealt with this through the page metaphor, pacing out content and using varying rhythm and interesting variations in the grid. Rather than ask the user to digest 30 blocks of content all at once, scrolling can give them a nice and easy rhythm to follow content and digest it a few pieces at a time.

I am all for experimenting with new ways to bring pacing to the web.

I've found the key is making sure the "cards" only tile in one dimension.

[ ] [ ] [ ] [ ]

or

[ ]
[ ]
[ ]

If you add a second dimension, scanning slows down immensely.

[ ] [ ] [ ] [ ]
[ ] [ ] [ ] [ ]
[ ] [ ] [ ]

This doesn't mean that the second dimension is useless, however. You can use it to group cards by some criteria: post date or category, for example. I like to call this "chunking".

[ ] [ ] [ ] [ ]

[ ] [ ] [ ]

[ ] [ ] [ ] [ ] [ ]

or

[ ] [ ] [ ]
[ ] [ ] [ ]
[ ] [ ] [ ]
[ ] [ ]
[ ]

This way, you intuitively scan one chunk at a time, and only have to scan in one dimension, until you're ready to move on to the next chunk.

(Gah, Branch removed some space characters from the last example there. The three columns are supposed to be separated by gutters.)

@joni So, that's just a grid right? I think of "Masonry" as a very particular kind of layout where code is used to fit arbitrarily-sized elements together in the tightest configuration.

@Justin Well, the problems they cause seem to stem from that bi-dimensional scanning they require. If you could somehow get around that issue in a masonry layout, I'm sure it could work beautifully for text. :)

I'm also wondering what you think about the solution we came up with. Granted it's not quite masonry, but maybe a bit livelier than a regular grid.

For how long were we able to sustain your attention? Did you find it easy to skim the titles, or did it feel like work?

@Cemre It's definitely easier to scan than "true" masonry layouts. I guess Instapaper for iPad has a similar layout (two columns as well). In Instapaper I ended up turning the two-column layout off, but I don't mind this one. :p The set card heights help a lot.

However, I must say I end up paying much less attention to each branch in this layout than in the previous one. :( There's just so many of them now, and instead of being grouped into those nice three chunks, they're all one big chunk. I feel like I don't know what to do with them all.

(My judgment may be affected by the fact that my retina MBP now scrolls the home page at like 4 FPS. What's up with that? o_O)

In general I'm not a fan of masonry grids. They do, in someways anyway, make sense for content with no formal hierarchy, but they feel unfocused and don't really lead the eye anywhere of note. Also, seem a bit hard to implement and often result in some really funky whitespace issues.

I haven't seen to many text based masonry layouts, as, in most cases you'd want to enforce some kind of hierarchy with text. In general I don't think they work too well

With images, they work better, but... still seem overwhelming to me. Pintrest comes to mind as a place where it makes some more sense based on the content, but still has some downsides.

In the case of Branch, I'm not sure it makes sense, but maybe it needs some time. I think I get the goal, and would be very interested to see how it effects some of your key metrics, but, from my initial reaction is that it's much harder to pull out what's interesting or important.

Everything kind of bleeds together and exploring is much less directed. More content isn't always better, I think I'm finding myself less drawn to participate with so much going on. Or having to put more effort in.

Some of that is the nature of the masonry grid, some is the grouping and chunking of the content, was more clear before. But maybe it'll be something I get used to.

An aside: some of the images lend the layout a messy, clunky look. Part the dark overlay and part the low-quality. I like the idea of keying on images or links, but right now it's like a bunch of dark, fuzzy and, hate to say this, kinda ugly, boxes to me.

Could just be a personal pref, but I prefer the light, crisp look of the text and would probably love crisp, clear and bright images in there. Not sure how you'd enforce quality though. Tricky problem, but I do think I get why you'd want to look at that.

I applaud you for experimenting though! Test, get feedback/metrics and iterate. :)

+1 on the image comment. I've never been a fan of text over images. Either the text is illegible or, inevitably, someone in the photo gets a headline running over their face.

Presentation aside, an "All" view typically isn't going to be the best view for discovery. You may ultimately need something like content categorization or to surface relevant branches based on my Twitter graph, former branch co-participants, etc.

The reason why we went with dark boxes was legibility, if we tinted images towards white where text in front became legible, they looked quite ugly. It's definitely a challenge with user generated content.

As for "All", this is our first stab, making it smarter is definitely a priority :)

@cemre - Did you try displaying the image free of overlaying text? Again, I know everyone does this these days, but text over images works best when you're designing like a one-off Nike ad or something. It's really hard to do it programmatically.

Also re:images – I really, really miss seeing all the people in the branch. Seeing people, helped to gauge the size/intimacy/popularity of a conversation AND it provided some visual content.

*Definitely* agree with Justin there. That ring of people conveyed so much data with a since glance.

We had space constraints, that's why we ended up with the overlaying solution.

Re: the people ring, we had initially built the ring of people as a fun hack, it's cool hearing that it had some utility as well. A pile of avatars didn't seem to work as well in an infinite scroll setting, but we will experiment with bringing back elements of that.

I wanted to start with showing the minimum amount of information we could get away with, instead of cluttering the layout things we might not really need. We will tweak and improve this page as we look at metrics and get your opinions, so thanks for all the feedback!