Inferior to a native app. Navigating it with the keyboard is clunky, the UI is never as crisp and responsive, it's harder to save and open files... the list goes on
Indeed. In addition to the UI issues, there's no way this product can be "the fastest spreadsheet" when it's browser-based. By definition it runs at least ten times slower than native apps will.
Is it true? Google sheets is great, google docs is great, and hyperlinks! How much native app fast UX is due to using local state on disk? The future is not on local disk!
Google has the benefit of having all of Google drive around it
But even then, the benchmark is Excel. Nearly every Excel user is saving files to disk. Companies like to own data in a shared drive on a network. Maybe making networked drives better is another problem that needs solving, but I don't think spreadsheet applications should disregard that and just hope everyone moves to online. At a minimum you should give users a choice (which Excel/Office does, by the way)
And we still haven't talked about navigating the UI with the keyboard. Limiting power users to online-only is like telling vim users they have to use Notepad++. Sure, they can do everything they could in vim, but it's overall objectively worse
That's certainly true among a subset of users who demand Excel power features, but it is not a universal benchmark. People who more highly value collaboration might prefer Google Sheets. There are tons of users and use cases where the choice of local storage is irrelevant or even a drawback.
The benefit of files is that they are a consistent, application-independent abstraction. You can copy, move, rename, backup, version, and generally organize them however you want, restrict or grant access, without being constrained by what the respective application supports. Importantly, you can organize files from different applications together without those applications having to know anything about each other. Hyperlinks are no substitute for the object-like, independent nature of files.
Applications that are not based on files create their own little separate universe, or rather island, that isn’t really interoperable.
> files are consistent and application-independent
I see diverse, inhomogenous state schemas that are deeply coupled to the originating application (internal data structures serialized to disk!) and have arbitrary legacy structural constraints ("document") as well as seams between application silos
I sense a trap, but i'll bite – APIs and schemas and other logical data models can be remixed, at least in principle. Physical data models (i.e. coupled to storage layout) are too low level to be useful, all you can do is load them back into into their originating app.
Ok, you're right – i don't think a smooth transition is possible in the office market – but I also don't think you can disrupt Office from within. Example: the thing that disrupted the New York Times was not a better newspaper, rather Facebook
I agree! Which is why I'm not building the next Excel, but rather something different which offers (or "will offer") ~feature parity with Excel spreadsheets but approaches knowledge work and document authoring from an entirely new angle
Microsoft teams has the option to open all shared files in the browser so you can have multiple "teams" Microsoft files open at once. This is the direction spreadsheets are going.
I agree it feels clunky to me who grew up on excel the application. I memorized a few dozen keyboard shortcuts that are all broken in the "teams collaboration browser spreadsheet" sigh.
In Teams you can not work on a Excel Sheet shared in a chat. You have to share it in a Team .. you have to ask the IT to create a Team for you first .. great.
