Description: Asian and CTL language users can't immediately check font name at format dialog since LibreofficeDev rev.d73602dc51aa8829fc88e5e67e2b0c4da6b8f715. You may say "It's not a bug but design." However, I think from the viewpoint of UX, it is undesirable that only users who use Asian and CTL fonts have to do such operation. The Font tab always shows Western notebook first whatever font contained in the selected text. This means that the name of Asian or CTL fonts is never seen first when the Font tab is shown even if the text has only one of such fonts. That makes Asian and CTL users confused before clicking 'Asian' or 'Complex' tab because a user will usually believe what dialog shows first reflects present state. In order to know the exact font name, an extra step, clicking 'Asian' or 'Complex' tab is required every time. That is bothering for the users. I understand why the such changes have been made, however wonder if the actual result is against "Simple for beginners", the LibreOffice on Desktop UX goal. Steps to Reproduce: 1. Type a text with a Japanese font. 2. Select the Japanese text. 3. Click Format -> Charactor... (and Charactor dialog is opened.) 4. Click Font tab. Actual Results: "Western" notebook is opened and the "Family" indicates the Font name for a west European language Clicking 'Asian' tab is requiered in order to check the exact font name. Expected Results: "Asian" notebook is opened and the "Famly" indicates the Japanese Font name. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 503f10205559673185150110c2d2a2faacab1fcb CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: CL
Created attachment 177716 [details] sample odt file sample file
I agree with the awareness of the issues. I hope "Font" tab page to be returned to the previous layout for the moment.
Moved the fonts into a GtkNotebook (aka tabs) to reduce the dialog size for small screens. Before submitting the patch I asked on the CJK/CTL Telegram group whether this would be a blocker for the workflow and got green light. So I hesitate to switch back unless many user will complain / CC here. However, the probably better solution is to open the right tab depending on the font in focus. In this case you wont see Western unless the text is Latin. Shouldn't be too difficult.
(In reply to Heiko Tietze from comment #3) > Moved the fonts into a GtkNotebook (aka tabs) to reduce the dialog size for > small screens. Before submitting the patch I asked on the CJK/CTL Telegram > group whether this would be a blocker for the workflow and got green light. > So I hesitate to switch back unless many user will complain / CC here. > > However, the probably better solution is to open the right tab depending on > the font in focus. In this case you wont see Western unless the text is > Latin. Shouldn't be too difficult. Most Japanese documents use both Japanese and English characters at the same time. Even in Japanese documents that do not use alphabets, numbers are written in half-width characters and Western fonts are used. Japanese users (maybe all CJK users) need to set both Asian and Western fonts. Also, the balance between Japanese and English font sizes is important. In some cases, they may adjust the settings of the two fonts many times. This is because each font has a different font size. And font settings aren't just used when creating documents. Rather, it is often used when editing documents created in other environments. Style font settings are a very important feature for ensuring interoperability with Microsoft Office and multiple operating systems. In conclusion, I think it's important for CJK users to be able to see both Western and Asian fonts at the same time and edit them in one place. I would like to know why CJK users are required to make such a big sacrifice
(In reply to Heiko Tietze from comment #3) > Before submitting the patch I asked on the CJK/CTL Telegram > group whether this would be a blocker for the workflow and got green light. I'm sory for not being able to reply at the right time on CJK's Telegram group. So far, all the feedback I've received from a few people is negative for this UI change. In fact, very few people in the Japanese community are willing to participate in these discussions. I don't know why, but it may be the influence of a culture that dislikes debate. However, in my imagination, when this UI change is released, Japanese users will feel that their existence is being neglected. I've already received such an opinion from one person, even though it is not released it yet.
I'm sorry for the late response. It depends on my poor physical condition. I have the same understanding as Enoki. We always deal with documents where Western and Asian are mixed in the same paragraph. Layout with Notebook UI increases our operation steps and greatly reduces usability. I don't understand why we now have to reduce the dialog size at the expense of our usability. The height of the paragraph style dialog in 7.3.0 is 713px in my environment (Win 10). All my PCs purchased after 2000 have a screen size of 768px or more. Even the oldest smartphone I own have 720px. Also, Bug 139395 was an issue where the increased number of items on the "Font Effects" tab page did not fit on the 768px display. In the paragraph style dialog, the "Aria" tab page etc. are also taller than the "Font" tab page. For the "Font" tab page, I don't know who is having trouble with the previous layout that has been widely used so far. As you know, the CJK Telegram group is not so active. The activity before Heiko threw the article on January 13th was last August. There are only a few users who speak. The reduction of usability only reduces the number of LibreOffice users, quietly. Members of the CJK Telegram group, including myself, were talking about Bug 146910 as a premise. About Notebook UI, we don't necessarily get green.
I'm sorry I mistyped about "Area". I forgot to mention one point. In the layout with Notebook UI, not only the operation steps but also the visibility becomes the first issue. Not being able to compare and confirm the setting status of Western and Asian at a glance greatly reduces workability.
Created attachment 178419 [details] ubuntu hidetopbar image It can be solved by ingenuity. Screen height is no problem at 768px. install "gnome-shell-extension-autohidetopbar"
Created attachment 178567 [details] Test Layout [Paragraph Style]-[Font] JO3EMC 20220216a After Comment 7, I had a long discussion with Heiko on the Telegram CJK channel on 2022-02-17. Thank you for that, @Heiko. In the discussion, Heiko emphasized the importance of reducing the height of the dialog. As in Bug 139395 Comment 10, he says it needs to fit in 600px according to HIG [1]. [1] Wiki Global "Design/Guidelines/PropertyDialog" https://wiki.documentfoundation.org/Design/Guidelines/PropertyDialog I feel that a 600px dialog size is an over-requirement for a 768px display size, but if that's the guideline's judgment, then it's unavoidable. It's still unconvincing to me that we're making changes to the "Font" tab page, which is a major detriment to our usability, before the other larger tab pages. I don't think the discussion on the layout proposal was held with enough time to gather the voices of CJK/CTL users. However, there is no objection to aiming to comply with the guidelines as a future issue. Under such circumstances, I was thinking about the 600px layout like an attached file. I think it's feasible with a layout like page 8 "Omit Frame Header", but I can't tell if it's damaging HIG or other requirements. When I asked some Japanese users about their opinions, they all felt that the notebook layout would make it less convenient to use, but there were also voices that supported respect for HIGH, and I felt the mood of giving up. Unfortunately so far, my claim for reverting does not seem to have gained clear support. Given the above, I would like to withdraw my claim for reverting in this issue. The discussion of layout improvement will take a considerable amount of time. Please revert to the original request (Expected Results:) of this issue to improve the usability of the notebook layout, which is unlikely to be reverted to the previous layout for the time being. I don't have clear opinion now if Heiko's suggestion in Comment 3 is better or not. I would like to expect the opinions of others. Only one point. In the notebook layout, I would like to be assigned the same accelerator key for the Asian "Features ..." button in the en-US locale as Western/CTL. The current implementation of 7.4.0.0a0 seems to differ only in Asian. Regarding the layout of the "Font" tab page, I would like to participate in the discussion of improvement if the momentum seems to increase in the future while watching the release of 7.4 or latter.
Heiko: Is it difficult to support with 7.4.0?
(In reply to JO3EMC from comment #10) > Is it difficult to support with 7.4.0? What exactly do you want to support? Revert the patch (the 600px is not carved in stone but a good rule of thumb) or open the corresponding tab depending of the language at the cursor (might be difficult)?
> That makes Asian and CTL users confused before clicking 'Asian' or 'Complex' tab because a user will usually believe what dialog shows first reflects present state. As far as I can speak for RTL language users (which is to be debated...) I semi-disagree. The tab heading clearly states "Western". And - RTL language users are used to there being "two fonts" - the English/LTR/European languages font and the RTL languages font. (You could argue that "Western" is a questionable choice of name, but that's a different story.) I agree that in its previous state, the dialog was kind of repetitive; and that readability is somewhat improved now. What I suggest as an alternative solution is that, when the Character properties dialog is opened, the focused tab will be the one corresponding to the language group in whose context the dialog was opened. That seems like Heiko's second suggested option; and it should suffice to avoid the element of surprise described by Kiyotaka-san (Or is it Nishibori-san? Sorry, I couldn't figure out which one is the family name).
My own first choice is revert, but I've withdrawn that claim because I haven't received the support of the community so far. In that case, I don't have a clear idea of how the Tab Notebook UI behaves. On the other hand, the suggestions of Nishibori, Heiko and Eyal seem to be consistent. It may be the opinion of this place. (In this case, Nishibori is a family name. However, in Japan, there is a movement to reorder the names in English recently. It may be confusing in the future. And I'm afraid but also I can't figure out the family name for Eyal and Heiko...)
(In reply to JO3EMC from comment #13) > I don't have a clear idea of how the Tab Notebook UI behaves. To be clear - my comments did not regard the "Tab Notebook UI" (which I dislike and don't use). > And I'm afraid but also I can't figure out the family name for > Eyal and Heiko... Eyal and Heiko are both personal names, not family names.
Oh ... I was careless about using the terms. My intention was not the Tabbed UI of LibreOffice, but the notebook component (= GtkNotebook) in the font settings dialog. Sorry for the misleading expression. > Eyal and Heiko are both personal names, not family names. Thank you very much. I will remember.
(In reply to JO3EMC from comment #9) > Created attachment 178567 [details] I like most the integrated icon-only buttons. But consider also how the dialog looks when CJK/CTL are disabled, somewhat naked I'm afraid. A completely different solution is to have three columns, actually a table. Maybe worth to try.
I don't know what "the integrated icon-only buttons" means ...but, the current implementation seems to have a completely different design layout when CJK / CTL is disabled. The arrangement and parts are completely different. Therefore, it seems nonsense to take that into consideration when considering the layout here. Isn't it better to design independently? I also dreamed of the three-row arrangement. However, given the frame splits that "Western" users seem to want and the long messages like "The same font will be used on both your printer and your screen.", that idea seemed difficult and I stopped considering it. I think it seems quite difficult to fit in the 800px width dialog that HIG requires. I can't imagine a concrete layout image, including the requirements required in the horizontal direction. The traditional layout seemed better. In any case, it seems that such a study will take a considerable amount of time to discuss, I think. I don't think it will be in time for 7.4 at all. It was said that reverting would be difficult without the requests of many users, so I understand that we cannot secure time for that consideration. Around me, there are opinions that it is better to actually release the current implementation of tab notebook and leave it to the market evaluation.
(In reply to JO3EMC from comment #17) > I don't know what "the integrated icon-only buttons" means ... When the button has no label but only an icon. > The arrangement and parts are completely different. The western section was the only one shown in a large dialog tab before the patch with a lot of white space. Technically we had three frames and hid some depending on the options. Now the tabs are shown or hidden making it a bit more balanced. > long messages like "The same font will be used on both your printer... Can't we use one option for all languages here?
Created attachment 179898 [details] 254dpi ScreenShot [Paragraph Style]-[Font] CJK/CTL Off in 7.3.2.2 I made a mistake in the term in the previous post. "the three-row arrangement" should have been called "the three-column arrangement". Excuse me. > The western section was the only one shown in a large dialog tab before the patch with a lot of white space. I have attached a screenshot of CJK/CTL Off in 7.3.2.2. The same is true for earlier versions, and almost 7.4.0.0.a0 too. As you know, list boxes those don't exist with CJK/CTL On are placed. It doesn't look like "with a lot of white space". The placement of the "Language" field is also different from when CJK/CTL On. It's true that the technical structure is 3 frames, but with such differences, it's already an original design. I don't think that it's good, but also I don't think it has to be changed with losing usability of CJK/CTL users. The mental health problem of "with a lot of white space" does not specifically impair usability compared to CJK/CTL users. What's more, the traditional design doesn't really make such a situation. Rather, it may have provided better visibility only to Western users. On the other hand, a separated pane design really violates the usability of CJK/CTL users. I was saying that. The only problem that exists is to the size which requested by HIG. > Can't we use one option for all languages here? Do you mean to display messages for three language groups together? I can't tell if that's possible. Isn't this message the result of some judgment? Or is it a literal rather than a placeholder? If it's a placeholder, it seems too big a problem to deal with here. Because this issue is just discussing the layout. I think it is necessary to discuss the functionality. I don't know how to put together messages for three different fonts. I also don't know if other types of messages will be displayed. If it is literal, it may be okay to put it together. If so, a layout like pages 6 and 7 of attachment 178567 [details] will solve the problem. There is no need to make major changes to the traditional layout. It may be possible to make it even more compact by combining it with the ideas on pages 8 and 9. In any case, I don't think we have time left for such a discussion. Once the notebook layout is released, it will be difficult to re-change to a design close to revert for a while.
Created attachment 179899 [details] Test Layout [Paragraph Style]-[Font] JO3EMC 20220503
(In reply to Heiko Tietze from comment #16) > A completely different solution is to have three columns, actually a table. > Maybe worth to try. Do you think of "three columns" as something like page 10 of attachment 179899 [details]? Indeed, it may be possible to layout. If this kind of thing could be done technically. The contents of the Font field are hard to identify, but it doesn't seem to be a problem if we only use up to two language groups. If the extra space required by HIG, such as 24px between frames, can be adjusted, it may be a little better. I'm a little worried about how the accelerator key behaves. When CJK/CTL Off, the "Western" fields will be stretched horizontally, but I'm not sure if that's okay. From the perspective of inheritance, I think that the conventional layout base is preferable, but it may have been one option.
The row headings (field label) may have to be a little wider. Depending on the UI language.
Created attachment 180245 [details] CTL/CJK in tabs Played around with a GtkGrid where three columns hold the languages next to each other. Blocker here is that comboboxes take the width of the largest entry, which is in particular relevant for the read-only comboboxes. In the consequence I get a dialog with ~1000px width. We could place CJK and CTL into tabs so only two columns are visible at once. Family should become a list, Style and Size next to each other, the NB border removed - and to align controls of western with ctl/cjk I'd have to use a GtkNotebook there too. What do you think?
Created attachment 180443 [details] Test Layout [Paragraph Style]-[Font] JO3EMC 20220528 This is just my personal opinion, but... Even if you are asked "What do you think?" ... I can only answer "not good". The reason has been mentioned so far. As mentioned in Comment 19, if we can unify the messages, it seems possible to achieve the required dialog size with a layout that is close to traditional one, like attachment file. We don't need the Notebook Widget at all from the beginning. We should have been able to continue to use the familiar and easy-to-read layout. "Western" only users also should have enjoyed the same layout benefits as before. The example layout given in Comment 23 may be better than the one currently implemented in 7.4, but it's worse than the traditional layout. To get the time to do such discussions, I repeatedly and strongly asked for a revert to the traditional layout. But the request was rejected by the forced adoption of the Notebook layout. Unfortunately, it has already been decided that the layout that has been adopted for many years will be replaced with the Notebook layout. It was a decision that did not take into account the opinions of CJK/CTL users. However, it is irresponsible to change the frequently used interface layout easily and frequently. Without looking at the evaluation of the released Notebook layout, I don't feel the need to discuss the basic structure of the layout anymore. At present, what we can only do is evaluate the usability of the notebook layout that has been adopted unfortunately and make the improvements like suggested in this issue. If we continue the discuss about the basic structure of the layout, I think we need to be able to continue using the traditional layout for the time being, not to cause confusion. What on earth are you aiming for and calling for opinions?
(In reply to JO3EMC from comment #24) > What on earth are you aiming for and calling for opinions? I don't understand your reply. I am working on alternatives to the tabbed UI and two columns with Western next to CTL or CJK sounds perfectly fine to me since you probably never switch between the two.
I also don't understand. No one needs extra switching operations in a layout based on traditional styles. No one. I don't understand why you want to increase the step of operation so much. However, as mentioned above, the Comment 23 proposal seems relatively better than the one implemented in 7.4 currently and may help many users, in my opinion. It doesn't seem perfect to me at all, but it might be better to adopt it than to keep implementing the current one.
Traditional styles like Attachment 180443 [details] will not require the implementation of features you suggested in Comment 3 as before, but Attachment 180245 [details] styles do. Do we have to take the risk of implementing a feature that we don't know if it will work for everyone?
Maybe the problem is that the "Features..." button gets too big depending on the UI language?
Thank you for discussion and efforts so far. Sorry for the late comment. https://bugs.documentfoundation.org/show_bug.cgi?id=146928#c23 If my understanding is correct, Western is always visible, Asia and Complex can be switched on tabs. This Heiko's idea is much better than the current development version because it can set Western and Asian languages without switching tabs. I was a little wondering why only Western is always displayed, but it is easy to use for Japanese users. Another way, if JO3EMC’s idea solves the problem of the vertical length of the dialog, that is a good approach. The previous layout is not the best, but the risk of UX changes is minimal. However I don't know if that is technically possible.
Created attachment 180527 [details] Screenshot https://gerrit.libreoffice.org/c/core/+/134666 Need to do a final check tomorrow before it goes into production...
(In reply to Heiko Tietze from comment #30) > https://gerrit.libreoffice.org/c/core/+/134666 And for CTL/RTL + Western only, we'll also get this layout? And can you post a screenshot with all three enabled?
(In reply to Eyal Rozenberg from comment #31) > And for CTL/RTL + Western only, we'll also get this layout? Yes, CJK and CTL are placed in tabs, which are shown depending on the language settings. Unlikely to use both options so CTL looks the same as CJK.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/196d9e16b7017db2225531cd240e7b6e8f7c1d66 Resolves tdf#146928 - Redesign charnamedialog It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Trying to rephrase the title to encompass the entire discussion and better correspond to what ended up happening.