808384 - Confusing intention at "Edit messages" screen.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect, P5)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

1. Ensure you have messages in the Messaging app.
2. Tap on a message conversation.
3. Tap on the icon on the top right.
4. We now see "Edit messages".

Here, we cannot "edit" messages at all - we can only choose to select some/all for deletion.

We should probably clarify the message.


===

My Git commit info currently shows:

2012-11-01 09:44:34
0894302377ec0f8541f1b5b2fbf6ca5223c5df... (I see ellipsis at the end)

Comment 2

[ayman maat :maat]

i cannot reproduce this bug anymore
request QA to test if it is still valid.

Comment 3

[Carlos Martínez Toral [:carlosmartinez]]

As this is a UX issue I´m requesting info from Pablo (UX QA Team)

Comment 4

[Pablo Sanchez [:pabloUX]]

The issue here is a labeling problem: tittle says you can edit (wide action), but can only delete messages (very narrow action), so it could be confusing for the user.

In my opinion the bug is still valid

Comment 5

[Pablo Sanchez [:pabloUX]]

The issue here is a labeling problem: tittle says you can edit (wide action), but can only delete messages (very narrow action), so it could be confusing for the user.

In my opinion the bug is still valid and needs a decision from the UX team (considering consistency between other apps and available space as well)

Comment 6

[ayman maat :maat]

(In reply to Pablo Sanchez [:pabloUX] from comment #5)
> The issue here is a labeling problem: tittle says you can edit (wide
> action), but can only delete messages (very narrow action), so it could be
> confusing for the user.
> 
> In my opinion the bug is still valid and needs a decision from the UX team
> (considering consistency between other apps and available space as well)

I agree that in this instance, in isolation, the labeling could be tighter. But the bigger picture is that the same CTA icon appears on other apps, and in other apps there are more options available other than delete. e.g. the email app contains 'delete', 'flag', 'mark as unread' and 'move to another folder' with an overarching functional title of 'edit'. Therefore there are three things to take into consideration when making a decision about this:

1) for the sake of consistency, learnability and end user orientation the same CTA icon appearing in different places should have the same header or 'genre' of headers across all its instances. So in one instance the 'edit' icon should not be 'delete' and in another 'edit'.

2) we should think of the wider picture. The SMS app is by no means the finished article. We have designed and delivered the very very basic app. There are more functions and facilities to be woven into and layered on top of the app we have designed and delivered. Various artifacts exist within the architecture of the current design in preparation for this, to facilitate their integration, and this edit function is one of them. 

3) How 'misleading', or viewed from the other direction, 'learnable' is the current edit function of the SMS app. Does the current architecture mislead the end user leaving them lost and foraging for further editing functions? …Or is the fact that there are only two options within the function (exit edit function or delete content) quickly learnable, even though the expectation to be set when looking at the heading in isolation is not explicit?

With regards to point 3 i would propose that the fact that there are only two options within the edit function (exit edit function or delete content) is quickly learnable, even though the expectation when looking at the heading in isolation is not explicit. Therfore for this reason and with further consideration to the others i have outlined in point 1) and 2) i would propose to leave the labeling as it is.

Comment 7

[Rick Waldron [:rwaldron]]

Platform parity:

iOS refers to this mode as "Edit"
Android (v4.2) does not have an analogous multi-delete


I'd like to resolve this as "wontfix"

Comment 8

[Fernando Campo (:fcampo)]

Based on comment 6 and comment 7 I'm marking it as wontfix.