4 ms·
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
by csours 10y ago
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.
- josephcooney 10y agoAgree. 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-imagination-or-abdication-of-design-responsibility.aspx https://jcooney.net/post/2008/06/08/Data-grids-lack-of-imagi...
- csours 10y agoYup, 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 http://www.snopes.com/weddings/newlywed/secret.asp
- flukus 10y agoI 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.
- david927 10y agoError 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.
- deleted 10y ago[deleted]
- csours 10y ago> 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'.