[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Include user interface?
As I understand it, the vast majority (and I mean vast) of spreadsheets use very little of this functionality. Some simple arithmetic MAYBE plus the SUM function. References to cells sometimes, and much less frequently to cells on related sheets. Very few use variables. Is this true? Do we have a real survey? I heard that Lotus did one many years ago, is there anything new or at least access to that data? I think the key is that if a capability is implemented it be implemented in a fashion that lets the data files interchange easily and have consistent results, common documentation, test cases, etc. We must allow for user interface advances (which may include formula syntax on display and entry) and simplicity. We want even the most basic innovation to "go with ODF" as the basic compatibility format. Testing 100+ functions (let alone typing them in) is not something those innovators will want to do nor afford. (I remember what we had to do at Slate to get those done -- we had to contract out and we had lots of VC funding.) I think we really need a "Level 0" that has very little. Remember, VisiCalc had hundreds of thousands of users with just a handful of functions, and of those some we used by less than 1% of the users I'm sure. Maybe what we need is innovation on how to test for which functions are being used and how to fail gracefully and let the user know. Also, perhaps a preferred way of implementing user created functions that can provide those "standard" capabilities. That way if I want to use the PDA version but really need a matrix multiply or complex divide I can do it by just getting one from a kind provider of such extensions or write it myself from the ODF spec (and hopefully let others know it's available). -DanB At 06:33 PM Monday 2/27/2006, David A. Wheeler wrote: >Again, I'm splitting out the email into topics, summarizing, and >then commenting. > >This email is about user interfaces, and whether they should be in scope. > >>* Scope: Define this specification as ONLY an interchange format, >>and at most RECOMMEND user interface issues? > >Mecir believes we SHOULD recommend some user interface issues, e.g., >"operator X can also be presented to the user in the form Y, but >must always be saved as X - for all cases where it matters." >When I say "UI", I mean "how the formula is perceived by the USER": >do you use commas or semicolons to separate function parameters, and so on. > >Mecir says: "the user-perceived format would usually be pretty >similar to the storage format >- because there's no reason why not." Agreed. > >But Mecir says: "the test-cases show exactly that - user-perceived version." >No, the test cases of OpenFormula show the STORAGE version >(except for XML-quoting special characters like <). For example, >I know of NO spreadsheet implementations where users MUST surround >cell references with [..], but the interchange syntax of OpenFormula >demands it.... and so the test cases do too. > > >"I would suggest that we say, user-perceived version should look >like this, unless you have a good reason to differ." >Problem is, everyone has a good reason. Some implementations, like >Quattro Pro, actually have skinnable syntaxes -- they vary their >display syntax, depending on a user setting. Most implementations' >function names vary depending on the locale (they translate function >names to the local language). Many implementations' decimal point >(comma or period) also vary depending on the locale. > >It would be NIFTY if everyone would agree to a common display >format, and then made >the storage format identical (or nearly so). But what's the common format? >Excel, Gnumeric, SheetToGo all use "," for function parameters, >which is horrific >if you want to support locales where "," is the decimal separator. >They also use "," for the "union" operator (how silly!). >Is ".." or ":" the range operator? Is "=" or "==" equal-to? >And if cell references aren't surrounded by [..], there are nasty >ambiguity problems >that are no problem for human-written text, but as a storage format >it's terrible. > >We could devise a RECOMMENDED user interface format; that'd be great. >There might still be occasional variance between that and >the storage format (e.g., [..] as a cell reference marker). >Otherwise, is QT3 a variable, or a cell in a spreadsheet with lots of columns? >But I'd hate to MANDATE that. > > >--- David A. Wheeler > > >