![](https://secure.gravatar.com/avatar/1280ab8004c08ad36f83942837b1423e.jpg?s=120&d=mm&r=g)
During observing a team using observium coming from one of the similar competing platforms; noticed a fair bit of confusion as to what updates and what not. Mostly during ‘dive ins’ when something post incident was ‘kept an eye on’ for the ensuing 3-6 hours; including across work-shift related handovers.
The issue is which pages auto-refresh - and which not. And I think the only place where it jars is at the date selection/update buttoned pages.
Specifically - when you look at the detailed graph; i.e. on:
http://10.11.0.132/graphs/to=1454928724/id=7287/type=sensor_graph/from=14548...
Having gotten there from an overview page such as:
http://10.11.0.132/device/device=722/tab=health/metric=temperature/id= 7287/
it shows right away as a most recent 24 hour ‘date preset’.
The user then sees this page nicely reload every N minutes (as confirmed in the top right of the page).
And an experienced ops-hand will track that from the corner of his/her eye - and ignore it the instant the graph stays ‘sane’.
BUT in reality the date preset does not track - it is just the 6/24/48h/week/month/year tiny graphs at the top that get updated.
And that is easy to miss.
So two small UX things suggestions:
1) Would it be possible if, left unattended after, to start rolling with the time; updating the date presets bar when it was never touched in the first place.
OR
once it was shown for 2-3 minutes - highlight something in the Date preset bar to signal the data is out of date — e.g. have the Update/reload button on the far right be highlighted; i.e. signal an update is possible/due/needed.
OR
perhaps in combination with a pause/play button very OBVIOUSLY set to ‘pause’ as a more generic idea.
2) Since the preset shown there is in effect the second preset from the 6, 24, 48, one week bare above it - may be nice to indicate this - i.e. that the preset has been filled out in this mode.
Dw.