You see this shit SO much more often than you would think. And the infuriating thing is, it seems to be most common among programs that are INCREDIBLY complex and sophisticated.
It’ll be like this:
“What does my program do? Glad you asked. It simulates stress patterns in glass and ceramics, after they come out of a kiln. You can specify any melting temperature, adjust the composition of elements in the glass, and the ambient temperature of the cooling and tempering stages.”
“Wow, can you show me how it works?”
“Sure! <opens a command line and starts typing commands>”
“O-oh. Do you have any plans to add a graphical user interface?”
“HAHAHAHAHHA, no. That’s never happening. And here I thought you were serious about using advanced software, and being an intelligent person.”
Obviously, that last part is just kinda implied. But sometimes, when users request a GUI, the goddamn developer will kinda get in their face, like that.
They always fall back on the position of “well, I developed this shit for free, for your ungrateful ass. So you can build your own fucking GUI.”
But the thing about that is…no. And fuck you. I shouldn’t have to be two-thirds of a fucking developer, in order to use the fucking software.
If you can figure out how to simulate molecules, or draw 3D stereograms, or translate hieroglyphics, or any other RIDICULOUSLY COMPLICATED SHIT, making a graphical user interface should be nothing to you. You should be able to do it in a fucking afternoon.
IT DEFINITELY SHOULD BE THE EASY PART, FOR YOU.
All the rest of us, who aren’t programmers? We envy programmers, and their ability to really connect with computers, on that deep logic level.
If we could do that shit, we would. But a lot of us have tried, and we realize it’s not a good use of our time. We can do cool stuff with software, but it’s just not ever going to be worthwhile for us to struggle through the act of creating software.
Also, I hasten to add that I have put in my time, using command line interfaces. I used DOS, I used BBS systems, I have used modern command-line-only programs. I know how to do it, but I DON’T WANT TO.
I don’t want to have to memorize commands. I don’t consider a GUI workflow to be some kind of weird luxury. It has been a basic part of modern software, for around 40 years at this point. Literally get with the program, guys.
If you’re serious about making software, get your shit together and implement a fucking GUI from the very first release. Nobody ought to be taking you seriously, if you refuse.
Command line software isn’t for your average end user, I agree with that. If you expect your user to be able use the command line, you’re targeting a tech-adept niche audience. That doesn’t make the software bad, unless it claims to be usable by anyone. It just means that most people won’t be able to use it, and that’s fine.
If you don’t like the free software people give you, you’re free to buy or build your own. If you don’t want to use the terminal, that’s okay! You can buy software from someone else who does the same thing in a GUI, or hire someone to make a GUI wrapper around the program you’ve bought. You could even ask for a refund if the program isn’t as easy to use as it said on the website.
Of course, nobody is going to care about what you want if you’re taking the stuff other people make for free. Complaining online doesn’t make anyone interested in uploading that .exe to Github that you’ve been demanding. Get your shit together and pay someone to do the work for you.
I’m a senior software dev and have built a shitload of tools and scripts that are command line only. I’ve been told that I’m a really great developer, and I have a knack for figuring things out, even when there’s no documentation.
For the life of me, I absolutely cannot wrap my head around frontend shit. Like, I can do markdown just fine. HTML? CSS? Any of the popular frontend UI frameworks? I just seem to have some sort of conceptual and motivational block that prevents me from figuring out how to make those accursed fucking frontends.
It’s such a different form of software development. I wish I could wrap my head around it, but I’ve accept that I’m not ever going to be a frontend dev. I just write server side stuff and scripts. I apologize if you ever have to use my software :(
I appreciate your perspective. I’ll also fire off a question at you, which I’ve also posed to some of the other participants in this discussion:
Why is all of this so different, when you shift the frame to game development? Modern game engines are built to allow EXTREMELY fast implementation of realtime GUI elements. When you go to study gamedev, you’re tying GUI elements to backend code in literally the second hour of the coursework.
So why aren’t game engines used for productivity and specialized-use-case software?
Conversely, I think that every program should have a way to operate it from the command line and the GUI can just needlessly get in the way a lot of the time ¯_(ツ)_/¯
You write a command once and you can do whatever you want with it, repeatably, forever. It’s fantastic! You can then pipe the results into a completely different program all without needing to do much of anything! Want to run it on a schedule? Easy! Want to send the exact parameters you used to someone else? Easy! Want to copy and paste the exact output? Easy! Want to get a daily email with the results? Easy!
Some things are better with a GUI, but, plenty don’t need it.
With all that said, I understand why a dev who didn’t build their program with CLI in mind wouldn’t want to go in afterwards and add it in, especially if they don’t use/like CLI interfaces.I’ve seen similar arguments to yours that every program should have be packaged as an exe, because fuck those fucking programmers thinking I should need to install python to make their shitty programs work. The devs are like “I don’t use Windows and wouldn’t even know how to package it as an exe and even then, I wouldn’t even be able to test that it works, python just works for everyone” and then the guy just continues to go off on a similar rant to yours about how ridiculous this is.
Besides, even if it had a GUI, the complaint would be “why don’t they make their software do the things that people want it to do‽‽‽” and then going off about how easy this {insanely complicated thing} would be to add in and EVERYONE {nope, just you} needs this function in order for this software to be useful and the dev is just a POS for not adding it.
Like, I get your point if you’re paying for software that doesn’t make it clear it doesn’t have a GUI, but if you’re just on github using someone elses software that they made for themselves and thought other people might like, why are you bitching? Just move on to another piece of software that can do what you want and has a GUI (I’m going to guess you can’t/won’t because those cost money and you wouldn’t be able to belittle and harass the actual software creators and that’s half the fun for you).
Upvote for solid unpopular opinion post. Also a fairly entertaining rant.
They always fall back on the position of “well, I developed this shit for free, for your ungrateful ass. So you can build your own fucking GUI.”
But the thing about that is…no. And fuck you.
Okay, but consider this: yes.
And fuck you.
Yeah GUI development isn’t easy or straightforward. Thats why there are UI/UX engineers who’s sole job is to design and create simple and easy to use interfaces. And they get paid big money to do it too.
If those programmers making ultra specialized software were to waste their time making a GUI, they would never finish the project or would require funding of some sort.
Those ultra-specialists are paid to make GOOD GUIs, for software that is going to cost real money.
I just want a fucking window with fucking buttons on it, so that I don’t need to refer to a cheat sheet of fucking text commands. I don’t care how ugly the UI is.
That makes a HUGE difference, and you know it. There have been libraries, development environments, fully featured frameworks, and templates for basic GUI structures, for almost as long as there have been GUIs.
I mean, for fuck’s sake, does anyone remember Visual Basic? I even developed some shitty software in that language, back in the day.
And, more to the point, there are a bunch of solo developers who do make graphical applications. If this conversation has to come down to me saying “well, this is a skill issue. If you want users, you’re gonna have to step up your game and learn to play like the big boys do,” then so be it. That’s my position, then.
Even if I’m getting the software for free, GUI development being oh-so-difficult is not my problem. If you want to develop software, get your shit together and accept that GUI is kinda here to stay, as a concept.
I mean, not for nothing, but phone apps are all GUI based. There are outreach programs that have volunteers teaching random hobos and 11-year-olds to make phone apps. If they can do it, grown-ass nerds can do it. Fucking facts.
This is a really good and entertaining post and thanks for making it
As a guy who burned out super, super, super, super hard to the point that thinking about code–even though I’m good at it–just makes me feel baaaad, I still can’t help but chuckle. Like, in my case, providing what I did to the code world was literally all I could do before I stopped being able to contribute because it hurts inside my brain lol.
But at the same thing the fucking most hilarious part of it is you’re right 🤣 People do just not see software as “real” if it involves any reading and typing outside a comment box. Buttons and visualizations are truly everything if one wants to code and be taken seriously by anyone but other hackers. 😭😂 I wonder how much low hanging fruit there is out there of software that people could just make a paid GUI for and make a killing
I really appreciate this perspective. It really is a matter of software dying on the vine, because it’s truly not possible to use it for its actual purpose, if you have to be looking at a cheat-sheet of commands.
As I explained to someone else in the thread, I don’t need the UI to be pretty. I just need it to be visual. And, just to stress the point, it’s not about feelings. It’s about me actually using the software to produce data or art or whatever complex output that I’m using it for. Actual use cases are not the same thing as the developer testing all the inputs in a command line, and going “well, it doesn’t really need a GUI, does it? I mean, I just proved that, when I tested all the commands.”
I think that’s a big part of the disconnect. Sometimes, developers make software that they’re going to use themselves, but in many (most?) cases, they really aren’t going to be the users. The actual users are going to need their brain space for CREATING A THING with the software, and that means it’s really not okay to be clogging that brain space up, with the need to remember commands, and where they are in the text-based workflow of the software.
I mean, going back to the first principles of the whole matter, that is WHY THE GRAPHICAL USER INTERFACE WAS CONCEIVED, wasn’t it? That’s the killer application of the whole concept. The user can be free to think about what they’re doing, and not how they’re doing it.
I don’t get it. If you remember the days of visual basic, why not grab Gambas and make your own GUI? Hell, you can still run Visual Basic 6 on modern versions of Windows. All you need to do is add a few buttons that add a bunch of command line arguments, you’ll only need to read the documentation just once!
Even if I’m getting the software for free
Lol. Lmao even.
Congrats on the true unpopular opinion lol.
I’ll add one thing that I don’t think has been said, adding gui adds a lot to the dependencies and complexity of maintaining a program. Keeping it in the cli keeps the size of the program down, and ensures it will work longer and on more devices since it’s dependent on less libraries that could change.
Because of that, if a cli program gets a gui it’s usually a separate project, like how yt-dlp has front-ends like this.
I asked another person this, but I’ll ask you, too:
Why is all of this SO INCREDIBLY DIFFERENT when it’s a game being developed, instead of a program that does non-game stuff?
When you go to learn game development, every student is being taught to use an engine to manipulate graphical elements in, like, the second hour of study. Why not use engines (even the same game engines) for non-game applications?
Is there some real reason not to do this, especially for small projects? Am I missing something fundamental?
Front end and back end development are two very different things. I can write extremely complex software, but I couldn’t design or code a GUI to save my life.
They’re two very different skill sets.
I suppose there really does need to be a renaissance of people trying to contribute on the frontend side.
I do feel some real motivation to get my shit together, learn Godot, and start shoving small open-source projects into it. I could make a difference.
Exactly, be the change you want to see in the world. You’ve identified a problem that you feel strongly about, just like the developers of the esoteric software. If GUI development is something you can get into, go for it (plus, good front end devs make a lot of money).
Games are already doing a lot of complex things, and pretty much all games are inherited graphical (other than text adventures I guess).
And a game engine is useful since it helps you do a lot, but it’s also a huge dependency with a lot of moving parts. This can be a problem even for games, but games do so many things that having an engine often outweighs the downsides.
Using ytdlp as an example again, that just has to connect to the Internet, and write to a file. Using a game engine for that would be major overkill and make the project way bigger then it has to be, as well as increasing the barrier to entry for developers who want to contribute. Python can do all those things but is lighter, smaller, more flexible, and has a much larger userbase.
Using a game engine for that would be major overkill and make the project way bigger then it has to be
But what if that makes the difference between users being able to actually use the software, versus…just literally not using it?
Keep in mind that I’m talking about end-user software, from the very start of the conversation. Not backend-only stuff, not tools that are only ever going to be used for batch process stuff. I’m talking about stuff like my example of a simulation program for glass and ceramic casting.
Wouldn’t it make absolutely perfect sense to use a game engine for something like that? The user won’t give a fuck if it takes 2 gigs of disk space, and has a loading screen on startup. They are going to be spending real hours of time, using the application to generate actionable information.
The Python solution that would be lighter, smaller, and more flexible isn’t any good if nobody actually implements it, right? And, from where I’m sitting, it seems like the version that uses Godot or Unity would be so much more actionable.
By all means, provide a GUI.
But being able to do it all from the command line means you can pipe the output of another program directly into your program, and then take that output and feed it into yet another.
The program you describe could be slotted into the control systems of the kiln, cooling, and tempering ovens.
GUIs break that connection. As soon as you start using a GUI, the ability to automatically pipe outputs to inputs is broken. The user is now the link between the programs, manually transferring data between them that could be performed automatically.
All the rest of us, who aren’t programmers? We envy programmers, and their ability to really connect with computers, on that deep logic level.
A good GUI will leave the command line visible, and interact able, so that the user can see the program’s input and output syntax, and gain that sense of “connection”. A good GUI will teach the command line, so that by merely using two programs, the user learns what they need to connect them together.
I actually kinda agree with this.
Even if a commandline tool has more power, utility and flexibility than a gui tool, guis let you drill down into the core workflow of what your software is meant to do. At a minimum, it lets you segment what your regular users are expected to do from what your power users could use your software to do.
Additionally, if you intend for your software to be used by non-software adjacent users, a commandline interface is just asking for people to get lost/confused.
At work, we use ROS on some of our systems and while the commandline tools are simple to someone who works in the ecosystem, knowing what to look at when things go wrong is tricky.
Even a simple gui in tkinter that shows statuses or shows a list of topics and lets you print them out is leagues above the commandline when it comes to how much I need to be involved in other peoples’ problems.
It is a luxury to be knowledgeable in software concepts and I think software devs/power users forget that often.
I mentioned VisiCalc to a couple of people, in this discussion, and I think it REALLY needs to be remembered more often, and more clearly.
I keep seeing a lot of people replying to various parts of this discussion, with varying degrees of this opinion:
“Anything you can do with a GUI can be done without a GUI. You basically just THINK you need a GUI, because you’re a lazy non-software person. You just need to get used to using CLI, and when you do, you’ll thank me, because you’ll be able to do even more powerful things than you ever could, with your GUI crutch.”
Well, spreadsheets blow that entire argument out of the water, instantly.
The whole thing about spreadsheets is the fact that they are a GUI. The original VisiCalc spreadsheet application BARELY had a GUI. It was all text characters. It was barely running in realtime. But it was a realtime GUI, and that was the entire reason that it was useful.
Note that you could make a command-line-only spreadsheet program. As in, an entirely hidden spreadsheet, where you use commands to define the fields, enter the data, and then use other commands to do operations and query for the results. But that’s entirely destroying the whole point of the spreadsheet, as a tool. With VisiCalc (and all modern spreadsheet programs), you can see all the fields at once, change them in any order, and watch as any other relevant fields are affected by the different numbers.
As many people have said about the spreadsheet revolution, it allowed people to “play around with the numbers.” For most users, that was what elevated the microcomputer from a mere calculator to a game-changing, paradigm-shifting, universally necessary tool, for anyone who did any kind of business.
Before VisiCalc, you might as well just use a digital calculator, to help you with your business stuff. Just using command-line programs to do calculations wasn’t really any faster than a desktop calculator. And those desktop calculators usually had hard-copy printers built into them, so that you wouldn’t ever have to re-list the queries you’d made, to refresh your memory.
But, again, the realtime GUI spreadsheet blasted all that apart, and gave users life-altering tools. It wasn’t just a matter of “oh, look. We dumbed down the interface, so that stupid Bob the Business Major can finally use software.” It was a real step beyond what command-line tools can do.
Now, think about my example of a molecular simulation program for melting, cooling, and tempering ceramics. Isn’t that process even more complex than doing sum and division operations on some dollar values, rounded to two digits after the zero? Doesn’t it logically follow that you’d want a GUI for a molecular simulation tool, so that you could PLAY AROUND WITH THE NUMBERS, in the same way that you would, with your business expense sheets?
That’s the whole point of the software doing simulations, right? On the one level, it’s simply easier to poke around at finite-state machines that model known physical and chemical properties than it is to do a bunch of experiments in a real kiln. That’s the first stage of why simulation is good for progress. But it really does go beyond that. I would argue that a GUI in a simulation lets you see things from angles that you would never have thought of, before you started tinkering.
If you have to think about how you’re going to query the system, on a command line, then read out the data afterward, you’re going to run up against the limitations of the human imagination. Some users will think of every query they ought to make, without any prompting, and with less trial and error. Others will never think of certain aspects of the simulation, unless and until they can SEE the parameters laid out in front of them, in a graphical, preferably realtime fashion.
Obviously, not everything can be realtime. But graphical interfaces always allow better viewing of simultaneous and parallel functions.
It’s not just a matter of “we’ll throw some of these non-techie users a bone, and make this stuff easier for their lazy asses.” There ARE fundamental advantages to a GUI, which truly to go beyond simple “user friendliness.” Succinctly, a GUI user is not the opposite of a power user.
This software is not for you. It’s for the author. It’s in furtherance of their research, or their career, or their interests. It is only incidentally available to you.
That’s it, that’s the whole story. You get a GUI if the authors wanted there to be a GUI.
If you join a community around the product - which would require being nice, willing to engage, understand, not make demands - you might be able to give feedback and occasionally help steer the direction of the product.
People who do things they like for free are called “hobbyists”. These hobbyists, unsurprisingly, only do what they want to do. And sometimes they don’t want to make a GUI.
The fact that they share the results of their hobby for free at all is just a bonus.
I honestly do get that. And I realize I am overstating my case, in a way that basically makes me an asshole.
I think the problem is often rooted in how projects advertise themselves. The small dev team is like “WE’RE PASSIONATE ABOUT GETTING ________ INTO THE HANDS OF USERS, BECAUSE WE KNOW THE ONLY OTHER SOFTWARE THAT DOES _______ IS A 27-YEAR-OLD APP THAT ONLY WORKS ON A SPECIFIC REVISION OF WINDOWS 95.”
But then the damned app is command-line only, and it just feels like it was all a tease.
But if you’re this passionate about the stress levels of ceramic whatever, presumably you’ve trudged through countless dense works of academia. After that how big of a step is it to learn to type a few keywords into a command line? You’re not required to learn a whole programming language.
That’s a hard argument to rebut. The only thing I can really refer to is VisiCalc. The OG spreadsheet program. The original “killer app.”
The whole thing about a spreadsheet is that it’s a realtime pseudo-GUI. It’s not a command-line-interface thing, and that’s VITAL TO ITS FUNCTION, AT THE END-USER LEVEL.
Of course, the computer can do any of the spreadsheet calculations by means of querying a CLI. But the thing about a spreadsheet is that you just change one element on the screen, and all the other elements auto-update, in response to the altered field.
That functionality was a major-ass deal for doing some summing and dividing, so you don’t fuck up your payroll and your expense reports. It increased productivity. It reduced clerical errors.
But you’re over here, like “well, can’t you just use the command line to enter the new parameters for your molecular glass simulation?”
My argument: isn’t that shit just a little more complex than a spreadsheet with some basic monetary figures on it? If a GUI is a game-changer for juggling a few dollar-figures in a monthly budget document, it’s EVEN MORE CRITICAL in any application where both the data and the calculations are more complicated.
The GUI paradigm isn’t a frivolous luxury, which is only made for those of us who are just too lazy to get savvy with the CLI game. GUI has real and exclusive benefits. The more complex the data entry, the sillier it becomes to just say “you don’t really NEED that GUI, you just want it for convenience.”
I’ve dealt with that kind of software that was a paid for product.
Part of the issue is that the software is that it is very specialized, so there isn’t a big demand for the software. At that point, it is usually cheaper to train the users instead of making the program easier to run.
You also run into problems where a GUI can cause a false sense of confidence in the work. People end up trusting the program completely instead of using it as a tool that could cause problems.
This raises a point though. A command line tool from '95 will likely recompile and run just fine with maybe a warning or two, while the GUI app is no longer supported because GUI frameworks are notoriously fickle things that go obsolete all the time.
GUI components aren’t (usually) interoperable, with other programs, they aren’t flexible, and they aren’t scriptable at scale. They are good for new people and laypeople, but they are hard to write (lots of requirements for input validation) and you have to prescribe a specific workflow. I would argue after being on both ends of the discussion that the one guy you DEFINITELY don’t want to write a UI for a complex scientific program is the guy who wrote the program: it means to use it he expects you to think like him.
I would suggest the other perspective: any academic or research tool that DOESNT have CLI parity available alongside a GUI (if it has one) shouldn’t be taken seriously.
Not all end-users are the same though. Clearly, you are not in the target user group for this software. If a GUI was that sought after, someone could create that as a standalone project. Upvoted for the genuine unpopular opinion
I upvoted this because it’s the point of the sub. Some people like terminal apps, most open source programs are initially created for personal use and then shared to others. GUI can be the hardest, buggiest part of an application and rarely teaches the programmer anything. I think you should try to make one ;)
Like I said to someone else, I actually did make some GUI apps, with Visual Basic, back in the day.
It was, like, ludicrously easy. If the current frameworks that are meant for GUI development have regressed, and it’s incredibly hard to make GUIs now, that is something that needs to be solved.
Also, as I said to that person: as an end-user, especially when I’m using free software, I do not need the UI to be pretty, at all.
It can be as ugly as sin on toast, but I just need to have a window with buttons on it, or else I cannot use the damn thing to do real work. My brain just doesn’t operate that way. I’ll be checking back and forth between the screen and a cheat-sheet of commands that I printed out, and I’ll be angry the whole time I’m doing it.
I actually did make some GUI apps, with Visual Basic, back in the day.
A lot has changed in the 20 years since VB was used for GUI application development, especially on the OS side. It’s not that GUI development had regressed, it’s that everything else has gotten more complicated. It’s not about being pretty, it’s about complying with all the new security and testing requirements to make a functional application.
If you think that GUI application development should be simple, you could try creating a GUI wrapper around these CLI tools. I’m sure lots of people would be willing to test it for you.
To be fair, Visual Studio is as easy to use as it’s ever been. If you want a Windows Forms application, it’s pretty easy to make those god awful UIs that the 90s were known for.
Unfortunately for choosing beggars, most free software development doesn’t happen on Windows, and the free alternatives (Qt Creator, Gnome Builder, etc.) are all more complicated than what Microsoft produced. Gambas comes close, but it’s stuck with some kind of VB6 derived language and a bunch of potential GPL licensing issues.
it’s about complying with all the new security and testing requirements to make a functional application
Even if that’s technically not regression, it’s still a problem. Maybe it’s not a problem that has anyone you can blame, but it certainly needs solutions.
For what it’s worth, rather than developers kicking the burden down the chain to the users and saying “GUIs are hard now,” and then users saying “okay, I guess,” we should all be yelling upward.
I think I’m being perfectly reasonable to yell “hey, I actually do need GUIs for everything, ya know,” and then you’d be reasonable for yelling up at the operating system architects and development environment creators, like “hey, do whatever needs to be done, for us to manage these requirements more easily.”
Some people will hiss and bare their teeth like a vampire at this suggestion, but I actually think maybe modern generative AI systems can really help with this crap.
I think that yelling at developers to make something for you is where the problem lies. You can try asking nicely, but ultimately other priorities have to be dealt with first. Until there are enough people asking for the same thing, this will always be the case. But you can always be the change that you want to see. Even if it’s a ugly shitty GUI, as long as it does what it needs then other people should start using it. And then you can start dealing with all the user requests to add functionality that you never planned on. Or you can just tell them that this is the tool you made, and if they want more than they can create it themselves.
Things become a lot more muddy when you actually get in the dirt to fix things. It’s easy to yell from the sidelines, but actually fixing things isn’t as simple.
Edit: To everyone except OP, downvoting this dude isn’t going to help anything. He’s asking valid questions from a point of view that’s 20 years out of GUI development. A lot has changed that isn’t obvious to someone that hasn’t actually done it for that long. Education should be more important than downvoting someone with an unpopular opinion in a forum for unpopular opinions.
You can look at it as me yelling and being rude. And I was exaggerating, for effect. I realize things are harder than I made it out.
On the other hand, the problem remains, even if nobody is yelling about it, and maybe that’s worse. If a project goes on, for literal years, as a supposedly released thing, but there’s never a GUI, then most users won’t use it.
I will admit that I’m an asshole, in this situation. I almost certainly could really apply myself, and help to add GUIs to some of these apps that I’ve wanted to see GUIs in, over the years. But others absolutely cannot. They just aren’t built for coding, in any way, shape, or form.
So they just won’t use the software in question, even if it is exactly what they need. When developers contribute to free software projects, the hope is that they will be used. I lament the fact that some projects just float around forever, never getting that use, because a GUI isn’t forthcoming.
That just sucks. Even if everyone has a perfectly valid excuse for not fixing it. It still sucks.
EDIT: Your edit is extremely appreciated.
True a UI doesn’t have to be pretty but it has to be usable/provide a good experience. To me at least a bad GUI is much worse than a terminal interface. Which is also a UI, just not graphical. I don’t write desktop apps with GUIs so I’m not sure how complex it is but it probably depends a lot on the language. If the initial project is using C for example I’d expect adding a GUI to be more of a pain than if it was written in Visual Basic.
As a developer, it’s not the coding of the GUI that’s a problem. Making a text box or a button or lining two items up does only take a minute. The issues are (in order of complexity for me):
- Making it look nice. I’m just not very artistic in this way
- Sanitising all inputs (no letters in a number text box for example)
- Error checking and handling
- Creating a good intuitive flow and making sure that everything is explained nicely on screen. Better yet, make it so intuitive that no explanation is needed and make a separate help file in case someone gets stuck
- Idiot-proofing. Just have to think of every single thing someone could do wrong with the UI and what damage this would do to the program / database. I had one customer who spam-clicked apparently at random and kept deleting items from the database and somehow this was my problem to solve. I added an artificial delay to dialog boxes opening so that they wouldn’t click the new buttons that appeared in the dialog before having a chance to read it…
Honestly, designing a good GUI is the hardest part for me.
I’m the exact opposite, I can’t remember what the buttons do. So I look for terminal software, and I write terminal software. Everyone doesn’t think the same way as you do, same with me.
That really is a fascinating thing. I intellectually realized that there are people who truly prefer command-line interfaces, but I just can’t really make myself relate to it.
Not having anything visual in front of me is a burden on my own working memory. When I’m having to remind myself of what the program is doing, what commands are appropriate at this stage, etc, it disrupts any planning and decision-making that I need to do, in order to actually make use of the software.
The idea that someone else would feel exactly the opposite is a real eye-opener.
Part of the reason I like text based better is because it gives me the power of search, literally everywhere. Too many complicated GUIs give me headaches and make me intensely frustrated as I click around seemingly at random, digging into menus or hunting around buttons with labels or icons that I don’t recognize.
On the command line, I can just start searching and jump straight to the thing I’m looking for instead of forgetting what I was doing wandering around in GUI land.
What if the GUI was just another terminal emulator?
I’d…ummm…feel like I was being trolled?
EDIT: But, like, expertly trolled, obviously.
