>One of Mehrotra’s chief frustrations with the older generation of documents was what he calls “the game of Battleship” — the need to describe rows and columns in formulas using headings like “A1 to F7,” as in the old board game. In Coda documents, rows and columns are named objects, making formulas both easier to read and write.
Lotus Improv from 1991 had "names" instead of rowcolumn coordinates. Quantrix from 2003 also has named "items" instead of rowcolumn coordinates. Neither product had widespread adoption.
It seems plausible that cryptic rowcolumns would be a major paint point for most Excel users but maybe it isn't.
Quantrix found a niche in financial modeling so maybe that domain of users (~50k users) value features like that enough to not use Excel.
Google Sheets continued the tradition of cryptic rowcols and has more adoption than either of those alternative products. (Probably because it costs $0.)
It turns out that not having to name things is a feature. Users often avoid naming things and dislike being forced to do so.
The reason is what developers already know: naming things is hard! (Two hard problems, etc.)
Of course, developers also know how valuable good names are, so we like to take the time to pick good names. Users would rather just skip naming altogether and refer to things by letter/number or just by clicking on them.
>It turns out that not having to name things is a feature.
I think this is one of those great insightful points that's counterintuitive and yet has abundant real-world evidence we can't deny.
I'd guess that vast majority (99%) of programmers that program in languages requiring explicit variable names (Python, C, Java, Go, etc) will still use Excel without named cells nor named columns. Yes, they will label their adjacent cells with freeform text (e.g. "TOTAL PRICE:") but they won't use the Excel "named regions" feature to be referenced in formulas. How do we reconcile the inconsistent attitude we have about the benefits of names?!?
It turns out that yes, naming cells is a form of "code documentation" and helps avoid "spaghetti formulas" -- but it's also a friction. If programmers using Excel eschew cell names, it's a given regular users will too.
It also doesn't help that "names" in Excel is not a 1st class feature. It's a separate menu item and the name is a hidden "alias" for the cell.
With other products, the "name" of the cell is what you type into the box right there on the sheet. The UI for giving a cell a name is more immediate.
Yes, clicking on "this thing right here!" is a powerful way for ordinary users to create references. It shouldn't be underestimated.
Programmers are so used to having to name things that we don't see the mental overhead of using names. A named cell is conceptually a pointer -- you can change what it points to (by giving the same name to some other cell instead), and if you delete the referent, it can point to nothing. That kind of invisible indirection is not easy for non-programmers.
This is on top of the glaring issue that, if my formula says multiply "itemCount" by "itemPrice"... Where do I actually find those things? If I see A2 referenced, I know exactly where to find it.
Excel also has named rows/columns and cells - one of the bunch of useful tips I learned from Joel Spolsky's "You Suck at Excel" presentation - here's the part where he covers that: https://youtu.be/0nbkaYsR94c?t=25m54s
Excel also supports Multiplan-style RC syntax for cell addresses, if you like. I find the syntax a bit more clear, but ultimately too verbose to be useful.
R1C1 = Row 1, Column 1.
R[1]C[1] = cell one row over and one row down.
One other point worth mentioning is that cell-relative references in Excel are more pervasive than they might appear. For example, you can specify a conditional format formula that highlights a cell if it has a different value than the cell immediately above. (Or a number of other more considerably complex scenarios.)
Range names work this way too... it's possible to define a range of the form "three cells to the right of the current cell".
Data tables can also make things considerably faster. A colleague of mine once made a spreadsheet something like an order of magnitude faster by switching to data tables. (Maybe more speedup than that, even.)
If you are building a business plan in Excel, or trying to explain how the financial accounts consolidates in a large organisation with multiple subsidiaries, tables are not particular useful.
That's the catch with Excel. One application, thousands of very different use cases.
I don't know what the intersection of 'most' and 'power' Excel users is, but as a very casual user I rarely need to explicitly type cell references because I can click to select which cell I'm referring to in the formula. Since Excel does multicolour highlighting it's easy to check that the right cell was selected. If I need an absolute reference (or whatever) I can go in afterwards and modify appropriately.
Named cells does significantly improve the readability of spreadsheets at a later date though!
Lotus Improv was one of the best programs I've ever used, and I wish it would come back in a modern form. It was much more sophisticated than just having "names" instead of row/column coordinates. It had an easier to use and in some ways more powerful version of PivotTables. Man, I miss Improv.
Anyone trying to unseat Excel is going to have the same problems as people trying to unseat Facebook: they already have lock-in of the vast majority of the userbase.
I use Google Sheets for most spreadsheet work now, but I was never heavily invested in Excel. Everyone I know who is a serious Excel user just isn't interested in anything else. Excel does everything they need it to do, and they have years worth of templates and formulas developed for all their needs.
Excel is also extremely robust. You can, for example, do VLOOKUP between tables that are ~10K columns by 100K rows. And it just does it. And pauses/restarts calculating, if you need to tweak something. But Calc? It just freezes, and eventually dies, and then must rebuild the file after restart. Which may end up being impossible. Indeed, Excel will do pivot tables that choke MySQL :) And it uses multiple processors.
It becomes a whole lot easier to give the position of the letter 's', I just have to say C5. Instead of giving a name which the user has to hunt in a large spreadsheet. Its easier to look up things in a sequence, than look at an arbitrary name.
Besides you can always name a cell in Excel and use that in a formula.
I suspect path dependence (and price for quantrix) more than anything is what keeps Excel in charge.
I mean even beyond just switching costs: Excel is for instance the only format for getting data from http://www.earthchem.org/petdb/ or, to keep harping on geologists, people that keep implementing models in excel: which you then have to use because nobody trusts code you wrote yourself.
Does it really make sense for someone who doesn't understand the concept of 2D Cartesian coordinates to be using a spreadsheet at all?
"Battleship coordinates" are pretty darned far down the list of Things Wrong with Excel. Considering you still can't open multiple instances the way every other Windows application on the planet works...
Frankly that statement puts the whole company into poor light; if you are building an Excel competitor, you better know Excel pretty well. If your chief frustration is battleship coordinates then that does not exactly evoke the feeling Excel expertise, or that they have done sufficient market research. Or maybe they are not really targeting Excel as hard as the article posits?
I think the problem is that almost everyone uses excel for different things, and that lots of people feel like they know excel when they barely scratched the surface. But the reality is that 80% of excel users probably only need basic table formatting and basic formulas.
To some, excel is a data analysis tool. For those, all excel should have is big tables where every column should have a name and you would only ever do simple operations between them. To them, things like pivot functionalities, or connecting to database is critical. Data visualisation too.
To others, excel is a way to format a table, display a planning, a work flow.
To others it is a calculation scratch pad.
To others it is merely a UI, calling powerful custom XLL or calling server APIs that will do some complex pricing, book or retrieve trades from systems and whatever.
To others it is a full feature model builder, they will run some complex business plans, with all sorts of ratios and calculations that are unique to this use case and can't be generalised by an IT dept.
To others it is a custom app, with forms, lots of VBA code, etc.
For most people it is the "xml" (as in common standard format) for users to exchange data that they can open, inspect and reason without requiring a degree in computer science.
etc
So on one side there is nothing that annoys me more that someone pretending that all an Excel user ever needs is this particular feature and that he will replace Excel with that little website.
On the other side it is true that for parts of the Excel user base, all they will ever need is one particular feature and one could take a bite at Excel's market share.
There are many projects aimed at making Excel "a thing of the past" but they focus on different needs:
I think this is why Excel/Google Sheets still dominate and will continue to.
All of these products do one or a few things things that Excel or Google Sheet do, but perhaps they make it little easier for a novice. I think what people don't understand about Excel (and to a lesser extent Google Sheets) is that it's an IDE. A novice can build interesting things, a power user can build incredible things.
The only way to make Excel a thing of the past would be to make a blow-away awesome replacement that does everything excel does but better. There's plenty of blue ocean around Excel and I think each of the products you listed could do just fine.
I would love all of Excel's power available to me but delivered like Google Sheets. That would definitely kill Excel. So far neither Microsoft nor Google seem really committed to this. Google Sheets is nice but just grabs the low hanging spreadsheet fruit. Office 365 is anemic.
If I had the time and funding I'd love to make a true Excel killer that was a faithful recreation of ALL of Excel's capabilities but delivered in a modern way. I'd pay good money for this. I believe many would. Excel may be a dinosaur, but it's still the apex predator.
The witheve.com stuff (and the underlying "differential dataflow") is also interesting as a model for derived data which updates itself. I'm keeping an eye on that project too.
As far as your site goes (I just took a brief glance), if you haven't seen it already, you might find some interesting ideas in the sieuferd project:
I wonder if a kind of hybrid programming would be possible which switches between this dataflow-like functionality for parts and more traditional ('large blocks of text'-based) techniques for other parts.
I was working on a simple framework a while ago where the highest-level organizational structure was a 'domain' and these domains would connect to one another via 'converters'. I think the dataflow format would work really well for defining and linking up domains, and small functions that do things like filtering would work well within converters—but then maybe within particular domains it's somewhat of a free-for-all again (i.e. you use traditional programming techniques). Just thought I'd share the idea on the off chance that it sparks something for ya—I'm not really doing anything with that project at the moment.
I'm also curious why you prefer the tabular format over something graph-based. Is it just that it's more straightforward for people to lay things out/organize?
I'm not currently a user but https://www.smartsheet.com/ had pretty advanced features that I liked. The UI was a bit old-fashioned but the tool is capable.
Yeah - in the macOS community Coda is a fairly well known text editor for web development. The team at Panic should definitely stand their ground on this one...
I wonder how creative people can be with naming. Coda vs Coda. An editor vs an editor. Three years in stealth and this name... Well, if they change the name in the future, probably it will be... Excel! The new Excel.
I really want to hate that project (too much hype and the UI looks like this just another crappy and locked in office suite). That said there is someone out there who is going to get it right. Excel has too major problems:
1. Legacy: newer versions will always need to support VB6 and activeX and all that garbage - that's quite a big drag.
2. Inability to track changes easily. (Just move a table one row down, and it becomes impossible to compare the 2 versions) which causes what people call "spreadsheet risk"
That makes Excel "somewhat" vulnerable to asymmetric marketing attacks. It is in fact surprising that this hasn't happened yet. I think one of the big reasons is that most SV people don't use much Excel (not like we financial guys do)
I'm just hoping that Mike Bostock and the 2 other guys as Observable HQ are going to nail it. I'd much rather have a totally hackable front end that does the DAG for me, than a cloud-based document-editing-with-formulae...
There is no good way to share data between spreadsheets (linked spreadsheets are a nightmare)
There is no good way to link a word or ppt document to a spreadsheet (an extremely common use case, think reports, client presentations). Linked tables are unstable (crash and unstable rendering) and you have to do all sort of hacks to ensure the links are not screwed up if you ever modify one while the other is closed.
Excel should move away from a single grid approach per sheet (Apple’s approach makes a lot of sense).
What is depressing is that outside of ensuring it runs on new platforms, Microsoft pretty much stopped development of new major features 10 years ago. If you look at the past Excel’s what’s new, these are mostly cosmetic/minor/maintenance changes.
You can make a shopping list in Excel, and you can also run a $100M+ company with it. It's probably the most important and powerful product Microsoft has made, right next to Windows itself. Anything taking on Excel would have to be able to do all that, while also offering so much more to overcome the friction of switching.
Otherwise it's just a niche product, which is still valid, but not really a next-gen spreadsheet. Coda seems like it would be great project management/CRM tool rather than a spreadsheet app.
Panic's Coda has been around since 2007 and is a well known name. Their latest release date June 2017 and is still very active.
It has over 100 reviews on the Apple store for their mobile version and their desktop version has hundreds of reviews on independent download websites and multiple blog posts by different developers.
Writing "Coda" on Google leads to Panic's software on the first page. So does "Coda Software", "Coda App", "Coda Download" and "Coda Review".
Coda.io has been around since 19th of this month. You can get to it (well, this article on The Verge) by writing "Coda Software" on Google, but it is on page 3.
Surely naming it Coda was a mistake. It leads to confusion and hurts their branding.
If something is going to be better than Excel because its "40 years ahead of it" it ought to be a native app and be more powerful than Excel. Excels value comes from its power features and ability to finesse with fine detail - simplicity isn't always the answer.
Readit News
Lotus Improv from 1991 had "names" instead of rowcolumn coordinates. Quantrix from 2003 also has named "items" instead of rowcolumn coordinates. Neither product had widespread adoption.
It seems plausible that cryptic rowcolumns would be a major paint point for most Excel users but maybe it isn't.
Quantrix found a niche in financial modeling so maybe that domain of users (~50k users) value features like that enough to not use Excel.
Google Sheets continued the tradition of cryptic rowcols and has more adoption than either of those alternative products. (Probably because it costs $0.)
[1] https://en.wikipedia.org/wiki/Lotus_Improv
[2] https://www.quantrix.com/QuantrixandExcelWhitePaper.pdf
The reason is what developers already know: naming things is hard! (Two hard problems, etc.)
Of course, developers also know how valuable good names are, so we like to take the time to pick good names. Users would rather just skip naming altogether and refer to things by letter/number or just by clicking on them.
I think this is one of those great insightful points that's counterintuitive and yet has abundant real-world evidence we can't deny.
I'd guess that vast majority (99%) of programmers that program in languages requiring explicit variable names (Python, C, Java, Go, etc) will still use Excel without named cells nor named columns. Yes, they will label their adjacent cells with freeform text (e.g. "TOTAL PRICE:") but they won't use the Excel "named regions" feature to be referenced in formulas. How do we reconcile the inconsistent attitude we have about the benefits of names?!?
It turns out that yes, naming cells is a form of "code documentation" and helps avoid "spaghetti formulas" -- but it's also a friction. If programmers using Excel eschew cell names, it's a given regular users will too.
It also doesn't help that "names" in Excel is not a 1st class feature. It's a separate menu item and the name is a hidden "alias" for the cell.
With other products, the "name" of the cell is what you type into the box right there on the sheet. The UI for giving a cell a name is more immediate.
Programmers are so used to having to name things that we don't see the mental overhead of using names. A named cell is conceptually a pointer -- you can change what it points to (by giving the same name to some other cell instead), and if you delete the referent, it can point to nothing. That kind of invisible indirection is not easy for non-programmers.
From that perspective it's very telling that the editor's/document's/spreadsheet's/product's name was taken from a long-time editor for the web, Coda.
R1C1 = Row 1, Column 1. R[1]C[1] = cell one row over and one row down.
One other point worth mentioning is that cell-relative references in Excel are more pervasive than they might appear. For example, you can specify a conditional format formula that highlights a cell if it has a different value than the cell immediately above. (Or a number of other more considerably complex scenarios.)
Range names work this way too... it's possible to define a range of the form "three cells to the right of the current cell".
Deleted Comment
Edit: and of course individual cells can be renamed since forever.
If you are building a business plan in Excel, or trying to explain how the financial accounts consolidates in a large organisation with multiple subsidiaries, tables are not particular useful.
That's the catch with Excel. One application, thousands of very different use cases.
Named cells does significantly improve the readability of spreadsheets at a later date though!
Random tutorial off Google:
https://www.excel-university.com/indirectly-refer-to-table-c...
I use Google Sheets for most spreadsheet work now, but I was never heavily invested in Excel. Everyone I know who is a serious Excel user just isn't interested in anything else. Excel does everything they need it to do, and they have years worth of templates and formulas developed for all their needs.
Deleted Comment
Its not cryptic, its the most intuitive way of finding the position of a cell in a spreadsheet.
It becomes a whole lot easier to give the position of the letter 's', I just have to say C5. Instead of giving a name which the user has to hunt in a large spreadsheet. Its easier to look up things in a sequence, than look at an arbitrary name.Besides you can always name a cell in Excel and use that in a formula.
Except that doesn't work correctly if you move the formula around, whereas R5C3 does (and makes relative addressing very explicit).
I mean even beyond just switching costs: Excel is for instance the only format for getting data from http://www.earthchem.org/petdb/ or, to keep harping on geologists, people that keep implementing models in excel: which you then have to use because nobody trusts code you wrote yourself.
and it only gets worse with time.
http://www.sciencemag.org/news/2016/08/one-five-genetics-pap...
"Battleship coordinates" are pretty darned far down the list of Things Wrong with Excel. Considering you still can't open multiple instances the way every other Windows application on the planet works...
Deleted Comment
To some, excel is a data analysis tool. For those, all excel should have is big tables where every column should have a name and you would only ever do simple operations between them. To them, things like pivot functionalities, or connecting to database is critical. Data visualisation too.
To others, excel is a way to format a table, display a planning, a work flow.
To others it is a calculation scratch pad.
To others it is merely a UI, calling powerful custom XLL or calling server APIs that will do some complex pricing, book or retrieve trades from systems and whatever.
To others it is a full feature model builder, they will run some complex business plans, with all sorts of ratios and calculations that are unique to this use case and can't be generalised by an IT dept.
To others it is a custom app, with forms, lots of VBA code, etc.
For most people it is the "xml" (as in common standard format) for users to exchange data that they can open, inspect and reason without requiring a degree in computer science.
etc
So on one side there is nothing that annoys me more that someone pretending that all an Excel user ever needs is this particular feature and that he will replace Excel with that little website.
On the other side it is true that for parts of the Excel user base, all they will ever need is one particular feature and one could take a bite at Excel's market share.
I read that more as a way to demean Excel by comparing it to a toy than any kind of exhaustive list of complaints...
There are many projects aimed at making Excel "a thing of the past" but they focus on different needs:
o https://airtable.com - use tables for data organization (organize anything)
o https://fieldbook.com - spreadsheet as a database
o https://www.rowshare.com share data (share rows, not data)
o http://conceptoriented.com - data transformations and data wrangling (I am the author)
o Coda - integration with documents
It is interesting if one of these approaches will eventually dominate or we will have a zoo of spreadsheet-like applications.
I think this is why Excel/Google Sheets still dominate and will continue to.
All of these products do one or a few things things that Excel or Google Sheet do, but perhaps they make it little easier for a novice. I think what people don't understand about Excel (and to a lesser extent Google Sheets) is that it's an IDE. A novice can build interesting things, a power user can build incredible things.
The only way to make Excel a thing of the past would be to make a blow-away awesome replacement that does everything excel does but better. There's plenty of blue ocean around Excel and I think each of the products you listed could do just fine.
I would love all of Excel's power available to me but delivered like Google Sheets. That would definitely kill Excel. So far neither Microsoft nor Google seem really committed to this. Google Sheets is nice but just grabs the low hanging spreadsheet fruit. Office 365 is anemic.
If I had the time and funding I'd love to make a true Excel killer that was a faithful recreation of ALL of Excel's capabilities but delivered in a modern way. I'd pay good money for this. I believe many would. Excel may be a dinosaur, but it's still the apex predator.
Deleted Comment
Years ago there was DabbleDB - https://en.wikipedia.org/wiki/Dabble_DB And Simile Exhibit experimented with a dynamic UI for filtering / faceting tabular data - http://www.simile-widgets.org/exhibit/
The witheve.com stuff (and the underlying "differential dataflow") is also interesting as a model for derived data which updates itself. I'm keeping an eye on that project too.
As far as your site goes (I just took a brief glance), if you haven't seen it already, you might find some interesting ideas in the sieuferd project:
http://people.csail.mit.edu/ebakke/sieuferd/index.html
https://www.youtube.com/watch?v=MCVj5RZOqwY
Although my goal is to use it to understand how we can write software better.
I wonder if a kind of hybrid programming would be possible which switches between this dataflow-like functionality for parts and more traditional ('large blocks of text'-based) techniques for other parts.
I was working on a simple framework a while ago where the highest-level organizational structure was a 'domain' and these domains would connect to one another via 'converters'. I think the dataflow format would work really well for defining and linking up domains, and small functions that do things like filtering would work well within converters—but then maybe within particular domains it's somewhat of a free-for-all again (i.e. you use traditional programming techniques). Just thought I'd share the idea on the off chance that it sparks something for ya—I'm not really doing anything with that project at the moment.
I'm also curious why you prefer the tabular format over something graph-based. Is it just that it's more straightforward for people to lay things out/organize?
Deleted Comment
Dead Comment
Web editor and web spreadsheets aren't exactly the same field, but that seems close enough for a trademark collision.
https://news.ycombinator.com/item?id=15543362
1. Legacy: newer versions will always need to support VB6 and activeX and all that garbage - that's quite a big drag.
2. Inability to track changes easily. (Just move a table one row down, and it becomes impossible to compare the 2 versions) which causes what people call "spreadsheet risk"
That makes Excel "somewhat" vulnerable to asymmetric marketing attacks. It is in fact surprising that this hasn't happened yet. I think one of the big reasons is that most SV people don't use much Excel (not like we financial guys do)
I'm just hoping that Mike Bostock and the 2 other guys as Observable HQ are going to nail it. I'd much rather have a totally hackable front end that does the DAG for me, than a cloud-based document-editing-with-formulae...
There is no good way to share data between spreadsheets (linked spreadsheets are a nightmare)
There is no good way to link a word or ppt document to a spreadsheet (an extremely common use case, think reports, client presentations). Linked tables are unstable (crash and unstable rendering) and you have to do all sort of hacks to ensure the links are not screwed up if you ever modify one while the other is closed.
Excel should move away from a single grid approach per sheet (Apple’s approach makes a lot of sense).
What is depressing is that outside of ensuring it runs on new platforms, Microsoft pretty much stopped development of new major features 10 years ago. If you look at the past Excel’s what’s new, these are mostly cosmetic/minor/maintenance changes.
Otherwise it's just a niche product, which is still valid, but not really a next-gen spreadsheet. Coda seems like it would be great project management/CRM tool rather than a spreadsheet app.
See also:
https://airtable.com/
https://fieldbook.com/
https://quip.com/
Nevertheless, this Coda looks quite interesting.
0: https://panic.com/coda/
It has over 100 reviews on the Apple store for their mobile version and their desktop version has hundreds of reviews on independent download websites and multiple blog posts by different developers.
Writing "Coda" on Google leads to Panic's software on the first page. So does "Coda Software", "Coda App", "Coda Download" and "Coda Review".
Coda.io has been around since 19th of this month. You can get to it (well, this article on The Verge) by writing "Coda Software" on Google, but it is on page 3.
Surely naming it Coda was a mistake. It leads to confusion and hurts their branding.