[Libreoffice-ux-advise] [Bug 88367] STATUSBAR: Removal of insert mode status

https://bugs.freedesktop.org/show_bug.cgi?id=88367

--- Comment #9 from Jay Philips <philipz85@hotmail.com> ---
(In reply to Cor Nouws from comment #7)
> I think the status bar is designed to show clutter ;)

We seem to be continuously adding clutter to it. :D

> We cannot always serve small displays. I think.

Working on smaller screen was an added advantage, but not primary one.

(In reply to V Stuart Foote from comment #8)
> Yes adding a Numlock, Caps Lock indicator are both useful statusbar
> additions. As is retaining the Insert/Overwrite mode indicator.

I guess we will have to agree to disagree on this one. ;D

> Samuel's patches allowing deeper shrinkage of the status bar element labels
> resolved issues of bug 86018. Frankly concern about "clutter" on the
> statusbar is trivial. In fact, there are very few users attempting to do
> anything with LO on monitors less than 1024x768, and I can't remember the
> last time I came across an 800x600 resolution laptop or desktop display. The
> minimum now is probably around 1366x768 found on older laptops with outdated
> screens. We aren't dealing with Android/iOS based devices--running LO in a
> minimum screen width should not be a primary design consideration going
> forward to 4.5.0

I am aware of the various screen resolutions used by users, as i had to take
those into consideration when i redid the toolbars and tried my best to keep it
under 1024px width, though it has slipped over in calc and impress.

> Full HD resolution 1920x1080 (16:9) or 1920:1200 (16:10) monitors are the
> norm, with 4K and Retina HiDPI displays becoming more common, so the
> "clutter" you suggest of the status bar is simply not an issue for majority
> of users.  Yet removing functions that reside appropriately on the statusbar
> would be.

Users with large screen like to compare documents side by side, which results
in each window being 960 pixels in width on a 1920x1080 display and the reason
i noticed and filed bug 86018 (though this problem still effects other modules
- bug 86612). "Clutter" is clutter at whatever resolution a user is at when
they have things in the statusbar that has no benefit to them.

> Our biggest problem with the Statusbar is that we have translatable fielded
> names rather than functional icons.  The by language the named fields expand
> or shirnk to fill the statusbar.  Are some less useful than others? Sure.
> But the space is there, and we are not considering removal or default
> suppression of the statusbar. The statusbar takes up screen space, so it
> should be populated with functional elements.

I would say the biggest problem with the statusbar is that it is not
configurable, so we can have a simple default statusbar to fit most users needs
and users who want more fields in it can enable them.

We have an icon in the statusbar to identify whether the document was modified
since the last save. For what reason is this useful when the save button in the
toolbar tells us the exact same thing.

> That said, there are two GUI issue here: one is the resizable labeling (and
> requisite translation). Some additional icons with consistent placement and
> behavior solves most of that.  Might not be able to do it for all, but
> certainly--Page, words, characters.

I think text is preferable over icons, as the icons would be small users would
have to rely on tooltips to understand it. (may not have understood what you
meant here :D)

> The other "clutter" as you put it, comes from lack of customization of the
> status bar. For users working in reduced size VM, or with multiple instances
> of LO open, the Status bar could be made configurable allowing selection of
> the status indicator widgets that are rendered active.

I'd assume most of the statusbar would need to be customizable.

> Do that as opposed to ripping them out of the statusbar.  Leave the
> Insert/Overwrite indicator alone, it has a function--fix the GUI.

With the statusbar customizable, the Insert/Overwrite indicator maybe useful to
some people, so in that scenario there wouldnt be a need to rip out the code
that makes it function, as it would be hide-able.

-- 
You are receiving this mail because:
You are on the CC list for the bug.