Create 'condensed' design version

[nlhkabu]

We have had a lot of positive feedback about the new design. However, there are a number of power users who have made it clear that they prefer a more condensed, data-rich layout.

One possible solution is to have different viewing modes available - a bit like gmail:

To start with we could have "Standard mode" and "compact mode".

Standard mode would display the current layout. Compact mode would significantly reduce the page whitespace.

On the CSS side, this would be a matter of adding a class to the body and changing each style accordingly.

@dstufft what do you think? How could we do this on your side? Would we attach the preference to the logged in user? Or would we use cookies?

[dstufft]

I think the way of handling this in terms of implementation would be to have a separate cookie (that we filter out in the VCL so it doesn't affect caching) and implement the body class switching using javascript client side reading that cookie. If the user is logged in we can persist that setting server side using an ajax call to some internal endpoint and restore that persisted setting whenever the user logs in.

One thing I'd maybe push back on though is whether this is something that's worth spending time on. It seems like it's something that's going to increase the amount of effort of making any UI change since you're going to effectively need to design each change twice (or N times for each "mode") and since we don't have great UI level tests going, whatever the non-default mode is, is more likely to get broken unless we manually test each possible iteration.

To be clear, I'm not specifically against this, Mostly I'm questioning whether it's something we actually need. Is there in fact two distinct groups of users who need different UIs in order to effectively interact with the site, or can we satisfy both groups with a shared UI?

[nlhkabu]

Yes, I agree, it does significantly increase the workload.

Is there in fact two distinct groups of users who need different UIs in order to effectively interact with the site, or can we satisfy both groups with a shared UI?

The only way to verify this is to do some direct user testing. I have a list of volunteers for this, but not a lot of time to conduct them. In the short term, let's see what feedback we get on this issue.

[rsyring]

FWIW, I think having two UIs is a waste of manpower. One good UI should be sufficient IMO. If the power users mentioned in the OP have convinced you that the current layout could be improved, then make those improvements. If you aren't convinced, then leave the current layout. But having two UI layouts to maintain/improve, just seems like a lot of work for very little benefit.

[nkanaev]

From my personal experience, I find npmjs.com interface more appealing. They've managed to fit all the necessary information in one page without tab navigation, yet it doesn't feel bloated. Rubygems does the same thing, having the similar page structure.

What if we could borrow some of their ideas?

[keysmashes]

It seems like one obvious thing to do here would be to decrease the size of the header. Here's a side-by-side comparison of the above-the-fold view of npm, rubygems and Warehouse:

Here's the same image, but with Warehouse scrolled so the header appears about the same size as the other two sites:

A closeup of the scrolled Warehouse:

That's massively better. And the only information lost in that change was the Warehouse logo, the package version, and the search bar*, all of which would easily fit in the reduced header:

Alternatively:

(but then the install command starts to get a bit long, and runs the risk of crashing into the search bar.)

*I'm not counting the donation banner, mostly because I forgot about it while I was making those mockups, and I'm too lazy to add it back in :) There's still space to fit some more text in, but it's not like a banner on the top would completely ruin how it looks.

[rsyring]

@anowlcalledjosh very helpful post, thanks. FWIW, I think the first mockup you made is the best (package version by the date, simpler install command). The only additional suggestion I'd make is that their should be a page heading with the package name and version, like NPM and rubygems.