Elm-Ui-Widgets 2.0 - Native Material Design Widgets for Elm-UI

I am proud to announce that the rewrite of orasund/elm-ui-widgets is finished.

You can checkout the last post about it here:

Screenshot of the website
You can checkout the website here.

Every example also has an Ellie, checkout the doc to find them.

Native Material Design Implementation

I actually implemented material design in Elm :partying_face:. This came with some difficulties.

Color System

The original specification always has two colors for everything: a base color and a “-on” color to specify transitions. This “-on” color is typically either black(transition to black) or white(transition to white) but actually it may be any color. The problem here was that my widgets only supported a single color. So I needed to write a function that did the transition for me. Hidden in the source code I now have a nifty little function that can do additive and subtractive mixing of colors and even allows a percentage how much of a color should be added. Personally, I feel like the resulting transitions look better than the implemented transitions in chrome. I might want to publish it.

Specification Trickeries

The devil is in the detail. I quickly notice that the specification did not match the example images and website like youtube or google drive. I concluded that one specification was a newer version. Only problem: The specification actually does not have an official version number. So it came back to looking at a lot of images of material design and trying to figure out what specification to use.

Future Projects

Here are a few ways how to continue now that the package is published.

  • More Material Design - I feel like the “Elm way” would be to have a new Materal Design package that in addition to the styling also ensures that a the website follows the Material design philosophy.
  • More Widgets - Its actually not necessary that all widgets are in one single package. So maybe different packages for different use cases might be useful.
  • More Complexity - My current implementations all assume that we have unformatted text. It might be also interesting to add support for different markup languages, like a Markdown widgets, wrapping Element.textColumn.

Special thanks goes out to @dmy and @mdgriffith for fixing a nasty little bug in elm-ui that would have made this package useless. Thank you soo much!


Great job! Could have used it when I started my project using lucamug/style-framework 4 months ago :frowning:
This looks so much easier to customize. Maybe I’ll switch over in a few months!

1 Like

Looks gorgeous! I like the variety of widgets you provide. Have you considered a dropdown? I couldn’t find a good dropdown library in elm-ui and the best I can get requires a lot of config to look decent.

1 Like

Simple answer is: Dropdowns are out of fashion. That’s also the reason why Elm-Ui does not have them.

I was thinking about it. Material Design recommends using Chips instead. I had an example for filtering Chips before… it should be lying somewhere. If you’re interested I’ll upload it to Ellie.

Material Design also has menus, but they are not used to filter something.

I’m guessing you could write a very lightweight implementation using Elment.below. For a more sophisticated widget I’m guessing you’d need to track the position of the element as well as the height of the page and than constantly update the position of the dropdown menu.

You could write a function

syncPositions : Dropdown -> Task Error (Dropdown -> Dropdown)

similar to ScrollingNav.syncPositions. This function would need to be called regularly by the subscriptions function.

And after that you should be able to write something like

{-| Caculates the amount of pixels the dropdown needs to moved up
in order to be visible in the viewport
xOffset : { Dropdown, height : Float } -> Float

from there i would leave it to the user to define the rest.


Great job!

The example page has some reusable views with internal state. Below there is some “States” thing that seems dead. Is that on purpose?

Another thing, when sorting strings, you need to be able to supply a sorting function as this depends on language. The builtin sorting is not for human consumption.

I don’t immediately understand how this works in this package.

You got me.
This was a hotfix for a problem in the logic. Didn’t want to fix it at the time, now I feel a bit stupid. :sweat_smile:
…should be fixed now

Are you talking about the ordering in the sortable table?

You can specify the sorting function using the toValue field of the column:

stringColumn :
    { title : String
    , value : a -> String
    , toString : String -> String
    , width : Length
    -> Column a

I’ve added a small remark to the doc of that function. Will be included in the next version. Thanks.

1 Like

Thanks for the detailed explanation. Now I do see why dropdowns are not the best UI design.

Yes please! I would love to see an example of filtering and Chips. :bowing_man:

Here you go


Thank you very kindly @Lucas_Payr. :bowing_man:

And thank you for building this library. I’m excited to try it out.

That article was great. However, it also reads:

Sometimes it makes the most sense to use a dropdown. The most common cases are when there is limited space or an input is nonessential. Probably the most common example is sorting a list.

Not that I need a dropdown right now, just couldn’t help but notice :sweat_smile: .

I’m not against having a lot of different widgets (and variants of them) in the package. If anybody wants to add a widget, please feel free to start an issue.

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