Multiple search UI suggestions

[ChameleonRed]

What's the problem this feature will solve?

It will save my life time and yours :)
It allow faster find correct module and spread Python programming.
It will be like Python simple and useful.

Problem is too much esthetics but lack of usefulness.
Search design is broken - the most important features is missed.
There is a lot of trash information.

Very old interface was fantastic - current is esthetics domination of usefulness (that is wrong idea).

Let consider my examples - why I do not like and other programmer this interface (or even hate).

What is need to choose package.

1. Date of recent changes (higher is better in 80% cases)
2. Version of Python (higher is better in 80% cases - can be done with filters currently)
3. Short description (3-5 lines of text)
4. Web page link.

What search gives - Why we not like this - Consider:

1. Date of recent changes (higher is better in 80% cases)
   a. Try to see here date of changes -> https://pypi.org/search/?q=caller+callee+graph&o=
   b. Go deep and try to see date of change -> https://pypi.org/project/callee/
   c. Date is here after 3rd click -> https://pypi.org/project/callee/#history
   Three click to see but I want see on search results.

2. Version of Python (higher is better in 80% cases - can be done with filters currently)
   a. I have to click filters (and choose from ADA, C++, Haskell - why I need it in Python???)
   b. I have to click 20 filters -> I can not choose Python 3+... or Python 2+....
   20 clicks without any sense.

3. Short description (3-5 lines of text)
   a. need to click each project from long search list and open new tab to see what is description
   20 tabs without sense and waste of time.

Describe the solution you'd like

Save my life time :)

1. Date of recent changes (higher is better in 80% cases)
   In search results not three steps deeper.

2. Version of Python (higher is better in 80% cases)
   In search results or quick filter or allow me save this filter forever. Can be configurable and savable.

3. Short description (3 lines of text)
   In search results can be configurable and savable for forever.

4. Web page link.
   In search results can be configurable and savable for forever.

Additional context

Do not allow to dominate esthetics over usefulness.
Python is both esthetics and usefull - it is possible to balance it and make great tool.

[ChameleonRed]

I search pypi over 40 times and each time I have to do it I like it less. I am doing professional programs in python with over 50k lines, AI, monitoring, web, chess and much more.

Old interface was much better and I like it more with each search after 'simplification' all become 'hard' not simpler and not useful as previous one. Graphics is better but what is sense of beautiful graphics if search is ugly since to complex.

[yeraydiazdiaz]

Hi @ChameleonRed, thanks for your report.

Can I please ask to consider your choice of words? "Hate" and "ugly" are quite offensive and unfair to the people that worked really hard on Warehouse.

[di]

It seems like there are four separate requests here:

1. surface the "last updated" date in the search results for a given package
2. surface the "requires python" metadata in the search results for a given package
3. use a longer description than the current "short description" metadata field
4. include a link to the "homepage" metadata value if present

I think 1, 2, and possibly 4 are probably valid. I'm not sure there's anything we can do about 3 -- our options are to include the short description (which is what we currently do) or the long description (which is essentially a README and is far too long to include in the search results page).

We should probably split this issue up into separate feature requests for each as we've got multiple things mixed up here.

Also I want to point out that the old interface had the exact same content as the current interface and none of these additional bits of information. There isn't much difference between them, besides how condensed the old interface is:

[ChameleonRed]

It seems like there are four separate requests here:

1. surface the "last updated" date in the search results for a given package

2. surface the "requires python" metadata in the search results for a given package

3. use a longer description than the current "short description" metadata field

4. include a link to the "homepage" metadata value if present

I think 1, 2, and possibly 4 are probably valid. I'm not sure there's anything we can do about 3 -- our options are to include the short description (which is what we currently do) or the long description (which is essentially a README and is far too long to include in the search results page).

We should probably split this issue up into separate feature requests for each as we've got multiple things mixed up here.

Also I want to point out that the old interface had the exact same content as the current interface and none of these additional bits of information. There isn't much difference between them, besides how condensed the old interface is:

Hard to response you you all question in one comment. I try response to all you question in separate comments.

[ChameleonRed]

It seems like there are four separate requests here:

1. surface the "last updated" date in the search results for a given package

2. surface the "requires python" metadata in the search results for a given package

3. use a longer description than the current "short description" metadata field

4. include a link to the "homepage" metadata value if present

I think 1, 2, and possibly 4 are probably valid. I'm not sure there's anything we can do about 3 -- our options are to include the short description (which is what we currently do) or the long description (which is essentially a README and is far too long to include in the search results page).

We should probably split this issue up into separate feature requests for each as we've got multiple things mixed up here.

You can split it or not it depend how do you manage project. You can write four children stories and do it separately or do it together. It depend on your free will.

I prefer to do it all at once since what is sense o write 4 stories for myself from 1 story (less writing stories and more coding - it will save some of my lifetime).

Will write 4 stories for this one or need some help for me?

[ChameleonRed]

1. surface the "last updated" date in the search results for a given package

2. surface the "requires python" metadata in the search results for a given package

3. use a longer description than the current "short description" metadata field

4. include a link to the "homepage" metadata value if present

I think 1, 2, and possibly 4 are probably valid. I'm not sure there's anything we can do about 3 -- our options are to include the short description (which is what we currently do) or the long description (which is essentially a README and is far too long to include in the search results page).

I do not understand "surface" but it is not matter.

What is need to choose package.

1. Date of recent changes (higher is better in 80% cases)
   I think to add this to search result on user request and quick filter on the first page.
2. Version of Python (higher is better in 80% cases - can be done with filters currently)
   I think to add this to search result on user request and quick filter on the first page.
3. Short description (3-5 lines of text).
   I think you not understand my suggestion. I see some description in search results but not see description from page after click of result (it maybe readme). It can be added for example 7 lines or readme. Whatever it is hard to say how to do it - it matter of some experiments with layout and extracting metadata (it can be readme but not always). I do not understand metadata to formulate solution and I do not propose something not analysed.
4. Web page link.
   As you describe.

[ChameleonRed]

Also I want to point out that the old interface had the exact same content as the current interface and none of these additional bits of information. There isn't much difference between them, besides how condensed the old interface is:

Old interface is almost the same but not - small details determines usability.

1. Information was more compact. You see at once if you found anything.
   Tables are faster in read. Than blocks.
2. Weight is clear so if you see >5 you know that is not relevant. You know where cut searching digging and change keywords.
3. It was faster to open 20 windows (dense text/compact) - no scroll need.

UI need years of experience to understand and master - many people (80%) thinks that is very simple but it tough like chess. The most hard in UI design is not programming but psychology and listening and analysing tons of contradictory users feedbacks.

[brainwane]

Related to #1988, #3463, #727.

I appreciate the time you've put into trying to communicate with us about some aspects of the PyPI redesign that aren't working well for you. Thank you.

In your own personal life, you may act as though there is no such thing as a hurtful way to speak, and as though the wording you choose does not affect how other people respond to your requests. In PyPA projects, and in Python projects stewarded by the Python Software Foundation in general, we aim to be less rude. We aim to remember that we're all working together. We aim to acknowledge that, even if we don't like a decision, the people who made that decision probably had some good reasons for it, and put hard work into it. You may need to take some time to get used to that expectation. Regardless, it is the expectation for people talking in our GitHub issues, and you'll get more of what you want, faster, if you speak with more empathy.

Warehouse's maintainers will continue to assess the user experience of PyPI using GitHub issues like this one, systematic user testing research and user surveys, and so on.