>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.
Range names come at a price. Try copying a sheet into another workbook that has conflicting names. Or copy-pasting your table in the same sheet to do something slightly different.
I use excel a lot and I found that the only convincing use case for range names is if you need to refer to ranges from VBA, then this is the only way for the code to find its way on a spreadsheet even if someone inserts some rows and columns. Otherwise range names create more problems than they solve.
We are designing nothing, excel allows you to create variables with names assured unique in a namespace(A single spreadsheet). You could use it any way you like.
But if you are copying a formula that has things like variable names into a new sheet, you have to understand that pasting the formula with its variables pointing to nothing is like inducing a NullPointerException.
//B1 is renamed as first
//B2 is renamed as second
_______________
f(x)| C3 = first * second
_______________
A | B | C | D
_______________
1|___|_2_|___|__
2|___|_3_|___|__
3|___|___|___|__
4| | | |
vs
_______________
f(x)| C3 = B1 * B2
_______________
A | B | C | D
_______________
1|___|_2_|___|__
2|___|_3_|___|__
3|___|___|___|__
4| | | |
It barely matters if you copy paste the first one or second one into a new sheet. C3 will be pointing to null. If anything its easy to trouble shoot former because you can chose any cell in the spreadsheet and call it 'first', chose another and call it 'second'- Compared to say to having fixed cells B1 for first and B2 for last.
I didn't know excel allowed you to assign names to cells. Nobody taught me so. Of course I'd find it useful if the UI for that feature was easy to reach.
In programming the UI to assign names is very intuitive and right there in your face. You place the name next to the thing you want to have named. Done.
In Excel it is both, very accessible and not obvious at the same time.
At the top left corner of the sheet, just to the left of the formula bar, there is a textbox that displays the cell Number (eg. A1). Simply click on that and enter a name for that cell.
But the fact that people routinely do create labels for cells, and have columns with headers is also a hint that the people are willing to name things.
So it does come down to a UI issue after all: the right UI for getting users to name things is one they want to use for labels/headers.
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.
An important thing about cell references that makes them almost but not quite entirely unlike pointers is that they can be relative, absolute, or mixed.
Aren’t named cells/columns a category of their own? They’re not relative nor absolute, but resolved by the name binding that exists at evaluation time.
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.
that is exactly the reason why developers dont get the naming/not naming conundrum, A2 is a better name than itemCount and a better way to reference when dealing with hundreds if not thousands of variables, the advancement would be actually the ability to autoname vars and then allow users to rewrite them in case of inaccuracy, and also still allow for coordinate mapping bringing the best of both worlds
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.
Basically a sheet is a blank canvas on which you can drop tables or charts or other things.
You can see on the left the list of the sheets, and within the list of the objects they contain.
It has all sorts of benefits over Excel's one grid approach:
- You can display two tables, one above the other, and the first can overflow without pushing the bottom table off-screen
- You can display two tables, one above the other, and the columns do not have to be aligned / have the same width (I am sure everyone using excel ran into this problem), same thing for row height for side by side tables.
- If these tables contain data, it allows to separate logically data on the same sheet instead of relying on empty columns as a convention. You can then filter the two tables independently but have both always visible on the same sheet
- Makes more sense for positioning charts vs tables
- Preserves the full flexibility of a generic excel grid, i.e. one object could be a table containing data, the other could be some complex calculation, etc. Excel has some ways to present data in a similar way but at this stage it is just summary data, not a generic spreadsheet
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.
Yeah. I've tried messing with those too. No luck. Calc seems to crap out at about 10 MB. Anything over 5 MB is prone to freezing. Especially if you use AutoFilter.
The first time I encountered the file-repair prompt, it was total déjà vu to the DOS era ;)
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.
How is saying Row 'C' , Column '5' any different than saying Row '3', Column '5'. These are just ways of pointing to a cell with regards to its position from the cell at the top left column & top left row in the spreadsheet.
> How is saying Row 'C' , Column '5' any different than saying Row '3', Column '5'.
Well an obvious reason is R1C1 clearly spells out which is the row and which is the column and further makes it very clear when you're using absolute addressing (RYCX) or relative (R[±Y]C[±X]).
But that's not what I'm talking about in the previous comment. What I'm saying is that A1 is implicitly relative: open excel or google spreadsheet, type "=A1" in a cell, then copy/paste it to an other cell, it won't be "=A1" anymore it'll be offset by the difference between the source and destination cell and thus may have become e.g. "=C8". To fix that you have to "lock in" the dimensions by prefixing them with $ e.g. $A$1 does not move around at all, $A1 does not move in the column but may move in the row and A$1 does not move in the row but may move in the column. R1C1 does not have that issue, as a user you spell out explicitly whether you want absolute or relative addressing (in either dimension) and the software keeps thing exactly as specified.
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.
Point being that if he actually knew Excel then he'd also know that Excel supports named columns just fine. With statement like that, he presents himself as ignorant of the basic features of their main competitor, which is not exactly great way to win the power-users of mentioned competitor.
I'd be inclined to attribute that to messaging more than understanding. I hear what you're saying, but a fully qualified statement that captures all of the details both loses a lot of impact and isn't the kind of thing that would appear in the Verge.
Exactly. It's the same problem as communication of science to the general public: if you make it 100% accurate, most people either won't understand or won't care. After enough customer interviews you start to get a sense of what gets people nodding their heads, and that's what makes it into these articles. Assuming that statements like this reflect a company's complete understanding of the problem just isn't fair.
I don't think it's a question of whether it supports it or not, it's that Coda does it by default and has built the rest of the tool around that feature.
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.
I can't speak for ryanmarsh, but I have a few thoughts.
* Excel really has two major ways of performing computations on data - formulas within the grid and actions upon the grid. Despite the utility of the formula based dataflow model, there are too many operations that have to be performed as one-shot operations via commands (or scripted via VBA). Having formula based approaches for sorting, dividing into bins, etc. would be very useful.
* It'd be nice if Excel cells could contain values other than scalars. (Arrays, tuples, lists, maps, matrices, complex numbers, etc.)
* VBA can be used to define custom functions, but there's a lot of marshalling overhead going to VBA and the programming model is slightly different. It'd be nice to fix both of those issues.
* There's no way to locally bind names within a cell formula, so often subexpressions have to be duplicated. (And I believe they're doubly evaluated too.)
Shameless plug: I'm a founder of Alphasheets, a company seeking to solve problems like these! I couldn't resist replying after seeing these comments.
We make a collaborative (Google Sheets style) spreadsheet with Python and R running in the sheet. You can define functions, plot using ggplot, embed numpy dataframes, matrices and all that good stuff. We don't let people use macros, all the code runs in cells because we think macros are too brittle. You can check out the website at http://alphasheets.com .
We're seeing that many enterprises (for example, in finance) that have Excel power users are moving to Python because of limitations like these, and are running into adoption issues because people like spreadsheets so much. That's generally where we come in and provide a bridge from the Excel world to Python through a more friendly frontend.
We're also seeing that Alphasheets can help a lot with shortening feedback cycles on more sophisticated data analyses- Excel is the most popular self-serve analytics tool out there, but doesn't cover cases where you need Python/R/fresh data.
This is very nice. Problem is, there are sooo many more features in Excel you'll have to copy to get me to move. If you ask "which ones" I'll say "all of them". I'm a power user. I build huge dashboards and analytical tools in Excel. The thing I hate most is that all my work goes into a file that I have to pray works on the other persons computer.
The product is great. But you guys will need to launch a fully feature rich desktop client, which can sync with the cloud.
Else its the same thing mentioned in the previous comments. You would build a web app with 5% the features of excel, and the moment somebody reaches use case that can't be solved with your tool, they will have to switch to excel. If they have switch every second time they use your product. They might as well do all their work in Excel to begin with.
You have to be feature compliant with excel and you can't do that on a web app alone.
* see a modern replacement for VBA, dare I say using JS
* be able to share a document that won't break when someone opens it on their computer (even if its using all the excel bells and whistles including external data sources and plugins). Google Sheets by contrast, is just a link.
* be able to use all the amazing features via the web and/or an app
Let's call Google Sheets "modern" because it can be used from an app or any web browser. I can share a Google Sheet much easier than an Excel file using all the bells and whistles.
The problem is, Excel has a ton of very powerful features. Many of which Google Sheets doesn't provide. Something like VBA would be nice. I'm aware you can write JS plugins for Google Sheets but the experience is no where near as good. Pivot tables in Excel still smoke Google Sheets.
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.
For people who need this kind of thing, FileMaker can be an extremely effective solution. The article doesn’t really explain what is differentiating about Coda.
I was wondering how Coda differed from Quip, et al, but this article makes me pretty excited about it. As someone who used to spend all day in Excel and VBA, there's definitely room for a new "light coding" platform.
The general idea of Coda, unifying document text and calcultion code is very attractive. Jupyter notebooks do something similar in a different Domain. Yet the result in Coda looks much more sleek and polished than Jupyters cells.
A smaller example of programs that go into the same direction would be Soulver (on OSX), NaSc (on Linux) or CalcNote (on Android). Theese three of course have a much smaller feature set and different goals than Coda.
The main culprit I see with Coda is the reliance on one closed source software product maintained by a commercial company with a closed source file format. I think Google (Reader) should have taught us something about relying on software that you don't even remotely control or understand.
Jupyters next iteration, JupyterLab, is giving users more flexibility in terms of screen estate layout, but it will look even more technical instead of more elegant and integrated. Maybe inspiration for further iterations can be drawn from Coda (and good old MathCAD) for a more integrated future version.
Until then staying with Emacs/Spacemacs and org-mode/org-babel gives you the flexibility for output in a lot of different high quality formats AND the guarantee that your carefully crafted documents will be accessible decades in the future.
I think the next successful spreadsheet might be compatible with xlsx and support a handful of fundamental clean data / database concepts. Things like enforcing keys, tabular structure, NAs instead of blank fields, types. These are simple enough you can teach them to average white collar workers and powerful enough that they would dramatically improve data quality.
Neat for some use cases, however the fact that its only online will cause issues for some folks.
People process a lot of data in excel - sensitive, private data. Putting that data into the cloud with a startup (regardless of pedigree) will be a bit too much risk for some.
”We haven’t had an application creation tool like this since HyperCard. I think we’re going to see lots and lots of good experiments.”
”a collaborative document editor that combines a word processor and a spreadsheet”
I get the impression this is more like another attempt to do what Opendoc, the various ‘Works’ products of the ‘90s, OLE, Ashton-Tate’s Framework, etc. promised than a spreadsheet.
Question then is what would make this succeed at doing that where those products failed. That many people think they want something like it isn’t enough. Has the time for this kind of product come, is ‘collaborative’ the killer feature, or what?
“While Excel 5 was being designed, Lotus had shipped a “new paradigm” spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it. […] Of course, Improv is now a footnote in history. […] Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they asked people, they would discover that making lists was so much more common than multi-dimensional financial models, and in Improv, making lists was a downright chore, if not impossible.”
Disclosure: Spolsky worked on Excel for several years as a product manager, and is biased.
The other reason that Microsoft Office tools succeeded is that Microsoft was very good at all of the extra-technical stuff – business deals, marketing, software bundling, legal fights, etc., some of it quite underhanded/anticompetitive.
Lotus made Improv for NeXTSTEP originally, so there was a niche platform problem for the first 2 years, and after it had been ported to Windows Improv was competing against Lotus’s own previous spreadsheet program 1-2-3, creating consumer confusion and confusion within other parts of the Lotus organization.
But the main reason is probably just inertia. Once people have learned one tool that seems to work well enough for their needs, getting them to adopt something else (especially if it isn’t conceptually identical) is twice as hard.
He probably is biased - but it seems they were building "spreadsheet for advanced users" when most people who use a spreadsheet are not or will ever be advanced users.
Apart from “home” use, Excel users usually lack functionality and tend to build an unmaintainable mess in their spreadsheets. Quarter of my ‘system integration’ work came from Excel users trying to automate and/or formalize what they created in there for years. Sadly, these types of businesses take hell of efforts to convert to good information systems; high failure rates are normal there. For me, Excel is a heroin of a business world. It drags you from reality and breaks you when you’re trying to get back into it.
There aren’t enough trained programmers in the world to do in code what all Excel users get done with spreadsheets. Let alone programmers who understand the business of the company they work for.
The thing is, with Excel the programming is gradual, you first just add some formulas, followed by conditional formatting, small macros, until eventually jumping into full VBA.
Alternatives, including Access, require good programming knowledge from day one.
But I still fundamentally agree with this approach. Perhaps not all users, but most users should be given a path toward more programming based approach to modelling.
I think lighswitch was stillborn when it wasn't distributed as part of office (irrespective of its merits, haven't tried it myself). Asking IT departments to deploy it was bound to fail. It needs to be available at the fingertips of excel users, like VBA is, always there, running with Excel, and you know it is available to everyone else so anything you do will run without having to install anything on their machine.
Powerapps look amazing to be honest. I actually would like to use that and the BI integration, but unfortunately I don't have enough reason to spend money on it. The small organising that I do need ends up in Airtable instead, but that's not even close. (I miss proper graphing features)
>>Excel users usually lack functionality and tend to build an unmaintainable mess in their spreadsheets
Excel needs to be viewed as a programming tool. And a good programming tool is something that gives as much control to the user.
There are many Excel tutorials online and on Youtube that try to teach you how you can do MVC with Excel. That is separate presentation from data, and its control.
Yet there is an enormous amount of important money-work being done by Excel users who are far more advanced than me, building what are essentially computer programs / databases.
So even if that market has fewer users then Excel itself, there an still be money to be made from people who could use a tool that is better behaved than a consumer spreadsheet but easier to use (for domain specialists) than a general programming environment.
I accept the analogy here between Excel and C, but I think the moral is the opposite.
Excel is very likely a good choice for a lot of people doing complicated stuff with it -- in spite of its problems. It's just that some of those people might also want a niche product that replaces it for some particular purpose. Not an entirely new, general purpose tool.
The problem with using a tool with say 5% of the features excel provides is you sooner or later run into some feature you need, but is absent in the niche tool. You can't exactly split your work between two tools now. So it just makes sense to use the tool with the super set of all the features, even if you don't use all those features all the time.
The right comparison for this would be using some thing like awk/sed compared to using Perl.
I used to work in support for Lotus in the UK. A few people used Improv, but if IIRC once you got beyond a few dimensions the file sizes became huge.
The other alleged reason for Office beating our SmartSuite is the way new Windows or MS Dos releases always seemed to accidentally break Ami Pro or 1-2-3.
Maybe improv was just ahead of it’s time. It wouldn’t be the first time we see a product fail only to have a similar one years later become a success. I bet there are more people using excel for complex stuff now, they might as well find a niche.
Yes. Kind of like saying that you could replace a general programming language with FoxPro because all you ever need to do is database related code. As a programmer, even if you only deal with database, you kind of like to have full flexibility to do anything you want and not be cornered in a specific use case and fight against the product if you want to do things slightly differently. Users think the same way, even if it means more opportunities to shoot oneself in the foot.
The biggest reason why lists matter so much is because. Most data structure use cases in everyday life are lists, or lists of lists(Tables). Of course you have graphs and trees. But for all practical purposes, most problems there are, are either lists or tables. Excel will benefit, if they add optional tree and graph interfaces. Like you get an option to build a graph of how your business things are connected and help you figure the shortest steps to a solution etc.
And yes if you want to build a Microsoft Excel killer. Please build a thick client desktop application which is as feature rich as a Excel and give it away for free. Charge for the cloud usage. Anything less isn't going to cut it.
Excel is just way ahead of anything that is out there. The only competing product I've seen is Libreoffice Calc. But even that has a long way to go.
Also, you live in a 3D world, hence any non-cognitively overloading "work surface" has to be -1 dim, so 2D, hence List or ListOfLists (spreadsheet). Anything else will require brainpower you could be using for something else instead! (like solving the actual problem, not masturbating with the tools...)
Other alternatives are Trees, which are also "lists of lists" but without the size constraints (Graphs "look 2D" but easily grow multi-dimensional information-wise). But trees have a big problem: they easily grow bigger than the screen, so you expand/collapse them, so you always end up with hidden information that you can overlook - hence they are really bad for sloppy people (I know it from first hand experience... if I'm not careful I can really forget that whole sections or Wrkflowy trees or Org-mode documents I work with even exits!)
Now combining list & lists-of-lists & trees & formatted text could work, if they manage to not informationally overload the user.
But I'm 99% sure that any tool more complex than matrixes and trees as information shape will not take on wide scale, until we manage to couple it with some superhuman-Clippy AI-assistant that almost reads your mind. We're stupid monkeys and it's only so much our brains can handle...
Thanks. It’s interesting but even that solves a very specific use of Excel. It will become painful if you need to cross reference different periods, etc. I sort of built a similar calculation engine for work that works in a similar way, but it is a solution taylored to a very specific problem. Finance depart who would be the primary user for that would still need Excel on the side.
I'm going to stick with Excel for the row/column grouping feature. This seemingly minor feature enables multiple level of abstractions so different audiences can understand the spreadsheet in different views. As much as I want to move my team to Google Sheet or any other major competitors for easy collaboration, I simply can't.
Would be interesting if cells of groups of cells in a spreadsheet could show a subset of the UI of another graphical program on the system. If it could allow user interaction with that graphical program then even better. That could allow users to build a dashboard of their running graphical software. Has this been tried before?
Yes, on Windows this technology is called OLE (Object Linking and Embedding). It allows embedding (parts) of other applications' documents in a document. Nowadays only a few programs besides the MS Office suite provide OLE capability.
For example, you can embed a complete Word document inside an Excel cell by clicking: Insert -> Object -> Microsoft Word Document. By double clicking this object, the Word UI opens up inside Excel.
I've begun to use the beta and see a lot of value.
One point of concern (and PSA): After creating a document, my browser blocked a CoinHive miner. As far as I know, there isn't a "best practice" pattern for passively mining, but personally, I like to opt-in to this sort of thing.
Distributedly consistent spreadsheets maybe? Make inner mechanics of a complex sheet easier to tackle? Add persistence and database capabilities that blend in?
i suspect more fluff than substance since this has been in the media all week with tons of fluffy articles about how much awesome it is. please prove me wrong
CSV is hell. Some idiot somewhere decided that Comma Separated Values in certain locales should be based on semicolons (who would have thought files would be shared across country borders!?), so when we open CSV files that are actually comma separated all the information is in the first cell (until a semicolon appears).
To get comma separated CSVs to show properly in Excel we have to mess around with OS language settings. CSV as a format should have died years ago, it's a shame so many apps/services only export CSV files. Many developers (mainly US/UK based) are probably not aware of how much of a headache they inflict on people in other countries by using CSV files.
Actually you can change the extension from .csv (that Excel believes it can recognize) to something else and open it, the "import wizard" will let you choose the "separating character" and other settings that are very useful when importing Comma (or other character) separated values (such as forcing the "data type" by column).
A good idea, however is to use TSV (TAB separated values) that can be usually copy pasted directly, it still remains in many cases the "feature" that Excel has to auto-identify data types, creating a mess with a number of pieces of data (such as a columen with Hex values, half of which will be "text" and the other half "numbers").
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