(no title)
richardkmichael | 4 years ago
I've just gone though your `example.csv`, and have this feedback:
- the (row) "Remove" action seemed like data column to me, because it is placed adjacent to the data. I would separate the actions completely from the data. I'd probably avoid the "X" within the column, as again, it looks like data. Admittedly, users probably know the content of the CSV they are uploading, so this might not be too big a concern. But the UX/semantics of styling the "actions" the same as "data" seems like it will lead to confusion. At the moment, the only action is "Remove", so I might drop the Remove "column", just put a button labelled "Remove"; after all, the "X" is already a "button" (as a link). That said, bulk actions a chore to implement and so I suspect getting this working nicely will probably be a big draw for your target market. Whether it's checkbox boxes with a single select drop down to apply an "action", or a select drop down on each row (painful UX, I'd think). Hopefully you already have a revision on your roadmap.
- The wording "File has 1 invalid rows. Please resolve the errors before uploading." is occurring after the user has already uploaded the CSV, so I think it should be adjusted. At this point in the workflow, I'd probably stop referring to "File" (the user is only concerned with the data at this point). I'd suggest more succinct wording, perhaps: "1 invalid row must be resolve before continuing."; or "...before you may continue.", if you prefer using the second person in the app messages.
- The full screen modal for a small number of rows forces the user to hunt for the buttons and mouse a far distance. I realize for most data, the modal is likely to be the entire screen (and multi-page), but nevertheless, I would probably make the modal shrink to the data. As a consideration for your market: I've written apps which use CSV for only ~25 rows, and I would still consider using this because the user interaction for sanity and clean-up was still code I would've prefer to skip writing.
- I would increase the number of rows permitted at the lower tiers. Maybe you are analyzing the imports and have a lot of information about the pricing breakpoints and segmentation, but my hunch would be that fewer imports with more rows might entice people. I can think of apps which might have only 5 or 10 imports per month, but need more than 50K rows per import, but it's a pretty big jump to Basic, so you might miss those customers.
- I would make the corrected/edited CSV available for download (by the customer) at the end of the import. If anyone needs to re-import, it will surely be annoying to re-correct it during import; or even to remember all the corrections they made during import and go back and correct their original spreadsheet (or other data source).
- Would be nice to see PostgreSQL on your destination roadmap :-)
Again, this seems like a really good idea to me. I wish you success!
spreadr|4 years ago
I am adding all of the 6 points that you have raised in our roadmap to be developed in the near term.
richardkmichael|4 years ago
I just thought of one more comment: have you tested the UI/UX when there are enough columns so that the modal must scroll? In that case, the actions adjacent to the data will also probably not work very well; i.e., I would not make the user horizontal scroll to access the actions. Meaning, I think you'll definitely want the actions separated from the data, so that the data scrolls while the actions remain fixed position.
Sorry I don't have more time to experiment with actual data types. I'm sure you can do a lot here too. I once dealt with an app that imported a CSV with geographic coords [lat,long]. During import validation, we showed a map to allow for correction / precise placement. That kind of richness would be great. To be validated with your market, of course.
Good luck!