CS2103 Project: Points to Ponder

General Command format UI Search Other

[source]

Here are some things to think about when refining the design of the product.

General

• Make common things easy. What are the most common things a user may want to achieve using the app? e.g. To find out the schedule for today/tomorrow. Make those things VERY easy to do.


• Make rare things possible: Think twice before prohibiting things such as overlapping events, editing past events, etc. For example, people do schedule things in the same period when they are not sure which one they are going to do. Not allowing it can be a great inconvenience. Highlighting and warning about overlaps is a better approach.
  That is not to say anything should be allowed. Disallowing certain things can even be beneficial to users. However, a decision to disallow a certain usage should be taken after careful consideration, not simply because it makes the implementation easier.
  Similarly, the software must cater for the possibility of task description containing keywords such as ‘from’ ‘to’. e.g., If the user wants to add the task ‘watch day after tomorrow’; (i.e., watch the movie named ‘day after tomorrow’) to the list, there should be a way to enter it without the software interpreting ‘tomorrow’ as the day for the task.


• Stick to users’ language: Using the names mentioned in the requirements (e.g. floating tasks) in the user guide or in the app itself might not make sense to users. If you want to stick with such terms, at least you should explain the terms to users. Do not make users learn new terms unless absolutely necessary.


• Use sensible defaults: Schedule the task NOW if no time is specified? really? Choose smart defaults when you can, but don’t chose silly defaults.


• Give only useful features: Reconsider features such as login, sort, hashtag, priority. They are OK to have if you have a strong justification. Always ask yourself, ‘What if we don’t have this feature? Is it going to be a problem for Jim?’. A feature common to other similar software may turn out to be useless for Jim.
  Similarly a feature that may be valuable to ‘somebody’ may not be valuable to Jim. For example, Jim uses the software from his office computer. A audio playback of the command is unlikely to be useful in such an environment. Imagine how Jim’s co-workers would feel if Jim’s computer keeps making audio commentary!


• Avoid half-baked features: When you implement a feature, consider all aspects of it. For example, if your extra feature is GCal sync, consider things such as how to store floating tasks in GCal, how to sync older items in GCal with your software, how to sync repeating events, and so on. It is not necessary that you implement all those things. However, you should have considered all those things and you should have good reasons why you chose what you implemented over what you did not implement. “Oh, we didn’t think of that” is not a good answer.

Command format

• Optimize command format for users, not developers: Don’t design the command format solely to make parsing easier. Primarily, it should be easy to remember and type. Ease of parsing is secondary.


• Unix-like commands: Excessive use of symbols make the command hard to remember/type. We are targeting fast typists, not necessarily UNIX system admins. No matter how fast you can type, normal letters are faster to type than certain symbols such as -@#$^. But symbols such as . , / may be easier than other symbols.


• Prefer typing over keyboard shortcuts: Keyboard shortcuts are useful and they do not require the mouse. But keep in mind that Jim prefers typing, not necessarily keyboard shortcuts. Keyboard shortcuts involving key combinations often takes more time than regular typing.
  Automatically generating a command template to fill in may not be good either. For a fast typist, editing an existing text by moving around using arrow/tab keys is slower than typing everything in one burst.
  The goal is to give Jim a faster ‘typing’ alternative to anything that can be done in other ways.


• Avoil multi-step CLIs: The user should be able to accomplish most tasks using a single command. For example, the approach ‘type add, press enter, then type description, press enter again etc. is unacceptable.


• Flexible or rigid? The more you make the command “natural-language-like”, the higher the risk of misinterpreting a user command. The more you use special symbols and strict formats, the harder it is for users to use the software. How do you choose? May be you don’t have to choose. Why not support both? A flexible and natural format that users will use most of the time, and a more rigid one when they have to issue a command that has a risk of misinterpretation.

UI

• Optimize the display format:
• For example, listing of tasks should be nicely laid out, sorted in a meaningful way, aligned properly, etc so that the user can read the information quickly. For example, the text UIs below have similar content but one is much more readable than the other.
  
• Consider how the display area will look like for scenarios such as when you have many tasks in a single day, when you have 100s of tasks in the system, when a task has a long description, etc. Will the display are look neat and readable in those situations too?
• What format should you use to display date/times so that it takes less space but still easy to understand? Is there any point in displaying year, seconds? Is it better to display the day as well (e.g. Saturday)?
• But do be careful about going for a Calendar-like UIs (i.e., grids). They are a lot of work to implement and hard to get right. It may be easier to link up with existing calendar interfaces such as Google Calendar.


• Give enough feedback to the user: When the user executes a command, the feedback given should be informative. e.g. When giving feedback after adding a task, ‘Success’ is not good enough. Jim should see the details of the task added so that he can verify if it is indeed the task that he meant to add.
  It may be even more useful if the result is shown ‘in context’. e.g. showing the newly added task together with the tasks in that day, but the new one is highlighted


• Make use of the welcome screen: The welcome screen (what you display at the very beginning) can be used to display something that is useful to the user, such as the tasks for the day.


• Scrolling is a design fail: Yes, the use should be able to scroll when there is more information to show than the display area allows. It is better if the user rarely need to scroll. You should design such that whatever the user was looking for is already visible in the display area, without having to scroll.

Search

• Give sensible search filters:
  When searching for a task, what can we expect the user to type? Surely, we cannot expect them to type the original tasks name precisely?
  When designing search options, start with the kind of things users may want to search for. For example, if Jim is trying to schedule a lunch appointment, he may want to search for tasks (or free times) he has during lunch hour for the next few days, but he is unlikely to want to search for tasks scheduled during a particular time in a particular day. Instead, he can simply display that day’s schedule to find that information.

Other

• Saving things only at exit command is a bad idea; Data will be lost if the the program is closed without using the exit command.
• Is there any situation where a regular user may want to see a list *all* tasks? To sort all tasks alphabetically?
• Are there other types of tasks that we should consider, in addition to the three types mentioned?
• Should we force the user to explicitly identify task types or can the task type be dealt with internally most of the time?
• What about conversions from one task type to another?
• Is it better to show deadlines and timed tasks together or separately? Do people process those two types of things separately when they think about things they have to do?
• What is the best way to handle overdue tasks? Automatically hide or highlight?
• Is there a need to ask for confirmation when an undo feature is available?
• How useful is automatic scheduling? Would you follow a schedule automatically generated by an app?