[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [birt-charting-dev] Chart functionalspecifications update-MeterCharts
|
That is a good idea to provide the option
to superimpose the dials. Yes the mockup I created doesn't show the
scales for the other dials. If they were shown the tick marks would
be along the edge of the dials. The dials don't share scales.
Your changes to the APIs looks fine.
Thanks,
Sheldon
______________________________________
Sheldon Lee-Loy
Problem Deterministic Group, IBM Toronto Lab
email: sleeloy@xxxxxxxxxx
phone: 905.413.2610
"David Michonneau"
<dmichonneau@xxxxxxxxxxx>
Sent by: birt-charting-dev-bounces@xxxxxxxxxxx
08/12/2005 12:49 PM
Please respond to
For developers on the BIRT Charting project |
|
To
| "For developers on the
BIRT Charting project" <birt-charting-dev@xxxxxxxxxxx>
|
cc
| Christine Knight/Toronto/IBM@IBMCA,
Monika Mikolajczyk/Toronto/IBM@IBMCA
|
Subject
| RE: [birt-charting-dev] Chart
functionalspecifications
update-MeterCharts |
|
Sheldon,
Thank you for the clarification.
So if my understanding is correct a dial is the axis representation, and
the needle would represent a serie. Your design assumes that one dial can
only have one needle, which is perfectly fine as a dial with multiple needles
(one axis with multiple series) doesn’t seem very useful. I think however
a nice addition would be to allow the user to choose if the dials are superimposed
like in your mockup or drawn next to each other.
Regarding the mockup, I was
first confused by the scale, I believe only one is shown in the mockup.
How would the ones of the other dials appear? Or does that mean that they
all share the same dial scale when superimposed?
So here is an updated proposal
in conclusion of this:
Let’s subclass ChartWithoutAxes
and add a DialSeries interface :
interface DialChart extends
ChartWithoutAxes
{
void setDialsSuperImposition(boolean areSuperImposed)
boolean getDialsSuperimposition();
}
interface DialSerie extend
Series
{
Dial getDial();
void setDial(Dial dial);
Needle getNeedle();
void setNeedle(Needle needle);
}
Other interfaces Dial, Needle
and DialRegion will be as defined by the schema in the spec. Just some
small amendments: FormatSpecifier and Label are not needed in Dial as they
are already defined in SeriesDefinition and Series. FormatSpecifier in
DialRegion is not needed either.
How does that sound?
Thanks,
David
From: birt-charting-dev-bounces@xxxxxxxxxxx
[mailto:birt-charting-dev-bounces@xxxxxxxxxxx] On Behalf Of Sheldon
Lee-Loy
Sent: Friday, August 12, 2005 4:34 PM
To: For developers on the BIRT Charting project
Cc: Christine Knight; Monika Mikolajczyk
Subject: RE: [birt-charting-dev] Chart functionalspecifications update-MeterCharts
Lets first break down the use cases for meter charts.
Meter chart with one dial with one series
-----------------------------------------------------------
For a simple meter chart I would have one dial that will contain a list
of dial regions, a scale and a needle. One series will also be associated
with the dial. This series will only contain one value that determines
the position of the needle. The value of the needle can only
span over the scale defined for this dial.
Meter chart with multiple dials and multiple series
------------------------------------------------------------------------
In this case we can logically treat each dial as a separate meter chart.
For example, lets say I have three series. One series represents
the value of Wind Speed, the second series represents a value of Temperature
and the third series represents the value of Precipitation. Lets
now treat these series individually. I would define a dial for each
of these series. Therefore, I would have a dial that has a scale,
a needle and a list of regions that is associated with Wind Speed. I
would have two other dials that are associated withTemperator and Precipitation.
Visually I could represent these three series in three distinct meter
charts. However, from the mockups I provided it is possible to merge
these three dials into one meter chart. It is basically trying to
visually represent three meter charts into one.
You can think of a dial as a seperate chart. The proposal I presented
is trying to visually represent several dials in one plot area.
Thanks,
Sheldon
______________________________________
Sheldon Lee-Loy
Problem Deterministic Group, IBM Toronto Lab
email: sleeloy@xxxxxxxxxx
phone: 905.413.2610
"David Michonneau"
<dmichonneau@xxxxxxxxxxx>
Sent by: birt-charting-dev-bounces@xxxxxxxxxxx
08/12/2005 09:47 AM
Please respond to
For developers on the BIRT Charting project |
|
To
| "For developers
on the BIRT Charting project" <birt-charting-dev@xxxxxxxxxxx>
|
cc
| Christine Knight/Toronto/IBM@IBMCA,
Monika Mikolajczyk/Toronto/IBM@IBMCA
|
Subject
| RE: [birt-charting-dev] Chart
functional specifications update-MeterCharts |
|
Hi Sheldon,
Regarding the single/multiple dial charts, let me try to clarify things.
Charts with Axes in general, can possibly have multiple axes (an axis hold
a scale and marker line/ranges) and multiple series (dials), each being
associated with an axis. If we apply this to Dials, I would say a given
axis with several series results in a superimposition of the dials like
shown in your mockup. However several axes will result in several charts
being drawn (sharing the legend), one chart for each axis. Furthermore,
each serie(Dial) can define several DialRegions (also called DialRange?)
to allow a given needle to go through different colors. I am not sure if
that was what you had in mind, in your design I got the impression each
Dial is an axis and a serie at the same time. But how can you have several
scales within the same chart?
Another question is how many dials and/or axes do you want the builder
to support? So far the builder allows at most 2 axes and 2 series/axis
for existing types.
Let’s first agree on what we support here, before making a ChartWithoutAxes/ChartWithAxes
decision. In the meantime, I have merged the Dial spec with the latest
version of the type spec. There are some dial mockups for the two first
screens of the new chart builder, let us know your comments about them.
Besides that, it includes minor updates, not dial-related.
Thanks,
David
From: birt-charting-dev-bounces@xxxxxxxxxxx [mailto:birt-charting-dev-bounces@xxxxxxxxxxx]
On Behalf Of Milind Padhye
Sent: Wednesday, August 10, 2005 9:19 PM
To: For developers on the BIRT Charting project
Cc: Christine Knight; Monika Mikolajczyk
Subject: RE: [birt-charting-dev] Chart functional specifications update-MeterCharts
Sheldon, David,
I am a little concerned about
using a ChartWithAxis mechanism directly for a Dial / Meter chart type.
To be sure, this is something that the underlying framework supports. However,
as far as I can tell, the only thing you are looking for is to use the
Scale and MarkerRegion concept from the axis. I think creating a ChartWithAxis
has some implications as far as handling of axis rendering etc. is performed
in the library and needs to be investigated before going down that route.
E.g. do you want to see the Axis UI in the builder for a Dial/Meter chart?
I would think not. This will however happen if you use a Chart with Axis.
Further, by creating a ChartWithAxis
structure, you will need to use / set a bunch of properties and will need
to follow the structural restrictions it imposes while not necessary applying
to this chart type. E.g. The actual data carrying series in the chart with
axis will be residing under an axis which itself resides under a separate
axis. This looks like a very convoluted structure for a dial chart (from
an API standpoint).
I think this can be done by creating
a type that extends ChartWithoutAxis but has a collection of scales associated
with it. To make it possible to associate a MarkerRange, you could consider
specifying the color regions as statically defined for the ‘DialSeries’
at design time or alternatively the Scale structure can be modified to
support MarkerLines and MarkerRanges. This would allow for maximum re-use
of the existing structures without placing unnecessary structural restrictions
on the chart type.
Just my 2 cents.
Thanks,
Milind
From: birt-charting-dev-bounces@xxxxxxxxxxx [mailto:birt-charting-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sheldon Lee-Loy
Sent: Wednesday, August 10, 2005 10:43 AM
To: For developers on the BIRT Charting project
Cc: Christine Knight; Monika Mikolajczyk
Subject: RE: [birt-charting-dev] Chart functional specifications update
-MeterCharts
The current design doesn't prevent you from creating separate charts with
a single dial. I believe one of the driving requirements for specifying
several dials within a meter chart is to fit in as much information as
possible within limited space. Usesablity wise this may not be good
however in some cases working in limited space may be necessary.
I guess a dial can be modelled after an axis since a dial has a scale and
marker regions are associated with a dial. This seems to be the way
to go.
Thanks,
Sheldon
______________________________________
Sheldon Lee-Loy
Problem Deterministic Group, IBM Toronto Lab
email: sleeloy@xxxxxxxxxx
phone: 905.413.2610
"David Michonneau"
<dmichonneau@xxxxxxxxxxx>
Sent by: birt-charting-dev-bounces@xxxxxxxxxxx
08/10/2005 12:31 PM
Please respond to
For developers on the BIRT Charting project |
|
To
| "For developers
on the BIRT Charting project" <birt-charting-dev@xxxxxxxxxxx>
|
cc
| Christine Knight/Toronto/IBM@IBMCA,
Monika Mikolajczyk/Toronto/IBM@IBMCA
|
Subject
| RE: [birt-charting-dev] Chart
functional specifications update - MeterCharts |
|
Hi Sheldon,
Thank you for the specifications of this dial type. I have a few questions:
In case of multiple dials, did you consider as an alternative to show them
next to each other, like we do for pie charts? I think one of the advantages
of this approach is to allow multi-coloring of one given region, to act
as a dashboard indicator. For instance if the temperature is higher than
50, the region color could change to red, then if the needle goes in the
red, the user knows it requires specific attention. It also minimizes the
complexity of the chart graphics, as it’s easier to read three separate
dials than three superimposed dials (imagine if your car speedometer, engine
rotation counter, and gas tank indicator were all in one same dial with
three needles).
Regarding the model, I thought DialRegion would in fact be DialSeries in
the types.xsd. I also assume this new type falls in the ChartWithoutAxes
category. If we follow my suggestion above, it seems Dial and DialRegion
will fusion together. If we keep the current design, maybe Dial should
subclass ChartWithoutAxes instead of being a component, or maybe the other
way would be to make it a ChartWithAxes and subclass the Axis interface
with a DialAxis (Dial).
Thanks,
David
From: birt-charting-dev-bounces@xxxxxxxxxxx [mailto:birt-charting-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sheldon Lee-Loy
Sent: Tuesday, August 09, 2005 10:47 PM
To: For developers on the BIRT Charting project
Cc: Christine Knight; Monika Mikolajczyk
Subject: [birt-charting-dev] Chart functional specifications update
- MeterCharts
Hi All,
I updated the funtional specification document that covers the meter/dial
chart type. In this document I have included schema updates and mockups
of the chart builder. Let me know if you have any concerns and questions.
Thanks,
Sheldon
______________________________________
Sheldon Lee-Loy
Problem Deterministic Group, IBM Toronto Lab
email: sleeloy@xxxxxxxxxx
phone: 905.413.2610_______________________________________________
birt-charting-dev mailing list
birt-charting-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-charting-dev[attachment "BPS38
- Chart Types SPEC.pdf" deleted by Sheldon Lee-Loy/Toronto/IBM] _______________________________________________
birt-charting-dev mailing list
birt-charting-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-charting-dev_______________________________________________
birt-charting-dev mailing list
birt-charting-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-charting-dev