Ui facelift and usability improvements

[rbjoern84]

Hi!

First I want to apologize for this very comprehensive PR. At the beginning I thought about changing the icons first and then the other things step by step. But it turned out, that the interim results were not satisfying. The new single colored icons would only look nice in the context of an adjusted color scheme. But there is also a good news: Although there is a huge amount of changes the code base shrinked: 74 files changed, 826 insertions(+), 896 deletions(-) :)

To make the review easier for you, I will try to summarize the changes I did on the interface and provide some screenshots:

1.) Icons

• All png icons were replaced with a new icon font (a combination of google material icons, font awesome and customly created ones)

• Some Icons were summarized (e.g. the context based create-, add- and delete icons)

• Some Icons were basically changed for better distinguishing and consistency
  ( e.g. "destroy", "languages", "publish", "go to page", "sites", "reorder pages", "leave page", "hide elements")

• A new icon as a "drag indicator" was assigned to the element panels. (I recognized that the order changing of elements was not obvious enough to the clients)
  

• Some status icons and icons for critical or primary actions were colored, e.g.
  
  

:

2.) UI surface

• Alchemy got a more modern color scheme. The neutral "dead" gray turned into a toned blueish gray.
• The light blue of the menu bar turned into a contrastful dark blue-gray.
• A set of lively new accent colors is used across the whole interface (for icons, flash messages, notices, ...)
• nearly all of the color modifications are done with sass functions, now

Screenshot: Page edit view (before/after)

Screenshot: Pages view (before/after)

Screenshot image library (before/after)

3.) Tables

• In addition to the color adjustments tables were visually simplified: Horizontal gaps were replaced by borders and vertical borders were removed.
• Table heading typo was optimized.

(e.g. Tags > before/after)

(e.g. Dashboard > before/after)

Further improvements of consistency and usability

• Pages: All status attributes are grouped consequently on the right, now (before the warnings and hints were on the left next to the expand button) > flashier now

• Page edit: Order of toolbar buttons has changed and "publish" comes with a text label now:
  Reason: "Publish" was often not recognized by our clients, so that we had to mention it again and again. Now it's more prominent and obvious.

• For better understanding for beginners all primary actions in the tool bar come with text labels now (where we have enough space)

Probably I missed some details to explain but basically these are the changes the PR contains.

Although it's big and will take some time to review I look forward to hearing from you soon :)

Björn

[rbjoern84]

@tvdeyen Wenn du Lust und Zeit hast und es das Review einfacher macht, können wir uns auch gerne mal zu einer Screenhero-Session verabreden.

LG, Björn

[tvdeyen]

WOW! 😍

This will take some time, but at the first glance this looks like amazing work. Thanks Björn!

NOTE: This will be merged into master after we released a Rails 5 compatible version (Alchemy 4.0).
Then this will be part of Alchemy 4.1. The reason is, that we want to have the only difference between Alchemy 3.6 and Alchemy 4.0 to be the Rails dependency, so upgrades are way easier.

[tvdeyen]

Wenn du Lust und Zeit hast und es das Review einfacher macht, können wir uns auch gerne mal zu einer Screenhero-Session verabreden.

@rbjoern84 gerne!

[robinboening]

Wow! Thank you very much for the very detailed explanation and all the screenshots! I see these UI changes as big improvements and I really like them!

I haven't looked at the code yet, but I am really stunned from how it looks like. :)

[rbjoern84]

Thanks mates! I'm very lucky that you like it 😄
In which version this should go, there you are the experts. I'm fine with that.

[mtomov]

@rbjoern84 that is sooo awesome!!! Thank you so much for all you've done!

I don't actually think that is is so much about code review, as it is to:

1. Tests to pass
2. Someone to click it through around, but even if there's things small off - it's certainly a big improvement over before, and it's better to address those in other increments later on when others can also help out.

I really didn't think that the core team would ever have so much time to go through it all and do what you've done! Thanks a lot again!

I think that have only one suggestion on the code:

• My suggestion is to use the Fontello free service for the icons along with the Rails Fontello Gem, and the reason is that this will give us a standard way of managing and modifying icons that everyone can later contribute to.

Thanks again!

[rbjoern84]

Thank you for your positive feedback @mtomov ! :)

I've had a look on the gem and fontello. Fontello I already knew. It works nearly the same like IcoMoon (I used in this case). Generally I like the idea of automating the process, but I'm afraid that it will not work straightforward for some reasons:

• Because I used another tool the codes will probably change when you import the current font in fontello
• We don't need all the stuff from the downloaded font package
• We can't just replace all the codes because there are some custom class selectors, too, that share the codes coming from the automatically generated classes by the font tool. (Some Icons are still used in different contextes but with other colors, like e.g. "error", "alert" and "warning". Otherwise we would have redundant icons in the font.

But I see the actual problem of contributing to the icons you want to address. So I thought about another solution and added an instruction "How to update the icon font" to the top of the icon-font.scss. It's available now within the last commit.

Thank you for you useful feedback!

[dhonig]

I'm very excited for this to get merged. Nice work!

[tvdeyen]

I see the overall excitement and am very much excited myself

Easy, everybody, hold your 🐴

I would like to take an iterative approach instead of an "all-in-one PR". And we need to talk about some fundamentals before we start to discuss on the implementation itself.

it's better to address those in other increments later on when others can also help out.

I don't think this works out with UI. Changing colors and icons on a regular basis is very confusing for users. So, we should not rush this in, despite all of the excitement.

These are the issues I see right now having played around with this awhile

1. The icons are not well selected and don't play nicely together and with the UI.

   Mainly the edit, info, settings and trash icons don't look like they are from the same set. We don't want to change them afterwards, so we need to be sure that all icons are appealing and serve their purpose well.

   IMO we should not use two different icon sets (and especially not Google material icons, they are just ugly 😏), but should find a set that fits well for us and then add custom icons (that are very well drawn btw. 👏 ) when we see fit.

2. The icon colors are not fitting well and should probably just be removed

   I don't think that having these colors actually help the UX. Yes, I am very aware of what colors mean in UX and that they are quicker to determine than trying to decode an icons meaning.

   BUT: Most of the time we need additional color because of a "not ideal icon" choice (see 1. above).

   So, before we start to choose colors for actions and icons we should find great icons and then add colors where we see fit for them.

3. The overall color should be adjusted slightly

   I think we need to adjust the colors. They seem way too "cold" and "technical" for me and just doesn't feel unique, like Alchemy (I.e. the main gray in the background is too green, but I like the color in the left toolbar). This is tough, I know.

   Yes, we are a technical product (and all the chemistry analogies are on me 😄 so the colors play nicely with this), but I still think we can improve them.

   Also I'm not very sure if a lighter UI theme (I know you have one) might not be better for our brand. We should not diverge too far from what we have right now. Also light themes are just "friendlier" to look at. Yes, dark themes are better for the eyes and for late night workers like us, but meh.

   Not that I'm proposing to keep the baby blue and gray, but something "more modern" and still "nice to look at" would be better for our brand IMO.

4. Forms and buttons

   The buttons and select boxes are "too flat", "too hard to find", they "look disabled" and not like a "main action thing" I just "have to click". In contrary the inputs fields do not fit the flat UI of the selects and the buttons, they just look misplaced.

   Also, the "everything flat" trend is over (thank god!), so we should not jump on that wagon anymore. This might be not true for website UIs but is for web app UIs. Buttons need to look like they are actually clickable. Currently they look disabled (also the select boxes).

   Most important forms need to have a consistent look. They are the main UI element we have in Alchemy. They just need to look and work great.

   Here are some rules of thumb I am proposing we should consider:

   • Input fields should be flat, but still look "editable", not just "bordered values"
   • Buttons should look clickable / touchable, not disabled
   • Selects should look like input fields and not like buttons

5. There are still some smaller UI "bugs", like wrong spacing and missing icons

   I don't want to concentrate on them right now, as I think we have more fundamental stuff to discuss before we start to implement things.

Again, this is great work and I really appreciate the work and effort that went into this

So please don't see this as an criticism of your person or work. There is lots of great stuff in this PR and I really want to have this in, but we still have room for improvement.

[rbjoern84]

Hi @tvdeyen, thank you for your detailed feedback.

I completely agree that there is still room for improvement and that we should get the regular basis satisfying before we go public. In some points you are right. In other "issues" I don't share your opinion. Let's go through it:

1. Icons

The icons are not well selected and don't play nicely together and with the UI. Mainly the edit, info, settings and trash icons don't look like they are from the same set.

Could you explain more detailed what you exactly mean, please?
I think you don't mean the symbols itself, because they are very common, but the graphical design, right? The overall icon style is "filled icons". That's what should make them consistent. Which aspects do you mean that cause inconsistency?

If you just mean the details of the graphic, yes, this can be still improved (Although I don't see this that critical like you).

2. Icon colors

The icon colors are not fitting well and should probably just be removed
I don't think that having these colors actually help the UX. Yes, I am very aware of what colors mean in UX and that they are quicker to determine than trying to decode an icons meaning.

You're completely right with your contradiction :)

BUT: Most of the time we need additional color because of a "not ideal icon" choice (see 1. above).

That's not true. The reasons why we use colored icons are:

• To highlight important/primary actions
• To easier determine and distinguish (as you've already said)
• To emphasize critical actions (e.g. destroy)
• To lend the interface a sense of livelyness

What I agree is, that the highlight color values could be improved, although we have to keep in mind that it will look different on every monitor. Removing them at all I keep not for a good idea.

3. Colors general

The overall color should be adjusted slightly
I think we need to adjust the colors. They seem way too "cold" and "technical" for me and just doesn't feel unique, ...

It's hard to become unique through the interface theme color (without getting colorful). The funny part is, that I even tried to achive this by adding some blue to the neutral gray.
But sure, there is still room for improvements. So let's play around with the saturation and the hue again. But basically I would rather keep the blueish direction instead of becoming warm. All modern (web)interfaces I know go from a neutral to colder gray. That's why I perceive warmer gray as old-fashioned.

Also I'm not very sure if a lighter UI theme (I know you have one) might not be better for our brand. We should not diverge too far from what we have right now. Also light themes are just "friendlier" to look at.

Ähm, actually this is already a light theme ;)
Only the main menu bar is dark which provides a nice contrast. The other backgrounds go from a light to a mid gray.

Of course, we could lighten it a little bit in general. But then the contrast between the different grays would decrease and, especially on bad displays, they might get to close and harder to distinguish.
The differenciation is useful to group sections in the interface or visualize depth (e.g. element panels).

4. Buttons and forms

The buttons and select boxes are "too flat", "too hard to find", they "look disabled" and not like a "main action thing" I just "have to click".

What I agree to:
The buttons could be more prominent (e.g. inverted or even colored).

What I disagree to:
The buttons and select boxes are not too flat. They already have a slight gradient. This level of affordance is absolutely enough to recognize and understand it as a button.
Additionally we have the rounded corners and a slight border (to improve contrast to the background). There are even interfaces outside where buttons are understood well although they even don't have this. So the plastical button metapher is actually not necessary anymore, except we want to design for our grandma ;)

That they look disabled I can not agree, too. Usually disabled buttons have less contrast to the background and the text labels and icons are very translucent.

BTW: The "everything is flat" trend is not over. It is just matured and improved with (sometimes) very slight gradients, shadows, rounded corners and transitions where it makes sense to support the mental model of the user, improve affordance or make it more appealing. But in comparison to the former (skeumorphic) trend it's still flat.
And we can be sure that with the ongoing ubiquity of software interfaces and the rise of the digital natives simplicity will go on in the future.

Selects should look like input fields and not like buttons

It depends. If I can also type in values directly into the select box, your're right.
If I'm only able to select predefined values or a seperate input field is placed inside the select dropdown it should NOT look like an input field (it would suggests a possibility to input something although there isn't one).

So please don't see this as an criticism of your person or work.

Don't worry :) As you know I'm always open for discussion. And for improvements more than ever.

[tvdeyen]

1. Icons

I think you don't mean the symbols itself, because they are very common, but the graphical design, right? The overall icon style is "filled icons". That's what should make them consistent. Which aspects do you mean that cause inconsistency?

Yes, I mean the graphical design. They don't look like been drawn by the same person.

They have different sizes, different stroke widths and not matching positions. This looks jumpy and inconsistent.

Although I don't see this that critical like you

I see this critical, as I don't want to change icons in the near future. Adding icons that are 80% ok, but change them some months later on, or even worse live with bad icons for ever, is a no go for me.

That's what I liked about the current icons (although they are very outdated, sure): They are consistent as they share the same graphical design. They look drawn by the same person and therefore give a very solid and "professional" look.

There are some good candidates of free sets out there. I will collect some resources and share them with the rest of us, so we can decide on a good set of icons.

For me this is the No. 1 blocker of this PR.

2. Icon colors

That's not true. The reasons why we use colored icons are:

• To highlight important/primary actions
• To easier determine and distinguish (as you've already said)
• To emphasize critical actions (e.g. destroy)
• To lend the interface a sense of livelyness

What I agree is, that the highlight color values could be improved, although we have to keep in mind that it will look different on every monitor. Removing them at all I keep not for a good idea.

I agree to not remove them completely, but let's try to improve them and only use them where they are absolutely necessary.

3. Colors general

It's hard to become unique through the interface theme color (without getting colorful).

One of the reasons why the overall trend of dark/gray/monochrome interfaces is a bad trend at least from a brand-thinking kind of standpoint 😏

The funny part is, that I even tried to achieve this by adding some blue to the neutral gray. But sure, there is still room for improvements. So let's play around with the saturation and the hue again. But basically I would rather keep the blueish direction instead of becoming warm.

I am totally fine with the blueish tones. I just don't like the greenish grays. Like I said I like the colors in the main nav, but the body BG is not fitting. Maybe just try white as body bg?

All modern (web)interfaces I know go from a neutral to colder gray. That's why I perceive warmer gray as old-fashioned.

I don't follow trends and fashion. I consider this bad habit in UI/UX. Good UI and even more good UX are based on research and knowing how people work, not what designers think is beautiful (I don't mean you by that, as you are a UX person).

It's more mathematical then aesthetical (you now this better then me).

That said, I know that we basically are on the same track here. I just don't follow your argument, as you know better than me that this is BS ;)

Ähm, actually this is already a light theme ;)

Don't show me the dark theme 😆

Only the main menu bar is dark which provides a nice contrast. The other backgrounds go from a light to a mid gray.

I like the dark main menu

Of course, we could lighten it a little bit in general. But then the contrast between the different grays would decrease and, especially on bad displays, they might get to close and harder to distinguish.

Maybe we don't need so many different grays? What about white on the body?

The differentiation is useful to group sections in the interface or visualize depth (e.g. element panels).

I agree and think the element panel grays are good (slightly less greenish), but yes. It's mostly the body background.

4. Buttons and forms

The buttons could be more prominent (e.g. inverted or even colored).

Thought the same 👍 colored is good. Primary and secondary actions colors.

The buttons and select boxes are not too flat. They already have a slight gradient. This level of affordance is absolutely enough to recognize and understand it as a button.

Agree, add some color and we should be fine 👍

Additionally we have the rounded corners and a slight border (to improve contrast to the background). There are even interfaces outside where buttons are understood well although they even don't have this. So the plastical button metaphor is actually not necessary anymore, except we want to design for our grandma ;)

There is a huge span from plastically buttons to flat buttons, but yeah agree. But please don't confuse web design buttons (these thin lined hollow buttons that arise all over the place) with user interface buttons. These are different things. We are designing an web app here, but you know that ;)

That they look disabled I can not agree, too. Usually disabled buttons have less contrast to the background and the text labels and icons are very translucent.

Maybe disabled is the wrong term. Secondary action would fit better. They don't look like the primary action. But we already agreed on adding some background color to them 👍

BTW: The "everything is flat" trend is not over. It is just improved with (sometimes) very slight gradients, shadows and transitions where it makes sense to support the mental model of the user or makes it more appealing.

That's what I meant. They coming back from overall flat and no gradients and no shadows at all to having slight shadows and gradients. And this is what I want.

With the ongoing ubiquity of software interfaces simplicity will go on in the future.

Simplicity is fine, but not sacrificing usability

It depends. If I can also type in values directly into the select box, you're right. If I'm only able to select predefined values or a separate input field is placed inside the select dropdown it should NOT look like an input field (it would suggests a possibility to input something although there isn't one).

I think the select style you have in this PR is actually pretty great. If we color the buttons and reduce vertical depth (meaning inner shadow) of the inputs - so they actually look like they belong to the same graphical style as the selects - we're all fine.

Don't worry :) As you know I'm always open for discussion. And for improvements more than ever.

Always a pleasure to discuss UX with you, Björn! 💋

[tvdeyen]

Re: Icons

I think actually Fontawesome 4 is a good choice:

• They are around for ages and are therefore well known and good supported
• They update and add new icons regularly
• They are free, editable and you can fork them on GitHub
• They have great accessibility support
• They offer great sass support and css utilities
• The upcoming Fontawesome 5 even offers SVG in the free version
• Solidus uses them and Alchemy is used a lot together with Solidus

We should give it a try

[rbjoern84]

1. Icons

They have different sizes, different stroke widths and not matching positions. This looks jumpy and inconsistent.

I see the alignment issue now. The trash and destroy icon seem to be hanging a bit. 👍
The clipboard and add icon seem to be slightly bigger than the others.

The stroke width differs in some icons on purpose, e.g. the arrows and the close icon, because of the context they are used in.

The Icons consisting of strokes because of its natural shape (eg. sidebar toggle and change order) have thicker strokes (2px) to increase the weight to better fit together with the filled ones.

The strokes you can find on some filled icons like "select/unselect", "go to page" or "leave" should have all 1px strokes (it's too tiny for 2px).

Maybe the cut, link and unlink icon could have a bit more weight, if it's possible with this detailed shapes.

The other icons seem to be ok for me related to the stroke width.

I think actually Fontawesome 4 is a good choice:

I already took a couple of them and modified them so that they fit into the 16px grid I've choosen for the icons. Because FA4 is designed for a 14px grid and this is more tiny in our user interface than it has to be. Just applying a font size of 16px would cause bluryness.

In addition to that there are quite a couple of icons we need that FA4 does not provide or only provide as lined icons (e.g. order, pictures, all the filetype icons, select all/nothing, ...).

And some of them have mistakes. (See e.g. logout: The arrow should be in the opposite direction).

Some of them are much more inconsistent (like you mentioned above) and neither fit the filled nor the lined icons (e.g. logout or the eye). That's why I had to modify them or even create custom ones by myself.

I'm not in favour to replace the set with FA in general and add the custom ones afterwards.
I rather would keep the current Alchemy set and optimize or replace the icons that need a further iteration. That actually should not be the majority of them.

2. Icon colors

I agree to not remove them completely, but let's try to improve them and only use them where they are absolutely necessary.

Adjusting the colors, yap, let's play around with it again.
Only use them where they are absolutely necessary? What do you have in mind?
I could imagine to uncolor the destroy icon. In the other cases I actually see this valuable and helpful for recognition.

3. Colors General

One of the reasons why the overall trend of dark/gray/monochrome interfaces is a bad trend at least from a brand-thinking kind of standpoint

Mmnnn ... I don't think a dark interface is bad in general. There are some reasons for it's popularity, even from the UX perspective:

1. The same reason why picture galleries, or logo presentations are put on a dark background: A dark stage mostly provides more contrast (except with dark objects). So the object of interest is moved into the spotlight. In case of UI the object of interest should be what you are working on, not the interface itself.

2. A dark background has the advantage, that you can bring interface elements like buttons to the foreground (lighter and more saturated objects are perceived closer).

But there is also a downside (= advantage of light UI): Negative text and icons is harder to read, especially when they are very small).

But anyway, I guess basically we both like the current combination of dark and light :)

I am totally fine with the blueish tones. I just don't like the greenish grays. Like I said I like the colors in the main nav, but the body BG is not fitting. Maybe just try white as body bg?

I'm going to slightly adjust the bg colors again.

I don't follow trends and fashion. I consider this bad habit in UI/UX.

I basically agree. There are sometimes trends set by famous brands like apple that establish (at least for a certain time) although they cause some usability issues and many people follow blindly. Depending on the target group even these new "patterns" will be adapted and issues are tolerated (or stay unknown) by designers. In cases where the branding is very important and the target group is very affine it sometimes even makes sense. It depends on the target group.

Maybe we don't need so many different grays? What about white on the body?

A white bg I would advise against. This would take away the possibility to place lighter elements on it, which is very useful to bring them to the front, like Input fields or the panels on the page view.

Don't show me the dark theme 😆

Here is a former mockup I made in the past.
This I would call a "dark theme". ;)
(But I'm still in favour for the light one)

4. Buttons and Forms

👍 We're on the same track.

Summary

To sum up I have in mind the following ToDos:

• Adjust Icon colors and maybe uncolor "destroy" (Some others to discuss?)
• Adjust interface bg colors slightly
• Color the primary buttons
• Adjust input field color/effects to match with the other UI
• Go through the icons and adjust these ones that need optimization (Trash, destroy, clipboard, add, ???)

Are you fine with that? Did I miss something? Do we need further discussion on something?

LG

[mamhoff]

I think we're coming towards a difficult spot here where the discussion starts revolving around matters of taste. That's a spot I'd very much like to avoid, as it's just very hard to build consensus on taste.

What about we commit, instead, to a different goal than "make the UI/UX nicer": "Make the UI/UX easier to customize from the host app".

A good test for this would be to implement the theme in this PR from a host app, with as few changes as possible to Alchemy's core.

This PR shows a number of spots in which we need to get better to accomplish the goal of a theme-able Alchemy backend:

• streamline icon classes to all use icon-whatever

• make alchemy-icons.css file exchangeable

• find a minimal set of functional SASS color variables ($alchemy-background-color, $alchemy-primary-button-color etc.). Naming the variables after their contents doesn't help much because then we end up with taste issues again.

• make find the spots where we need to be able to configure spacing between elements and put these spacings into variables

I think if we go about this issue that way we might be able to sidestep the taste discussion.

[robinboening]

@mamhoff I like the approach, but that is a very different scope and a very different PR. I definitely vote for doing it, but afterwards. The UI Björn built and wants to merge is so much better than what we have right now. If we use that as our base to move towards the goal of making UI development more flexible in the future that sounds great to me!

[tvdeyen]

I'm with @mamhoff here.

so much better than what we have right now

is just another matter of taste. I disagree on many ways, but this is also just a matter of taste. Also there are still many missing places and some wrong colors. What is due to the huge change and that lots of stuff has to be tackled. Smaller, incremental PRs would help here.

There are on the other hand many good things in this PR that I would like to have in:

• Adjusted spacing (especially the resource tables)
• Introducing unified icon classes
• Adding inline labels to mayor actions (like "publish changes" and "add element", "create new site")

We should concentrate on that before we actually change colors and icons. These are not a matter of taste, but are improvements of the UI, which I'm absolute fine with.

Then we should

• Make Alchemy better skinnable
• Agree on a good icon set
• Agree on a good color theme
• Implement a default skin

Doing this the other way round would never lead to anything mergeable. We then would lose all the good stuff of this PR. Which would be sad. Because again, there is great stuff in this PR.

[rbjoern84]

I pretty much like this idea from @mamhoff of customizing themes, but do not completely agree on what should be custumized. The things I see in a customizable theme are interface colors, a custom logo and probably the font.
Icons, hmm, this is very advanced I think. We need a bunch of custom designed icons that are not part of a ready made icon set and the developer has to be very careful to don't miss an icon when he/she replaces the set. But yay, I see the advantage, e.g. if someone want's the same appearance like in his shop backend.

Spacing I wouldn't make editable in a template. Why should anybody want to clutter the layout? The spacing should be as optimal as it could be.

But in general, I see this as a separate feature I would appreciate to build on top. I don't want to do this just as a compromise because of disagreement in "taste". Also with a customizable template we would have to decide for a default theme!

is just another matter of taste. I disagree on many ways, but this is also just a matter of taste.

To be honest, we are not talking about taste that much. The decisions I made in terms of color and icons (there is the main disagreement I feel), I argued conclusively in my comments above.

Of course, there are always different ways to go and space for improvements. But in general, in comparison to the current state, it is NOT just another matter of taste.
There are a lot of smaller usability improvements, especially on the icons (some symbols are much more understandable now and have unique meanings), but also on grouping, positioning and clutter. And all in all it feels more contemporary than before because it looks much closer to popular applications of today.
These things have nothing to do with my personal taste. It's not that I'm a fan of gray or like the gear as a symbol. It's because it works well in this context. If somebody comes up with a "weller" approach, welcome!

Also there are still many missing places and some wrong colors.

Please be more constructive with your critics. Otherwise it sounds like blaming and has no information I can work on. What do you mean by "wrong colors"? Where are the many missing places?

What is due to the huge change and that lots of stuff has to be tackled. Smaller, incremental PRs would help here.

True. It is a huge PR, indeed. Smaller, incremental PRs sounds easy, but would have resulted in hight inconsistency where we would have had much more issues to discuss that we have right now. Some things can only evaluated in context, because everything is linked.

---

Until now I've heard no reason to basically replace one of the icons (I mean basically, not in terms of alignment or moving some pixels). There were neither questioning nor suggestions for replacing a certain icon we could discuss about. That's why I actually don't understand the problems you have with the icons @tvdeyen. The things you mentioned above where all minor adjustments, but you are intensively arguing for a complete replacement of the whole icon set and this one you suggested is not that far away from what we have in this PR (except the icons are designed smaller and incomplete for what we need).

That's why I have the feeling we go round in circles and I've still not figured out the actual problem.

I think we will only come to a conclusion if either the problems are named more detailed or you come up with a draft or example that shows the idea you have in mind.

Doing this the other way round would never lead to anything mergeable.

The suggested steps only move the discussion we have right now, but not solve it.
The only difference is, that we make it easier to customize (which is just a matter of implementation).

But this is a separate feature that has nothing to do with the goal of improving the UI/UX and making it visually feel state of the art.

Please don't get me wrong. I'm very open to add this feature in this PR. But keep in mind that we would make it even bigger and the discussion about icons and color would persist.

[rbjoern84]

BTW: Yesterday I pushed some commits where I changed the primary buttons, improved the input fields, slightly adjusted the colors and fixed some missing icons. (only to make sure this discussion will go on from the same base)

[mtomov]

Well, I tried out the version that you have just now.

My personal taste would be to go with warmer colors .. I have a feeling that the existing interface has had enough of greyish and bluish and the darker blue on the side bar seems too corporate.

I don't think that a CMS backend has to look corporate, and on the contrary - newer SaaS start-ups indeed prefer more vibrant colors to look more friendly.

--

As to having settings to adjust spacing .. that's too much indeed. If one is up for it CSS is enough flexible to allow to override existing classes.

Having settings to adjust colors .. I think the colors that we have now are already in SASS variables, so wouldn't it be a matter of adding a !default at the end of those, like the CSS frameworks do it?

Then again, I also don't think that this is a priority, as I can't imagine any of our clients investing money in changing those colors .. and if they do, I'm sure that I will be happy to contribute the code refactoring back.

So, I'd really avoid spending time in features with unclear benefit.

Edit:, oh, and @mamhoff's idea on the color variable names was a really good one!

find a minimal set of functional SASS color variables ($alchemy-background-color, $alchemy-primary-button-color etc.). Naming the variables after their contents doesn't help much because then we end up with taste issues again.

Not so much taste, as sometimes difficulty in naming the color and even more so making later refactoring difficult.

---

Apart from the non-constructive criticism above, I have few small details that I noticed : )

[rbjoern84]

@mtomov Thank you for your feedback. The screenshots are very helpful to fix the remaining issues with the icons 👍

I don't think that a CMS backend has to look corporate

I agree. The content should be king, not the interface.

newer SaaS start-ups indeed prefer more vibrant colors to look more friendly

Do you have an example you are in favor for? Just for inspiring, not for discussing.

Having settings to adjust colors .. I think the colors that we have now are already in SASS variables, so wouldn't it be a matter of adding a !default at the end of those, like the CSS frameworks do it?

Basically yes. We would provide an alchemy settings file with default variables we want to be able to customize. But I guess we can not just take our variables file for it, because it contains more than this.
I think we should tidy up and separate it first, and provide additional variables for the different contexts (that use the basic color variables), e.g. $header-color. Actually the same way like it's done in bootstrap or foundation.
And it might make sense to automatically copy the file (without the !defaults) into the rails app during the alchemy installation. Am I right?

The question we are still struggling with is if it should be part of this PR. I also would like to do this as a separate task, to not blow the PR up even more. Still waiting for feedback from @tvdeyen .

In the meantime (when I'm able to spend time) I go on fixing the interface bugs and playing around with the colors again. I still didn't give up hope to find a satisfying solution we all can live with :)

Thanks again. Was very helpful.
BTW: The spinner is not part of this PR. It already exists since a couple of month. ;)

[rbjoern84]

What do you think about that?

[mamhoff]

Hey @rbjoern84! First things first: We really appreciate your work on Alchemy's appearance.

This PR has many things that we really like and that we would love to merge into Alchemy. However, some things are still subject to discussions, most notably icons and colors.

That's why we would like you to send those things that we agree on as separate PRs, that can then be discussed and merged in a more focused and fast manner.

As much as you say you "have argued conclusively", we're not convinced. And as long as we're not convinced, we won't merge this PR, simple as that.

I've been through this exact process - proposing a large change and being rejected because of how large it is - many times, in Alchemy, Spree and Solidus. I know how much it feels like the work is done, and it should just be merged and we can get on with our lives.

But Open Source is about forging compromise, and compromise is easily forged with small changes. This change, as it stands, contains too many arguable changes, and they're holding the good stuff back. Thomas laid out a clear route for this to be merged, and it is: PR the things all of us agree on.

If at the end of that process we end up with a themeable Alchemy, and you happen not to agree with the core team's design choices, you will be free to use your icons and colors in your theme. Win-win!

[rbjoern84]

Hi @mamhoff,

I understand that reviewing all the commits is horrible and that it would have been better to separate it. But sending the things you agree on as separate PRs afterwards unfortunately sounds easier as it is. The problem is, that many commits were build on top of the changes of previous ones and would not work independently.

Even thought I would insanely start at zero, when it comes to the icons we would run into the same issue:
The problem with the icon replacement is, unless we don't want to rely on a png sprite, that a change to an icon font will brake all the icons and need a huge amount of further layout adjustments and refactoring that have to go hand in hand. That's btw the main reason for the big amount of changes in this PR. And we would have to decide for a default icon set anyway.

Anyway. My main motivation for this PR was making the look of the interface more state of the art and addressing the icons that are incomprehensible. The other smaller improvements like text labels, table paddings and some refactoring stuff came along the process. Did I understand you right, you want me to extract these minor things and drop the other 90% of my work (icons and colors)?

Sorry mates. This is not an option. I'm not willing to start at zero.

I'm still open for discussion about the icons and colors (or whatever comes up). If you compare the last screenshot to this one from the initial PR, you should already see a difference at some icons, the buttons, the inputs and the colors as well. I would be glad to get some feedback because I thought I've had solved the issues Thomas mentioned at the beginning.
To go on I need further constructive feedback or examples to see what you like. I'm quite willing to compromises. But this requires counterproposals.

At the moment I have no further indications I could work on related to the icons and colors.

I will instantly push the current version (if you want to play around with it). It already contains some additional themeable variables.
Please tell me if it makes sense to keep working on this PR (to fix the remaining bugs).

Otherwise I sadly give up and quit.

[rbjoern84]

Hello @mamhoff & @tvdeyen
Today I sat together with Robin to tidy up the commit history a little bit. We spend 3 hours now to get the icon related stuff at the beginning as clean and separate as possible. The other stuff related to the color changes and layout fixes/adjustments we've not touched. We would like to stop now (because of time) and hand it over to you. Hopefully it's better to follow now with less redundant changes.

Separating it into different PR's without breaking something, missing some icons or being inconsistent would still be very time consuming and challenging I think. Feel free to try it out if you still think that this is necessary :)

[tvdeyen]

Superseded by #1342