Timeline for Why do some programmers hate the UI part of the development?
Current License: CC BY-SA 2.5
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 29, 2013 at 9:05 | comment | added | John Cartwright | 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." | |
| Aug 28, 2013 at 18:58 | comment | added | Adam Lear♦ | @ZanLynx I was talking about UI implementation. Stuff like arranging buttons on the screen, wiring up events to them, etc. | |
| Aug 28, 2013 at 18:55 | comment | added | Zan Lynx | 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. | |
| Jan 29, 2011 at 14:41 | comment | added | Mike Dunlavey | @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!" | |
| Jan 29, 2011 at 14:34 | comment | added | Mike Dunlavey | @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 ](stackoverflow.com/questions/371898/…). I've seen lots of systems try to address these issues, but (IME) they only get it part-way. | |
| Jan 29, 2011 at 11:25 | history | made wiki | Post Made Community Wiki | ||
| Jan 28, 2011 at 2:11 | comment | added | dan04 | @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?" | |
| Jan 27, 2011 at 22:23 | vote | accept | zero95teen | ||
| Jan 27, 2011 at 22:23 | vote | accept | zero95teen | ||
| Jan 27, 2011 at 22:23 | |||||
| Jan 27, 2011 at 22:23 | vote | accept | zero95teen | ||
| Jan 27, 2011 at 22:23 | |||||
| Jan 27, 2011 at 22:22 | vote | accept | zero95teen | ||
| Jan 27, 2011 at 22:22 | |||||
| Jan 27, 2011 at 21:21 | comment | added | Adam Lear♦ | @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. :) | |
| Jan 27, 2011 at 21:13 | comment | added | munificent | @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. | |
| Jan 27, 2011 at 20:26 | comment | added | CaffGeek | @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. | |
| Jan 27, 2011 at 19:59 | comment | added | Mason Wheeler | @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. | |
| Jan 27, 2011 at 19:51 | comment | added | Adam Lear♦ | @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? | |
| Jan 27, 2011 at 19:45 | comment | added | munificent | 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. | |
| Jan 27, 2011 at 19:31 | comment | added | Josh K | +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. | |
| Jan 27, 2011 at 19:00 | comment | added | John Bode | 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. | |
| Jan 27, 2011 at 18:49 | comment | added | jprete | +1 for noting that it's much more interesting to design a GUI than to build it. | |
| Jan 27, 2011 at 18:41 | comment | added | CaffGeek | @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. | |
| Jan 27, 2011 at 18:37 | comment | added | Robert Harvey | @Chad: Been there, done that. | |
| Jan 27, 2011 at 18:30 | comment | added | CaffGeek | +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. | |
| Jan 27, 2011 at 18:24 | history | answered | Adam Lear♦ | CC BY-SA 2.5 |