Preference of one-shot input over multi-line input

[rabhijit]

Hi Prof,

I noted that one of the recommendations in the course website was to use one-shot input instead of multi-line input as the latter tends to be slower. However, in the event that some of our commands require multiple parameters (3-5 parameters), would that always be the case?

From doing testing yesterday, typing one wrong stroke in a long one-shot input often resulted in the whole thing having to be re-typed, which was quite a pain, as compared to multi-line inputs which would just require that one wrong parameter to be retyped.

Just wanted to check if the line against multi-line inputs was a hard line, or whether it's still okay to implement it for some situations. Thanks!

[okkhoy]

Let me give an example, see if it helps to clarify your question:

Scenario: Add a person to my contact list with Phone: 123456 Address 117417 Singapore 13 computing drive

Preferred/Correct/not violating constraints: add XYZABC /phone 123456 /address 117417 Singapore 13 computing drive
Versus: (not preferred/correct/violating constraints)
add Enter
Enter name: XYZABC Enter
Enter phone: 123456 Enter
Enter address: 117417 Singapore 13 computing drive Enter

If your scenario calls for multistep command, it may be acceptable: E.g., from a past project (product was to manage a restaurant including orders and stocks) which had no GUI:
create order Enter
add /item noodles /qty 1 /item coke /qty1 /item vanilla ice cream /qty2 Enter

create purchaselist Enter
add /item flour /qty 4 /item olive oil /qty 2

In this case, the first command was creating the context, and adding the respective item was a one-shot command.

[okkhoy]

What you could do for a command with 3-5 parameters is to make the "non-mandatory" parameters really non-mandatory in the input.

E.g., Adding person to contact list, I can say, except name nothing is mandatory. So the command has 2 forms at least:
add XYZABC << adds the person; you later edit this item to add fields
add XYZABC /phone 123456 << adds person with phone.
So both phone and address are non-mandatory in this case for the command to pass.

However, if you plan to do this now, please be careful as it may break your product!

[rabhijit]

Hi Prof,

Thanks for your clarification! Considering your first example of adding a person to your contact list using one-shot vs. multi-line input, is using multi-line input considered violating project constraints? What is the penalty for violating this constraint? Because my project currently uses multi-line inputs similar to the first example you gave, and we would probably have to change our project drastically if we were to change to a one-shot format now.

[okkhoy]

If your scenario is similar to the first case, then a multi-line input / multi-step command is considered as violating the constraints. What is the penalty: you are definitely not getting 0 for your project because of this! But the actual penalty, I dunno yet (plainly 'cos in the previous offerings, no one violated this constraint, so no experience yet 😀).
Your UG seemed alright when you submitted for review in week 7, did you deviate later?
There were a few cases where I warned the team about this in the UG. Unfortunately, you missed out.

[rabhijit]

Hi Prof, thanks for the (rather saddening) answer! Yes we chose to deviate after week 7 on the basis of offering a better user experience. We did ask our TA about it, who said that multi-line inputs should be acceptable. But it's still our fault for not checking the constraints.

On another note, is it acceptable to break a command into multiple one-shot commands?
For example, to delete one of many frisbees from a sports cupboard:
delete /item frisbee
(program generates a list of all frisbees, with each frisbee having a unique ID}
delete /id {frisbee id}

Is this allowed? Thank you so much for your help!