Seeking philosophical guidance on library interface design.

Tom Glod tom at makeshyft.com
Tue Apr 23 22:22:50 EDT 2019


interesting thread.  sounds like a useful library. * watching * thanks Alex

On Tue, Apr 23, 2019 at 7:19 PM Bob Sneidar via use-livecode <
use-livecode at lists.runrev.com> wrote:

> My thinking is to ask what visual impact if any would having the extra
> attributes have? Is there a scenario where the graphs would be created so
> small that the extras would be visually unappealing? Also, I think less to
> start with is better, because adding more features makes the end user feel
> like he's getting a bonus!
>
> Bob S
>
>
> > On Apr 23, 2019, at 16:01 , 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
>
>
> _______________________________________________
> 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