Gmail BiDi Enabling - A Case Study from Two Perspectives

44
Gmail BiDi Enabling - A Case Study from Two Perspectives Shoshannah Forbes, Shanjian Li 1

description

The Hebrew and Arabic versions of Gmail support bidirectional text editing. This talk gives a little "behind the scenes" peak into the process and issues of creating this bidi version of gmail, given from a dual perspectives- developer's and QA's. Topics include: Creating generic technical solutions for common problems (CSS changes, bracket handling, text layout order control), bug management strategies, better bug reporting enabling communication of complex issues and faster fixes and suggestions we have for future BiDi projects.

Transcript of Gmail BiDi Enabling - A Case Study from Two Perspectives

Page 1: Gmail BiDi Enabling - A Case Study from Two Perspectives

Gmail BiDi Enabling - A Case Study from Two Perspectives

Shoshannah Forbes, Shanjian Li

1

Page 2: Gmail BiDi Enabling - A Case Study from Two Perspectives

Agenda

‣A quick recap of bidi

‣The challenge

‣The Goal

‣Layout issues

‣Truncation issues

‣Element order

‣Brackets

‣Bidirectional text editing

‣ Geresh & Gershayim

2

2

Page 3: Gmail BiDi Enabling - A Case Study from Two Perspectives

A quick recap of bidi

Short for “bidirectional”- text flows both from Right to Left (RTL) and Left to Right (LTR)

3I assume that the audience here knows what bidi is, however, to make sure we are all on the same page, a quick recap is needed

Page 4: Gmail BiDi Enabling - A Case Study from Two Perspectives

4

Types of directionality for characters

‣ Strong characters

‣ Weak characters

‣ Neutral characters

4

Strong characters- they know their directionality Weak characters- determine their directionality according to their proximity to other characters with strong directionality Neutral characters- determine their directionality from either the surrounding strong text or the embedding level

Page 5: Gmail BiDi Enabling - A Case Study from Two Perspectives

5

The challenge

‣Bidi : one of the most messy problems in I18n.

‣Many bidi issues not solved cleanly in the industry yet.

‣Browser Bidi supports are buggy, and each browser behaves differently.

‣Direction change impacts whole layout, brings up many layout issues.

‣GMail is a complicated, dynamic AJAX applications with restriction of browser capability. Mail display, composing etc, and those are not static pages.

5

Page 6: Gmail BiDi Enabling - A Case Study from Two Perspectives

6

The Goal

5

6

Final goal- fully mirrored UI, mixing RTL and LTR elements and text

Page 7: Gmail BiDi Enabling - A Case Study from Two Perspectives

7

The goal- a closer look

7

Users tend to have mail both in English and in local language, so we need to be able to handle both (for example, email from international sits like facebook or last.fm). Although element order is RTL, many small details are LTR.Note the mixed language labels (and the numbers next to them), bi-directional sender names, and subject lines/snippets.Note how although the order of the elements (sender, unread count, label, subject, snippet) is rtl, each element can be either rtl or ltr.

Page 8: Gmail BiDi Enabling - A Case Study from Two Perspectives

8

Just plain flipping isn’t enough

8

You would think that setting dir=rtl to the body or html element will do the job. But look what it caused here...

Page 9: Gmail BiDi Enabling - A Case Study from Two Perspectives

9

From an early build

9

Page 10: Gmail BiDi Enabling - A Case Study from Two Perspectives

10

More complex than seen at first glance

‣ <body dir=”rtl”> is good, but hardly enough

‣BiDi is about text directionality, right? But HTML layout raised more difficult issues.

‣LTR elements are unavoidable, even with Hebrew/Arabic only emails. Because it is BiDi!

‣ Typical BiDi users use a mix of English and Hebrew/Arabic emails.

10

Page 11: Gmail BiDi Enabling - A Case Study from Two Perspectives

11

Layout issues

Look out for elements near the edge of the screen, esp. when resizing

11

Mirroring the UI can be really tricky and have a TON of bugs. psudo-rtl can help, although it was not used for this project.

Page 12: Gmail BiDi Enabling - A Case Study from Two Perspectives

12

Window made larger

12

The window was made larger, but the menu was still in the old location, covering the text and buttons. refresh would fix the display, but would also reload the full inbox (the wonders of ajax)

Page 13: Gmail BiDi Enabling - A Case Study from Two Perspectives

13

Window made smaller

13

Same page- window made smaller, menu jumped off the screen (notice the scroll bars)

Page 14: Gmail BiDi Enabling - A Case Study from Two Perspectives

14

Contact suggestion

14

The suggestion to auto-complete the contact fired nicely on a Hebrew key press, but the actual completion is way too far away (although properly RTL)

Page 15: Gmail BiDi Enabling - A Case Study from Two Perspectives

15

Snippets

15

As mentioned before, although the general order is RTL, each element needs to have it’s own directionality, as can be seen here (broken).

Page 16: Gmail BiDi Enabling - A Case Study from Two Perspectives

16

Things to look out for

‣Menus‣Fixed width elements‣Absolutely positioned elements‣“Auto complete” /Suggest‣Resizing‣Working in lower screen resolution

16

All of these things tend to break in RTL UI, but even more when windows get re-sized and locations need to be re-calculated by the browser.

Page 17: Gmail BiDi Enabling - A Case Study from Two Perspectives

17

How to fix?

‣Change whole html page's direction to 'rtl‘‣ Apply “dir” on “html” tag or “body” tag, like “<body dir=rtl>”.‣ Not to use CSS styling to control directionality, use markup.

-- ”Internationalization Best Practices: Handling Right-to-left Scripts in XHTML and HTML Content” by W3C

‣Rationale:

‣ Directionality is about document, not representation.

‣ CSS is not reliable, could be turned off or unavailable.

‣ Conforming user agent may ignore this CSS bidi properties.

‣This is considered as an exception. We strongly suggest heavy use of CSS in BiDi enabling. See next page…

17

Also, try to have clear style sheets. Why oh why didn’t begin and end get into css 3?

Page 18: Gmail BiDi Enabling - A Case Study from Two Perspectives

18

How to fix?

‣CSS offer a good separation of representation data.

‣Proper use of CSS is much easier to manage.

‣W3C best practice suggest separate CSS.

‣We also want a single CSS source. ‣ I18n and L10n will always be secondary, and will be ignored if things existing in

separate source tree.

‣CSS swapping can be done on server side / client side.

‣ Swap 'left' and 'right'

‣ Swap paddings, margins, border-width, border-style …

‣ Some CSS property might want to stay. Better organize them into 2 sections, section need to be swapped and section need not.

18

Page 19: Gmail BiDi Enabling - A Case Study from Two Perspectives

Truncation

19

19

Page 20: Gmail BiDi Enabling - A Case Study from Two Perspectives

20

Cut off location

20

In Hebrew and Arabic, the most important information is at the right, so you need to make sure not to cut from the right. This is the display under IE

Page 21: Gmail BiDi Enabling - A Case Study from Two Perspectives

21

Cut off

21

And the same under FF- FF cut the beginning of the text.

Page 22: Gmail BiDi Enabling - A Case Study from Two Perspectives

22

Cut off

‣Make sure to cut off from the left.

‣One example: Firefox table cutoff bug<table><tbody><tr><td dir="rtl" nowrap="nowrap"> <div style="width: 150px; overflow: hidden;"> first second third</div></td> <td><- Should be cut off on the left.</td></tr></tbody></table>

‣Solution: Wrap a fixed width div element <table><tbody><tr><td dir="rtl" nowrap="nowrap"> <div style="width: 150px; overflow: hidden;"> <div style=“wdith:600px”; align=right> first second third </div> </div></td> <td><- Should be cut off on the left.</td></tr></tbody></table>

22

Work around for table cut off bug in Firefox we saw- put a fixed width div inside. the right aligned element made the browser chop off from the left.Beware: IE 6 has a bug, causing the layout to be garbled in certain cases when there is a div inside a cell. (fun!)

Page 23: Gmail BiDi Enabling - A Case Study from Two Perspectives

23

Element order

23

x out of y are tricky in Hebrew- each element is ltr, but the order of them is rtl. Also, notice here that we have a run of weak and neutral characters. Need to use <span> and &rlm; in places

Page 24: Gmail BiDi Enabling - A Case Study from Two Perspectives

24

How to fix?

‣Element order is not always consistent with layout order, because layout is “Bidi”.

‣Raise embed level: <span dir=”rtl”>blah blah</span>

‣ Insert invisible bidi mark &rlm; / &lrm;

‣Control a element group’s internal and extern directionality. Use embedded span tag. <span dir=rtl> <span dir=ltr> some text! </span></span>

‣Beware of browser bugs! If you omit the space between first 2 span tag, you will have a surprise.

24

Better to use span, but you can’t always- in those cases use the right entity. Mozilla has a weird span tag merge "functionality". If you don't separate SPAN tags with space and newline, thing won't happen the way you want.

Page 25: Gmail BiDi Enabling - A Case Study from Two Perspectives

Bracket issues

Weak characters? I think not!

( )[ ]

< >

25

25

Page 26: Gmail BiDi Enabling - A Case Study from Two Perspectives

26

Conversation display

26

you can play “find the bugs” in this picture. But the interest is the brackets (ok on top, broken on bottom)

Page 27: Gmail BiDi Enabling - A Case Study from Two Perspectives

27

Contact display

27

The contact has set his details to have both Hebrew and English- which confuses the display of the brackets around the email address.

Page 28: Gmail BiDi Enabling - A Case Study from Two Perspectives

28

28

Notice the brackets around the English filters

Page 29: Gmail BiDi Enabling - A Case Study from Two Perspectives

29

Brackets and arrows

29

Keep and eye open for arrows pointing at stuff, back/forward icons, and disclosure triangles

Page 30: Gmail BiDi Enabling - A Case Study from Two Perspectives

30

30

Page 31: Gmail BiDi Enabling - A Case Study from Two Perspectives

31

Brackets

Not as weak as you might think...

In unicode bidi layout algorithm, bracket’s directionality is determined by its context.

But, each bracket is considered separately.

Solution: span tag or &lrm;/&rlm;Javascript regex is a efficient way to deal with this issue. str.replace(/(\([^\)]*\))|(\[[^\]]*\])|({[^}]*})|(&lt;[^&]*&gt;)/g,'<span dir="rtl">$&</span>');

The span tag works more reliably in html context, but lrm/rlm is more compact.

31

In applications, and esp. in email, brackets are used for more that originally thought of, and since they are weak, things tend to break. A few examples...

Page 32: Gmail BiDi Enabling - A Case Study from Two Perspectives

32

Things to look out for

‣ Arrows pointing to stuff

‣ Next / Previous icons

‣ Disclosure triangles

‣ Copyright symbol

‣ Brackets at element boundary

32

Page 33: Gmail BiDi Enabling - A Case Study from Two Perspectives

33

How to fix

Have finer control where the element should go

With the span trick, you can control a group of text’s external directionality.

From: [label message] (16)

33

(Consistency sometimes is more important.) "XXX (12)" and "abc (12)" will be layed out as "(12) XXX" and "abc (12)", that's inconsistent for column display. Other things may also need to be "guarded". Fraction character " 1⁄4", "1⁄2", "3⁄4" are examples.

Page 34: Gmail BiDi Enabling - A Case Study from Two Perspectives

34

How to fix

To:

<span dir=rtl> [label message] </span> <span dir=rtl> (16) <span>

34

(Consistency sometimes is more important.) "XXX (12)" and "abc (12)" will be layed out as "(12) XXX" and "abc (12)", that's inconsistent for column display. Other things may also need to be "guarded". Fraction character " 1⁄4", "1⁄2", "3⁄4" are examples.

Page 35: Gmail BiDi Enabling - A Case Study from Two Perspectives

35

Bidirectional text editing

For more than a few words of text, users want control!

35

The moment the users are going to enter more than a few words, they would like to be able to control the directionality.This is done by giving directionality control buttons, similar to what is seen in desktop applications.

Page 36: Gmail BiDi Enabling - A Case Study from Two Perspectives

36

Bidirectional toolbar

36

RTL and LTR toolbars, with bidirectional controls.Things to note:* The current directionality and alignment are highlighted (they are related, but separate).* Some icons change their function/appearance according to directionality- indent, outdent, quote, lists.

Page 37: Gmail BiDi Enabling - A Case Study from Two Perspectives

37

Mixing both in the same email

37

This is much harder than it seems, and there are many edge cases. Since we only do “block level” inline control can’t be done.This is the old 80/20 rule.

Page 38: Gmail BiDi Enabling - A Case Study from Two Perspectives

38

How it is done

‣Rich text editing is a complicated issue.

‣IE has the directionality switch functionality in design mode if you could accept its behavior.

‣In Firefox, we manipulate DOM node.

‣Since Firefox uses <br> to separate paragraphs, you might need to create new block element to apply directionality.

‣List needs to be treated as a whole.

‣Toolbar need to reflect directionality in current selection, and change appearance accordingly.

38

Page 39: Gmail BiDi Enabling - A Case Study from Two Perspectives

39

How it is done: more on DOM

‣Directionality detection and switch is done on block level.

‣Block level elements need to be created when it is not there yet.

‣Block level elements could be removed when it is not needed.

‣Based on selection range, we need to grab all the block element involved.

‣Though directionality and alignment are separate issues, user often perceives them as a whole.

39

Page 40: Gmail BiDi Enabling - A Case Study from Two Perspectives

Geresh and Gershayim

40

HEBREW PUNCTUATION GERESH- 05F3HEBREW PUNCTUATION GERSHAYIM- 05F4

40

Page 41: Gmail BiDi Enabling - A Case Study from Two Perspectives

Geresh Examples

41

George Bush

Winston Churchill

Jean-Jacques Rousseau

Doc. Dolittlee

Prof. Kahneman

5th of Iyar

41

Page 42: Gmail BiDi Enabling - A Case Study from Two Perspectives

Gershayim Examples

42

USA

Attorney

LTD

Accountant

UN

Katz (common sure-name)17th of Sivan, 5,738

42

Page 43: Gmail BiDi Enabling - A Case Study from Two Perspectives

One possible fix

Replace latin characters with proper Hebrew ones

function I18n_QuoteReplacementInHebrew(str) { for (var i = 1; i < str.length; i++ ) { if (str.charAt(i) == '"') { if (str.charAt(i-1) > '\u0590' && str.charAt(i-1) < '\u05f3') { str = str.substring(0, i) + '\u05f4' + str.substring(i+1); } } else if (str.charAt(i) == "'") { if (str.charAt(i-1) > '\u0590' && str.charAt(i-1) < '\u05f3') { str = str.substring(0, i) + '\u05f3' + str.substring(i+1); } } } return str; }

43

43

Page 44: Gmail BiDi Enabling - A Case Study from Two Perspectives

44

Summary

• Bidi has 2 directions, not just RTL.

• Apply “dir=rtl” to “html” or “body” tag.

• Fix page layout issues. If possible, do it through CSS.

• Fix text layout problems.

• Fix misc stuff, like image, popup dialog box, etc.

• Be careful about differences in browsers and each browser’s specific deficiency.

44

RTL is basically a presentation stuff, CSS can help to greatly reduce the number of issues. A bunch of solutions are available in JS code now, and can easily be ported to other places.Otherwise, try to avoid explicit alignment.Many many bugs- don’t be afraid.