Because:

* in open source software projects, professional designers are rare.

* functionality or documentation might have been higher priorities

* it would be unfair to deprive you of the opportunity to contribute a better design to this open source projet

The last bullet should come with a warning to put your drink down first.

What is the best way for designers to help with opensource projects? These projects are often very developer oriented.

Nicely ask in the bug tracker about how a designer can help. Maybe start with a mock of what you want to change. I'm sure most open source developers will put in extra effort to help you because they value contributions from designers.

Not bash their contributions like it has happened on GNOME and KDE.

The bashing is truly amazing. Not only does it lack constructiveness (in most cases), but Gnome (I speak of Gnome here not to the exclusion of KDE. I just happen to be a Gnome user) is beautiful, and has been for years.

Thank you Gnome team, including designers, that created such a beautiful desktop experience for me.

Design is more than beauty. Design is functionality, how you use stuff. As long as I rather jump into a terminal than navigate through the UI, that's a fail in my book, and very few DE's on Linux pass this test.

And the hordes clamoured in unison "You need to have an MVP. If you are not embarrassed by your first release, then you have released too late!!". And the developer released his Minimum Viable Product unto the public. And the hordes were dismayed, and they reeled back uttering "That is butt ugly!". And the developer was dejected and wandered away to work on something else.

In all seriousness - mixed messaging as seen on this thread is why I believe most (myself included) eschew the whole 'MVP' thing and try to polish products before release.

Exactly. It drives me nuts in startup world the "push for MVP" or critical path first -> release -> iterate/improve, yet when the product gets released it is criticized for rough edges, bugs, but most appallingly missing features.

Well yeah, users want the full fucking product, not the MVP.

MVPs happen to be an (apparently) efficient model for startups, but its not like anyone actually wants it. Your users might grudgingly accept your half-finished, buggy, unoptimized MVP because nothing better is available to them, but how could you possibly expect anyone to be happy with this?

MVPs are pushed by businesses, not by consumers. But on the market-scale, it also pushes MVPs (because you get bonuses from being first-to-market and such).

But no individual consumer goes around saying "yeah I'd love to be promised the world, and instead recieve a millionth of it".

Of course you're going to be criticized by the people you've given hope to, only to let down with bug report #985

These developers are front end developers they should care about that kind of thing.

I guess this is an early release and getting the details right does take time. I sometimes get comments along the lines of 'is that all it does?' when I've spent lots of time getting the details correct.

Plus yes I think it does require some level of sensitivity to it. 99% of people just don't notice, but the details do matter in the long run as it begins to feel right to people, who will never be able to explain to you why or even complement you on it but will carry on using the system because of it.

What do you mean; the lack of padding in the blue column?

Overall, UI design is really not too bad here. On the other hand, it's almost 1:1 copied from the official Slack app.

There is no "vertical rhythm". The strength of the different elements is all over the place.

Some elements randomly have 20px spaces between them, some have 28px, some have 32px. This would be fine if they were done on purpose but right now they look like they were chosen randomly.

https://user-images.githubusercontent.com/639601/38463114-17...

Take a closer look at the space below the "BabelJS" title.

Compare the space between "direct message"/"slackbot" vs. "slackbox"/"zcbenz".

Why is the padding around the channel icons 20px on all side while the spacing to the left of "BabelJS" only 13px?

etc.

Edit: If you still cannot grok what I'm taking about, play a bit with this tool and you will understand https://www.gridlover.net/try

Yeah, heading distances are a bit awkward - especially because the lower one ("Direct Messages") is closer to the first item than the first to the second item. But I'd say it doesn't hurt usability too much. If anything, I'd rather tackle the slightly different font sizes in the left and right area first.

I can see what's wrong with the things you're talking about, except for one — the space below the BabelJS title. For me, it creates a clear separation between it and what is below, which I think makes sense. What am I not getting?

(I have to work hard to see such things, though, and I'd have to try even harder to be bothered by them.)

Without a doubt. However, why the magical 50px?

Why not take some of that screen space and move the title a bit lower so that it doesn't look so out of place with the whole vertical rythm of the page? The icons to the left are starting at 20px, why not put the title there? The title is also directly linked to those icons. Clicking on an icon changes the title. The title is the current selected icons's title, in fact. Aligning them makes that connection clearer.

That's the kind of questions you should ask yourself when you design an interface.

Right now, the title has a 50px margin because that's the distance the official Slack app uses. However, the official app puts the current user's username there, so that there's Title>10px>Username>30px>Channels ... instead of Title>50px>Channels. It's a direct copy that is missing some elements and that's why it feels wrong to the eye.

Thank you for those details. I'll have to look for a good resource that explains these things well.

Then let me recommend you Design for Hackers† by David Kadavy. If you care to take the step it'll be an enlightening journey after which many things cannot be unseen.

† ISBN 978-1119998952

Thanks for recommending D4H!

This! It's very far from being 1:1 clone of Slack UI, it's closer to a child's drawing of Slack UI. A mockup.

See, this is what I meant, some people just don't see it!

You could also argue that with the Slack app's memory usage, it's closer to how a child would build professional app, and is more of a prototype than a shipping product. (No disrespect to Slack developers: I understand the tradeoffs of using Electron). My point is that if design shortcuts were taken, that's because development priorities were elsewhere (ostensibly, focusing on performance)

I absolutely agree with you, my observation is strictly limited to the design. I think Slack's devs are way more to blame than Wey's, we're just not talking about memory usage in this thread :)

> See, this is what I meant, some people just don't see it!

i'd say most people don't see it. maybe it's not very important then?

People won't see it when looking at you app with blinders on. However, they will feel the difference when using the competition's app.

They won't be able to tell you why they prefer the one with more time invested in the UX/UI, but they will almost always choose that one.

There are universal rules in design and everyone is using them. We are actively training the users into feeling those rules as superior.

(This is also why huge paradigm changes feel so refreshing. Breaking the rules on purpose is very strong.)

> They won't be able to tell you why they prefer the one with more time invested in the UX/UI, but they will almost always choose that one.

do you really believe that or does your job depending on you and others, believing that? I get UX is important, where UX is defined by such things like "number of clicks to achieve a task", but the OP was talking about margins and padding etc which just are a lot less important than designers like to think. It's probably an uncomfortable truth for people who spend all day tweaking things 1px at a time, but I think it's largely true.

A case in point is the new Reddit design being tested (https://media.wired.com/photos/5abed25228f0c90b2647ac08/mast...)

It's prettier, I can see that. If it was a painting I'd rather hang the new one than the old one on my wall, but when it comes to pure functionality (read a list of links) the current (ugly) design is better (imho).

>do you really believe that or does your job depending on you and others, believing that?

It's not a question of believing; the job exists because there's a real need to optimize the visuals. The brain has its own API (see [1], [2]) and if you don't optimize the "visual code" to it, the interface may work, but in sub-optimal ways and causing a discomfort to the user. It's like having a C program that leaks memory. It may perform the expected task, but you wouldn't say it's "right".

Margin and padding, alignment, contrast and relative positions define the structure of the interface - in the same way that you use Layout objects behind the curtain to program where every widget is placed, you should use the visual properties of separation, visual weight and rhythm to tell the user which parts are related and what is the hierarchy of the elements. If you fail to convey the structure to the user, their mental model will be wrong and the interface will be hard to use.

[1] https://en.wikipedia.org/wiki/Gestalt_psychology#Pr%C3%A4gna...

[2] http://www.scholarpedia.org/article/Gestalt_principles

There are no glaring mistakes when it comes to Reddit's new design. Nobody is saying that the use of white space is wrong or that having margins and padding is wrong.

The issue is when it's not respecting anything and is simply thrown together randomly. If OP's app were to copy the same padding and margins as Reddit's new sidebar, I would have nothing to say against it.

Yes, your app will do fine with minor design issues. It won't drives all of your users away. However, they might start to notice that your main competitor's app feels better and slowly trickle that way. There is a reason that all top brands have such strong design and user experience/graphic design teams. One or two small issues is fine, but they pile in really quickly. Nobody wants to complete a checkout when the entire page looks like the content of a 1995 website in a iframe.

My personal philosophy is "why do anything if you are not going to do it beautifuly?". As a full-stack developer, it's easy for me to see both side of the medal. It would be very straightforward for me to simply throw components on the screen and call it a day. By the time I've programmed and integrated them in, I'm tired and only want to close the task. I have to remind myself of my motto and it always results in a better experience for everyone involved with the end product. Most of those design decisions can be done in a few minutes if you take the time (and if you have received proper training to spot the issues) and those few minutes can results in a big leap in quality.

I agree with you wholeheartedly (as a fellow full-stack dev) but I think that much of what constitutes modern "design" places too much emphasis on expectations management and user feelings. There seem to be few that are truly concerned with usability metrics and too many concerned about aesthetics or optimizing for business objectives.

Sometimes the best user experience does not look the prettiest, and even more often does it fail to line up with business requirements. Both of those concerns need to be de-prioritized.

> OP was talking about margins and padding etc which just are a lot less important than designers like to think

Are you just saying that or do you have evidence to back it up? I'm not a designer but I work closely with them and I'd say it's the exact opposite. Developers (myself included) tend to get tunnel vision on finishing functionality but the actual end users of the software care a lot more about the 'small things' like that than you're giving them credit for.

The fact that you say 'tweaking things 1px at a time' shows that you don't quite understand that it isn't about moving things around arbitrarily, it's about creating a design system that does it for you. Every header should have X amount of spacing between it and other elements, every paragraph should have the same size that makes sense with the headings it sits under, backgrounds should draw the users eye to important places, etc.

Using the old/new Reddit is a horrible example, because the old Reddit absolutely had a design system that made sense to the user. It might have been simple, but the spacing was consistent across every element. Watch the comments when a subreddit mod team updates their theme and small things like the padding around the comment preview is missing, it's the first thing that the users of the sub notice.

I've done a lot of end-user interviews, and actually paying attention to your padding/margins and making sure all of the elements fit your grid can be the difference between the user trusting your app because it looks professional, and giving up on it because it looks like a side project (or to use the Reddit example, the difference between using the home page and a half-baked custom sub theme).

HN might not be the demographic that you're going to get that feedback, but unless you're writing your software specifically for developers you're going to be losing a lot of trust regardless of how solid your software is behind the UI. It's not about creating 'art', it's about making your work look trustworthy to the end user.

grids are great. nobody's arguing that a UI should be inconsistent, that is absurd. The vast majority of designers only attack the problem from a shallow aesthetic pov though.

>Using the old/new Reddit is a horrible example, because the old Reddit absolutely had a design system that made sense to the user.

Your own argument supports exactly what I'm saying. The designers of the new Reddit took an existing, very functional design and then f*cked it up by making it "pretty".

Most designers put UX on their resume (because it's trendy), but their folios betray that they do aesthetics (which is great, but not terribly important), and only have an effect on UX accidentally.

> There are universal rules in design and everyone is using them. We are actively training the users into feeling those rules as superior.

If the rules are universal, then why would users have to be trained to consider them superior?

Dissonance and consonance are universal. You still have classical music, rock & roll, metal, techno, pop, etc. Even in the world of classical music, there are different waves and composers stretching the limits of the framework around them.

We are training the users into enjoying very rigid and professional looking websites. Anything amateur looks jarring these days.

This wasn't true in the 90's - we trained the eyes of the users into disliking amateur looking websites.

OK. If you say so. It doesn't make much sense to me.

> We are actively training the users into feeling those rules as superior.

I would wager that we are not necessarily training users into feeling those rules as superior, but the absolute opposite — people tend to feel more at ease / comfortable when those rules are in place, and we want people to feel that way when they use our products, and so we use those rules. Ubiquity/familiarity is one reason why someone may feel at ease with a design, but it’s absolutely not the only reason. There are other more fundamental reasons why some designs are pleasant and others are unsettling / frustrating.

For example we can’t explain why harmony sounds pleasant and why dissonance is unsettling. We can explain how they are different from each other and describe these differences with rules, but not necessarily why one makes us feel good and why another makes us feel bad. But the musician knows these things— that certain arrangements make people feel a certain way. And using this knowledge, the musician can compose music that falls in line with the effects that he wants it to have on people.

Still, you don’t need to be a musician to know when a song sounds horrible. You don’t need to be a chef to know that the food tastes horrible. You don’t need to be a designer to know that it’s unpleasant. We can feel an unsettling interface even if we don’t necessarily know why it’s bad. Good designers are just more in tune to these feelings and also are able to identify and implement the technicalities as to how to make the design feel the way they want it to.

We generally don’t want people to feel uncomfortable when using our interfaces (although maybe sometimes we do), so we tend to settle on some rules of thumb that we know make people more comfortable like “visual heierarchy” “vertical rhythm” “line length not more than 60 characters” “not having to make 6 clicks for something you do fairly often” “context (such as breadcrumb navigation)” etc. And, I mean, when you put a lot of these rules together you end up with a lot of interfaces that converge to look and feel the same. Doesn’t necessarily mean we are actively training people to feel that these things are better. At a fundamental level people already do. Good design is more of a discovery of human nature / an applied science.. than a conspiracy to make people like things.

We don’t like food that tastes like crap. If everyone’s food tastes like crap, well, we’re going to be eating food that tastes like crap. Because we still need to eat. But the moment someone puts out food that tastes less like crap, people are going to want to eat that person’s food more than others’. And maybe that chef proclaims a rule that “when you include X in your recipe, or when you don’t do Y, your food tastes less like crap and more people want it.” And now more chefs who want to sell food are putting out food that follows that rule. And now more food on the market taste a little less like crap. That’s pretty much how design works as an industry.

Unfortunately a lot of developers value aesthetic and polish somewhere deep down on the list of priorities and don't seem to comprehend that other people care a lot about such things.

And a lot of developers just don't have an eye for it at all. I can look at a UI all day and tell that something is off but I couldn't even begin to tell you what or how to fix it. It doesn't mean I don't care.

It’s not just having an eye for it; UI design is an entire field, and human computer interaction (HCI) has existed since the 70s. I think that a large part of the problem is PMs / managers / tech leads not understanding that design has subjective elements but can also be objectively good or bad, and that they can’t tell the difference between a design that is correct and works well but might not look very flashy vs something that gets lots of likes on Dribble but is awful to use. This feeds into itself and leads to more people thinking that they know what good design is (pretty) and hiring other people who call themselves designers who have no idea about the actual science behind it.

As a developer who appreciates good design but doesn’t really know how to create it, can you suggest a good entry level resource that summarizes what we’ve learned over the last 50 years about HCI and how to make usable interfaces?

Don't Make Me Think be Steve Krugg,Grid systems in Graphic Design by Josef Müller Brockman, Designing with Grids by Mark Boulton, Any of Ellen Lupton's Type Design books. All light reads except Josef's.

Also, the classic Elements of Typographic Style by Robert Bringhurst, and probably just go and read everything on Smashing Magazine from about 2010 to now.

Pluralsight has a few nice courses.

cracks fingers I made a book for you! http://uxbook.io/

A sample would be nice.

The publishers have plans to do that apparently but not yet. I definitely want to do chapter excerpts.

I have the same problem. If you showed me two UIs I could probably identify the more aesthetically pleasing one.

But if you showed me a single UI, I highly doubt I could improve it.

I believe [0] the biggest trick is to avoid most of the things you can do.

[0] http://beza1e1.tuxen.de/slide_design_programmers.html

Tweaking that stuff early on is so effective that it could almost be thought of as a "cheat code" for development. User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

> User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

Some of us explicitly don't want the UI to give off the impression that the software is more finished than what it really is, so we sometimes intentionally keep the UI unpolished while we know that we have important things not yet implemented.

However I have come to realize that there are several downsides to this line of thinking;

1. If the app looks bad then it might permanently put off would-be users.

2. By not giving the UI enough attention early on, discoveries of UX problems that could have been caught early are not made until much later, delaying the project and potentially leading to more work as well because there will be more things that need to be rewritten or remade in order to fix the UX problems.

3. If you think feature X needs to be completed before you do the UI, then what is going to keep features Y and Z and so on to make you think the same way when you get there? Software is often never "complete". If you think it needs to be "complete enough" before you can give it the UI it deserves, how will you know that you've reached the stage of complete enough?

Furthermore, I have come to realize that often we don't know what we want exactly. We might think we know, but as we work on implementing our ideas things turn out to not be quite as we'd imagined them to.

But I also think that grand parent was on to something. When we build software, we should strive to implement features that are useful but not only that, the software needs to make the most common tasks as efficient for the user to perform as possible. And in order to find out what that means, we need to consider the UI from the very beginning.

First make it work, then make it correct, then document it, then make it efficient, then make it pretty.

Rarely all stages are reached, but in open source projects, anyone can cook their favorite dish for this dinner.

The problem with that is that “pretty” is implying simple visual beauty. It diminishes what design really is: the way something works not simply how it looks. “Pretty” should be integral to “make it work.” If your design is good, it’s more self-documenting, so pretty early in the process means less work documenting — it also reveals more of the essence of what exactly you are building which then helps drive the decisions on what to build next.

Design shouldn’t be an afterthought, it should be THE thought.

I disagree. If you make something, THE thought is that it fulfills its function correctly. I wouldn't pursue an excellent UX if the inner workings are buggy.

It is ok, we cannot be an expert on all areas.

My focus is on full stack, so I do care a lot about UI/UX, and improving my skills there.

However don't ask me to do anything related to NoSQL or Deep Learning, I would be a lousy contributor.

> It is ok, we cannot be an expert on all areas.

> My focus is on full stack,

I'm sorry, imo those are two contradicting sentences.

But it might be related to a personal pet peeve of "full stack" developers claiming to be expert in most moving parts of the stack.

Only to post on medium this amazing db hack they found, to be called out in hn comments for not reading the basic docs of one of the core items in their stack.

I always look at Doctors for a bad analogy; why full stack developer is a bad idea. Sure the heart surgeon will be able to diagnose your broken leg. Might even be able to assist you with a cast. But trust him to operate? There a specialist for that!

Is this not the same for dev work? Designer, Developer split into 4 fields(desktop, mobile, frontend, backend), database admin, sys admin. All possible to be done by a "full stack" developer.

But I don't see you become a specialist or expert in any of the fields of your stack, if you don't dedicate to a few.

Well, there is a reason why in some countries access to specialists is forbidden unless you are checked by a general physician first, the one responsible for being your official doctor throughout your entire life.

He knows best than having people searching for specialist by themselves.

As for myself, if you prefer a more descriptive example, I specialize in everything related to Java, .NET and Web (VanilaJS) stacks.

As a citizen of one of those countries, this fails spectacularly when your family doctor does -not- know best or just doesn’t care about his job, yet due to the huge scarcity of family doctors, will never lose any of his clientele.

I used to work for a company that put out thousands of site a year. I was fortunate enough to work with some really anal retentive designers. After a few months, I was able to pick up a 1 or 2 pixel difference in the photoshop docs, see how fonts did or didn't work and if color schemes were decent.

There's a ton of tools out there to help you with these, and as a developer, I like tossing around a lot of the design stuff that gets regulated until an app or site is totally functional, when I feel like most of the design work stuff should be done prior to getting your app working.

Design is the hard part, coding it? For me, that's the easy part. I feel like once I've got some decent font's paired, a color scheme worked out and other design elements nailed, the rest is easy.

I don't think that's a matter of priorities so much. I think most of them simply don't notice it or don't know what's exactly wrong when they do. At least that's what I noticed in some people I worked with.

Aesthetic and polish are over-prioritized in modern development. Which is more likely to anger the user -- a beautiful app sadly broken or an ugly one which does what it says on the tin?

It really depends on degrees. I've seen apps that were so bad, I couldn't even figure out what to do. It could be mathematically provable under the hood, but if I can't even figure out how to use it, or if the experience is bad enough, I won't care how well it is implemented.

They are one in the same. It’s not zero sum. You don’t sacrifice function for form nor should you sacrifice form for function. They should be the same thing. Form follows function — form shouldn’t be tacked on at the end.

We aren’t talking about the color of the paint, we are talking about the way the parts fit together.

It's not necessary that everyone should be well versed in design. I code in js and can't really do design well. If you can do good UI stuff then you can contribute to it!! They would welcome withopen arms!! Cheers!

Design is not my thing as well. I code - mobile OSes, XMPP clients, backend/frontend, native utils, games, various stuff (majority of this as FLOSS contributions, even at work ;)) I was never trained in design, I don't care about it that much. Yet I see all those wrong paddings and wouldn't do them this way even in a quick proof of concept.

I don't blame the developers, I don't blame the project. I'm glad they do such client and would probably use it over the official Slack client even with its current UI (I'm more interested in a solid XMPP transport though). I just noticed that some people genuinely don't see or can't put their finger on those issues at all, which makes them unable to think about it and fix them without external help. And I wonder why it is like that - what makes you see those misaligned things as standing out, while others don't notice it?

I thought it wouldn't be so bad, but now that I have seen the screenshots... it's pretty bad.

The thing is, a lot of developers seem to have no anesthetic sense whatsoever. I realized this when I noticed that almost all Emacs themes are garbage, and that no one seems to mind. I even wrote a blog post about it with several examples and people thought I was trolling.

I mean, just five minutes of work put into this Slack thing would have improved the look a lot, so the other commenter's point about priorities is just kind of dumb. Slack may be a piece of junk but at least it is passable in the looks department. It's not like it's the 90s or anything. How can someone think that looks aren't important?

It’s an open source project with bold text saying not to use it for work since it’s incomplete and may be buggy.

The authors goals may not align with yours, and their decision of what they want to do on their free time might not align with yours - this is exactly why releasing it to the open is a good thing, talented and interested people can contribute to it if they choose, or use something else if they are so inclined.

I’d love to try themes developed by someone with as strong opinions on design as yourself, but you wrote a blog instead. Its what you wanted to do, and you did!

Not that designers have any better ideas. Where the hell did 20px margins and 90% whitespace come from?

I tend to focus on configurability up front, while respecting system defaults. That approach doesn't always yield the cleanest results out of the box, but I'd want user feedback on functionality before I get into polishing the look and feel.

Even if they just went with 10px spacing everywhere it'd be an improvement.

Personal opinion I guess. FWIW the screenshots look completely fine to me. And most important, they don't waste so much screen space as is common with UIs created by "UI designers".

I've been trying to put this effect into words for years... You've nailed it with "wrong paddings, margins & font size". Nicely done!

As a developer who both suffers from the same issue and is a little aware of it, I would say lack of training. What do I need to read to fix this?

Regardless of comments about the required skill levels of whatever profession, in this case I think it is clear that it is because it is still in development and the screenshots are only meant to demonstrate the look of the native UI elements. Setting all the paddings to something acceptable takes time (and is just one part of perfecting a design), and that time is pretty much wasted if the layout might still change significantly.

Yes, it is called frontend development, regardless of native or web based stacks.

Care to learn about UI/UX and human psychology how regular users approach computers.

Learn how to design UIs and application workflows for people that care how to do their job, without having to understand the internals how computers work.

Requires to learn about design and soft skills as well.

Although it's important to care about stuff you mentioned, that's completely unrelated to what I meant ;)