search

ianyong / pe

0 stars 0 forks source link

Unoptimal use of space #8

Open ianyong opened 3 years ago

ianyong commented 3 years ago

The following screenshot is Productiv upon first starting up (default sample data, screen resolution):

image.png

More than half of the sample titles are being cut off even though the entire right panel is empty. When the view command is not being used, the list should be expanded to take on the entire space of the application. This would allow the user to be able to glean much more information at a glance.

nus-se-bot commented 3 years ago

Team's Response

This is the intended design to provide a concise and clean look.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: > This is the intended design to provide a concise and clean look.

I understand that this is the intended design. However, I disagree that the look is concise and clean. Note that in the screenshot provided in the original bug report, Productiv contains only its sample data and is in its default screen resolution. Out of the deliverables viewable in the screenshot, 7 out of 10 of them are truncated. Unlike the case of most other testers, this is not me manually adding extremely long titles just so that I can have a contrived example. Rather, it is the sample data provided by the team, which indicates that the team fully intended for the user to input long titles.

In order to view the full titles, I would need to use the view command on each and every item I want to know the full title of. This is a feature flaw because it makes the lists of deliverables, meetings and contacts less useful to users in the sense that they cannot see the full titles at a glance due to the lists only taking up half the width of the application even when the right panel is not displaying anything. On the other hand, if the lists were to take up the full width of the application when the right panel is not in use, then the use of space would be optimal and titles that are not ridiculously long would be viewable at a glance.

For reference, type.FeatureFlaw is defined as:

Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance-testing bug that falls within the scope of v1.4 features. These issues are counted against the product design aspect of the project.

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Low]

Reason for disagreement: severity.VeryLow is defined as:

A flaw that is purely cosmetic and does not affect usage e.g., a typo/spacing/layout/color/font issues in the docs or the UI that doesn't affect usage.

I disagree with this as this flaw is not purely cosmetic for the reasons stated in the issue response above.

severity.Low is defined as:

A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

Rather, this flaw should be classified as severity.Low because not being able to view the full titles of items with moderately long titles (such as those provided in the sample data) poses a minor inconvenience to the user as they have to keep using the view command.