Seeking philosophical guidance on library interface design.

prothero at earthlearningsolutions.org prothero at earthlearningsolutions.org
Wed Apr 24 09:54:41 EDT 2019


Alex,
A great idea! I do a lot of plotting and would find this kind of library very useful. I would need it to be able to determine some reasonable default values for plot axes, but also to be able to set them. The plot label and axis labels need to be settable. Also, there could be histogram type plots or x/y plots where plot points are from x/y data. Lots of kinds. Symbols could be plotted at data points or lines, or lines with symbols.

Also useful would be a message that sends the x,y data values as the mouse moves over it. That way it would be possible for me to build a little window that gives me data values and other information as needed. Perhaps it could be clicked on and off with a checkbox.

I’d be glad to give feedback as you set specs.
Best,
Bill

William Prothero
http://es.earthednet.org

> On Apr 23, 2019, at 4:01 PM, Alex Tweedly via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Hi folks,
> 
> I'm building a library (which I plan to release as Open Source), and I'm having trouble trying to decide which approach to take with default values.
> 
> The library is to produce XY graphs (charts). An app which is using it will provide one or more sets of data to be plotted. The app can also *optionally* provide additional parameters, such as
> 
>  - display tick-marks on each axis
> 
>  - display grid lines along each axis
> 
>  - label the ticks / grids (e.g. display label every 5 ticks)
> 
> etc.
> 
> Without going into each one of them, there is an overall "phlosophy" chioce
> 
> A - should the default be that the produced graph be simple (e.g. no ticks, no labels, etc.)
> 
> or
> 
> B  - should the default be to try to find reasonable / possible values (e.g. set a value for ticks such that they appear, say, more than 10 pixels apart, but less than 100 pixels apart; that you label every 2nd-5th tick, ...)
> 
> A is appealing because it means that the library isn't making guesses, often dumb guesses, on your behalf; you see a blank, sparse graph, and can then, as app developer, provide additional parameters to supply info you think will help. But it is unappealing because the graphs are just *so* empty by default.
> 
> B is appealing because it feels like it is being helpful, and will (try to) produce a reasonable looking graph as best it can.
> 
> 
> So - I'd welcome any suggestions, comments, design philosophy ideas ?
> 
> Thanks
> 
> Alex.
> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the Use-livecode mailing list