Created attachment 1002211 [details] screenshot1 Description of problem: It would be nice to have interface Rx/Tx counters displayed in more human readable fashion. It is a inconvenient to read for example 90TB displayed in bytes. It would be nice to have intelligent switching of units. For example when total traffic on interface reaches 1,000,000 bytes to switch unit to MB etc... Actual results: RX/TX counters displayed in Bytes Expected results: Intelligent switching of Rx/Tx units based on how big is the displayed number Additional info:
I contemplated this while implementing but wasn't sure this was the right thing to do. My main issue was as follows: one of the customer tickets on the original BZ needed a way to see if an interface is even wired properly, which could easily be seen by increasing total RX/TX statistics. If we display them "intelligently", however, small increments will no longer be visible. One thing I can think about that will allow for both is a button users could toggle and choose between "precise" or "human-readable" format. I don't know where this button should be located and how it should be designed. There might be other possible solutions, tagging with "UserExperience". Assuming we do find a plausible solution, I think this would be an easy win and something we'd want to implement with high priority.
How about "tooltip"? Display the units in human readable format and on mouse hover it would display the precise value in bytes?
With a tooltip there'd be the issue of discoverability - would users guess that they could see the exact value by hovering?
@Lior, I think your suggestion of a toggle is a great direction for this request. It's not overwhelming with respect to visual additions. How about the use of radio buttons to toggle between the views? I was also thinking a lot about terminology and something I've come up with that I wanted to get your thoughts on was "Rounded Units" vs. "Granular Units". Let me know what you think! Thanks, Liz
I would name the "Rounded Units" "Human-readable" instead - I think that's what people are used to from Linux utilities. "Granular" might be replaced by a simpler word - "Exact" maybe? I'm also not sure about where to place this radio button - top right corner of the subtab?
@Lior - If these terms are well known to users then I would say we should stick with them. Whatever would make it easier to understand! Your suggested placement makes sense. I think the toggle should remain close to the table rather than be associated with the page. Just mentioning this incase we add any fields on top of the table in the future. Thanks, Liz
this bug Wasn't picked up in the weekathon , moving to 4.0
The least-significant digits should not be hidden, as they are the only ones which change between screen refreshes. To improve readability I suggest to use thousand separator (in en_US it is the coma character, but IIRC in Czech it is the dot).
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
(In reply to Dan Kenigsberg from comment #9) > To improve readability I suggest to use thousand separator (in en_US it is > the coma character, but IIRC in Czech it is the dot). You probably want to use http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/NumberFormat.html#getDecimalFormat--
From my point of view, this is not a RFE, it is a bug fix. On older versions such as - 3.6/4.0/4.1 we always had the coma separator between thousands, this is not something new. The original request was to implement shorten numbers to MB/GB/TB and such. The coma separator between thousands was missing only when the new 4.2 UI was introduced and this bug fixing this glitch. Verified on - 4.2.1.6-0.1.el7
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.