Where I work I always have to switch between LO and MSO applications because my students/colleagues mostly use MSO. From using Calc and Excel very often, one thing that always struck me is that it seems that Excel has more space available for entering data into the spreadsheet than Calc does, but I never understood why I had this feeling. Today I figured out why I have this impression... it is because the default width of columns in Calc is about 33% wider that the width used in Excel. The default widths are: In Excel: 1.69cm In Calc: 2.26cm Because of this, when I create an empty sheet in Calc, I get to fit 46 rows x 22 columns (at 100% zoom on a 1920p display, no scaling). On Excel I get to fit 38 rows x 29 columns at 100% zoom. So LO has an advantage in the number of rows (Excel's ribbon UI takes up a lot of vertical spacing), because our UI takes up less space. But the smaller number of columns makes it feel like the default column width is too wide... I always find myself reducing them without even entering data, so that I can see more columns. I know that this is super subjective, but try setting a template with default width of 1,69cm... this feels more "optimized" (in a subjective way) to start a new spreadsheet. So I'm creating this report to discuss whether we should change the default column width in Calc to something narrower, possibly using 1.69 cm as well.
BTW, the overall number of cells visible is smaller in Calc than in Excel: In Calc: 46 x 22 = 1012 cells In Excel: 38 x 29 = 1102 cells
Having a working template mechanism, I find it strange to change defaults like this. There will never be a default fitting everybody. And this request is possibly the only one in our 150000+ bug tracker. I doubt it is worth it.
The other thing is that we might want to change the hardcoded constants into configurable settings ... but that creates some kind of alternative to templates (though having differences). We already provide such settings as "document default language" or epoch, so having more would not change things drastically. But that "un-hardcoding" should be accompanied by another change - bug 144814 - about moving the document defaults out from Options.
In any case, the default column width should also consider how many glyphs (characters) are expected to be seen in such width. That is, using the default font, the default font size, the default row's height and the default column's width, how many characters are completely seen without additional formatting? To test that condition, the screen resolution, screen scaling, text scaling, and zoom features (from Calc itself and from the OS) are also relevant. I also assume that some other conditions might be relevant too, such as the desktop environment (e.g. using (vertical) task bars and/or similar items). Such test should involve 3 rows by 3 columns (at least).
(In reply to Mike Kaganski from comment #2) > Having a working template mechanism, I find it strange to change defaults > like this. There will never be a default fitting everybody. LO has a very nice template mechanism indeed and this issue can easily be fixed by creating a simple template. However, the reason I brought this up is because I would like to discuss the default experience we're offering users when they first open Calc. Also, many users are not savvy enough to know how to create a template and set it as default. See for instance the discussion in bug 33743 (define default fonts for Calc and Impress). The solution would be to create a new template as well, but this is a bit advanced for many users. (In reply to Mike Kaganski from comment #3) > The other thing is that we might want to change the hardcoded constants into > configurable settings... If wee decide to make this configurable, we could add this option to Tools - Options - LibreOffice Calc - Defaults. But maybe it should simply be hard-coded. I don't know whats best UX-wise.
(In reply to Mike Kaganski from comment #2) > There will never be a default fitting everybody. True, but we should probably minimize some metric of annoyance, or the mean amount of customization/modification work people do relative to the default. Naturally we don't actually measure this, but certainly a discussion can be had regarding how the default width is chosen. And speaking of that... how _did_ we choose the hard-coded value we have now? > And this request is possibly the only one in our 150000+ bug tracker. But this may well be because people do not consider the possibility of making this request, as it's a subtle comparative-usability issue. (In reply to Mike Kaganski from comment #3) > we might want to change the hardcoded constants into configurable settings Perhaps, but even when that happens - there's the matter of choosing the default. So I don't believe this bug should wait until the setting is un-hard-coded. I'm not sure I have a strong personal opinion about what the default width should be. Right now, I can fit the number "12345678901" into a cell, but not "123456789012". Is this good? Is this bad? Not sure. BTW, we may also want to think about the number of columns we can fit when the window does not fill a wide-aspect-ration screen, e.g. on a 4x3 display, or when it's sized to half of the screen.
We discussed the topic in the design meeting. We shared the view that Excel cells are too narrow but ours is a bit too large. But it's very much a personal taste and good for a quick poll. We may offer three or more options like ( ) 1.5cm, ( ) 2cm, ( ) 2.5cm, or the like, and we could even ask freely. However I think the easiest and most reliable way is to find a good value from the design POV and ask users whether they prefer the current value (aka don't change) or the new. So what would be the best choice? (keeping UX keyword until the poll is finished)
I wouldn't touch it. It isn't matter what width cell in new spreadsheet for me. I enter the data in cells and then format cells as I need anyway.
(In reply to Roman Kuznetsov from comment #8) If, for you, it doesn't matter - then you're basically voting "abstain"... Anyway, the current width is 2.26 cm . I'd also look at options relative to 1 inch (1"). Right now we have about 0.89". reasonable option might be 0.8" = 2.032 cm - fits 012345678 and half of a 9. 0.75" = 1.905 cm - fits 0123456789 I would not go below that.
(In reply to Eyal Rozenberg from comment #9) > 0.8" = 2.032 cm - fits 012345678 and half of a 9. > 0.75" = 1.905 cm - fits 0123456789 FWIW, that would be the other way around, twofold... 0.8" fits 1234567890 while 0.75" fits 123456789 plus half of a zero, which could easily be automatically presented in scientific format – that's what happening in my system. Besides the width for the characters themselves, each column demands some additional "padding" space by default. Please don't forget that other factors influence the rendered result too.
(In reply to ady from comment #10) > FWIW, that would be the other way around, Yes, I mis-copy-pasted, sorry.
(In reply to Eyal Rozenberg from comment #9) > 0.8" = 2.032 cm - fits 012345678 and half of a 9. > 0.75" = 1.905 cm - fits 0123456789 I like the idea of 1.905 cm (0.75").
[Automated Action] NeedInfo-To-Unconfirmed
https://fosstodon.org/@libodesign/110275158368343954
Note that, in case there's a decision to go with a change, it is absolutely bad to make a global default in inches, which are used by minority of the population of the world. Either we get per-locale default, or we create a *metric* global default (noting that even where inches are used as a primary unit, metric system is also usable and standardized).
(In reply to Mike Kaganski from comment #15) > Note that, in case there's a decision to go with a change, it is absolutely > bad to make a global default in inches, which are used by minority of the > population of the world. I agree in principle. We don't use inches in Palestine/Israel. The thing is that the current width is close to an inch, so it seemed more intuitive to think about it in those terms. But 2cm, 1.9cm is also fine by me.
(In reply to Rafael Lima from comment #12) > I like the idea of 1.905 cm (0.75"). May I ask, why? Is it the amount of digits (9, without separators)? Is there any non-subjective reasoning? Let's not forget that the default font is not mono-spaced (i.e. not fixed-width), so the width for digits is not the same as some other set of characters. Users with accounting requirements might like some default, whereas engineers might prefer some other default width. The current calculation accuracy of 15 digits might sound ideal for some users to match the default width. (In reply to Mike Kaganski from comment #15) > Either we get per-locale default That would result in users seeing different areas according to their locale, which might make it unnecessarily more difficult to reproduce some behavior, either between users sharing some document, or for some bug reports.
Default of STD_COL_WIDTH is set to 64 twips in sc/inc/global.hxx.
(In reply to Heiko Tietze from comment #18) > Default of STD_COL_WIDTH is set to 64 twips in sc/inc/global.hxx. No, to 64 *points* (point is 1/72 in) (and that value converts to twips for internal use).
The "problem" has a very simple solution using default template customizing. I still don't see any real reason to change the default cell size
For understanding the values: Measurement of cell widths is in typographical points (1/72 inch) and the internal calculation is in twips (twentieth of an inch point, 1/20 point = 1/1440 inch) The current value is 64 points or 1280 twips, which is 0.88888" or 2.25775cm. The proposed value would be 54 points or 1080 twips, which is 0.75" or 1.905cm. The nearest value to 20mm would be 57 points or 1140 twips, which is 0.79166" or 2.01081cm. If we defined cell widths directly in twips instead we could get nearest to 20mm with 1134 twips, which is 0.7875" or 2.00025cm or 56.7 points. A rather odd value for typography.. and quite likely provoking round-off errors in layout.
(In reply to ady from comment #17) > Let's not forget that the default font is not mono-spaced (i.e. not > fixed-width), so the width for digits is not the same as some other set of > characters. Sane proportional fonts have monospaced digits.
(In reply to Eike Rathke from comment #21) So 54 points is nice and round. If we were to go with 0.8", it would be 55.6 points or 1112 twips. (In reply to Eike Rathke from comment #22) > Sane proportional fonts have monospaced digits. Well, Times New Roman and its brother, Liberation Serif, are not part of that sane group... and that's the case also for Arial and Liberation Sans. I vaguely recall LO phasing them out in favor of Carlito and Caladea, but that doesn't seem to have happened very earnestly.
Liberation Sans digits appear perfectly monospaced in Writer and Calc. Anyway, this is getting off-topic.
(In reply to Eike Rathke from comment #22) > Sane proportional fonts have monospaced digits. ... which is not what ady talked about - the phrase was that "the width for digits is not the same as some *other set of characters*". (In reply to Eyal Rozenberg from comment #23) > Well, Times New Roman and its brother, Liberation Serif, are not part of > that sane group... and that's the case also for Arial and Liberation Sans. Huh? These fonts do have the same width for digits. > I vaguely recall LO phasing them out in favor of Carlito and Caladea, but that > doesn't seem to have happened very earnestly. LO? TNR and friends are MS fonts, and Carlito at al are a metric-compatible substitutes for a *different* set of MS fonts. LO is not in a position to phase fonts out from users' documents, it can only provide descent substitutions (which it does, both for older and for newer MS fonts). [/OT]
64 points = .888889 in --or-- 2.260 cm But I kind of doubt our STD_COL_WIDTH (of 64 pts) and STD_ROWHEIGHT_DIFF (of 23 pts) are being calculated the same way on Excel where UI works with character units (default of 8.43 ch and 15 pt height). Also, folks do realize that the "default" cell on MS Excel is formatted with 11 point Calibri, while in LibreOffice Calc we use 10 point Liberation Sans? LO fits 11 at 10pt "12345678901" MS fits 8 at 11pt "12345678" Compounded by the fact that few os/DE actually work at 100% scaling. Windows for example defaults to 125% scaling on a Full HD 1920x1080px display--so it is a moving target unless we move to a character "ch" based UI. Point is a user can adjust their environment to match an Excel session when working in OOXML, but for our ODF originated sheets there is no real point. -1 for any change from current LO defaults pursuing interoperability. It would not offer any real relief as we are unlikely to adopt a UI oriented to character counts for Calc column widths.
(In reply to V Stuart Foote from comment #26) > -1 for any change from current LO defaults pursuing interoperability. It > would not offer any real relief as we are unlikely to adopt a UI oriented to > character counts for Calc column widths. Just to clarify a bit, this request has nothing to do with interoperability. Column width and height already are interoperable with MSO and other office suites. This request is about the default experience we offer users. It is about what they first see when they open LO Calc, even for those who do not know what a template is. I still feel that our cells are a bit too wide, which gives an initial impression that Calc does not use well the available space (see Comment #0 and #1). Maybe we do not need to go as far as 1.69cm (as in Excel), but changing it to something closer to 1.9cm will already be an improvement. With 1.9cm column width, at 100% zoom in a 1080p display it is possible to show 26 columns (as opposed to 22 columns with the current 2.26cm default width).
(In reply to Rafael Lima from comment #27) As I noted -- MS Office Word presents a UI of 8.43 characters and uses *Calibri at 11 points*. We calculate a width of 64 points but use *Liberation Sans at 10 points*. Different "M" em-space width (11pt vs 10pt), also Calibri is a screen font vs our Libreration Sans font that only matches metrics of Arial, accordingly the feel will never match between the two UIs. Also that is only at 100% os/DE scaling. Any os/DE desktop scaling, which is the norm, skews the differences further.
Asked of Mastodon [1] and 63% out of 408 people voted to keep the current width. In the comments it was argued that column width largely depends on the scenario, and some users always make the columns wider. An alternative width of 2cm was suggested often (see comment 21 for this). Resolving therefore as WF. [1] https://fosstodon.org/@libodesign/110275158368343954
(In reply to Heiko Tietze from comment #29) > Asked of Mastodon [1] and 63% out of 408 people voted to keep the current > width... Thank you for the effort of considering this change =)