Created attachment 110325 [details] Screenshot of problem Using the default settings on latest git, I noticed the following strange behavior: * The Cartesian Plot skips number 3 on X axis and 4 on the Y axis * The graph makes the Y axis start at 1 instead of zero. * The plotted points don't line up with the numbers on the axes on either axis.
Created attachment 110326 [details] Project file exhibiting the problem
Git commit 624658f46d443e979b15ae139068cbf5b8ba9026 by Alexander Semke. Committed on 04/02/2018 at 18:11. Pushed by asemke into branch 'master'. Set the auto scale offset for plot ranges to 0 since it can lead to confusing results. We'll re-enable this offset once we have an option for this in the UI. FIXED-IN: 2.5 M +2 -3 src/backend/worksheet/plots/cartesian/CartesianPlot.cpp https://commits.kde.org/labplot/624658f46d443e979b15ae139068cbf5b8ba9026
(In reply to Matthew Trescott from comment #0) > * The Cartesian Plot skips number 3 on X axis and 4 on the Y axis > * The graph makes the Y axis start at 1 instead of zero. > * The plotted points don't line up with the numbers on the axes on either > axis. The problem here is because of the offset we add for the plot ranges. When plotting bigger data sets it is sometimes useful if you don't plot the data set exactly up to the plot boundaries but leave some space in between. In your example the plot range for x was not from 0 to 6 but from -0.3 to 6.3. I removed this offset now since it can lead to confusing results as you demonstrated with this example. The second problem here is that we show 6 axis ticks on default and set the precision to 0. So, we don't show in this case any decimals - again, this logic is useful when plotting bigger data sets with big ranges. We need to come up here with a better logic so the initial plot is already quite good. To fix your plot in the attached project, compile the current code, open the project and click on the auto scale button in the toolbar - the ranges will be set to 0-6 for x and to 1-7 for y. Change the number of ticks for the x-axis to 7 to obtain the desired result. In addition you can also change the precision of the tick labels to 1 if it's required.
I started over with a fresh project file after a git pull and ./compile and this is still not fixed, but I'm not sure I feel like continuing with this bug because it seems that quick-and-easy is not the target use-case. If it's any help, I'm comparing LabPlot to Vernier LoggerPro, and LoggerPro (which is a commercial product and not even open-source) is currently doing a much better job of following the KDE mantra of "simple by default, powerful when needed" than LabPlot. Maybe for inspiration you'd like to spin up an Ubuntu 14.04 VM and try out Vernier's discontinued Linux version: https://www.vernier.com/downloads/logger-pro-linux/ I wish you the best of luck because I'd really like to see LabPlot be successful, but right now I don't see it going in that direction.
(In reply to Matthew Trescott from comment #4) > I started over with a fresh project file after a git pull and ./compile and > this is still not fixed, With the new code, if you create a spreadsheet and add some data like 1 1 2 2 and create a plot (context menu in spreadsheet -> plot data -> new plot in a new worksheet) you should get a plot with ranges x=[1,2] and y=[1,2]. Is this the case for you? >but I'm not sure I feel like continuing with this > bug because it seems that quick-and-easy is not the target use-case. Quick-and-easy but still powerful is definitely our goal. We're open for any suggestions. > If it's > any help, I'm comparing LabPlot to Vernier LoggerPro, and LoggerPro (which > is a commercial product and not even open-source) is currently doing a much > better job of following the KDE mantra of "simple by default, powerful when > needed" than LabPlot. Maybe for inspiration you'd like to spin up an Ubuntu > 14.04 VM and try out Vernier's discontinued Linux version: > https://www.vernier.com/downloads/logger-pro-linux/ > I wish you the best of luck because I'd really like to see LabPlot be > successful, but right now I don't see it going in that direction. There are many different use-cases that need to be covered and it is not always easy to find an interface fulfilling the different wishes. We consider _all_ user reports (bugs and feature requests). Anything that would help to bring LabPlot into the right direction, here right meaning suitable for different scenarios, is welcome.
(In reply to Alexander Semke from comment #5) > With the new code, if you create a spreadsheet and add some data like > 1 1 > 2 2 > and create a plot (context menu in spreadsheet -> plot data -> new plot in a > new worksheet) you should get a plot with ranges x=[1,2] and y=[1,2]. Is > this the case for you? Yes. The problems start when I try to make a plot with ranges x=[0,2] and y=[0,2]. At first, the lowest tick is 1.2 on both axes. When hovering over the axes and using the mouse wheel, I can scale down the axes so that I can see all the ticks from 0 to 2, but then the axes become disconnected. I'll attach a video that I think explains this better. > Quick-and-easy but still powerful is definitely our goal. We're open for any > suggestions. In that case, my suggestion is that the plot be an infinite plane that can be panned by (for example) holding down the Ctrl key and clicking-and-dragging with the middle mouse button. My impression is that the current design is meant to be used for developing printed reports, so in order to maintain that functionality I suggest relegating it to some sort of "export to print" wizard or something.
Created attachment 110362 [details] Video of problem
(In reply to Matthew Trescott from comment #6) > Yes. The problems start when I try to make a plot with ranges x=[0,2] and > y=[0,2]. At first, the lowest tick is 1.2 on both axes. When hovering over > the axes and using the mouse wheel, I can scale down the axes so that I can > see all the ticks from 0 to 2, but then the axes become disconnected. I'll > attach a video that I think explains this better. Ok. I see the reason for the confusion. What you actually want to change are the ranges of the plot and not the start and the end values of the axes. For this, select the plot and modify the ranges. In LabPlot the user can define/have multiple axes. So, you first define the ranges of the data to be plotted (or keep it to "auto") and then start adding axes. On default, we create axes with "auto fit" which automatically adjust to the plot ranges. But the user can add in addition new axes which cover only a certain region with different formatting (labels, number of ticks, scaling, etc.). Though being very flexible, this concept is hard to grasp for people who have worked with applications only that do not support an arbitrary number of axes. So, simply change the plot ranges and you should get a behavior you're familiar with. > > Quick-and-easy but still powerful is definitely our goal. We're open for any > > suggestions. > > In that case, my suggestion is that the plot be an infinite plane that can > be panned by (for example) holding down the Ctrl key and > clicking-and-dragging with the middle mouse button. Panning is on the TODO-list already. We'll add this feature soon. At the moment we have the different buttons in the plot toolbar for the navigation in the data only. > My impression is that > the current design is meant to be used for developing printed reports, so in > order to maintain that functionality I suggest relegating it to some sort of > "export to print" wizard or something. Producing results that are ready to be exported and used in publications is one of the main emphasis of the application, yes. The export is done via the export dialog. But we also support other workflows like working with live data, analysis of imported data (ascii, binary, HDF5, netCDF, FITS), working with different computer algebra systems, etc. You can check the recent couple of blogs and the release announcements (2.1, 2.2, 2.3 and 2.4 releases) on our homepage to get some ideas about the feature set of the application - https://labplot.kde.org/ . The blog http://krajszgsoc.blogspot.de/2017/07/live-data-features-alive-in-labplot.html shows some features for plotting of live data.
(In reply to Alexander Semke from comment #8) > Ok. I see the reason for the confusion. What you actually want to change are > the ranges of the plot and not the start and the end values of the axes. For > this, select the plot and modify the ranges. > > In LabPlot the user can define/have multiple axes. So, you first define the > ranges of the data to be plotted (or keep it to "auto") and then start > adding axes. On default, we create axes with "auto fit" which automatically > adjust to the plot ranges. But the user can add in addition new axes which > cover only a certain region with different formatting (labels, number of > ticks, scaling, etc.). Though being very flexible, this concept is hard to > grasp for people who have worked with applications only that do not support > an arbitrary number of axes. So, simply change the plot ranges and you > should get a behavior you're familiar with. Fair enough, but that's still really unintuitive behavior. > > My impression is that > > the current design is meant to be used for developing printed reports, so in > > order to maintain that functionality I suggest relegating it to some sort of > > "export to print" wizard or something. > Producing results that are ready to be exported and used in publications is > one of the main emphasis of the application, yes. The export is done via the > export dialog. But we also support other workflows like working with live > data, analysis of imported data (ascii, binary, HDF5, netCDF, FITS), working > with different computer algebra systems, etc. You can check the recent > couple of blogs and the release announcements (2.1, 2.2, 2.3 and 2.4 > releases) on our homepage to get some ideas about the feature set of the > application - https://labplot.kde.org/ . I'm not convinced that working with live data is really a focus because the XY plot looks like a piece of paper. I seriously think that if you gave up on making the XY plot have fixed range values, you would be able to avoid simplify this. Here's my envisionment of the workflow: 1. The user enters data into a Spreadsheet. 2. The user creates an XY plot which by default is an infinite, linearly-scaled plane, then tells LabPlot to plot the data from the spreadsheet. The user is able to pan, zoom, edit points, and group-select points to analyze. Axes would have infinite ranges and number of ticks as well, and automatically decrease tick size when zooming in. 3. The user decides to make the data more readable, so he or she disables infinite ranges for the axes (which would also make the number of ticks constant), applies a theme to the graph, etc. So basically, please make the plot more freeform until _after_ the user is done analyzing. The average user will, I think, expect the number of ticks to grow with the number of data points added. The average user will also probably want to inspect the graph by panning and zooming before making a printable version. Finally, _please_ keep in mind that the average user expects things to Just Work. Thanks for all your help.
(In reply to Matthew Trescott from comment #9) > Fair enough, but that's still really unintuitive behavior. Agree. But this is still more intuitive than in most other programs that support multiple axes. You mentioned LoggerPro as an example for a software with good UX. What is the workflow in this program to create plots like on the screenshots in the following links? https://reference.wolfram.com/language/howto/GeneratePlotsWithTwoVerticalScales.html https://www.originlab.com/doc/Origin-Help/MultiY-Graph http://www.linuxjournal.com/article/3743?page=0,2 https://de.mathworks.com/help/matlab/creating_plots/graph-with-multiple-x-axes-and-y-axes.html?s_tid=gn_loc_drop > I'm not convinced that working with live data is really a focus because the > XY plot looks like a piece of paper. I seriously think that if you gave up > on making the XY plot have fixed range values, you would be able to avoid > simplify this. > Here's my envisionment of the workflow: > > 1. The user enters data into a Spreadsheet. > 2. The user creates an XY plot which by default is an infinite, > linearly-scaled plane, then tells LabPlot to plot the data from the > spreadsheet. The user is able to pan, zoom, edit points, and group-select > points to analyze. Axes would have infinite ranges and number of ticks as > well, and automatically decrease tick size when zooming in. > 3. The user decides to make the data more readable, so he or she disables > infinite ranges for the axes (which would also make the number of ticks > constant), applies a theme to the graph, etc. It looks like a piece of paper because every worksheet has a fixed size on default. What you're referring here to are, I think, not the _ranges_ of the data shown in the plot but the _size_ of plot and/or worksheet. I'm attaching two screenshots making the difference clear. Both plots show the same amount of data in the same data ranges, namely x=[0,20] and y=[-1,1], for f(x)=sin(x) with x \in (0,20). In the plot shown in worksheet_fixed_size.png the size of the worksheet is fixed (10cm x 10cm) and the plot adjusts its size (layout is active with some values for top, bottom, left and right margins). On the second screenshot worksheet_view_size.png the same function is plotted but now with worksheet adjusting it's size to the view size. To get this simply select "view size" for the size in the worksheet properties. If you resize the sub-window (change the size or maximize the sub-window), the worksheet and the plots on it will adjust the sizes accordingly. You can also set all the layout margins to 0 if you need more space for the plot(s) and also play around with the plot area paddings in the plot properties. You can even show the data in the presenter mode if you want to further get rid of menu bar and toolbars (main menu bar -> Worksheet -> show in presenter mode). Once you have your desired settings for the worksheet and plot (sizes, etc.) you can save them as default values (template buttons at the bottom of the properties dock widgets for different objects) - every newly created object will be then created with these properties. > So basically, please make the plot more freeform until _after_ the user is > done analyzing. The average user will, I think, expect the number of ticks > to grow with the number of data points added. The average user will also > probably want to inspect the graph by panning and zooming before making a > printable version. We have quite a lot for zooming already. Panning will come soon. But of course, we're not done yet. Still a lot can be improved and added. Number of ticks is tricky and very many users won't expect the number of ticks to grow with the number of data - if I plot couple of values in the x-range 1-10 I want to have maybe the ticks for 1, 2, ...10, but if I plot 100k points in the range 1-10^6, I don't want to have million of ticks. > Finally, _please_ keep in mind that the average user > expects things to Just Work. Thanks for all your help. Agree. The problem here is that there is no global "average" user. Depending on the actual workflows, tasks and scenarios, different users have different demands on this kind of software and we need to keep all of them in mind when implementing features and going for certain "default values".
Created attachment 110364 [details] views size
Created attachment 110365 [details] fixed size
(In reply to Alexander Semke from comment #10) > (In reply to Matthew Trescott from comment #9) > > Fair enough, but that's still really unintuitive behavior. > Agree. But this is still more intuitive than in most other programs that > support multiple axes. You mentioned LoggerPro as an example for a software > with good UX. What is the workflow in this program to create plots like on > the screenshots in the following links? > https://reference.wolfram.com/language/howto/ > GeneratePlotsWithTwoVerticalScales.html > https://www.originlab.com/doc/Origin-Help/MultiY-Graph > http://www.linuxjournal.com/article/3743?page=0,2 > https://de.mathworks.com/help/matlab/creating_plots/graph-with-multiple-x- > axes-and-y-axes.html?s_tid=gn_loc_drop I recorded a screen capture of an example with two Y axes in Logger Pro. It's on my Google Drive because of the size limit on Bugzilla: https://drive.google.com/open?id=1jf8bl6CPxstT6VC_s_8_lmiDEhW9bcHX True, it's less flexible than LabPlot, but notice how trivial it is to use. Before today I didn't even know that Logger Pro supported two y-axes, and that recording was only my second try. > It looks like a piece of paper because every worksheet has a fixed size on > default. What you're referring here to are, I think, not the _ranges_ of the > data shown in the plot but the _size_ of plot and/or worksheet. I'm > attaching two screenshots making the difference clear. Both plots show the > same amount of data in the same data ranges, namely x=[0,20] and y=[-1,1], > for f(x)=sin(x) with x \in (0,20). In the plot shown in > worksheet_fixed_size.png the size of the worksheet is fixed (10cm x 10cm) > and the plot adjusts its size (layout is active with some values for top, > bottom, left and right margins). On the second screenshot > worksheet_view_size.png the same function is plotted but now with worksheet > adjusting it's size to the view size. To get this simply select "view size" > for the size in the worksheet properties. If you resize the sub-window > (change the size or maximize the sub-window), the worksheet and the plots on > it will adjust the sizes accordingly. You can also set all the layout > margins to 0 if you need more space for the plot(s) and also play around > with the plot area paddings in the plot properties. You can even show the > data in the presenter mode if you want to further get rid of menu bar and > toolbars (main menu bar -> Worksheet -> show in presenter mode). Once you > have your desired settings for the worksheet and plot (sizes, etc.) you can > save them as default values (template buttons at the bottom of the > properties dock widgets for different objects) - every newly created object > will be then created with these properties. > > > > > So basically, please make the plot more freeform until _after_ the user is > > done analyzing. The average user will, I think, expect the number of ticks > > to grow with the number of data points added. The average user will also > > probably want to inspect the graph by panning and zooming before making a > > printable version. > We have quite a lot for zooming already. Panning will come soon. But of > course, we're not done yet. Still a lot can be improved and added. Number of > ticks is tricky and very many users won't expect the number of ticks to grow > with the number of data - if I plot couple of values in the x-range 1-10 I > want to have maybe the ticks for 1, 2, ...10, but if I plot 100k points in > the range 1-10^6, I don't want to have million of ticks. > > > Finally, _please_ keep in mind that the average user > > expects things to Just Work. Thanks for all your help. > Agree. The problem here is that there is no global "average" user. Depending > on the actual workflows, tasks and scenarios, different users have different > demands on this kind of software and we need to keep all of them in mind > when implementing features and going for certain "default values". I think there's another angle though: the user who needs advanced features will be smart enough (for lack of a better phrase) to find and enable them. The user who does not need them may simply be overwhelmed and give up if advanced formatting features are enabled by default. I can see that LabPlot has smart features, but it just hasn't yet learned to be smart on the user's behalf. ;) I think that two design choices mentioned here are kinda related. - The plot scales down to fit the data, rather than the worksheet expanding to fit it. This is understandable, since with massive numbers it would be unrealistic to grow the worksheet to fit the data. (But then it causes ticks to have non-whole-number labels). However, with panning and zooming, it would not be so surprising if the user wished to pan and zoom to various parts of the graph on his own. In this case, having the plot constantly autoscale while adding data points could be undesirable, so maybe autoscaling should by default only. - The number of ticks is fixed. Here, I think, is the problem. The user shouldn't have to guess-and-check how many ticks are needed. It should be possible for LabPlot, by default, to find a value equal to or higher than the maximum value on a given axis that is a whole-number multiple of some reasonable tick increment. (The tick increment would be based on the size of the plot on the screen.) Of course, advanced users might want to adjust the distance between ticks manually, but I think even that would be very much preferable to changing the _number_ of ticks. The above method describes roughly what Logger Pro does, although if LabPlot supported manually setting the tick increment it would actually have another feature that Logger Pro does not.
(In reply to Matthew Trescott from comment #13) > I recorded a screen capture of an example with two Y axes in Logger Pro. > It's on my Google Drive because of the size limit on Bugzilla: > https://drive.google.com/open?id=1jf8bl6CPxstT6VC_s_8_lmiDEhW9bcHX Thanks for the video. The behavior you've shown here is also the behavior that is documented in my links posted above for Origin, Mathematica and Matlab. We actually didn't support this workflow in LabPlot yet at all. When posting those links I didn't realize they were referring to something different. In you video and in the links above it's about plotting different data sets of two different scales in the same plot - the second scale is set by the properties of the second axis. I meant actually the ability to add an _arbitrary_ number of axis, like in the example with Gri http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/037/3743/3743f4.jpg . Anyway, this feature (two different scales in one plot) is something that we should add soon, too. > I think there's another angle though: the user who needs advanced features > will be smart enough (for lack of a better phrase) to find and enable them. > The user who does not need them may simply be overwhelmed and give up if > advanced formatting features are enabled by default. I can see that LabPlot > has smart features, but it just hasn't yet learned to be smart on the user's > behalf. ;) It's not only about using advanced features it's also about having different workflows. A user who needs an application with abilities to modify every single details of a plot and to produce a PDF-export to be embedded into the latex file for the next publication has totally different perspective and demands on us than a user who just wants to quickly plot some external data. With stated with the first perspective and adding now features to support also the other perspective. And yes, I agree, we need to find out how to make the usage of the application for different users comfortable. > > I think that two design choices mentioned here are kinda related. > > - The plot scales down to fit the data, rather than the worksheet expanding > to fit it. This is the default behavior in LabPlot. The plot we create has on default the data range set to "auto" and the axes added to the plot ("box plot" with 4 axes, etc.) have also "Auto fit" option set to "on". With this settings all the data is shown, also automatically on new data changes - the plot adjusts to the new ranges. The only think that caused here a bit confusion and that is different compared to other tools is the difference between the worksheet view having fixed size (e.g. 15cm x 15cm) or having and infinite size (i.e. the view fills out the whole available window space). The latter can be achieved by using "view size" for the worksheet size and can be saved as default settings if the user needs this kind of behavior all the time. > This is understandable, since with massive numbers it would be > unrealistic to grow the worksheet to fit the data. (But then it causes ticks > to have non-whole-number labels). However, with panning and zooming, it > would not be so surprising if the user wished to pan and zoom to various > parts of the graph on his own. In this case, having the plot constantly > autoscale while adding data points could be undesirable, so maybe > autoscaling should by default only. As mentioned above, this is the default behavior - the default plot auto adjusts to the data. With zooming and panning the user can navigate into a certain region in the data. The user can also switch off the auto-mode and set the ranges to fixed values manually - this is actually the more frequent use case for people working on the plots for publications. For panning we have the buttons in the plot toolbar at the moment (shift left X, etc.). Panning with the mouse is being implemented now. I added the first code already for this recently. It works already but needs to be finalized yet. > - The number of ticks is fixed. Here, I think, is the problem. The user > shouldn't have to guess-and-check how many ticks are needed. It should be > possible for LabPlot, by default, to find a value equal to or higher than > the maximum value on a given axis that is a whole-number multiple of some > reasonable tick increment. (The tick increment would be based on the size of > the plot on the screen.) Of course, advanced users might want to adjust the > distance between ticks manually, but I think even that would be very much > preferable to changing the _number_ of ticks. > > The above method describes roughly what Logger Pro does, although if LabPlot > supported manually setting the tick increment it would actually have another > feature that Logger Pro does not. In LabPlot you can set the number of ticks for every axis separately. You can * either specify the total number of ticks and LabPlot will re-calculate their values on zooming, panning or rescaling of the plot when new data added * or you can specify the "increment" (i.e. the distance between two ticks) and LabPlot will re-calculate the number of ticks all the time you zoom, pan, etc. * or you can specify a column with values where the ticks have to be placed - this is useful if you need to have the ticks at some certain positions only. The settings for this can be found in the axis properties dock -> Ticks -> Type. The settings can be done for major and for minor ticks separately. Matthew, I'm very thankful you for your feedback and for this discussion. User's feedback is very important for us. But having this kind of discussion in a bugzilla ticket is a bit hard. Can we close this ticket, if the original problem is fixed for you, and move the further discussions to kde-edu mailing list or to the private email conversion?
Yes, this bug can be closed. And I apologize for not doing sufficient research to see that LabPlot actually supports the workflow I'd expect. I would just suggest that the default tick type be "Increment" rather than "number". Feel free to email me at matthewtrescott <at symbol> gmail <period> com if you'd like. Thanks for your patience and understanding about this rather subjective topic of UI.
(In reply to Matthew Trescott from comment #15) > Yes, this bug can be closed. Thanks. > And I apologize for not doing sufficient > research to see that LabPlot actually supports the workflow I'd expect. Don't worry. We fixed an issue here and we had a helpful discussion on the general usability. I hope you'll give LabPlot another try and will be continuing using it in future :-) Please report any kind of bugs in LabPlot and wishes in bugzilla here. For more general discussions on new features it's maybe better to use the kde-edu mailing list. Thank you once more.