The UI grind
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
-
Yeah, I can't really do that in 300kB of primary ram and 4MB of 80mhz secondary ram on a CPU @ 240mhz attached at 20mhz to an 800x480 display. There's very little room for any niceties. I do support True Type on it though. :)
Real programmers use butterflies
Reminds me when I worked on a WYSIWYG emulator app for HP LaserJet printers. This was back in the old DOS days (the original IBM PCs had just came out a few years earlier) and was written in assembler as a .COM app. I developed the user interface similar to Lotus-123. Was actually fun and something I still remember with a bit of pride...
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
You must not be using MVVM. If you were, a visual designer would show up to do the visuals for you.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
You must not be using MVVM. If you were, a visual designer would show up to do the visuals for you.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
Yeah, you don't get visual designers with these particular MCUs and frameworks. Nor a lot of RAM. Nor a lot of CPU. It's not like desktop or web development.
Real programmers use butterflies
-
It can be a grind, but I'm actually enjoying Angular at the moment. There are plenty of interesting and challenging parts. Typescript, CSS, etc.
Yeah, I like the idea of typescript but I can't make heads or tails of angular and similar frameworks, with all their "routing" and stuff. It confuses me.
Real programmers use butterflies
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
honey the codewitch wrote:
Does anyone actually like creating screens/user interfaces? It's a slog, making screens. Just rote code and very little problem solving or creativity.
I'll try not to take your comments personally. I've spent the last 20 years at my current employer doing the user interfaces and installers for our line of commercial ink-jet printing systems[^]. Our older products used C++/MFC, and our current ones C#/WPF. I genuinely enjoy what I do. The challenge comes in making the product's features available to the user in a way that they can easily discover and understand. WPF provides wonderful tools for making articulate, capable UI's in a fairly short amount of time. Our UI's are heavily graphical since they are acting as the control panel for a complicated piece of machinery. That said, the "screen stuff" that others in this thread have derided actually isn't as much of my job as you might think. My UI applications are multithreaded out the wazoo. They communicate with one or more Windows services that handle hardware control. We have external interfaces for control from customer workflow equipment. There's a substantial data management facet to things, keeping track of the machine configuration and setup. A major part of my job is to insulate the user as much as possible from timing and other dependencies imposed by the hardware. I acquired this part of my team's workload by default. Nobody else wanted to do it, which seems to correspond with the prevailing view in this thread. In my view, both the "screen stuff" and the underlying application require significant creativity and skill. The creativity comes from considering the user, the foremost priority when designing a user interface. Skill comes from mapping that consideration onto your product features flexibly and efficiently. I gain significant satisfaction from doing both.
Software Zen:
delete this; -
Yeah, I like the idea of typescript but I can't make heads or tails of angular and similar frameworks, with all their "routing" and stuff. It confuses me.
Real programmers use butterflies
-
Angular does have a lot of set up, but it's not too bad once you get the hang of it. The lexical parsing and other things you do hurt my brain... :laugh:
I swear that stuff only looks difficult because I'm the one teaching it. If it was truly difficult, I wouldn't be able to make anything of it either. :laugh:
Real programmers use butterflies
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
Graphical UIs (not UIs in general, CLIs can often be hacked together easily which would explain why most CLI tools out there require arcane knowledge & a goat every now and then to use properly) are somewhat of a pain indeed. I came to regard that good old 80/20 rule as "you spent 20% of the work on actual functionality, 80% of the myriad UI details". Well, it really depends on how you regard the situation. When you're supposed to ship a product to end-users, then the GUI is indeed a crucial product feature. And it's not like doing GUI work sucked by default, it's just that it's a whole different kind of work from that algorithmic back-end work. However, I very much disagree on "little problem solving and complexity". Granted, that heavily depends on the product in question but I gotta say, the GUIs I'm working on require quite a lot of problem solving due to complex & (optionally) interconnected workflows the product is supposed to allow. The stuff I'm doing is not mundane dilligence-first creativity-never. And quite frankly, the moment there's no creativity involved, I'd write a GUI generator which takes my back-end data structures and just plops auto-generated GUIs on top of them. The biggest problem, aside from GUI being a whole different way to think (to, let's say, churning data in back-end), is the reliance on the product manager. As I said, the stuff I'm working on does a lot of (complex) things. That means that a dude talking to the users of this piece, discussing how the GUI could be set up to serve their needs, is invaluable. I sooooo wouldn't want to sit in customer seminars, let alone talking with customers! Who would apparently rather kill themselves, than say CLEARLY what they mean. So far, so good. The problem is, this dude isn't a developer. Meaning he doesn't quite get the concept of "If we talk about what we want in advance, this whole thing would take 1 week. If you keep on dropping tiny tidbits you want to have added after I'm basically done, it'll take a month." but I'm still glad to have him. And I think, such culture clashes are manageable. Meaning after I got proactive about suggesting potential extension points, defining by myself which kinds of changes could be dropped at which stage of that particular GUI development, things really got better. But yeah, if the GUIs I was doing required no problem-solving/creativity, I'd just automate the shit out of GUI building and call it a day.
-
Graphical UIs (not UIs in general, CLIs can often be hacked together easily which would explain why most CLI tools out there require arcane knowledge & a goat every now and then to use properly) are somewhat of a pain indeed. I came to regard that good old 80/20 rule as "you spent 20% of the work on actual functionality, 80% of the myriad UI details". Well, it really depends on how you regard the situation. When you're supposed to ship a product to end-users, then the GUI is indeed a crucial product feature. And it's not like doing GUI work sucked by default, it's just that it's a whole different kind of work from that algorithmic back-end work. However, I very much disagree on "little problem solving and complexity". Granted, that heavily depends on the product in question but I gotta say, the GUIs I'm working on require quite a lot of problem solving due to complex & (optionally) interconnected workflows the product is supposed to allow. The stuff I'm doing is not mundane dilligence-first creativity-never. And quite frankly, the moment there's no creativity involved, I'd write a GUI generator which takes my back-end data structures and just plops auto-generated GUIs on top of them. The biggest problem, aside from GUI being a whole different way to think (to, let's say, churning data in back-end), is the reliance on the product manager. As I said, the stuff I'm working on does a lot of (complex) things. That means that a dude talking to the users of this piece, discussing how the GUI could be set up to serve their needs, is invaluable. I sooooo wouldn't want to sit in customer seminars, let alone talking with customers! Who would apparently rather kill themselves, than say CLEARLY what they mean. So far, so good. The problem is, this dude isn't a developer. Meaning he doesn't quite get the concept of "If we talk about what we want in advance, this whole thing would take 1 week. If you keep on dropping tiny tidbits you want to have added after I'm basically done, it'll take a month." but I'm still glad to have him. And I think, such culture clashes are manageable. Meaning after I got proactive about suggesting potential extension points, defining by myself which kinds of changes could be dropped at which stage of that particular GUI development, things really got better. But yeah, if the GUIs I was doing required no problem-solving/creativity, I'd just automate the shit out of GUI building and call it a day.
I guess I overstated it. Basically here's the thing - I'm working on a machine running @ 240Mhz, with 300kB of usable internal RAM, 4MB of PSRAM accessible via SPI @80MHz, and a display operating at 20MHz. You'd think I'd need a lot of creativity to make that work. I did. I already put all that creativity into GFX - the library I used to make these screens. Basically, in a sense I did automate the sh*t out of it. But I can't automate everything. For starters, typesetting true type fonts without some sort of sophisticated open-type layout system requires manual tweaking, as does just figuring out where to put everything in 480x800 (yes the display is in profile) I'm considering adding a .bmp save feature just so I can render the screens to files on PC (GFX runs anywhere but i don't have drivers for windows so it will only draw to bitmaps) and that would save some turnaround time because of the upload times on the device every time i make a code change. I haven't had time to build out my layout/"windowing" engine yet or this would be somewhat easier. The bottom line though is, the creative stuff is behind me. Now it's just placement and tweaking. The actual functionality of the UI is pretty limited due to the nature of the device. The only challenge was making it pretty on a machine this petty.
Real programmers use butterflies
-
I swear that stuff only looks difficult because I'm the one teaching it. If it was truly difficult, I wouldn't be able to make anything of it either. :laugh:
Real programmers use butterflies
-
I think some brains are just wired in a way that they can make sense of certain things (math, parsers, etc.) easier than others can :)
and others can understand Angular. :laugh:
Real programmers use butterflies
-
I guess I overstated it. Basically here's the thing - I'm working on a machine running @ 240Mhz, with 300kB of usable internal RAM, 4MB of PSRAM accessible via SPI @80MHz, and a display operating at 20MHz. You'd think I'd need a lot of creativity to make that work. I did. I already put all that creativity into GFX - the library I used to make these screens. Basically, in a sense I did automate the sh*t out of it. But I can't automate everything. For starters, typesetting true type fonts without some sort of sophisticated open-type layout system requires manual tweaking, as does just figuring out where to put everything in 480x800 (yes the display is in profile) I'm considering adding a .bmp save feature just so I can render the screens to files on PC (GFX runs anywhere but i don't have drivers for windows so it will only draw to bitmaps) and that would save some turnaround time because of the upload times on the device every time i make a code change. I haven't had time to build out my layout/"windowing" engine yet or this would be somewhat easier. The bottom line though is, the creative stuff is behind me. Now it's just placement and tweaking. The actual functionality of the UI is pretty limited due to the nature of the device. The only challenge was making it pretty on a machine this petty.
Real programmers use butterflies
Ah, I see your point. So if I get it right, you're doing a heap crap lot of grunt work, GUI boilerplate not being any more enjoyable, than any sort of boilerplate. That's why I didn't get your point first, my product is a Windows executable and Windows is pretty good at taking grunt boilerplate off my shoulders.
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
Yes, I enjoy it, but then I work in plain vanilla php, building things from scratch, so there is plenty of creativity involved. Most often, working with legacy code, I must just copy the ui of other pages in the code, but occasionally I do get to build something new and I enjoy figuring out the CSS to make it work (there is a rule around here, soon to change, thank God, that we only use javascript when we also have a noscript option). Even though I know that I'm often reinventing the wheel, I find it a fun little diversion. I also enjoyed deriving physics formulas from scratch in my college classes, so that's a clue ;)
-
Ah, I see your point. So if I get it right, you're doing a heap crap lot of grunt work, GUI boilerplate not being any more enjoyable, than any sort of boilerplate. That's why I didn't get your point first, my product is a Windows executable and Windows is pretty good at taking grunt boilerplate off my shoulders.
I've done some UI work on an arduino - note the lack of the G but it's still a UI. Rotary encoders, buttons, joysticks, it's still all UI. I totally get the "how can I automate this?"
-
honey the codewitch wrote:
Does anyone actually like creating screens/user interfaces? It's a slog, making screens. Just rote code and very little problem solving or creativity.
I'll try not to take your comments personally. I've spent the last 20 years at my current employer doing the user interfaces and installers for our line of commercial ink-jet printing systems[^]. Our older products used C++/MFC, and our current ones C#/WPF. I genuinely enjoy what I do. The challenge comes in making the product's features available to the user in a way that they can easily discover and understand. WPF provides wonderful tools for making articulate, capable UI's in a fairly short amount of time. Our UI's are heavily graphical since they are acting as the control panel for a complicated piece of machinery. That said, the "screen stuff" that others in this thread have derided actually isn't as much of my job as you might think. My UI applications are multithreaded out the wazoo. They communicate with one or more Windows services that handle hardware control. We have external interfaces for control from customer workflow equipment. There's a substantial data management facet to things, keeping track of the machine configuration and setup. A major part of my job is to insulate the user as much as possible from timing and other dependencies imposed by the hardware. I acquired this part of my team's workload by default. Nobody else wanted to do it, which seems to correspond with the prevailing view in this thread. In my view, both the "screen stuff" and the underlying application require significant creativity and skill. The creativity comes from considering the user, the foremost priority when designing a user interface. Skill comes from mapping that consideration onto your product features flexibly and efficiently. I gain significant satisfaction from doing both.
Software Zen:
delete this;Quote:
The creativity comes from considering the user, the foremost priority when designing a user interface.
When I have said this very sentiment to people in the past, I very often receive head-tilted, forehead scrunched, incredulity in response. I would make one caveat, however. The same sentiment applies to everything else in software. Even to the point of having empathy current and future colleagues who may come later to repair or extend one's work. Empathy is a highly underrated character asset. Just my opinion, of course. :)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
I liked the days of the old Winforms. I don't mind HTML, but super dislike XAML and scaffolds like React. I can work in them, but they are not fun to me and I find myself delaying building them. Note I have not tried the new Winforms yet.
-
Yeah, I can't really do that in 300kB of primary ram and 4MB of 80mhz secondary ram on a CPU @ 240mhz attached at 20mhz to an 800x480 display. There's very little room for any niceties. I do support True Type on it though. :)
Real programmers use butterflies
About 40 years ago I wrote a full screen text editor with word wrapping that ran in 8kb of RAM (about 7K of code and 1k of data) and could handle editing large files by windowing through them (it used a second temp file to manage the data it couldn't keep in memory, with a stack algorithm to keep it fast). Oh, and it was all hand coded assembly (I also wrote one in BASIC to run on the same hardware, but it was more restrictive and had to page code in and out). It should be 'easy' to write a dynamic screen layout system in 300k, as long as you apply appropriate restrictions (e.g., no 1MB GIFs) ;)
-
About 40 years ago I wrote a full screen text editor with word wrapping that ran in 8kb of RAM (about 7K of code and 1k of data) and could handle editing large files by windowing through them (it used a second temp file to manage the data it couldn't keep in memory, with a stack algorithm to keep it fast). Oh, and it was all hand coded assembly (I also wrote one in BASIC to run on the same hardware, but it was more restrictive and had to page code in and out). It should be 'easy' to write a dynamic screen layout system in 300k, as long as you apply appropriate restrictions (e.g., no 1MB GIFs) ;)
A simple layout engine i could do given the time. This isn't really about that though. See the rest of the thread.
Real programmers use butterflies
-
Does anyone actually like creating screens/user interfaces? I wish I had someone to delegate this to. I wrote some fantastic supporting code to make all the screens look pretty, with an easy(ish) to use API (given its complexity and large featureset) - that doesn't mean I want to have to use it myself! :laugh: It's a slog, making screens. Just rote code and very little problem solving or creativity. It's times like this that make me eager to move on to my next project.
Real programmers use butterflies
Been a full-stack developer for a WinForms app for 15+ years. I actually enjoy the UI part as much as the rest (code, DB design/development). I am very particular about my UI work and have established a number of standards that I consistently follow. I make sure the other devs (who are much, much newer to the project than me) follow the same standards. They are not overly happen about that... :)