Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
45343003:
UMA data collection for docked windows (Closed)
|
Created:
7 years, 1 month ago by varkha Modified:
7 years, 1 month ago CC:
chromium-reviews, sadrul, jar (doing other things), asvitkine+watch_chromium.org, kalyank, Ilya Sherman, ben+ash_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Visibility:
Public. |
DescriptionUMA data collection for docked windows
BUG=294461
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=233193
Patch Set 1 : UMA data collection for docked windows #
Total comments: 12
Patch Set 2 : UMA data collection for docked windows (comments) #
Total comments: 16
Patch Set 3 : UMA data collection for docked windows (comments) #
Total comments: 13
Patch Set 4 : UMA data collection for docked windows (comments) #
Messages
Total messages: 20 (0 generated)
Can you please take a look? Do you think additional metrics would be good?
I've provided some specific feedback in the files, but at a high level try to have a rough idea of what you might learn and how you would act on what you learned from each metric. For example, what might you want to know that would suggest that overlap should be allowed? (i.e. maybe the total number of items including those which have been minimized). https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_layout_manager.cc:472: UMA_HISTOGRAM_CUSTOM_COUNTS("Ash.Dock.Width", docked_width_, 0, 360, 72); Create a common method for updating and/or tracking new docked width. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_layout_manager.cc:678: UMA_HISTOGRAM_COUNTS_100("Ash.Dock.Items", docked_windows); MaybeMinimizeChildrenExcept is only called from RestoreDockedWindow, i.e. this seems like the only time you'll be logging the item count is when a docked window is restored, but not when they are docked / undocked / closed / etc. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_layout_manager.cc:881: UMA_HISTOGRAM_CUSTOM_COUNTS("Ash.Dock.Width", docked_width_, 0, 360, 72); It might be worth setting a higher max in case we decide to change the limit at some point. I would use something higher than you expect any screen resolution to be. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... File ash/wm/dock/docked_window_resizer.cc (right): https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_resizer.cc:300: action = DOCKED_ACTION_CANCEL; As with the time between use below, I don't think this "cancel" operation is a useful metric. It would be effectively the number of windows dragged but not docked, which is certainly going to outnumber any of the other values. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_resizer.cc:305: time_now - last_docked_action_); Doesn't DockedWindowResizer::FinishDragging get called for the for every window drag whether it was docked or not? This would make the time between use actually the time between window drags. I'm not sure we could really learn much from the time between docked window drag operations anyways. https://codereview.chromium.org/45343003/diff/30001/tools/metrics/histograms/... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/45343003/diff/30001/tools/metrics/histograms/... tools/metrics/histograms/histograms.xml:205: +<histogram name="Ash.Dock.Actions"> enum="..." with descriptions for each enum value? See https://code.google.com/p/chromium/codesearch#chromium/src/tools/metrics/hist...
Thanks, that was very useful. I have added a few counts that should suggest which windows categories get docked. I am recording most stats on every action (other than "NONE") to get some idea about what state the dock is in after a user-initiated operation. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_layout_manager.cc:472: UMA_HISTOGRAM_CUSTOM_COUNTS("Ash.Dock.Width", docked_width_, 0, 360, 72); On 2013/10/29 21:33:49, flackr wrote: > Create a common method for updating and/or tracking new docked width. Done. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_layout_manager.cc:678: UMA_HISTOGRAM_COUNTS_100("Ash.Dock.Items", docked_windows); On 2013/10/29 21:33:49, flackr wrote: > MaybeMinimizeChildrenExcept is only called from RestoreDockedWindow, i.e. this > seems like the only time you'll be logging the item count is when a docked > window is restored, but not when they are docked / undocked / closed / etc. MaybeMinimizeChildrenExcept is called from FinishDragging so that should get called in all those cases other than closing a window. And of course if it is not called from any interaction that could increase the count then it would be a bug. I reworked it a bit, please see. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_layout_manager.cc:881: UMA_HISTOGRAM_CUSTOM_COUNTS("Ash.Dock.Width", docked_width_, 0, 360, 72); On 2013/10/29 21:33:49, flackr wrote: > It might be worth setting a higher max in case we decide to change the limit at > some point. I would use something higher than you expect any screen resolution > to be. Done. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... File ash/wm/dock/docked_window_resizer.cc (right): https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_resizer.cc:300: action = DOCKED_ACTION_CANCEL; On 2013/10/29 21:33:49, flackr wrote: > As with the time between use below, I don't think this "cancel" operation is a > useful metric. It would be effectively the number of windows dragged but not > docked, which is certainly going to outnumber any of the other values. Done. https://codereview.chromium.org/45343003/diff/30001/ash/wm/dock/docked_window... ash/wm/dock/docked_window_resizer.cc:305: time_now - last_docked_action_); On 2013/10/29 21:33:49, flackr wrote: > Doesn't DockedWindowResizer::FinishDragging get called for the for every window > drag whether it was docked or not? This would make the time between use actually > the time between window drags. I'm not sure we could really learn much from the > time between docked window drag operations anyways. Done. https://codereview.chromium.org/45343003/diff/30001/tools/metrics/histograms/... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/45343003/diff/30001/tools/metrics/histograms/... tools/metrics/histograms/histograms.xml:205: +<histogram name="Ash.Dock.Actions"> On 2013/10/29 21:33:49, flackr wrote: > enum="..." with descriptions for each enum value? > See > https://code.google.com/p/chromium/codesearch#chromium/src/tools/metrics/hist... Done.
https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:718: base::TimeDelta::FromHours(10), 100); Just a cautionary question, are there any instances where RecordUmaAction will be called more than once which will result in artificial 0 time deltas? https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.h (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.h:51: DOCKED_ACTION_NONE, // Dragged but not changing the docked state. Seems to me that this is a regular drag outside of the dock (i.e. dragged within the dock which also doesn't change the dock state is considered DOCKED_ACTION_REORDER) https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_resizer.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:304: action, So this will still be called with every window drag right? Is DOCKED_ACTION_NONE going to be a baseline measurement? https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:313: action, This would double count the action, perhaps there should be a special action for this case?
Just thoughts and questions, need to work some more on this. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:718: base::TimeDelta::FromHours(10), 100); On 2013/10/31 03:01:51, flackr wrote: > Just a cautionary question, are there any instances where RecordUmaAction will > be called more than once which will result in artificial 0 time deltas? There shouldn't be on a single screen configuration. With 2 screens I think I will need to implement a separate set of metrics. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.h (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.h:51: DOCKED_ACTION_NONE, // Dragged but not changing the docked state. On 2013/10/31 03:01:51, flackr wrote: > Seems to me that this is a regular drag outside of the dock (i.e. dragged within > the dock which also doesn't change the dock state is considered > DOCKED_ACTION_REORDER) I meant "not moving or changing state of docked windows and not docking any new windows". REORDER is logged for the drags within the dock but I don't expect those false positives to be statistically significant. It would be trivial to cancel them out by comparing bounds of the |dragged_window_| at the beginning of the drag with bounds at the end. Do you think it is worth the added state? I could also detect that in the resizer, this is probably better because it avoids issues with multiple concurrently dragged windows and I still have to add support for that (vector of dragged_windows instead of one per layout manager). https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_resizer.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:272: if ((is_resized || !attached_panel) && I am still thinking of a possibility for user confusion when a panel gets undocked by sliding it down to touch the shelf while in the dock. With windows being resized to their restore bounds during the drag it is almost guaranteed to create some confusion - even when I remove the guide box drawing in this case. It is especially confusing when the dock is on the left and panels status area on the right side. I am thinking of adding a metric for this, maybe measuring how often a window is redocked soon after it gets undocked, do you think it would be useful? I am afraid such metric will not be statistically significant. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:304: action, On 2013/10/31 03:01:51, flackr wrote: > So this will still be called with every window drag right? Is DOCKED_ACTION_NONE > going to be a baseline measurement? FinishDragging is called on every drag, however DOCKED_ACTION_NONE events are no longer counted or recorded. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:313: action, On 2013/10/31 03:01:51, flackr wrote: > This would double count the action, perhaps there should be a special action for > this case? Perhaps I need a separate set of metrics or some way to identify the instance of the dock (currently one per screen). I think this will address the issue.
https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:718: base::TimeDelta::FromHours(10), 100); On 2013/10/31 13:33:03, varkha wrote: > On 2013/10/31 03:01:51, flackr wrote: > > Just a cautionary question, are there any instances where RecordUmaAction will > > be called more than once which will result in artificial 0 time deltas? > > There shouldn't be on a single screen configuration. With 2 screens I think I > will need to implement a separate set of metrics. The timer per dock will be separate though so there shouldn't be inadvertent 0 times. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.h (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.h:51: DOCKED_ACTION_NONE, // Dragged but not changing the docked state. On 2013/10/31 13:33:03, varkha wrote: > On 2013/10/31 03:01:51, flackr wrote: > > Seems to me that this is a regular drag outside of the dock (i.e. dragged > within > > the dock which also doesn't change the dock state is considered > > DOCKED_ACTION_REORDER) > > I meant "not moving or changing state of docked windows and not docking any new > windows". REORDER is logged for the drags within the dock but I don't expect > those false positives to be statistically significant. It would be trivial to > cancel them out by comparing bounds of the |dragged_window_| at the beginning of > the drag with bounds at the end. Do you think it is worth the added state? I > could also detect that in the resizer, this is probably better because it avoids > issues with multiple concurrently dragged windows and I still have to add > support for that (vector of dragged_windows instead of one per layout manager). The collection is fine as is assuming that a drag within the dock is a reorder. I was just suggesting that perhaps the comment for DOCKED_ACTION_NONE should be that it was a regular dragged window. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_resizer.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:304: action, On 2013/10/31 13:33:03, varkha wrote: > On 2013/10/31 03:01:51, flackr wrote: > > So this will still be called with every window drag right? Is > DOCKED_ACTION_NONE > > going to be a baseline measurement? > > FinishDragging is called on every drag, however DOCKED_ACTION_NONE events are no > longer counted or recorded. Ah okay, I missed that. Sounds good. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:313: action, On 2013/10/31 13:33:03, varkha wrote: > On 2013/10/31 03:01:51, flackr wrote: > > This would double count the action, perhaps there should be a special action > for > > this case? > > Perhaps I need a separate set of metrics or some way to identify the instance of > the dock (currently one per screen). I think this will address the issue. Or just pass DOCKED_ACTION_NONE since this isn't counted.
Please take another look. I think multiple screen configuration can be addressed in a later CL. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:718: base::TimeDelta::FromHours(10), 100); > The timer per dock will be separate though so there shouldn't be inadvertent 0 > times. I understand. There should not be 0 times after using NONE in the second call to FinishDragging in resizer. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.h (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.h:51: DOCKED_ACTION_NONE, // Dragged but not changing the docked state. On 2013/10/31 22:17:58, flackr wrote: > On 2013/10/31 13:33:03, varkha wrote: > > On 2013/10/31 03:01:51, flackr wrote: > > > Seems to me that this is a regular drag outside of the dock (i.e. dragged > > within > > > the dock which also doesn't change the dock state is considered > > > DOCKED_ACTION_REORDER) > > > > I meant "not moving or changing state of docked windows and not docking any > new > > windows". REORDER is logged for the drags within the dock but I don't expect > > those false positives to be statistically significant. It would be trivial to > > cancel them out by comparing bounds of the |dragged_window_| at the beginning > of > > the drag with bounds at the end. Do you think it is worth the added state? I > > could also detect that in the resizer, this is probably better because it > avoids > > issues with multiple concurrently dragged windows and I still have to add > > support for that (vector of dragged_windows instead of one per layout > manager). > > The collection is fine as is assuming that a drag within the dock is a reorder. > I was just suggesting that perhaps the comment for DOCKED_ACTION_NONE should be > that it was a regular dragged window. Done. https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_resizer.cc (right): https://codereview.chromium.org/45343003/diff/260001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_resizer.cc:313: action, On 2013/10/31 22:17:58, flackr wrote: > On 2013/10/31 13:33:03, varkha wrote: > > On 2013/10/31 03:01:51, flackr wrote: > > > This would double count the action, perhaps there should be a special action > > for > > > this case? > > > > Perhaps I need a separate set of metrics or some way to identify the instance > of > > the dock (currently one per screen). I think this will address the issue. > > Or just pass DOCKED_ACTION_NONE since this isn't counted. Done.
Ping, not sure if you are still looking at this.
lgtm
+jamescook@chromium.org for OWNERS review (ash/wm/). +isherman@chromium.org for OWNERS review (tools/metrics/histograms/).
https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:744: UMA_HISTOGRAM_COUNTS_100("Ash.Dock.ItemsVisible", docked_visible_count); I suspect that you'll see a lot of uploads in the overflow bucket. I'd expect UMA_HISTOGRAM_COUNTS_10000 to still give you good resolution at the lower end, while also giving you a better view of the long tail. https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:751: UMA_HISTOGRAM_CUSTOM_COUNTS("Ash.Dock.Width", docked_width_, 0, 3600, 72); The parameters 0, 3600, and 72 are rather strange. Could you explain why 72 exponentially sized buckets ranging between 0 and 3600 are what you want? If you're really keen on using CUSTOM_COUNTS for this histogram, it's worth adding a comment documenting this decision. https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:236: + Recorded on every user action. On every user action that interacts with docked windows? Or just on every user action ever? (Please document in the histogram <summary>, not on the codereview site.) https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:260: +<histogram name="Ash.Dock.TimeBetweenUse" units="seconds"> If you use UMA_HISTOGRAM_CUSTOM_TIMES, I'm pretty sure the values will be emitted as milliseconds. If you want to emit seconds, then you'll need to use UMA_HISTOGRAM_CUSTOM_COUNTS instead, and call TimeDelta::ToSeconds() yourself. https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:269: + Width of the docked area in pixels. Recorded every time it changes. Just to sanity check: If I drag-resize the area, how many times will the size be emitted to this histogram as a result of that drag? Hopefully just once? https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:20734: + <int value="9" label="CLOSE"/> nit: These are human-visible strings on the dashboard, so "Close" is probably better than "CLOSE".
I have updated with the changes (and one clarification - just to be sure - in case when 100 windows is considered a high bound of reasonable values). PTAL. https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:744: UMA_HISTOGRAM_COUNTS_100("Ash.Dock.ItemsVisible", docked_visible_count); On 2013/11/04 23:31:50, Ilya Sherman wrote: > I suspect that you'll see a lot of uploads in the overflow bucket. I'd expect > UMA_HISTOGRAM_COUNTS_10000 to still give you good resolution at the lower end, > while also giving you a better view of the long tail. I think in this case I am much more interested in single digit numbers than in anything above 10. Even 100 docked windows is a very big stretch. So in this case long tail starts at 10 and I will be fine with anything above 100 recorded as 100 or not recorded at all. But I'd like to preserve single digit numbers as they are. Am I missing something here? https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:751: UMA_HISTOGRAM_CUSTOM_COUNTS("Ash.Dock.Width", docked_width_, 0, 3600, 72); On 2013/11/04 23:31:50, Ilya Sherman wrote: > The parameters 0, 3600, and 72 are rather strange. Could you explain why 72 > exponentially sized buckets ranging between 0 and 3600 are what you want? If > you're really keen on using CUSTOM_COUNTS for this histogram, it's worth adding > a comment documenting this decision. I have changed that to have 100 buckets up to 10 hours (in seconds). https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:236: + Recorded on every user action. On 2013/11/04 23:31:50, Ilya Sherman wrote: > On every user action that interacts with docked windows? Or just on every user > action ever? (Please document in the histogram <summary>, not on the codereview > site.) Done. https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:260: +<histogram name="Ash.Dock.TimeBetweenUse" units="seconds"> On 2013/11/04 23:31:50, Ilya Sherman wrote: > If you use UMA_HISTOGRAM_CUSTOM_TIMES, I'm pretty sure the values will be > emitted as milliseconds. If you want to emit seconds, then you'll need to use > UMA_HISTOGRAM_CUSTOM_COUNTS instead, and call TimeDelta::ToSeconds() yourself. Done. https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:269: + Width of the docked area in pixels. Recorded every time it changes. On 2013/11/04 23:31:50, Ilya Sherman wrote: > Just to sanity check: If I drag-resize the area, how many times will the size be > emitted to this histogram as a result of that drag? Hopefully just once? Just once when a docked window resize is complete (on mouse release) and only if the width actually changes. I've tried to clarify that in summary. https://codereview.chromium.org/45343003/diff/370001/tools/metrics/histograms... tools/metrics/histograms/histograms.xml:20734: + <int value="9" label="CLOSE"/> On 2013/11/04 23:31:50, Ilya Sherman wrote: > nit: These are human-visible strings on the dashboard, so "Close" is probably > better than "CLOSE". Done.
+jamescook@chromium.org for OWNERS review (ash/wm/).
ash/wm lgtm but... If you want to collect the number of windows at regular time intervals (rather than per-interaction) harrym has a patch in progress that adds a periodic metrics collection to Ash: https://codereview.chromium.org/26373009/ Doing it periodically would give you an idea about how frequently your feature is used -- in particular, the amount of time spent by people not using the feature.
On 2013/11/05 17:55:02, James Cook wrote: > ash/wm lgtm but... > > If you want to collect the number of windows at regular time intervals (rather > than per-interaction) harrym has a patch in progress that adds a periodic > metrics collection to Ash: https://codereview.chromium.org/26373009/ > > Doing it periodically would give you an idea about how frequently your feature > is used -- in particular, the amount of time spent by people not using the > feature. Thanks! That's good to know. I'll consider using that and will watch the patch.
histograms LGTM https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... File ash/wm/dock/docked_window_layout_manager.cc (right): https://codereview.chromium.org/45343003/diff/370001/ash/wm/dock/docked_windo... ash/wm/dock/docked_window_layout_manager.cc:744: UMA_HISTOGRAM_COUNTS_100("Ash.Dock.ItemsVisible", docked_visible_count); On 2013/11/05 17:41:15, varkha wrote: > On 2013/11/04 23:31:50, Ilya Sherman wrote: > > I suspect that you'll see a lot of uploads in the overflow bucket. I'd expect > > UMA_HISTOGRAM_COUNTS_10000 to still give you good resolution at the lower end, > > while also giving you a better view of the long tail. > > I think in this case I am much more interested in single digit numbers than in > anything above 10. Even 100 docked windows is a very big stretch. So in this > case long tail starts at 10 and I will be fine with anything above 100 recorded > as 100 or not recorded at all. But I'd like to preserve single digit numbers as > they are. Am I missing something here? Fair enough -- I misunderstood what sorts of items could appear in this "Dock". COUNTS_100 seems reasonable now that I understand that more clearly. Thanks.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/varkha@chromium.org/45343003/510001
Retried try job too often on linux_rel for step(s) interactive_ui_tests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/varkha@chromium.org/45343003/510001
Message was sent while issue was closed.
Change committed as 233193 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
