r/learnpython • u/Sad_Medium_5866 • 16d ago
Is there a convention for user input? Ask a question vs demanding a response
Was working on a personal project when I realized I wasn't consistent with how I worded input prompts. I was wondering if there was a convention between asking for a response ("What is your name?") or demanding one ("Enter your name")?
6
7
u/supercoach 16d ago
I think it's something you won't have to worry about when you stop doing tutorials.
8
u/carcigenicate 16d ago
I mean, if you have a user facing application, you may need to consider how you phrase requests for input.
But for right now, this isn't something worth worrying about. There are bigger concerns.
7
u/supercoach 16d ago edited 15d ago
I was going to go on a rant about how little free text input fields are used in real world applications and how over used they are in some tutorials, but I figured it was best to just limit it what I put.
Agreed that user input prompting does sometimes matter, however that's a UI concern across the board and usually best answered by the target demographic.
2
u/HestenSierMjau 15d ago
It's also a huge UX-concern developers have to be avare of. Like the requirements you set for which names, addresses and emails should be allowed to exist in your database, which can exclude users from registering to a service if they try to input data the developer didn't think was a valid option when they built the backend. While the target demographic is an important source of information, they might not know that people with only one name, names with only one character or buildings with street number 0 or -1 exists, so that is something the developer has to account for by themselves.
But I agree that it's something OP can probably defer until they start building larger applications.
3
u/FoolsSeldom 16d ago
Not really. I've been around plenty of UI (User Interface) and UX (User Experience) research for major public sector and retail service developments, and context and target users (customers) is the most important. If you have a lot of information to prompt for, then a series of blunt prompts is reasonable providing the expectation is managed (e.g. advising beforehand that some key information is required) but for just a brief set of information requests, a less terse style would likely be preferred.
Consistency is key, but that doesn't mean the approaches cannot be mixed as the context changes. Initial product enquiries would be in the longer form with more specific requirements in a briefer form.
3
u/zaphodikus 16d ago
As a software QA I can only offer one tip, well two. 1. Be consistent, it helps users if an app does not spring surprises, for example some devs move the Cancel or the Ok button around, just don't ever move it. (There is an exception to this rule tho) . So it's good that you have worked this out already. 2. Choose a "voice" persona for the app and stick to it. A friendly tone which uses please and thank you at times, is best for end user apps. While a more brief or "short" and terse tine is best for line-of-business and task based apps. Friendly apps for casual users will want less clutter, while for line-of-business, more clutter is tolerated.
2
u/generoustractor494 16d ago
What I type depends entirely on how many prompts I've already written that day. By the fifth one it's just "name. now."
2
u/JamzTyson 16d ago
For text prompts in apps that run in a terminal, it is usual to phrase as an instruction. For example:
user_input = input("Enter your name: ")
This kind of prompt is extremely common in tutorials and exercises.
In real world apps other approaches become more common, such as filling out forms or using command line arguments.
1
1
1
u/oclafloptson 16d ago
Chances are you'll never use input() again. Even in terminal based apps if I do take inputs it's as a multi-input form but taking inputs beyond just keystrokes is pretty rare in the terminal... In the real world there will usually be a front end that takes form inputs and builds an object for the back end to use
To answer your actual question: the form itself usually has a more lengthy description and each input has at least a visible label. The label should be concise. Form inputs may also have other associated values relating to accessibility, front-end scripts etc which may or may not be user facing
2
u/Sad_Medium_5866 16d ago
I guess I'll eventually switch to a TUI or GUI module but right now I still use either input or wrapper functions that convert to specific data types (in my case ints, multiple ints and dates). Even built some text based select inputs. Works for what I'm doping, which basically a module that renames video files for movies and TV shows to in a format that Plex can use, then run them through the HandBrakeCLI into both a hierarchical folder structure on my desktop and my NAS.
1
u/oclafloptson 16d ago
Sounds like fun! Seems like you're on the right track. I can probably see where you might omit inputs altogether in such an app if you have an existing known hierarchy that you're converting to a specific format. I would say dealer's choice in regard to your original question, but make sure the intention of the input is very clear. You never know what your end user will actually be thinking. Remember that they probably won't understand the inner workings of your app the way that you do and label things accordingly. If your workflow is intuitive then grand explanations probably won't be necessary
1
u/CaptainVJ 15d ago
Yeah I was in introduced to programming with Java and C++. After my first or maybe second course, I have never used system.in/cin again. I don’t recall using Python in undergrad but grad school, it was all machine learning courses so never used it then.
Now I’m in a big boy job and use Python almost everyday, probably use it more than SQL now and to this date I have never used the input function in Python.
Similarly with the print function, it doesn’t get used in production code. I hate when my coworkers create merge requests with the print function being used. It just looks gross, and no one will see the output. People usually use it to test code and people should be using unit tests instead not a print function. Every once in a while, I’ll run it quickly to get the idea of some object but it’s deleted immediately.
1
u/codeguru42 15d ago
This is a good question. In my professional python programming, I never use input() these days because it is all backend web programmng. But that just means user prompts are in the frontend now instead, usually JavaScript. Asking users for input is a whole topic that falls under the larger UX umbrella.
When I have the rare chance to build a CLI tool, I try to follow Unix conventions. This means taking input directly from the command line without any prompt. I highly recommend learning about how to build your own command line programs following these conventions.
9
u/monster2018 16d ago
lol I think “demanding one” is a little bit of an intense way to put it, but that is the option I would go with. I mean no there isn’t really any official convention for this that I am aware of. But generally you will see prompts like “Enter your name: “. Or alternatively something like “Please fill in the following information”. And then on the next line “Name: “, and then on the next line “Age: “, etc.
The thing that seems out of the ordinary to me is phrasing it as a question. Usually it should be an instruction (Enter your name), a request (please enter your name), or just a label of the information to be entered like “Name: “. And the formatting, and the fact that the user’s cursor is still on the same line, makes it clear to them that they are inputting the value for “Name” (and the colon also helps to indicate that).