Comment by crazygringo | Hacker News Reader

Comment by crazygringo | Hacker News Reader

Parent Full thread

I love the idea of finding new and better interfaces for spreadsheets, and I applaud this effort!

That being said, if you want this to be useful for people in general, not just programmers:

- People like WYSIWIG. Markdown and the split-pane view seems to be something only programmers like. So I'd suggest being able to do everything, or mostly everything, directly in the rendered/HTML panel. (Maybe the Markdown panel is for power users only)

- This is great for working with individual calculations, but a lot (most?) of spreadsheet use is about applying formulas to whole rows, columns, and tables of values. I see you support basic tables, but they're a huge pain to encode/format/edit in Markdown, and I don't see any ability to support things like 200 rows x 5 columns and do things like calculate sums and averages

So I think there's a ton of potential here! But I think WYSIWIG and easy tabular data support are going to be key here for broader usage. While the kinds of programmers this seems aimed at now, are already using Jupyter notebooks and Matplotlib for this kind of thing. (Like, when you describe "why did I build this", I don't understand why you didn't just fire up a Google Colab notebook.)

Tables are something I want to tackle and I'd like to do them right because (as you point out) are crucial. I didn't get there yet...

I want to make it such that you can code on the left and then hide everything and share that with non technical folks. That's why I did not use a Colab, creating something interactive with it (and I did that quite a lot in the past) it's a bit of a PITA.

As a well seasoned web developer, when I'm doing front-end, there are always 2 big problems: Data tables and loading indicators (fun way of saying it's hard to tackle lazy loading without a request waterfall).

The second problem has had good attempts in the recent years, but no single web application can beat excel in terms of data tables (while not 100% relevant anymore, I really like the super light introduction here from Joel Spolsky: https://www.youtube.com/watch?v=JxBg4sMusIg )

I highly suggest that you look at both Org mode table formats, one of them almost certainly has much of the UI and features you are targeting.

fwiw:I don't think WYSIWYG is that useful here. It'll by its nature appeal to a crowd that's more technical than the average user. (You won't replace Excel day 1)

There's also the fact that if this is supposed to become more than a design exploration, it might be useful to focus on what this can do that spreadsheets can't - a WYSIWYG editor for spreadsheets is just a spreadsheet.

And I definitely think there's something good here, and that is not a spreadsheet or a colab notebook. It's worth digging into what that might be.

The large tables issue might be solvable with Emacs. Org mode had two table formats, one of which is a veritable spreadsheet. It's all text under the hood, but Emacs (at least with Evil) provides a easy interface to create and populate rows, columns, and cells.

to your first point i think its a good idea to offer both if possible. Like hide the code behind an interface wysiwig-style but give users the option to also edit the code directly if they want to

These are basically block editors. The problem is more, regular users just arnt going to be doing it period.

It's basically a pyramid problem:

1 programmer will program all the things

2 power users will create all the forms from pieces of the programmers documents

999+ will use the output and never care about any of the rest

There's just minimal middle ground, and the only answer is to cater to all three but in Different ways

Reply on news.ycombinator.com