54

Lots of programmers that I've met always says that "He is not a UI guy." The fact is that development nowadays, whether web, Windows, Linux, OSX, or any other type of development now comprises software with a good-looking UI. Why do so many developers seem to not like UI work?

Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
zero95teen
  • 323
  • 1
  • 3
  • 8
  • 55
    because they're not designers :) – Mahmoud Hossam Jan 27 '11 at 19:06
  • 5
    @Phobia: my thoughts when I read the topic. I am a coder not a graphic designer, the UI means nothing to me when I am dreaming about my beautiful underlying implementation! – Chris Jan 27 '11 at 19:22
  • 18
    Development does **not** comprise having a good-looking UI, it comprises of having a *sellable product*. Anyone can make something look good, few can make it work. – Josh K Jan 27 '11 at 19:30
  • 1
    and even fewer who can make it go faster than it already is :) – Mahmoud Hossam Jan 27 '11 at 19:40
  • 2
    This question is loaded with argumentative verbiage. Some of us are bad GUI designers. Does that mean we "hate UI part"? Does that mean we "not like UI work"? I can't see how being poorly-skilled means "hate" or "not like". Can you explain that connection? – S.Lott Jan 27 '11 at 19:45
  • 61
    @JoshK - Your main point is spot-on, but I disagree that "Anyone can make something look good". We developers get irritated at folks who undervalue our profession ("it's just typing, how hard can it be?"), so let's not do the same to other disciplines. – Steve S Jan 27 '11 at 20:28
  • 1
    @Steve: I don't mean to undervalue you, I mean to point out the even when doing web development design is not always part of the package. – Josh K Jan 27 '11 at 20:33
  • 1
    @JoshK - I wasn't personally offended, sorry to give that impression. I've just seen enough of what goes into graphic design, and even good UI design, to know that it's not as simple as it might look. BTW, in your last comment, which kind of design do you mean -- software design, or graphic design? Dang overloaded terminology. Assuming that you're still talking about the back-end and/or architecture, I think you hit the nail on the head there -- Lots of people seem think that the UI is all there is. – Steve S Jan 27 '11 at 20:43
  • 5
    @JoshK - no, not everyone can make something look good. Looking good is very important and not very many developers focus on it. Steve Jobs understands that and that is probably the best reason Apple is the most valued technology company today. – whatsisname Jan 27 '11 at 21:49
  • 21
    Let's not forget that looking good isn't the most important thing about a UI. There have been numerous good-looking UIs that were really awkward to use. I'd rather not have a graphic designer design a UI, unless the designer has some human factors background. – David Thornley Jan 27 '11 at 22:42
  • 20
    @Josh K: Having read "The design of everyday things" I think it's the other way round. Making something work is the easy part. Making it work so well users will intuitively understand it, like it and want to use it again is far harder. – nikie Jan 28 '11 at 08:02
  • 3
    @JoshK - it's easer to have a sellable product with a great UI and limited functionality than the other way around. The rest of the world buys software with a different set of criteria than developers. – JeffO Jan 29 '11 at 13:01
  • 3
    Since when do all programs have a UI? – alternative Mar 05 '11 at 01:16
  • 1
    @JoshK UI design is hard. Most people (and most programmers) suck at doing it. – c69 Dec 10 '11 at 20:57
  • 1
    @C69: That's why we have designers, right? – Josh K Dec 10 '11 at 21:55
  • @DavidThornley I agree with you 100% about not having a graphic designer for the UI. Although, I learned graphic design long before I learned computer science so I don't mind doing some UI design but I have noticed most (bad) graphic designers are 'bad' because they ignore *all* constraints! In **Systems Analysis & Design**, when done correctly, the UI should be developed in the "System Design" phase (of development), which comes before implementation (writing the code). So once you've set your specifications and systems analysis you design the UI. Then you write the implementation code. – Charles D Pantoga Aug 28 '13 at 20:18

24 Answers24

106

I'm not a UI person either. Well, I do UI on my own projects, but at work I have nothing to do with it -- my work is in the guts of the app, not on the front end.

Beyond that, I think it's more boredom than hate. Designing the UI is the hard and challenging part. Implementation is mostly grunt work. There's very little challenge or innovation in how one can implement a user interface, and there's only so many times one can put a checkbox on the screen before going slightly mental. And that's not even touching on spending hours aligning pixels "just so".

Adam Lear
  • 31,939
  • 8
  • 101
  • 125
  • 64
    +1 for "aligning pixles 'just so'", I hate that. It's 99.99999% perfect, but the user wants the border around the box, that shouldn't be there in the first place, to be 2 pixels wide, not 1, and a "lighter" shade of blue, but not the light shade you had 2 revisions ago, darker than that. And so on, and so forth... Which is what I'm going through now. The app works 100%, but I'm getting tedious requests to change the casing of this tooltip, and remove the period... this is what my "testers" are focused on... not at all functionality. – CaffGeek Jan 27 '11 at 18:30
  • 1
    @Chad: Been there, done that. – Robert Harvey Jan 27 '11 at 18:37
  • 3
    @Robert Harvey, it's a daily struggle. I wish we had one or two dedicated UI people here... it would also aid in solving our inability to standardize our UI across our major apps. – CaffGeek Jan 27 '11 at 18:41
  • 24
    +1 for noting that it's much more interesting to design a GUI than to build it. – jprete Jan 27 '11 at 18:49
  • 2
    There's also the issue that HMI design is an engineering discipline all its own, and most software engineers don't really have the training to do it well. For my part, I find implementing UIs boring and tedious as hell. – John Bode Jan 27 '11 at 19:00
  • 1
    +1. There is a difference between being capable and being willing. I'm perfectly capable of implementing CSS / JavaScript / HTML, but often I lead with a simple bare-bones design that someone else will change later. – Josh K Jan 27 '11 at 19:31
  • 5
    Implementation should never be grunt work. If it is, you've either got a poorly factored architecture, or an inefficient process. We're programmers, if we're doing something a machine could do, *we should be automating it*. – munificent Jan 27 '11 at 19:45
  • 3
    @munificent: I don't disagree, but I don't quite follow your point there. For example, how would you automate the creation of a dialog window and the alignment of controls on it? How would you automate wiring the controls to the business logic? – Adam Lear Jan 27 '11 at 19:51
  • 3
    @Chad: I had a "wrong shade of light blue" issue one time. After a bunch of nitpicking, I just took about 2 minutes to produce a gradient in Photoshop and send it to the client. "Please indicate which shade looks best to you with an arrow." They sent it back with a little red arrow pointing to the "good" shade. I implemented it like that and never had any more trouble with that particular issue. – Mason Wheeler Jan 27 '11 at 19:59
  • 3
    @Mason Wheeler, sometimes that works. Other times they pick it... but they still don't like it. Or they do, for a couple weeks. Then they change something else on the page, and decide that the blue for that border no longer "looks right", etc, etc... Or they open the page on their other computer and it looks different. The fact that the LCD is dying or a different brand, or their settings are FUBAR on it makes no difference... And if it's not that issue, it's another equally trivial one. I realize, sometimes colours matter, but not always, and if they do, research it correctly. – CaffGeek Jan 27 '11 at 20:26
  • 1
    @Anna: I've tinkered with a couple of systems that could automatically position sets of controls. If you look at HTML with things like built-in baseline alignment, you can consider it a partial solution to this problem. There are lots of frameworks to automatically do data binding. Take a look at functional reactive programming, or Adobe's Adam and Eve languages. They address exactly these two problems. In general, if the level you're working at is drudgery, try to move up to a metalevel above that and use that to automate the drudgery. – munificent Jan 27 '11 at 21:13
  • 10
    @munificent I think that automation is a great goal, but I'm yet to see an automated UI layout that didn't need adjustment to adapt to the designer's vision or customer's preference. And then there's just plain technical limitations -- if you're using WinForms, for example, your auto-layout options will be limited. Web apps have a better go of it than desktop apps, I think, but unless we can telepathically create a UI layout and wire it up, I think there will still be a fair amount of drudgery involved. I look forward to being proven wrong on this point in the future. :) – Adam Lear Jan 27 '11 at 21:21
  • 1
    @Chad: Exactly. That's the annoying thing about User Interface work: those darned *users*. If you change your memory allocation scheme or your database engine, they say nothing because they don't notice. Change the user interface and right away someone will ask "what happened to that blue border I liked?" – dan04 Jan 28 '11 at 02:11
  • 1
    @Anna: @munificent: Your frustration with all that layout and binding stuff is what I'm SO glad I don't need to worry about any more. I'm not happy about having to tout a self-developed tool, but darn it, [ *it works* ](http://stackoverflow.com/questions/371898/how-does-differential-execution-work). I've seen lots of systems *try* to address these issues, but (IME) they only get it part-way. – Mike Dunlavey Jan 29 '11 at 14:34
  • 3
    @dan04: @Chad: You say it's annoying when users change their minds about what they want. I think that annoyance comes from the amount of work it is to implement that change. If it's an easy change to make, I actually get a certain satisfaction out of saying to a product manager "So you want a checkbox to hide those controls? Done!" – Mike Dunlavey Jan 29 '11 at 14:41
  • 1
    Implementation is grunt work? No, it is puzzle solving. For example, I am currently doing a modification to the guts of a program that parses some data and I want to output a structure that shows where in the original the results came from. So I have to rearrange all of the guts because all the code flattens, whitespace removes, stems and then parses the text before getting results. Doing this in the prettiest way with the fewest layer violations is not exactly grunt work. – Zan Lynx Aug 28 '13 at 18:55
  • 2
    @ZanLynx I was talking about *UI* implementation. Stuff like arranging buttons on the screen, wiring up events to them, etc. – Adam Lear Aug 28 '13 at 18:58
  • 1
    Typically the problems I get implementing the UI is fighting against what the SDK writers assumed to do what the designer demands. It's tedious and uninteresting but still difficult to get right. Whereas writing the guts of the app I am mostly trying to get performance or implement some components in a way that composes nicely. I like doing the UI when it involves some mathematical challenge, I hate it when it is like, "round these two corners and change the background colour; PS the SDK only expects all four corners to be rounded and will fill a rectangle for the background colour otherwise." – John Cartwright Aug 29 '13 at 09:05
55

Making a good UI involves a lot of different skills than writing some backend code.

Back-end requirements can usually be specified like a black box, x goes in and it's expected that y should come out. Making it work involves implementing the logic and you can programatically test whether it works or it doesn't.

To make a good UI, you need to consider usability, visual design, layout and things like colour schemes. Having some artistic creativity is a bonus here, and many programmers don't feel that they have this. To a logical brain the solution to a UI problem may seem subjective as there is no one correct answer or no easy way to validate that it is done 'correctly'.

I think a lot of programmers that don't have much UI experience or haven't done much research into it don't realise that there are rules and science behind both good UI design from both a usability perspective and a design one (e.g. colour theory).

Of course, some programmers don't have a problem with this aspect but hate it because many UIs are just boring to code. They may consist of a lot of repetitive work like pages of forms for admin pages where they just need to be functional and there is no design challenge.

Alb
  • 3,359
  • 2
  • 20
  • 24
  • 3
    Writing backend code involves a lot of different skills too (unlike what your first comment seems to imply), it's just a different set of skills. – Matthieu M. Jan 29 '11 at 13:33
  • 2
    @Matthieu it does, and I never said it didn't. What I meant was UI coding involves a *different* lot of skills than back-end coding. Please don't think I was belittling back-end coding, it's what I mostly do for a living :) – Alb Feb 03 '11 at 23:08
  • +1: This is hard, and the normal approach for software design just doesn't work for graphics. If it is ugly, it stays ugly. –  Feb 24 '11 at 08:51
19

People just have different interests. Some programmers are more interested in data stuctures and algorithms, some in architecture, some in usability and UI design- or any combination of those and other niches. They each require different skills and different ways of thinking about a problem. If you like the low-level nuts and bolts of programming, maybe you don't care as much about how the user thinks, or vice versa.

Personally, I fall into the latter camp- I'd much rather design a UI than a complex algorithm. It's just the kind of thing that I find interesting.

Travis Christian
  • 1,851
  • 17
  • 21
16

Whether a given UI design is good or bad is fairly subjective, which I think programmers in general find unappealing. A few decades of effort to quantify and qualify good UI techniques has helped to create some broad rules one can apply, but more often than not to really determine whether a UI is any good requires a lot of A/B testing and other user-observation techniques.

While there is certainly subjectivity in programming, commonly you can point to some form of objective reasons as to why one choice is better than another: speed of execution, memory requirements, flexibility to meet likely future needs, practices that have demonstrably proven more effective in the past, etc. Defending a given UI choice -- and therefor even making the choice itself -- commonly degrades to "I like it," which is a whole different kind of argument to support.

Matthew Frederick
  • 1,719
  • 10
  • 15
  • 2
    spot on, the "subjective" is annoying. Take two people out there and they have widely different opinions of what a good UI is. You cannot unit-test a GUI aspect (not really). etc... – Matthieu M. Jan 29 '11 at 13:35
13

I personally do not enjoy UI development because I am not good at it. There is HUGE element of user psychology that I am just not good at understanding. I think my biggest issue is that I can't put put myself in the user's shoes. I do not know how to make intuitive layouts largely because I do not know what is intuitive to the user, nor do I know how to make things look pretty.

I don't necessarily think some programmer hate designing UI's as much as they hate doing things that they are not good at. It just happens that there are a lot of developers that are not good at UI development.

Pemdas
  • 5,385
  • 3
  • 21
  • 41
  • +1 - "Programmers hate doing things that they are not good at." So true. When you're doing it on a personal project, it's practice and can be fun, but when you're doing it for your job - it's performance, and if you don't have the skills, it's just stressful. –  Jun 13 '13 at 18:57
12

The problem with UI design is everybody has an opinion...And there is no right or wrong answer. Developers on the other hand love black & white and logic. In any size company everyone will agree that 1+1=2, but ask which font makes it easiest to read (Comic Sans Obviously)...get ready for the flood. Ten thousand different answers and everyone is right, because everyone is different.

MVCylon
  • 597
  • 4
  • 15
  • 6
    Oh God, Comic Sans... – Maxpm Jan 27 '11 at 23:07
  • +1 for black & white logic. I really hate making decisions about things that don't have right or wrong answers (designing UI, deciding where to live, what to eat for dinner, etc. lol). – Dan Aug 03 '15 at 19:12
7

As a developer who actually enjoys working on UI (specifically, I've done my fair share of web design), I appreciate when someone who doesn't have the skill set stays out of it.

Developing requires the ability to hold a lot of data in your mind, and deal with a lot at once. UI design requires the ability to boil it down as minimally as possible, without sacrificing its integrity. I love the challenge of that; and I cringe when I see someone create a UI that's an unmanageable wall-o-data on screen. (I'm also a total geek when it comes to layout, color theory, etc.)

On the other hand, I hate low-level stuff. I will never touch code for drivers, kernels, or anything else like that :shudder: I'll leave that to the "non-UI guys", and I'm happy someone else enjoys doing it, or it would never get done.

keithjgrant
  • 259
  • 1
  • 7
6

I think it depends of most programmers use left part of their brain.

A good source for further reading of this subject.

enter image description here

Amir Rezaei
  • 10,938
  • 6
  • 61
  • 86
  • 6
    You might enjoy the book, *Pragmatic Thinking and Learning: Refactor Your Wetware*, it gives a new way to think about the left/right brain differences. In fact, it renames them Linear-mode and Rich-mode, and is a really really great read. – CaffGeek Jan 27 '11 at 18:39
  • @Chad Thankyou Chad! I will consider it! – Amir Rezaei Jan 27 '11 at 18:40
  • +1 for bringing this up. Backend app dev is highly analytical whereas frontend work is much more creative oriented. Some people like both, but many like to stick to their respective niches. – bunglestink Jan 27 '11 at 18:57
  • Just a little additional info for those who might be interested: it is actually [not 100% clear which hemisphere plays the bigger role in determining math ability](http://www.ncbi.nlm.nih.gov/pubmed/10320379). – Dan Tao Jan 27 '11 at 23:07
  • I disagree that "music" falls under right-brain functions, especially since it's grouped with "art". Music is extremely mathematical and logical, whereas art is the complete opposite (perhaps with the exception of pixel art, where technical limitations reintroduce logic to "art"). – Dan Aug 03 '15 at 19:19
6

UI development gets complex because you get too much input from the wrong people. They're all graphical design experts. They're no where to be found when you want to know the formula for something.

They don't know what they want but know it when they see it, have no taste, and those with the decision power won't use the application anyway but are certain it should be green. You follow guidelines for good UI like limiting the amount of fields on a form and you get a request to add 50 more fields because they 'need' all of them and having them on separate tabs is too much effort. You know, the same as Excel. Peasants!

You can't make this up. I sat in a meeting where the top two people in the accounting department (approx. 500K/year salary) for a large law firm spent half an hour arguing over a label on a billing website page used by the lawyers. This was suppose to make it easy for the lawyers to understand. Why not just ask the lawyers? Too easy. So the IT department gets to field 50 phone calls from lawyers wanting to know WTF "Residual Net Billing Amount" is and why is it on their time entry form.

JeffO
  • 36,816
  • 2
  • 57
  • 124
5

Some people like broccoli, some don't. We might have to eat it, but we don't have to like it and we are not going to enjoy it when we do eat it. Not only that, we are going to avoid having to eat it as much as we possibly can.

There are A LOT of other things to code than just the UI. Web Services, Windows Services, embedded (not much of a UI on a microwave), just to name a few examples.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Muad'Dib
  • 2,608
  • 18
  • 14
  • 9
    The UI usually gets short shrift on a microwave, which is why most of them suck. – Robert Harvey Jan 27 '11 at 18:34
  • 4
    The thing with a microwave is, when you have a good one, with a nice UI, where you don't need a very specific order to the buttons to accomplish a task, you don't even think about it. But when you buy that cheap bargain microwave for the basement, or whatever, you notice right away how horrible the UI is on it. You have to memorize precise orders of pushing buttons. Do I pick the power level before the time? Or after? Do I have to hit cook time first? etc, etc... And when you need to read the instructions hidden inside?! UGH! A good UI should be "invisible" to the user. – CaffGeek Jan 27 '11 at 18:48
  • Terrible metaphor. I love broccoli but hate designing UI. ;) – Dan Aug 03 '15 at 19:16
4

That might be because - in some cases - tools that are expressly conceived to help you draw the UI suck dead baby monkeys through a straw instead.

s.m
  • 766
  • 4
  • 12
4

There are certain things in UI development that are difficult to get right.

Layout is one of them. I've been building UIs for over 15 years and have not yet still a decent solution to layout management.

Another is event routing - even with MVP architectures and stuff mandated by frameworks, I would argue that most complex UIs have event routing problems - which might be discovered if any of the testing frameworks could address them well.

Uri
  • 4,836
  • 1
  • 18
  • 23
3

I know that for me I used to hate UI dev because I found it very tedious and slow, especially writing layout code to position things in a form or winow. Now with UI designer tools such as the Forms Designer in Visual Studio, I almost enjoy it. Other reasons for hating it I've heard from others included "it's stupid", "it always changes too much", "it's not challenging enough", "it's tedious/boring".

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • 4
    How does you answer square with your user name? :) – Robert Harvey Jan 27 '11 at 19:37
  • @Robert Harvey: Fair enough! The Forms Designer is good, but when you start getting fancy with generic UI containers, it starts to choke. Or at least VS2008 did. Haven't yet tried 2010, but I suspect it may have similar issues? Either way the problem was eventually resolved (See my very first post on SO). There are other things that choke it too but it removes enough of the tedium that I *usually* now enjoy UI design/development. – FrustratedWithFormsDesigner Jan 27 '11 at 19:39
3

Why don't all chess players like designing chessboards and the pieces they play with?

It's not weird that some people don't like that... it's weird you expect we should.

  • 1
    chess players don't design chess boards and pieces because those designs have for over a century been standardised by the international chess federation (FIDE) and those standards have been universally adopted. – jwenting Feb 24 '11 at 10:25
2

I like working on the UI. That wasn't always true for me, but my enjoyment of UI work has increased as I've gotten better at it over the last few years. I do know some developers should not be allowed near a stylesheet, or a color palette. It's definitely a different skillset, and not everyone has it.

Marcie
  • 3,009
  • 2
  • 19
  • 21
2

I don't as much hate UI work as I hate some UI frameworks. E.g. I've been programming .NET for >10years. The frameworks for creating web applications are great (ASP.NET WebForms and ASP.NET MVC). But the frameworks for writing desktop applications, well, I'm not fond of them (WinForms and WPF).

So in this respect, writing GUI applications is more an aspect of using frameworks I don't like.

There is another aspect. I often work with "enterprise"-style applications, i.e. applications where a desktop application needs to receive data from a server. In this case, there are so many layers of conversion of data from one format to another that it gets really really boring.

E.g. the application receives information through a series of DTO objects. The application then creates it's own model representation of the data (not reusing the same domain classes that were created on the server). The model classes are consumed by a view model (in a WPF MVVM pattern), that exposes the properties on the model.

That is a lot of times that the same data is represented by different classes. And that gets boring. But this is a problem specific to this type of desktop application.

There are also interesting challenges in this type of application, such as how do we get changes from one client to update immediately on another client.

Pete
  • 8,916
  • 3
  • 41
  • 53
  • ++ I know what you mean. For the last point about propagating updates between clients, I use polling (typically 1-second), but that probably only works for a fairly small DB and small number of clients. – Mike Dunlavey Jan 29 '11 at 14:54
2

I'm not a huge fan of UI development for these reasons:

  1. As a developer, you have less freedom to create: The customer can see and have opinions about every little facet of the UI, which you have to react to. You'll get requests like: change the color of this; move that button there; never mind, move it back. The back-end code is rarely as visible.

  2. UI is messier, while the back end is more "platonic." While I've seen ugly messes of back-end code, I think it's more common for it to be clean (from a code perspective) than UI code. A UI can be really clean looking and well designed for the user, but since I'm a developer and spend more time in the code than using it, I take a greater liking to clean code.

  3. I feel that UI is more of a "plumbing" than the back-end, i.e. there's less opportunity for clever algorithms and really pushing your brain to the limit.

Kaypro II
  • 356
  • 5
  • 11
1

Having worked on both sides of the coin i.e. UI design and the backend code, I found that both sides of the coin are basically the same thing.

Requirements that differ from what you do day to day do not come all the time and now in the era where all services revolve around CRUD then it becomes boring.

Anyway, coding the frontend allows better interaction and crazy dynamisms that basically screw an inexperienced hand in frontend design. I personally learnt the hard way in frontend and can comfortably say that designing frontend is far much more interesting and challenging.

Remi
  • 1
  • 1
1

As a CS student you'll be taught data structure, database, C++...except UI. So you'll not good at it from beginning. If you are not good at it, you'll hate it.

user16764
  • 3,583
  • 1
  • 25
  • 22
卢声远 Shengyuan Lu
  • 1,539
  • 2
  • 16
  • 25
1

I do both UI (desktop, not web) and internal guts.

The amount I like or don't like either one depends on how much I can get done using something like a domain-specific-language (DSL).

In the UI domain, what I am presenting to the users, and the complexity of the information I am getting from them, is such that I would go crazy if I had to use typical tools, like forms designers, lots of event handlers, MVC, all that "state of the art" stuff. Thankfully, decades ago I discovered what I think is a better way, which is to make a DSL for it, and work in that. Currently I call it Dynamic Dialogs, and it's based on a control structure I call Differential Execution. The good news is, for a given functionality, the source code is roughly an order of magnitude less, allowing me to put a lot more functionality into the UI. The bad news is, as much as I've tried to teach it, I haven't had much luck transferring the technology.

In the non-UI domain, I took a lesson from a number of products that started out as DSLs usable from the command-line, on which a UI was later grafted. That gives the expert user something where they can bypass the UI, while giving the casual user something they can use casually. (Examples: R, SPlus, Matlab, SAS, WinBugs.) So our product has a command-line language for experts. I love developing such things, with a parser, code generator, precompiler, and run-time modeling engine. The effort spent on that is at least a power of 10 less than the effort spent on the UI.

One reason the UI effort is so much is there's still a lot of "glue" that can't be done with a DSL - managing data grids, all kinds of ways of sorting data, all the stuff that falls in the yawning "crack" between pure UI and underlying language.

So your question was "Why do some programmers hate the UI part of development?". I only hate it because of that "glue" for which I don't have a DSL.

Community
  • 1
Mike Dunlavey
  • 12,815
  • 2
  • 35
  • 58
1

Honestly I find that finding the best GUI toolkit then actually learning the ins and outs of that is kinda a PITA... not to mention you don't learn much UI stuff in college and im a newbie so......ya..

1

Beyond what's already stated (it's tedious, boring, frustrating work to code it and the design is usually done up front by someone who has no clue as to what problems his ideas cause for those trying to implement them), an important factor is that you're having to work with people whose ideas about what you should be making change constantly, far more so than they do for the backend. As a result, you're shooting against a moving spec even more, and these people tend to be nitpickers too. I've literally have user interfaces fail tests because a components was 1 pixel off the location the person testing it thought it should have been. Did it work? Yes. Did it look good? Yes. But he started counting pixels and something was a single pixel out of line with the rest, so he sent it back for rework.

jwenting
  • 9,783
  • 3
  • 28
  • 45
1

A few more points:

1) UI Design can be harder to test, sure you can check if that button does what it should, but testing if it is easy to use that is harder. How about testing if it will be usable with someone with a disability?

2) Many programmers are not trained on it, and don't know much about it.

Zachary K
  • 10,433
  • 2
  • 37
  • 55
1

The fact is lots of UI tools/framework/API are bad, complex, far far away to be intuitive. I developed with Win32 API in C / C++, with javax.swing, CSS, etc Since that, i hate have to deals with UI development... Until Qt framework !

canardman
  • 103
  • 3
  • 1
    You mean you burned out on tools that are no longer in common use (most people would not use Win32 for UI programming these days)? Sorry, I just don't consider this a valid point. – user16764 Jul 15 '11 at 19:29