Bug 1014571
Summary: | [UX] user can barely select time range on metric graph image | ||||||
---|---|---|---|---|---|---|---|
Product: | [JBoss] JBoss Operations Network | Reporter: | Libor Zoubek <lzoubek> | ||||
Component: | UI, Usability | Assignee: | Mike Thompson <mithomps> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | JON 3.2 | CC: | asantos, crobson, jkremser, loleary, mithomps, myarboro, theute | ||||
Target Milestone: | DR01 | Keywords: | Triaged, UserExperience | ||||
Target Release: | JON 3.2.1 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-05-08 17:43:40 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Libor Zoubek
2013-10-02 11:05:04 UTC
I discussed this in some of our morning meetings. There is a conflict between hovers and zooming; they both compete for the same events on the same real estate (svg boxes). The issue behind this are that js events need objects to bind with via mouseover/mouseout. There are two objects here: 1) the svg bar in the bar chart and 2) the background svg box that covers the whole chart. Currently, the the background box has zoom events attached to it and the foreground bars have the hover events attached to them. The effect is when you hover between the bars the cursor changes because we are on the background. The issue is the hovers and zoom areas compete for binding on the same objects. If we didn't have hovers this would not be an issue. I have spent much time on this before but can revisit it again with fresh eyes if need be. One solution would be to increase the distance between the bars that would give more area to select the zoom. The bars would get a little narrower with this approach. (In reply to Mike Thompson from comment #1) If the two are incompatible then I'd suggest removing the gray bars and indicating that the resource was unavailable in some other manner. A user can probably make the correlation -or easily be led to understand - by contrasting the graph data with the availability data above. Another option may be to highlight the time axis differently if the resource was unavailable at that time in question. Mike - As discussed, we have two options to consider for making this easier for users to work with: Option 1 (preferred solution if feasible): - Use an on-click event on the bar to act as a zoom/time selection action. Even though users won't have the crosshair on the bar, they can click anywhere (on or off the bar) and start dragging the mouse across the chart to select a timeframe. Option 2: - This mostly becomes an issue for users to work with in charts where the bars are taking up most of the vertical height and there is no white space to work with for clicking and dragging. Therefore, we will add the ability to click and drag to select a timeframe to the x axis of the chart. The following changes to the selection interaction and visuals will help provide affordances to users that they can use the x axis for selection: > The blue selection area background will extend down to the bottom of the x axis label area. > The mouse will change to crosshairs on the x axis label area Option 1 is not feasible as the d3 library does the binding of events and lifecycle and provides the API to the developer: .on("brushstart", brushstart) .on("brush", brushmove) .on("brushend", brushend) So, given this moving to option #2. This is completed with option #2 above. I have added drag selection to the x-axis so when you drag over the time scale for selection instead of on the chart where selections became tricky. I will let this sit for a couple days before committing to release branch. Mike - is there a test system where we can see this and try it in action? Created attachment 859274 [details]
X-Axis Drag Selection Movie
@crobson I have attached the video of the new x-axis drag selection addition. Committed to master: commit c118c27222ab96a7f7d5f639843de7ad01011c72 Author: Mike Thompson <mithomps> Date: Tue Feb 4 15:28:37 2014 -0800 Thanks for the video. My only suggestion for improvement is that if possible, the highlight should show both above the x axis and below the x axis, regardless of where you clicked to select (above or below the axis). This might help users 'see' that both are possible, a bit of an affordance so they know the x axis is draggable if they missed it initially. Otherwise I think this looks great and will help in those cases where the graph is full and users have a hard time clicking to select above the x axis! So I extended the selection from the x-axis to go up through the bars on the top like you mentioned however, that consumes the hover events so hovers go away. So it looks like we are stuck with the solution on the video. reviewed and cherry-picked over to the release branch branch: release/jon3.2.x link: http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=433d661bf time: 2014-02-10 17:58:40 +0100 commit: 433d661bfc40bd85c47d7fff2f36bf367f544a3d author: Mike Thompson - mithomps message: [BZ 1014571] UX on selecting graph subselection via dragging. Add the drag selection to the x-axis. Moving to ON_QA as available for testing in the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=336752 Note: the installed version is still JON 3.2.0.GA by design and this represents part of the payload for JON 3.2.1 also known as cumulative patch 1 for 3.2.0.GA. How this will be delivered to customers is still being discussed. verified jon 3.2.1 DR1 JON 3.2.1 released week of 5/5/2014 |