Unofficial mobile friendly package website exploration

I’m running a mobile friendly experimental and custom version of the package.elm-lang.org frontend on my proxy:

Light theme: elm.dmy.fr
Dark theme: dark.elm.dmy.fr

It uses the official website backend, just replacing the elm.js, style.css and favicon.ico files.

You can find a brief list of new features and bug fixes in the following gist:
New features and bug fixes

The main ones are:

  • responsive design
  • packages ranking
  • query saved in URL
  • sticky scrollable modules navigation bar
  • authors page
  • click function/type/operator to go to source
  • overflows fixed

For now, this is a just personal exploration to check bug fixes, test and improve new features, so even if some of them might potentially inspire some modifications to the official website, there is absolutely no guarantee and it seems wiser to avoid any expectation. I may also change or break things without prior notice.

Feedback is very welcome.

27 Likes

Very cool!

One thing I miss is that elm-packages (when using the elm-package-info extension you made) has the About info shown on the side panel. I understand that won’t fit in a mobile view, but when viewing a package on a desktop screen, could that information still be shown? It’s very convenient to have that info visible immediately rather than needing to jump to another page.

A variant of the “About” page is currently in test for the official website and will most likely be available soon.

We have decided to use this approach because the information available there is mostly useful when selecting a package, but not much or not at all when consulting the documentation. As we read documentation much more than we select a package, it made sense to favor a clean and uncluttered package documentation page.

I know that in some cases, having the information available directly would be more productive, but I think overall the selected solution is a reasonable compromise.

In my case, I usually visit the package website to find some package I want to install. For reading documentation, I use intellij-elm which shows module and function documentation inside the editor so there isn’t as much of a need to visit the package website for referencing documentation.

I guess this isn’t a common use case for beginners so the compromise makes sense to show package info only in an about page.

1 Like

Exactly. I understand your use case but as you guessed, this is most likely not the most common one.

Remember that Elm is minimalist in its design, and this also leaks out in some web site design decisions.

For your specific use case, maybe you could use https://elm-greenwood.com/.
All the “About” information is available directly in the search page when clicking a card, so this might be even more efficient. Packages are not ranked though and the design needs to be refined.

If some features are missing, contributions are welcome.

I reworked the dark theme which was not satisfying.
Hopefully contrast is better without sacrificing on reducing eye strain.

Any chance you could implement a ToC for the types and functions in a module? The’s one of the features I really wish the official site had.

There is an experimental hidden feature that list all modules functions and types when entering a space in the Modules search box.

I can’t think of a better way to list those at the moment, so this was a way to introduce the feature without risking any drawback for those that don’t care about it.

Oh wow, right at the end, I think I read nearly everything but that haha. Nice!

I can’t think of a better way to list those at the moment, so this was a way to introduce the feature without risking any drawback for those that don’t care about it.

Isn’t there a big chunk of empty space on the left side? (I see that that’s not the case currently, but I swear it was when I clicked on it 5 minutes ago)

edit: yeah the site is currently not working right.

Yeah, the official website was updated, and its endpoints changed. It should be fixed now.

It depends on the width of the window, which is already pretty large for certain packages. Also, I don’t think that just having some space is a solution by itself, as some functions/types can be very big, for example Css - elm-css 18.0.0 which would push everything else a lot to the right, and I also want to avoid a cluttered interface to stay faithful to the official website.

I see. Well one improvement I’ll suggest to the current method of getting the ToC is to automatically scroll it to the module you’re currently on.

1 Like

Excellent idea. I have added it for any query. Thank you!

1 Like

Awesome! bookmarking that dark theme as my new go-to! :+1:

1 Like

Very nice! I’m particularly impressed with how the type signatures of the documentation section headers break and align.

1 Like

Most of this algorithm was already done by the official website. I just fixed a few bugs, made it take a dynamic width, and allowed the layout to break lines (with an indentation) if things go wrong (zoom, bug or non-default font) or if the width is too small.

Sometimes the algorithm still produces results that don’t look that nice:

The result here looks confusingly aligned as well as the two records not being aligned the same.

1 Like

Yes, I think there is still a width computation bug remaining with records, but I have not yet had the time to investigate this one. I noticed it with Browser.application too.

I will have a look later. I should also add some fuzzy testing.

Note that the result alignment is due to word wrapping to avoid overflow. This is a last resort workaround in case something goes wrong. Here the algorithm should have used a multi-line type for convert.

Lastly the records not being aligned is due to the -> for the second one. I don’t think fixing the bug would change this, the result would be:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.