ALL graphs that show numeric value on x-axis are useless and misleading

RESOLVED FIXED in Bugzilla 2.18

Status

()

defect
--
minor
RESOLVED FIXED
16 years ago
7 years ago

People

(Reporter: njaras, Assigned: gerv)

Tracking

unspecified
Bugzilla 2.18
Bug Flags:
approval +

Details

Attachments

(1 attachment, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624

ALL graphs that show numeric value on x-axis are useless and misleading, because
the x-axis is arranged in wrong order. 
Example: the graph showing anything against votes will show the x-axis as:
1,10,11,12,....19,2,21,22,23,...29,3,30,31,....

In other words, any graph with a numerical value in its x-axis is useless and
misleading!

http://bugzilla.mozilla.org/query.cgi?format=report-graph

Reproducible: Always

Steps to Reproduce:
1.Select any numerical value in x-axis for a chart
2.Plot the chart
3.

Actual Results:  
As explained above, the numerical values are shown in a totally wrong order. As
a result, all levels and trends shown in the chart are misleading.

Expected Results:  
Show the numerical values in ascending/descending order (should be user-selectable)

Alternatively, pad the values with leading zeros, which will sort them in
correct order.

I saw another bug related to this (Bug#142394; Bug count should be sortable),
which is left unattended for last 15 MONTHS. 

However, the originator of that bug does not explain that this results in
misleading, worthless charts.

The suggested work-around (export to CSV file and make a chart in Excel or
equivalent) *is* feasible, but leaves a major problem unresolbved: by that
logic, graphing module was not at all required--the users could have exported
data every time and constructed their own graphs!

Please do not mark this as a duplicate of bug#142394!
This is a valid bug; however, Votes is the only numerical option available for
the X axis, so the problem only occurs with Votes. That makes it fairly minor.

One solution would be to remove the "Votes" option from the X axis altogether. 

Gerv
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
That should be OK, as the export to CSV is already provided. Any interested
parties can always take the data and make their own graphs. 

Another *important* factor to be considered is that when Bugzilla is used in an
organization (as opposed to its use to manage bugs in a open-source freeware),
the "voting" factor is irrelevant, as bugs are prioritized based on
techno-commercial factors by designated persons, rather by majority vote.

Then again, Bugzilla's future version will have addition of user-definable
fields. In that case, some organization may want to add some numeric fields,
which would require plotting.

All said and done, better to add the sorting feature now and be ready for the
future.
Posted patch Patch v.1 (obsolete) — Splinter Review
Previously, all axes were sorted according to an alphabetic sort. This patch
changes the behaviour so that Bugzilla detects if a field is numeric, and uses
a numeric sort instead. This fixes the problem with the votes.

Gerv
Comment on attachment 130995 [details] [diff] [review]
Patch v.1

Jouni - are you still doing Bugzilla stuff, and could you review this? I seem
to remember you reviewing my graphing fixes before.

Gerv
Attachment #130995 - Flags: review?(jouni)
Comment on attachment 130995 [details] [diff] [review]
Patch v.1

>Jouni - are you still doing Bugzilla stuff, and could you review this? 

Yeah; I've just been so busy that I've barely been able to do anything. I try
to help when somebody asks though, especially with Win32 reviews and testing.

>+my $col_numeric = 1;
>+my $row_numeric = 1;
>+my $tbl_numeric = 1;

Nit: How about "xxx_isnumeric"? These are essentially booleans, but they could
look more like ones.

>+    $col_numeric = $col_numeric && ($col =~ /^\d+(\.\d+)?$/o);
>+    $row_numeric = $row_numeric && ($row =~ /^\d+(\.\d+)?$/o);
>+    $tbl_numeric = $tbl_numeric && ($tbl =~ /^\d+(\.\d+)?$/o);

Is there a reason for these not to accept negative numbers? For votes that's
irrelevant, but so is decimal support - let's go the generic way. I propose
adding a -? after the ^.

Nit: Make it "$col_numeric &&= ..." for more Perl guru points and extra brevity
:-)


With those, r=jouni.
Attachment #130995 - Flags: review?(jouni) → review+
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Posted patch Patch v.2Splinter Review
With review comments, and warnings eliminated.

Gerv
Attachment #130995 - Attachment is obsolete: true
Carried over jouni's review; requesting approval.

Gerv
Flags: approval+
Oops. That should be a ? for approval. :-)

Gerv
Flags: approval+ → approval?
Flags: approval? → approval+
Fixed.

Checking in report.cgi;
/cvsroot/mozilla/webtools/bugzilla/report.cgi,v  <--  report.cgi
new revision: 1.19; previous revision: 1.18
done

Gerv
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.