Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create 'condensed' design version #1988

Open
nlhkabu opened this issue May 13, 2017 · 27 comments
Open

Create 'condensed' design version #1988

nlhkabu opened this issue May 13, 2017 · 27 comments
Labels
accessibility Issues with accessibility or to improve accessibility needs discussion a product management/policy issue maintainers and users should discuss to user test Issues that should be investigated further via user testing usability UX/UI design, user experience, user interface

Comments

@nlhkabu
Copy link
Contributor

nlhkabu commented May 13, 2017

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:

screenshot from 2017-05-13 22-03-41

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
Copy link
Member

dstufft commented May 14, 2017

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
Copy link
Contributor Author

nlhkabu commented May 14, 2017

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
Copy link

rsyring commented May 15, 2017

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
Copy link
Contributor

nkanaev commented May 15, 2017

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?

@sersorrel
Copy link

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:

image

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

image

A closeup of the scrolled Warehouse:

image

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:

image

Alternatively:

image

(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
Copy link

rsyring commented Jul 27, 2017

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

@compute-e
Copy link

compute-e commented Nov 16, 2017

Here's two screenshots comparing the two designs on a tablet screen. I describe some things that need improving in this comment - including reducing whitespace, the colour scheme, moving the project tagline to the main column and organising the sidebar into a better structure, with fewer sections.

Newer design that needs some improvements Older design which had parts that look better
screenshot_2017-11-16-17-40-21_kindlephoto-51496782 screenshot_2017-11-16-17-40-56_kindlephoto-51571735

Even though the new design looks okay shown here in portrait orientation, the whitespace and other things look worse in the horizontal screen size on my tablet device.

@JohnSpeno
Copy link

Yes, the current design seems to waste too much vertical space. The thing I care about 99% of the time when visiting a PyPI page is getting the link to it's github repo (or equivalent). That should be front and center to maximize my personal use case. Thanks.

@brainwane brainwane added this to the 5: Shut Down Legacy PyPI milestone Dec 7, 2017
@merwok
Copy link
Contributor

merwok commented Feb 7, 2018

Glad to see that this discussion is happening, and thanks for thinking about all aspects of the user experience.

FWIW the thing that made me search for this ticket was not individual project pages, but the search results: the rectangles with margins allow only four (with the big header) to six items on my screen, compared to around fifteen in the table on the old PyPI.

@di
Copy link
Member

di commented Mar 1, 2018

#3107 also echoes concerns about extra space on the search results page.

@brainwane brainwane added needs UX/UI review needs discussion a product management/policy issue maintainers and users should discuss labels Mar 21, 2018
@brainwane brainwane modified the milestones: 5: Shut Down Legacy PyPI, 6. Post Legacy Shutdown Mar 21, 2018
@brainwane
Copy link
Contributor

I'm sorry for the delay in response here. The folks working on Warehouse have gotten limited funding to concentrate on improving and deploying Warehouse, and have kicked off work towards our development roadmap -- the most urgent task is to improve Warehouse to the point where we can redirect pypi.python.org to pypi.org so the site is more sustainable and reliable. I'm the project manager for this effort and I've been in frequent consultation with our designer, Nicole Harris.

I think some of you have read Nicole's (@nlhkabu's) writeup of her design goals, including her assessment of the legacy UI and its problems. She's doing user tests to get more data on what users have trouble with, and during those tests, looking at design inconsistency between www.python.org and Warehouse, usual device/browser/display usage and usual size/resolution, how much scrolling users have to do to achieve their goals, layout confusion, and so on. She's opening issues based on that testing and tagging them "user testing" in case you want to see what she's finding.

In the past several weeks we've also been fortunate enough to get volunteer frontend contributions from several folks (shoutout to @jmuzsik, @waseem18, @yeraydiazdiaz, @aalmazan, @jw, @Volcyy, @berkerpeksag, @alexwlchan, and @mds325, and sorry to anyone I forgot). I'd love input from any of you about how we could use existing functionality in Warehouse to give users the option of a more condensed experience, or what we could advise users to do to easily see a less styled, more condensed version immediately without code changes.

As Warehouse project manager, I'm marking this as something we will prioritize for post-launch work. I am sorry for the wait. We have limited grant-funded time to work on Warehouse and I am asking for volunteer help so we can get help on this issue faster.

@dstufft
Copy link
Member

dstufft commented Apr 2, 2018

Homepage probably can't be a tab, because we can have an arbitrary number of links for a project of which Homepage is one. As far as the tabbed concept goes, I'll leave that up to @nlhkabu :)

@aklaver
Copy link

aklaver commented Apr 16, 2018

Is there any movement on this, as the below is not good. I realize many people are glued to a phone that show only one item at a time, but for those of us who are not and want to scan more information at a time the current layout is not working.

screenshot_20180416_094241

@Safihre
Copy link

Safihre commented Apr 17, 2018

The amount of padding everywhere is just crazy on desktop. There is no need for condensed switch/toggle, it should just be more dense on the desktop by default.

But I doubt this will ever happen, I fear @nlhkabu just disagrees with this entirely since she has never responded to any of these topics.
I am sorry for being a bit blunt, but I made my issues months ago and was very constructive about it then (I think). But it just gets ignored by the designers, despite the number of issues created by others that feel the same way.

@nlhkabu nlhkabu added the to user test Issues that should be investigated further via user testing label Apr 18, 2018
@nlhkabu
Copy link
Contributor Author

nlhkabu commented Apr 18, 2018

@Safihre, I am sorry that you thought I was not responding on this issue -- I have heard the feedback here and will be taking it into consideration for future design updates.

I'm the only designer on this project and I'm working about ~10 hours a week, focusing on immediate launch-related issues. Often, when coding, reviewing others' PRs, user testing, and training others to user test takes up nearly all of my ~10 hours/week on Warehouse, I'm not going to have time to respond as fast as users would like to open issues (even issues I opened, like this one), and @brainwane will be replying in my stead (as she has done on many other tickets). I recognise that isn't ideal, and that this is an issue that several people have spoken about, however I need to prioritise my time to address those tickets which are blocking the team moving forward on our roadmap.

We need to user test this -- along with several other issues (marked "user test") to quantify how many people have this preference and balance that against what other users prefer. After this, we can start making decisions about what updates to make, and when.

@aklaver
Copy link

aklaver commented Apr 18, 2018

I believe, since there are issues going back to November 2015 related to this, that the user testing has been done and the site has been found wanting. Also AFAICT the roadmap for the new site is done: https://wiki.python.org/psf/WarehouseRoadmap
Please can you fix what is a usability problem.

@brainwane
Copy link
Contributor

@aklaver I maintain that roadmap; we're seeing some issues come up now that we've launched (like #3751 and #3689) that may need @nlhkabu's attention more urgently, and I may move them onto the "Shutdown Legacy" milestone. (We're running out of the funding we got to do the launch and the legacy shutdown.)

I recognize that several power users (people who are very used to using the old site) have mentioned that this is an issue for them. When @nlhkabu mentions user testing, she's talking about a systematic method that gets a greater variety of experiences, including but not limited to the self-selected sample of users who are already sophisticated enough to find this issue and speak up here. Right now, IMO, it looks like we will be finding ways to reduce the whitespace in some layouts while still keeping it easy for newer users to navigate; this is a balancing act that requires more data from our user tests, and volunteers to run user tests will make that go faster.

I absolutely recognize that some of our users are having a hard time with this right now. I'm sorry. People who absolutely need a workaround right now can try turning off styles in their browser (View: Page style: No style in Firefox). I know that is not a longterm solution, but I wanted to mention it since it's something people can do other than wait, volunteer to perform user tests, volunteer to be the subjects of user tests, donate to the Packaging Working Group to fund more work, or build their own "super-condensed-mode" clients.

@brainwane
Copy link
Contributor

@yeraydiazdiaz I'd like for you to turn your mockup from #1988 (comment) into a PR or a demo that @nlhkabu can use in user testing. Could you do that?

@brainwane brainwane added the accessibility Issues with accessibility or to improve accessibility label Apr 18, 2018
@brainwane
Copy link
Contributor

Python's BDFL, Guido van Rossum, just filed #3752:

"PyPI homepage has low information density"

I have a 13" laptop and my vision isn't what it used to be so I use the default font sizes etc.

When I open pypi.org, I essentially see a a huge blue box with a search box in it. While I admit this is a common trend for web sites these days, this seems to me a waste of precious real estate. The legacy site had much more useful info on the first screen. Is there a way you can improve the information density of the home page without sacrificing the "bold design" property?

(To give you an idea of what I see, the bottom of my screen has the line "The Python Package Index (PyPI) is a repository of software for the Python".)

I particularly appreciate @gvanrossum raising accessibility concerns and am tagging this issue accordingly.

@gvanrossum
Copy link

Whatever you do, please don't create a choice for the user between spread out and compact. That's a solution for lazy designers. Focus on usability. Also, think about who your users are and what they want. People don't go to pypi.org thinking "today I'm gonna download me some software". They come there with specific needs. Find those needs and the rest will follow.

@brainwane
Copy link
Contributor

@gvanrossum Thanks for your comment.

We do recognize that people come to PyPI with specific needs and tasks in mind; I recommend you check out Nicole's initial post and the user testing overview for more on how we discover those needs and test how PyPI fulfills, or doesn't fulfill, them. I do believe that, right now, we are leaning strongly towards making one UI rather than a spread out versus compact user option.

Please don't insinuate that our designer would be lazy. I recognize that a lot of us have dealt with hard-to-use designs in the past (including ones that make software harder to maintain because of combinatoric explosions), but let's distinguish between laziness in solutions and personal attributes of our contributors.

Thanks for the guidance.

@aklaver
Copy link

aklaver commented Apr 18, 2018

@brainwane the issue is that pypi is a utility site where people go to search and find information, possibility large amounts of information. Having to scroll through pages bloated with empty space makes the process painful. While I empathize with the current time and financial crunch, the topic under discussion has been know for some time(#793) and as the screenshot from the issue shows has not been dealt with in any meaningful manner.

@sersorrel
Copy link

If anyone wants a nicer workaround than turning off styles completely, I've hacked up a user stylesheet (which you can use with something like Stylus) to condense PyPI a bit; it's not perfect, and I'm not intending this as a suggestion for what I think PyPI should look like, but I do think it improves things somewhat.

Stylesheet
@-moz-document domain("pypi.org") {
/* header */

.site-header__logo {
    /* down from 15px */
    padding-top: 8px;
    padding-bottom: 8px;
}

.horizontal-menu--tall .horizontal-menu__link {
    /* down from 32px */
    padding-top: 25px;
    padding-bottom: 25px;
}

.search-form--primary {
    margin-top: 17px;
}

/* footer */

.footer__menus {
    margin-bottom: 0px; /* from 30px */
}

.footer {
    /* down from 30px */
    padding-top: 30px;
    padding-bottom: 20px;
}

/* homepage */

.homepage-banner__title { /* "Find, install and publish Python packages with the Python Package Index" */
    /* down from 40px */
    padding-bottom: 10px;
    /*display: none;*/ /* uncomment if you really want, I guess */
}

.homepage-banner__browse {
    /* down from 30px */
    margin-top: 10px;
}

.statistics-bar__statistic {
    /* down from 10px */
    padding-top: 0;
    padding-bottom: 0;
}

.banner {
    /* down from 50px */
    padding-top: 8px;
    padding-bottom: 8px;
}

.package-snippet {
    /* down from 15px */
    padding-top: 5px;
    padding-bottom: 5px;
    min-height: 65px; /* make the cards line up when a description is missing */
}

.horizontal-section {
    /* down from 70px */
    padding-top: 20px;
    padding-bottom: 20px;
}

.horizontal-section--thin {
    /* down from 10px */
    padding-top: 4px;
    padding-bottom: 4px;
}

.horizontal-section--statistics {
    padding-top: 10px;
    padding-bottom: 10px;
}

/* package details */

.package-header__name {
    margin-top: 0;
    margin-bottom: -10px;
}

.package-header__pip-instructions {
    /* I tried to get this to display in the header, but couldn't -- display: inline-block is probably the way forward */
    display: none;
}

.package-header__date {
    display: inline;
    margin-left: 0.5em;
}

.package-header__right {
    width: -webkit-fill-available;
    width: 40%;
}

.vertical-tabs__tab:focus { /* workaround for irritating bug where focused tab flashes on mouseover */
    background: #006dad;
    color: #fff;
}

.sidebar-section {
    /* from 20px */
    padding-bottom: 10px;
    margin-bottom: 10px;
}

.vertical-tabs__tab {
    /* from 15px -- changed for symmetry with section dividers */
    padding-top: 10px;
    padding-bottom: 10px;
}

#description .page-title {
    /* down from 30px */
    padding-bottom: 0px;
}

.project-description * {
    /* down from 30px */
    margin-top: 10px !important;
}

/* account settings */

hr {
    /* down from 45px */
    margin-top: 20px;
    margin-bottom: 20px;
}

/* releases */

.release__card {
    /* down from 15px */
    margin-top: 5px;
    margin-bottom: 5px;
}
}
Screenshots

pypi-stylesheet

@gvanrossum
Copy link

gvanrossum commented Apr 18, 2018 via email

cheungnj added a commit to cheungnj/warehouse that referenced this issue Apr 28, 2018
di pushed a commit that referenced this issue Apr 28, 2018
…est version box (#3481)

* update last released timestamp to visually connect it more to the latest version box

* display date as before and use border color defined in colours.scss

* add 'Last released:' to package header date status badge

* keep the style simple WRT #1988
@nlhkabu nlhkabu added UX/UI design, user experience, user interface and removed UX/UI design, user experience, user interface labels May 19, 2019
@nlhkabu nlhkabu removed their assignment May 19, 2019
@nlhkabu nlhkabu added UX/UI design, user experience, user interface and removed UX/UI design, user experience, user interface needs UX/UI review labels May 20, 2019
@di di removed the High priority label Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Issues with accessibility or to improve accessibility needs discussion a product management/policy issue maintainers and users should discuss to user test Issues that should be investigated further via user testing usability UX/UI design, user experience, user interface
Projects
None yet
Development

No branches or pull requests