|
|
|
|
|
by tehwalrus
4297 days ago
|
|
In terms of auto-update, sure. But I was talking mostly about how to structure your data - for most business activities, lists of objects with properties (or dictionary keys) are far superior to cells, and collections of cells, with obscure names. How much easier would spreadsheets be to understand if you had sum([widget.price for widget in catalogue])
instead of SUM(F3:F405)
?Teaching people to think more about their data structures, rather than teaching them to squash everything into a table even if it doesn't really fit into one, would dramatically expand their skills in this type of analysis! |
|
For immediate results and learning, your proposal spreadsheets would be harder to understand - if your data fits on a single screen (not ...F405), then you can just point your finger at it and say "Here! here are the widget prices!", but any structured model would (a) require thinking about what a right structure would be for the situation (that's the hard to use part, takes effort), (b) require understanding about what makes a proper data model (that's the hard to learn part, many people won't know how) and (c) makes it nontrivial to update that model (that's the hard to maintain part - less chance to break stuff, but more effort to do it properly).
For reusable datasheets and estabilished processes it's an entirely different situation, and for that there are not-Excel apps or named ranges within excel; but creating an usable dataflow and a reasonable structure is a much, much more difficult skill than using excel currently. It may be easy for you, but not for the general population; heck, I see heaps of second year CS students that have no clue about how to structure their data, so requiring that can't make spreadsheets easier to understand.