Hi Eike,
Eike Rathke wrote:
Hi Leonard,
On Monday, 2007-07-30 23:10:49 +0300, Leonard Mada wrote:
there is a new Calc Usability wiki page (see
http://wiki.services.openoffice.org/wiki/Calc_Usability_Activities).
However, I think the page should be moved to /Calc/Usability to bring
some structure to the OOo site.
Something like that might fit better, indeed. I'd suggest to name it
http://wiki.services.openoffice.org/wiki/Calc/To-Dos/Usability
instead though. Please check with Frank (mailto URI at the bottom of
that page) of the UX team whether they have something different in mind.
Sent an e-mail to Frank.
Please note for i79924 that changes like strong typing would affect the
ODF file format and especially the ODFF formula specification as well.
It would had to be supported not only by OOo but also by other
applications reading/writing ODF spreadsheet files.
Well, starting early with writing the necessary specifications and
implementing gradually the changes is better than starting later when
the competing applications have already adopted it. Someday this needs
to be done, and keeping this in mind is surely better than having to
implement it in a hurry.
Please note that from an enterprise point of view, I would mandate the
adoption of such a spreadsheet if one becomes available, as I
anticipate that some 30% of all errors could be caught early on.
For i80139 please note that for "3.2 DATA LINKS" external references are
already implemented (could be enhanced though to not create an internal
sheet and handle things a bit different)
Nahh, a bidirectional-link does not work (neither for 2 different
spreadsheets, nor for intra-spreadsheet links; the latter link-mechanism
does not exist at all). If I link to a cell having a formula, it does
not work, either. So it is basically never usable, because most of the
time there will be a formula somewhere in the spreadsheet blocking this.
"3.3 TRACK CHANGES" is already
implemented (see menu Edit.Changes), and "3.4 VERSIONING" is already
implemented (see file save/load dialog). Which leaves only "3.1
COLLABORATIONS" that is already handled by some other issue.
Eike
Nahh, mediawiki has a far better versioning/changes functionality than
every spreadsheet application. And that is rather a poor alias for
spreadsheets. Therefore, I am eagerly awaiting to see something more
advanced, something really mind breaking.
e.g. when changes are made in an enterprise environment, you do not care
for individual items. You care on a more global scale, i.e. group
changes. That means, the spreadsheet must be partitioned into various
*functional parts* and record/ display the changes per functional part.
I do not need to know (most of the time) that one single item has
changed. I do need to see changes in results,or in formulas (in a
functional region), or of some other data in a specific functional
region (or define an item of interest). It is good practice to split the
spreadsheet into functional regions.
There should be the ability to *document* extensively the changes. A
*hierarchical* / *tree view* of changes (per functional part) is also
needed and a lot of other features I cannot yet think of.
Implementing concurrent user support makes issues even more complex.
When multiple users interact with the spreasheet, some *automatic
update* mechanisms will need to be reworked and some disabled (otherwise
you will end waiting 99.99% of the time for the computer to recalculate
the spreadsheet; I mentioned previously, that changing only the type
from 'string' to 'number' on a moderate size spreadsheet in a competing
program needed 2 hours to complete). *Tracking* not-yet updated cells
will be a daunting task. This needs extensive reworking of the current
function implementation.
Extensive brainstorming is indeed needed here (I mentioned that; I do
not have a magic solution (yet)).
Sincerely,
Leonard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
