805977 - Truncate long app names on home screen

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect, P3)

Description

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

1. Update to 2012-10-24 build.
2. There will be a System app and a what I assume to be a "Dev Marketplace" app.
3. "Dev Marketplace" is a name of an app that is too long.

It should be truncated properly, because now it shows up as "Dev Marketpl".


===

My Git commit info currently shows:

2012-10-24 11:07:05
fcfa1857bed6596e992263206451c6814e4b2... (I see ellipsis at the end)

Comment 1

[Josh Carpenter [:jcarpenter]]

This is our approach for v1, but we're open to suggestions. We used ellipsis previously but they gobble up valuable horizontal real estate, reducing the number of characters that can be displayed.

cc'ing Patryk for input.

Comment 2

[Patryk Adamczyk [:patryk] UX]

Currently we can support 11 to 12 character labels which is adequate and inline with our competitors. For v.1 ellipsis should be the correct solution, as anything more would require feature work which we don't have dev support for.

Please make sure the proper unicode character is used for ellipsis (&#x2026), its about the length of an "m" so you'd get at least 10 characters before truncation happens.

Comment 3

[Josh Carpenter [:jcarpenter]]

(In reply to Patryk Adamczyk [:patryk] UX from comment #2)
> Currently we can support 11 to 12 character labels which is adequate and
> inline with our competitors. For v.1 ellipsis should be the correct
> solution, as anything more would require feature work which we don't have
> dev support for.
> 
> Please make sure the proper unicode character is used for ellipsis
> (&#x2026), its about the length of an "m" so you'd get at least 10
> characters before truncation happens.

The problem is that ellipsis actually reduces the number of characters that are visible by taking up valuable horizontal real estate. The choice is:

(1) Maximize number of visible characters but do not provide visual hint that text is truncated.

(2) Provide visual hunt that text is truncated, but at expense of 1 or more characters.

From a usability standpoint (1) seems like the obvious option. Also consider how cluttered (2) could look if half the apps have ellipsis added.

Comment 4

[Josh Carpenter [:jcarpenter]]

We could try to thread the needle by exploring alternative visual hints (eg: fade last character of text out), but I think that's something to defer to a future version.

Comment 5

[Patryk Adamczyk [:patryk] UX]

11 to 12 characters is a standard. On all mobile OSs that is what you see. Android added another line of text, but we should aim for all apps to have shorter names.

For v.2 I'd like to experiment with more visual treatments like Josh suggests, but they would be features I suspect.

If we can fade the last 2 characters... to 66% and 33% opacity, that would be a good alternative for the ellipsis.

Comment 6

[Josh Carpenter [:jcarpenter]]

(In reply to Patryk Adamczyk [:patryk] UX from comment #5)
> 11 to 12 characters is a standard. On all mobile OSs that is what you see.
> Android added another line of text, but we should aim for all apps to have
> shorter names.

Agreed on both counts, but what about the question of how to truncate text for v1? I feel it's better to cut the text off instead of sacrificing several characters and cluttering the screen.

> If we can fade the last 2 characters... to 66% and 33% opacity, that would
> be a good alternative for the ellipsis.

Only issue is that it might be tricky from a performance standpoint. Am cc'ing Gordon for input on our options here.

Comment 7

[Cristian Rodriguez (:crdlc)]

Hi everyone,

     In this screenshot[1] there are different versions for labels in v1. I guess that the best options is to use text-overlfow='' because it is very ugly to cut characters IMHO.

Thanks

[1] http://i.imgur.com/QdXzs.png

Comment 8

[Josh Carpenter [:jcarpenter]]

(In reply to crdlc from comment #7)
> Hi everyone,
> 
>      In this screenshot[1] there are different versions for labels in v1. I
> guess that the best options is to use text-overlfow='' because it is very
> ugly to cut characters IMHO.
> [1] http://i.imgur.com/QdXzs.png

Thanks for mocking that up.

I agree: let's go with text-overflow=''.

Comment 9

[Cristian Rodriguez (:crdlc)]

ok, Today I am going to implement it. Thanks a lot Josh for your help!

Comment 10

[Cristian Rodriguez (:crdlc)]

Attachment: Proposed patch v2

Comment 12

[Sergi]

sorry, i added another bug for this same issue. 

My suggestion is to use the 3 points at the end of a long text. We may use 12 characters and, in case the text is longer, 10 characters + 3points. I've attached a sample. IMHO Just cutting the text without making some kind of visual trick may drive to odd scenarios.

Comment 13

[Sergi]

Attachment: Truncating Text

Comment 14

[Cristian Rodriguez (:crdlc)]

It is feasible BUT we should add a layer over text with a gradient. The problem is that the gradients are not the best friend of performance in panning. So if from the design team we have a image that provides that effect it could be implemented.

Thanks

Comment 15

[Cristian Rodriguez (:crdlc)]

Sergi, could we do some test jointly? thanks

Comment 16

[Sergi]

I've updated the attachment to reflect the changes Patryk proposed about having the characters at the end of long names faded out. 

As a general rule we will display app names with 12 characters and, if the text is longer, we will also use 12 characters but the two characters at the end will have a fade effect.

Comment 17

[Sergi]

Attachment: Truncate Text :: Fade Effect

Comment 18

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

> As a general rule we will display app names with 12 characters and, if the
> text is longer, we will also use 12 characters but the two characters at the
> end will have a fade effect.

I absolutely agree that this is one of the best ways forward. :)

Comment 19

[Cristian Rodriguez (:crdlc)]

Attachment: My first approach

I've been working with masks + SVG and the result is awesome!. Now, please, Sergi we are going to review the mask to reach the result perfect.

Comment 20

[Josh Carpenter [:jcarpenter]]

Nice work guys, I agree, this is the best option... so long as there is not a negative performance impact. That's very  important. 

Am cc'ing cjones for input on potential impact.

Also, current mask width appears to be 25px. That seems excessive and undermines legibility. I recommend narrowing to 15px.

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 690377 [details]
Proposed patch v2

Code seems fine. As far as I understand how our transformations works it should not affect panning performance.

Comment 22

[Cristian Rodriguez (:crdlc)]

I was testing while implementation and the performance seems OK than before

Comment 23

[Cristian Rodriguez (:crdlc)]

We have different screenshots, Sergi will provide some real pictures for Unagi in a couple of hours, thanks

Comment 24

[Josh Carpenter [:jcarpenter]]

(In reply to crdlc from comment #23)
> We have different screenshots, Sergi will provide some real pictures for
> Unagi in a couple of hours, thanks

Awesome, thanks Cristian, that would be much appreciated.

Comment 25

[Sergi]

Attachment: Truncate Text :: Fade Effect v2

Comment 26

[Sergi]

Find attached a new version of the Fade Effect. 

I've added a couple of samples with different mask densities. Although the version which is more similar to the first visual mockup is "Test 3" i think "Test 2" works better visually. Let us know your opinion so Cristian can close this and place the PR.

Comment 27

[steve]

Go with Test 3.

Thanks guys

Comment 28

[Cristian Rodriguez (:crdlc)]

ok got it, I will implement with 3, thanks

Comment 29

[Cristian Rodriguez (:crdlc)]

Comment on attachment 690377 [details]
Proposed patch v2

Reviewed by Sergi from UX point of view

Comment 30

[Cristian Rodriguez (:crdlc)]

OK r+ but not bb+, approval gaia master?

Comment 31

[Josh Carpenter [:jcarpenter]]

(In reply to steve from comment #27)
> 
> Go with Test 3.
> 
> Thanks guys

Yep, agreed. Test 3 worst best. Nice work guys.

(In reply to crdlc from comment #30)
> OK r+ but not bb+, approval gaia master?

Nominating. 

* Patch is ready and reviewed. Mark it BB+ to get in for release.
* Many apps have long names and will benefit from this visual improvement.

Comment 32

[Joe Cheng [:jcheng] (please needinfo)]

Triage:BB-, tracking-b2g18+, can ask for gaia master approval

Comment 34

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Pike has something to say in bug 826013 comment 1.

Comment 36

[Cristian Rodriguez (:crdlc)]

Comment on attachment 690377 [details]
Proposed patch v2

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky):

Comment 37

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 690377 [details]
Proposed patch v2

Let's see if this does not regress perf.

Comment 38

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/1b1d055189e29a7d3f255714ee3abd3f2733710d

Comment 39

[Cristian Rodriguez (:crdlc)]

ok if there is a regression about performance we remove the commit