835830 - visuals in data usage graph need polish

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

Description

[marcoc]

Several elements in the visuals of the data usage graph are implemented inaccurately, and hence creates visual noise that interferes with easy legibility of data.  
1. Line weights in graph are too think: horizontal lines should have a different weight from vertical lines.
2. When a data use alert coincides with the horizontal line of in the graph, there should be no duplication, the dashed red alert level line should fully substitute the line in the graph.

Comment 1

[marcoc]

Attachment: Current implementation of data usage visuals

Comment 2

[marcoc]

Attachment: Specified visuals for data usage graph

Comment 3

[marcoc]

Difference between two are noticeable in:
- Padding between dates and data usage toggles is too much, should lower and give more space to graph
- Lineweights of graph should be corrected so that vertical lines are 1px #eeeeee, and horizontals are 1px #e0e0e0.
- Data alert line (when it coincides with amount on graph) should not overlap horizontal line but substitute it entirely
- In implementation there is either: a missing final date line or horizontal lines extend too far.
- Date capitalization 
- Alingment of data amounts of left side of graph should right justified, using correct font MozTT
- Font size of MB/GB to side of graph numbers should be smaller
- Color of 0MB indicator on graph bottom left should match that of other numbers on graph side

Comment 4

[Salvador de la Puente González [:salva]]

(In reply to marcoc from comment #3)
> - Date capitalization 

l10n guidelines encourage not to force capitalization to ensure correct representation by language. We follow this recommendation here.

It won't be fixed.

Comment 5

[Sergi]

(In reply to Salvador de la Puente González [:salva] from comment #4)
> (In reply to marcoc from comment #3)
> > - Date capitalization 
> 
> l10n guidelines encourage not to force capitalization to ensure correct
> representation by language. We follow this recommendation here.
> 
> It won't be fixed.
Can you share the link to review these guidelines you refer to? Thanks!

Comment 6

[Salvador de la Puente González [:salva]]

Nop. But I can ask Kaze, ;)

Kaze, about l10n, you recommended some time ago about remove all toUpperCase, can you help Sergi here? Are there official guidelines to review?

Thanks.

Comment 7

[Salvador de la Puente González [:salva]]

(In reply to marcoc from comment #3)
> - Alingment of data amounts of left side of graph should right justified,
> using correct font MozTT

Are you sure about this. It seems to me to be center aligned.

> - Font size of MB/GB to side of graph numbers should be smaller

I can not do this, sorry. The problem is l10n. I send the value and the unit to the localization utility and it returns me the correct way to write the amount of data in the current language but then I can not distinguish what is the number and what is the unit.

I can force this visualization not taking in count l10n but I don't think this is the correct way to do it. It's up to you.

I attached a couple of screenshots. All other problems are fixed.

Comment 8

[Salvador de la Puente González [:salva]]

Attachment: Data usage new look after polish when data limit is 1G

Comment 9

[Salvador de la Puente González [:salva]]

Attachment: Data usage new look after polish when data limit is 2G

Comment 10

[Francisco Jordano [:arcturus] [:francisco]]

Hi all,

the reference is our expert in L10n, Kaze, he has recommended not doing this in several cases.

In this point I'm with him, just for common sense, I don't know if in other cultures having a text all in upper case could mean 'danger'. So I would try to avoid that localizers would need to deal with any kind of formatting.

Cheers,
F.

Comment 11

[Sergi]

(In reply to Francisco Jordano [:arcturus] from comment #10)
> Hi all,
> 
> the reference is our expert in L10n, Kaze, he has recommended not doing this
> in several cases.
> 
> In this point I'm with him, just for common sense, I don't know if in other
> cultures having a text all in upper case could mean 'danger'. So I would try
> to avoid that localizers would need to deal with any kind of formatting.
> 
> Cheers,
> F.

I'd really appreciate if you can provide some data or document on this. I mean, the visuals are using uppercase for a reason: Giving more relevance to an important piece of data to the user. Basically the time period he has set up in the system and for which he's viewing the graph. I see you're point, but we're closing a bug without providing any data, just a guess.

It's possible to have an explanation on why we can not use uppercase here? because we are using uppercase in other places of the system. If what you're saying about L10n is true we will have to redesign other apps (like contact details). Otherwise i'd really appreciate to reopen that issue and try to solve it.

Thanks!

Comment 12

[Salvador de la Puente González [:salva]]

In my point of view, it should be cool to include in l10n utility something like "please, translate <this> and add emphasis" in order to allow l10n to return me a string with capitalization, underline or whatever is correct in the current language. But, at the present moment, this is a technical issue and I prefer to be conservative and support Kaze and Francisco points of view.

Francisco, please, can you answer Sergi.

Anyway, my advice is not to block on this. If transformations are needed, the we can file an undependable bug.

Comment 13

[marcoc]

(In reply to Salvador de la Puente González [:salva] from comment #7)
> (In reply to marcoc from comment #3)
> > - Alingment of data amounts of left side of graph should right justified,
> > using correct font MozTT
> 
> Are you sure about this. It seems to me to be center aligned.
> 
> > - Font size of MB/GB to side of graph numbers should be smaller
> 
> I can not do this, sorry. The problem is l10n. I send the value and the unit
> to the localization utility and it returns me the correct way to write the
> amount of data in the current language but then I can not distinguish what
> is the number and what is the unit.
> 
> I can force this visualization not taking in count l10n but I don't think
> this is the correct way to do it. It's up to you.
> 
> I attached a couple of screenshots. All other problems are fixed.

Text should be right justified

For now it is ok to keep all the same size. 
For the future it would mean a change to the graph scaling behavior to get it the way UX wants it exactly.

Comment 14

[Fabien Cazenave [:kaze]]

(In reply to Salvador de la Puente González [:salva] from comment #6)
> Kaze, about l10n, you recommended some time ago about remove all
> toUpperCase, can you help Sergi here? Are there official guidelines to
> review?

The guidelines could be summed up in one line: never concatenate nor transform any human-readable text.

For some languages (e.g. Greek), the uppercase form of some letters can be ambiguous and the capitalization rules (e.g. title case) can be very different from one language to another. If you want the text to be uppercase, just write it in uppercase in the *.properties file. If you need both lowercase and uppercase strings, I guess you’ll need two sets of entities in the *.properties file.

Comment 15

[Sergi]

Salva, from Fabien's answer i assume we can write months in uppercase inside the properties file. We do not need lowercase there. As far as this is an important improvement from UX perspective, can we update this?

Anyway, are you telling me we can't do it using CSS using text-transform:uppercase?

Thanks!

Comment 16

[Salvador de la Puente González [:salva]]

It is not as simple. If I include l10n changes, this bug could not be uplifted automatically. 

Furthermore, it adds extra complexity to l10n as now the strings would pass two translations: one to transform the abbreviations of months' names to upper-case, and another to include them in a short format concatenating the month's name with the day of the month properly.

Can we file another bug for this only?

Comment 17

[Sergi]

(In reply to Salvador de la Puente González [:salva] from comment #16)
 
> Can we file another bug for this only?

I've added a new bug and assigned it to you. Here's the link: https://bugzilla.mozilla.org/show_bug.cgi?id=848279

Thanks

Comment 18

[Salvador de la Puente González [:salva]]

Perfect, then let me finish the patch with last details and continue.
Thanks Sergi!

Comment 19

[Salvador de la Puente González [:salva]]

Attachment: Data Usage tab polish

Comment 20

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 722203 [details]
Data Usage tab polish

r+ once solved the minor comments pointed in the PR.

Thanks Salva!

Comment 21

[Salvador de la Puente González [:salva]]

Master: 5f7e5348af2418aefac3ec3d3f25f96151e5b130

Comment 22

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted commit 5f7e5348af2418aefac3ec3d3f25f96151e5b130 as:
v1-train: d7d80c87a1000f5c7b2971c5ff96ce2754339418