Package page

[flip111]

1. Navigation

It would be good to keep a good flow of navigation to flora and from flora. I would put the Links section in a more prominent place. At least when #518 point 3 is not there.

Links could be either the first thing top left. Or it could be horizontal underneath the title like this:

  1. title
  2. subtitle
  3. white stripe
  4. navigation links (or buttons)
  5. white strip
  6. the rest of the page like it is currently

2. Links

• When homepage is the same as git repository, homepage should not be listed
• git repository currently ends with .git. I don't dislike it, though the use is interesting and not obvious at first sight. When you left click on it the .git is removed by github. So it use would be if you right click copy link and then paste in your terminal for a git clone command. Perhaps make a copy button instead that copies the links with the .git to make it a bit more obvious.
• Changelog i would move this out of the section of Links because it's part of the navigation of the flora website. Perhaps use a tab-like interface in which you can switch between Readme, Changelog and Modules (once documentation is available on Flora)
• When there is no homepage the homepage is set to flora. IMO this shouldn't happen. Example: https://flora.pm/packages/@hackage/effectful https://github.com/haskell-effectful/effectful/blob/master/effectful-th/effectful-th.cabal

3. Installation.

Installation currently found in the right side should not be part of the "normal listing of package properties" (left and right area). Instead it should be more visibly clear that there is an action to do here. For example chocolately has distinct visual elements and buttons and also aligns right https://community.chocolatey.org/packages the install command.

4. Left and right bar/area

Not sure what the idea behind is what information is in the left and what is in the right area. My guess is that left is for more administrative information and right more about technical information.

I would argue that people have a "package property" such as "tested compilers" straight in mind as a first step. And do not go through an intermediate step of "is it a technical property or an administrative property?". That means that this division between the left and the right bar doesn't have to be like this.

One could either make it one area (like hackage does it currently). Or divide it by another criteria, such as: Left most interesting properties, right the other ones.

Disregarding the links (as already discussed in point 1). Also disregarding "installation". This could be an order in which package properties are interesting:

• Latest upload date and/or revision date
• Package versions
• Maintainer
• Tested compilers
• Dependencies
• Package flags
• Dependents
• Categories
• License

When dividing over two columns. Left could have

• Latest upload date and/or revision date
• Package versions
• Maintainer
• Tested compilers

Right could have

• Dependencies
• Package flags
• Dependents
• Categories
• License

5. License

Could be clickable. Relevant websites:

• https://spdx.dev/
• https://opensource.org/license
• https://choosealicense.com/

6. Versions

• The day of the week has no added value Sun, Fri etc.
• Personal preference is to have the month as a number
• Personal preference is to have YYYY-MM-DD. Year is the most important thing that i want to start reading left to right. I don't care about customs in letterheads and what not. It's a minor thing though.
• Version should be underlined if it is the version that is currently displayed
• Version in red. Example https://flora.pm/packages/@hackage/megaparsec 9.4.0 it's unclear to me what the meaning is. Prefer a small remark instead.
• Show all remove it. Especially as the situation is how it is right now when versions is the last element in the left area. To be able to scroll with the mouse wheel to see more versions is much more convenient than switching context by navigating pages.

7. Installation

• Visual indication that there is a text input which can be selected
• Copy button
• Stack command to install

8. Tested compilers

Is fine as it is. But would like the buttons to be clickable to something. Perhaps to the GHC users guide of that version.

9. Dependencies

• In case there is support for stackage and also we are currently browsing documentation which is part of a single LTS or nightly. In that case do not show a version range but the exact version of the dependency that can be found in the stackage version
• The clickable links for the package should not link to the latest version but the latest version matching the version bounds.
• Arguable one could list the exact versions if smaller than n when there are only a few versions of that package within the version bounds. One could then also link to the exact documentation for each version.
• The "Show all...." page (i didn't want to open a separate github discussions for this page). Example https://flora.pm/packages/%40hackage/megaparsec/9.6.1/dependencies (at least for the main library)
  • Items should start in expanded state
  • Like some visual separation between type (library, benchmark, test) and name. By color, font-size and not concatenate without spaces as currently, example: library:megaparsec
  • Previous remark about versions apply here too
  • Other remarks about package listing apply here too Package listing #518
  • Would be cool to have a Tree instead of a list where you can keep unfolding dependencies of packages
  • Like Versions, i don't like a "show all" link and prefer all the dependencies listed. But that doesn't go well together with other remarks (such as previous point to show a tree). So instead i would make a "Show detailed" at the top, and then list the dependencies directly after each other (like currently on hackage). Maybe even leave the version bounds/versions to the detail page.

10. Dependents

• Could have versions listed. Because only X,Y,Z versions of a dependent rely on the specific version of the package currently shown.
• Would leave out the @hackage stuff as much as possible, only add this when the dependent list has the same package name from multiple repositories.
• Show all. About the same comments apply as the Dependencies show all

11. Package Flags

• The ? mouse over is really good in my opinion. Could be added in more places where applicable.
• The flags start folded, but it is not necessary in my opinion they can always be expanded

• I don't have experience with flags but might be interesting to build a small UI around them. For example like in the screenshow above we could put a checkbox in front to enable and disable. The result of using that checkbox would be a cabal build command with the appropriate flags applied. Though arguable this would get too big for the sidebar and would have to be moved to a tab (as discussed above: readme, changelog, modules, build flags)

12. Readme section

It is too narrow. Comparison between flora and github.

I have a 1440p monitor but i already imagine that on full HD there is still much empty space to be used left and right.

There should be a little bit more margin at the very bottom of the readme, perhaps 40px.

[tchoutri]

License could be clickable

It could, but can't always. If a majority of new licenses are now SPDX, not all of them are (or were). Only starting with cabal 3.0 is SPDX enforced.

[TixieSalander]

Maybe a conditional link (to spdx.org/licenses pages for example) could be added for the ones matching an indexed SPDX identifier? And only text for the rest.

[TixieSalander]

Wooaaa thank you @flip111 for all those feedbacks!

As I'm currently working on improving Flora's design globally, I had plenty of similar thoughts for the package page. I will include your points into consideration and hope my redesign will solve the most of the issues mentioned.

And If you want, I can ping you when the first version including my work will be deployed, your feedback will be welcome! 🫶

[flip111]

I look forward to your redesign, keep me updated !