Comments (1)
Team's Response
We wanted to be uniform in our architecture when implementing our commands, this is so that we can maintain extensibility for our description commands.
Items for the Tester to Verify
❓ Issue response
Team chose [response.Rejected
]
- I disagree
Reason for disagreement: Sorry, but I have to disagree. I am arguing from a fast typist point of view and I believe that these unnecessary prefixes if they could be removed, should be removed.
From my understanding of prefixes, the main reason why prefixes are used originally in the addressbook, was because the user had to type in long verbose commands of each type, and the prefixes exist to allow users to be flexible when inputting their long commands (such as add case t:hello s:active
is equivalent to add case s:active t:hello
).
However, for this situation, there is clearly no flexibility here. Thus, they should be removed for the sake of fast typists.
Not to mention but your entire project failed to account for users who are fast typists and there was no optimisation put in place for these users (some suggestions could be allowing prefixes of commands to be executed, eg. add c t:hello
is equivalent to add case t:hello
or the implementation of supporting smart-tab, where the users can type in the prefix of a command and then press tab, and the app would fill in the rest of the word with a valid command for the user)
I am also unsure what you meant by "maintain extensibility for our description commands." because, from my understanding, this is all handled by the individual distinct parser, not the individual commands.
Overall, after much reconsideration, I feel that this issue should be raised to a low or medium severity level, because it can cause much inconvenience to fast typists.
from pe.
Related Issues (14)
- Add description to current case documentation bug? HOT 1
- Invalid phone numbers can be added HOT 1
- Very small inconsistency issue HOT 1
- Repeated content HOT 1
- Incorrect response from result display? HOT 1
- Outdated picture and description in DG HOT 1
- UML diagram self invocation method displayed incorrectly? HOT 1
- Some DG links are not updated HOT 1
- UML diagram undefined return type? HOT 1
- Interface not explicitly declared in UML diagram HOT 1
- Very minor inconsistency issue in DG HOT 1
- Activity Diagram can be improved? HOT 1
- Inconsistent DG use case error handling HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pe.