Re: [office-formula] Key Issues

[Dan Bricklin <danb@bricklin.com>]

I unfortunately don't have too much time to contribute to this 
interesting set of conversations (I'm really trying hard to get my 
spreadsheet shipped in version 1.0 and I'm the only developer...). 
However, as one who has created spreadsheets for new areas more than 
once (the original one, a pen-based one, and now a browser-based one) 
I know that spreadsheets are NOT "mature". They are only mature in 
light of the computer systems of the day they were designed. New 
capabilities are coming about in terms of I/O and application areas 
and spreadsheets need to address them. Also, ODF itself as well as 
the world of open source for experimentation (you couldn't experiment 
much with the Excel/1-2-3/etc. source code) will make this innovation 
even more likely than in the past.

For example, laser printers brought in the much greater need for cell 
font/border/etc. formatting. Ink (on pen-based computers) brought in 
ink data type. HTML (with its built-in auto formatting like "fit to 
screen width", viewer defined styles, etc.) as the main result 
(instead of a printed page) will bring in others (as I'm finding out 
in wikiCalc). Complex arithmetic is only one type of "new" operations 
we may need for the data types we'll want to deal with in a spreadsheet.

Also, the availability, through open source and proprietary cousins, 
of components and the continued drive to use them, means specialized uses.

This all means that the set of commonly implemented functions will 
grow, even if not all spreadsheets need / should make available all of them.

The UI tradeoffs a developer makes in creating a ***usable*** 
spreadsheet program may affect the subset of data types and functions 
to support. I believe that the success of the spreadsheet as a 
commonly used tool stems from the wide area of things it can do but 
most importantly with how easy many people found it was to apply to 
those areas. UI issues come into play here. A syntax for data 
interchange that can support a really wide range of data types, 
reference types, etc., and be easy to manipulate, etc., will almost 
certainly be too cumbersome for common use. Remember how 1-2-3's 
A1/$A$1 form won out in terms of use over the more "complete" and 
"elegant" earlier R1C1/R[+1]C[+1] format of Multiplan even in 
Microsoft's products. So we need to leave flexibility to the 
spreadsheet UI developer in how formulas are entered, displayed, and 
edited. What's important, I think, is that SUM or SIN work as 
expected. We don't distinguish between SIN written as a string of 
ASCII text with parenthesis vs. as a formula with implied 
parenthesis. We use them both but we expect the numeric results to be the same.

We need to think of ODF as lasting for decades and decades. UIs will 
evolve and data types and their manipulation primitives will evolve. 
The format for saving the formulas, though, can be made to handle 
such evolution at least to the extent we've seen it in the past and 
can foresee the future.

Back to coding.

-DanB

At 04:47 PM Monday 2/27/2006, Daniel Carrera wrote:
>robert_weir@us.ibm.com wrote:
>>If we want, is sufficient for us to define ODF formulas period, and 
>>leave it to a future specification to define subset and superset 
>>profiles for various other uses.  This could even be done by 
>>vendors or on an industry basis,
>
>Well, spreadsheets are a mature industry. In a sense, vendors have 
>already decided best practices. So, we could follow your approach 
>without waiting a few years. For example, take the intersection of 
>most interesting spread sheets and call that "basic". Take a 
>spreadsheet that focuses on the scientific field (Gnumeric? - not 
>sure) and use that to get the "science" package. You get the idea.
>
>I can't decide where I stand on the levels vs packages issue. I can 
>see good arguments for both sides. I'll comment more when I have 
>something meaningful to comment.
>
>>So maybe we can start by standardizing a way for implementations to 
>>define profiles, but we don't standardize on any profiles ourselves?
>
>If we know of a current implementation that focuses on a specific 
>area, we could ask them to submit a profile now-ish.
>
>>Think of C/C++.  When C was standardized, it had a single set of 
>>required libraries.  But eventually there emerged subsets for 
>>embedded uses and supersets for more specific uses.  Ditto for HTML.
>
>I understand. I think spreadsheets are pretty standarized already 
>though. They've been around for a while. So we can define packages now.
>
>Cheers,
>Daniel.
>--
>      /\/`) http://opendocumentfellowship.org
>     /\/_/
>    /\/_/ I'm not saying there should be a capital punishment for
>    \/_/  stupidity, but why don't we just take the safety labels
>    /     off of everything and let the problem solve itself?
>
>