Hacker News new | comments | show | ask | jobs | submit login

Anytime I see something that looks like Excel on the web, I cringe.

Unless you are Microsoft or Google and you are putting spreadsheets on a website (SoW), you are almost certainly doing something wrong.

---

Case 1: A co-worker (or yourself) previously wrote an excel-based app and now it's time to put it on the web for wider distribution. You implement the app with a custom gridview/spreadsheet.

Error in Case 1: The UI was copied, but what is almost always needed is an input wizard with validations and workflow along with a reporting backend.

---

Case 2: You have a database that you need to share in a human readable format.

Error in Case 2: Implement export functionality instead, you will never be able to implement all the features of Excel, and at some point someone will need that feature.

---

Case 3: You have a very small and well defined case that actually calls for SoW!

Error in Case 3: Your very small SoW app will grow and grow and strangle you.

---

Case 4: You want to challenge the stranglehold of Google Sheets and MS Office 365.

Error in Case 4: There is no error here, only madness.




Error in Case 4: There is no error here, only madness.

Then give me madness. The problem is that spreadsheets are one of the most natural interfaces for data that we humans have, and even with Microsoft and Google's efforts included, current spreadsheets on a website (SoW) suck.

So let's say the y-axis is importance of function and the x-axis is compelling implementation --> voila! Right there, plotted on the graph you can see that this is something that needs to be worked on.

I understand your reasoning: you've created a spreadsheet-styled labeled grid in no time and you're pumping your fist, only to find out later that it this is way less than 1% of the effort you will eventually have to dole out to make a basic, respectable spreadsheet. The landscape is littered with 1% efforts that look good until you start working with it.

My point, though, is that this area is too important to not try harder, to not see more true attempts.


> spreadsheets are one of the most natural interfaces for data that we humans have

Spreadsheets are natural for data, but not for humans. Spreadsheets are excellent for prototyping and data munging; and spreadsheet prototype apps are even fine for personal or small team use.

When you get medium team size or multiple small teams that spreadsheets break down.

Part of that breakdown is in distribution - which SoW solves.

But another part of that breakdown is in not understanding the implicit rules of the spreadsheet app - another team or person will put some garbage in a cell and break the 'app'.


Spreadsheets are the most intuitive programming environment known to man. Every time you reach for Excel to mung your data, that's opening a repl. The only problem is that Google and Microsoft don't care enough to make them powerful enough to do general purpose computation with, fast enough to build large systems with, versionable enough to enable large teams to use them.


> Spreadsheets are the most intuitive programming environment known to man. Every time you reach for Excel to mung your data, that's opening a repl.

I absolutely agree - REPLs are excellent for prototyping and exploring data and ideas, and spreadsheets are excellent in that role.

Allow me to ask you this then: when was the last time you shipped prototype code? Unless you live dangerously, you don't ship prototype code!

> The only problem is that Google and Microsoft don't care enough to make them powerful enough to do general purpose computation with, fast enough to build large systems with, versionable enough to enable large teams to use them.

I would counter that a more important problem is "productionalizing" spreadsheets - all of the fiddly things you do to ensure inputs are in the right format, etc, etc, along with testing, securing, and deploying code.


You might check out Airtable. They do a good job of this.


So the only reason it's not natural for humans is that current implementations of spreadsheets have issues with implicit rules?

I don't think that's a failure of the model but merely of the implementation. We can fix that. The model is right.


We solve the problems of implicit rules by adding UI and UX so that the rules become explicit.

Anything that solves the problem of implicit rules in spreadsheets is a UI or UX solution.

The question is, what is the best UI or UX solution?

My position is that the best UX is not a spreadsheet. To your point, it is possible that there is an acceptable UI or UX based on spreadsheets.

The next question would be, how much more difficult is it to create human driven spreadsheets than to create a classic UX solution (something like an input wizard)?


There are projects that try to get into that gap, for example have a look at https://www.ipushpull.com


Agree. Here is a rant from me expressing the same sentiment from a while ago https://jcooney.net/post/2008/06/08/Data-grids-lack-of-imagi...


Yup, you see a very similar pattern with prototype or MVP code.

People get fixated on the code or UI in front of them and they don't think about the actual use cases.

http://www.snopes.com/weddings/newlywed/secret.asp


I agree in general, datagrids usually mean "we have absolutely no idea what our users workflows are", but I'm not sure the credit risk example is a good one. If the credit risk is one of dozens of fields on a generic client edit table then it's awful. If it's a much more specific "adjust credit risk" form with relevant information to that specific workflow then it's fine.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: