You can now save plots. They have an edit/preview/save cycle like everything else.

I've integrated plots into the system now.   They are saved to the backend database, show up with their parent views in the view list, and have a save/edit/preview user interface cycle. So they're coming along pretty nicely. 

This chart is part of a diet tracker.   This chart is showing how much of each food group each person has eaten today.   I don't render a legend yet… it's coming.


Actual FormLis Powered Plots

I’ve been busy integrating charts into FormLis. Heres how they look together. Isn’t that lovely?

You generate charts from view data. In this case I used a food intake tracker that is helping people make sure they’re getting their recommended daily amounts. Here is the
relevant data — I’ve added the highlighting, column numbers and outlines — this is what the chart is seeing.
And here is the magic tying them together:
PLOT bar chart ;
ON “/*/” leaf-totals ;
X p# 0 case “Protein” ; then
     1 case “Grains” ; then
     2 case “Vegetables” ; then
     3 case “Fruits” ; then
     4 case “Milk” ; then
     5 case “Fats” ; then ;
Y 5 p# + column ;

Plots describe how views are transformed into (X & Y) pairs. ON “/*/” leaf-totals ;  slices the data up into multiple plots. In this case 1 plot per  top level group (e.g. Tom, Peggy, etc). Its the pink boxes in the view above.  I’m using the leaf-totals as data because they contain my daily sum (I’ve highlighted them in white). Leaf-totals means the same as the sub-sub-sub-sub-totals. I could have chosen to use the rows or the overall totals.

I want to restrict the plot to just todays data, which is the first row in each group, so I say LIMIT 1 ;.

Each of these rows will produce several (X &Y) pairs. For example Tom’s row will produce (“Protein” & 12), (“Grains” & 6), (“Vegatables” & 2.5) etc. So I say POINTS-PER-ROW 6 ;

Lastly, I have to tell FormLis how to compute the X & Y values. That’s what the X and Y functions above do. X says “take the point number (p#), if its zero -> Protein, if its 1 -> Grains, etc”. Y says take the point number, add 5, and use that column’s data.

Scatter Plots

I've added scatter plots. These charts are powered by code that does both the placing the (variably sized) dots on the scatter plot, and placing the line markers dots on the plot lines.


Nearly done.  I still have to make cumulative bar charts, and enable dot-markers on the cumulative line chart from the previous post. I'll probably add some white-space between the y-title and the y-numbers.  

Chart rendering is now (pretty much) in the bag.

I've got charts pretty much licked. The following image shows line charts, a bar chart, and a cumulative line chart.  I've still got to make scatter plot charts and cumulative bar charts.  Then I need to pick some better default colors — I dropped the sophisticated color AI I mentioned earlier because it had a tendency to pick a lovely shade of puke green and some complementary colors.    Now I just use preset colors that can be overridden.

The colors I'm using (blue, red, green) are okay, but I'll try to create a default set that is both lovely, sufficiently contrasted, and as usable by the visual impaired as can be without giving up too much prettyness. 

Also I dropped the object orientation.  As my design took shape I found the OO approach wasn't pulling its weight and was making me design an API that was good for subclasses rather than an API that was good for making charts.

Progress on bar, line and scatter plots.

With pie charts well in hand, I still have to do bar, line and scatter plots.  All three need a grid to draw over, so that’s what I’ve been working on.   The system is able to determine a nice range for the data, then appropriately size the labels.



Surprisingly, these charts are the object oriented; the only thing in my entire system that is.  Without getting controversial, I find objects usually makes problems more complicated and they make code more difficult to change.   In this case, my objects describe the plots and have routines to draw portions of it (i.e. draw titles, draw axis, draw data).  At a high level the plots are more same then different,  so it works out pretty well.

Charts still coming (here is a sample). Labels print horizontally, text-scale is determined automatically.

This is how the pie chart looks now.  It was difficult to write functions to add text to the charts. I've decided to use arial, so my font size calculations are based on that.  More importantly, I've now got the general flow figured out. Meaning that I've explored this problem enough that I have a handle on what parts can be reused when I make bar and line charts, which are still coming.


One Day, FormLis will build lovely charts. Pie charts, bar charts, line charts. Here is a sample.

FormLis makes data collection and reporting easy. One day (months away?)  I’ll add charting.  I’ve already got most of the chart description language planned out; so I took the time to make some lisp-assisted pie chart shapes:




This took work.  First I researched a bunch of pi charts to determine what I thought looked best: simple, round, and solid color. Then I needed super accurate math to compute the wedges, if they didn’t line up perfectly, little slivers of white would ruin the asthetic.   I ended up using fixed point math (and defining PI as exactly 4096), and I had to write my own trig functions.


That was the easy part.  The hard part is color.  My plan is to let users specify colors (blue, red, or via RGB triplets) if they want.  Regardless of what they do FormLis will have to select complimentary colors.


However, its not obvious how you code that.  My plan would bore you, but the trick is to operate in a color space where choosing complementary colors is easy.  In my case I select colors from the LAB color space and then map them to RGB.  In LAB, I can control brightness and saturation while picking colors, while in RGB all I could do would be to hold red and blue intensity while selecting green intensity.  The conversion is very math heavy though, I cargo-culted it from Bruce Lindbloom, who has the best resource on the mathematics I’ve ever seen.

How FormLis has Changed Appearance over Time.

I thought it would be cool to record all the different looks FormLis has had, you know just for posterity reason. Some time in the future I’ll try to dig up even older stuff — and maybe figure out approximately when these things were.

Version 1

version 1

Version 2

version 2

Version 3

version 3

FormLis: Security Interface Added & Bug Fixes

The security interface lets you control who can use your databases and who can modify them. I haven’t rolled it out to everyone yet, I’ll do that once I document it. Users who want to play with it earlier can send me a private email.

Bug Fixes

  • Tables in forms no longer show the ‘add row’ button in read mode.
  • Fixed the preview ability for new views. A Previous bug had made these previews empty.
  • Fixed a page error that sometimes put extra garbage characters at the end of the page
  • Fixed a page error that caused the last field to not render properly if it was the very last thing on the page.
  • Fixed a bug where FormLis would mistakenly think a document you were editing had been deleted in the meantime. This was a minor user-interface glitch.

p.s. FormLis has no outstanding bugs anymore — which is a good sign. However, I’m sure there are unencountered bugs yet to be discovered (and fixed).

Minor FormLis Enhancements

I was trying to migrate to multipart/form-data encoding rather than x-www-form-encoded. This is a necessary step for handling file-uploads. Unfortunately, I didn’t get it implemented in time, but I now know enough about multipart/form-data encoding to declare it’s the worst, most ambiguous, and most difficult to parse standard I’d ever seen.


Get every new post delivered to your Inbox.

Join 34 other followers