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.
I think this is a great idea. I've had to solve this on almost every web app I've worked on.
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!
However, the "restraint control module," which stores data such as whether seatbelts were in use, how fast the vehicle was going, acceleration information, and airbag deployment, although damaged by fire was recovered and turned over to the NTSB's laboratory to evaluate.
Having an extensive background in *nix and network systems through the 90s and early 2000s, image maintenance is the main reason I have avoided docker until recently (just not having time to investigate). One major reason to pay an OS vendor (e.g. RHEL) is to "outsource" security and systems-integration testing, so that ops people can simply "update" (the entire dep-tree of the distribution). I don't want to bring all that effort in-house, especially if I'm still paying for a vendor service contract. That said, I agree security and deployment can be eased by any form of "container" (in numerous OSes) because ops people can black-box the software while managing resource allocation, etc.
How are people handling container maintenance?
For example, I could imagine modifying SRPM spec files to also build a container (possibly even statically linked binaries inside). Then I can vendor update, and rebuild all the containers I need from SRPM; not much more complicated than `rpmbuild postgressql`, and re-deploy the emitted postgres container.
You can do this today with DWave, Rigetti and Xanadu. I've used D-Wave myself, signing up for their LEAP platform is inexpensive (possibly free for a small amount of use, I'm not sure about their current offering).
There are different implementations of "quantum computing" which are appropriate for different types of problems. Google and Wikipedia will teach you about them, for example quantum annealing vs. universal quantum computing.
If you want to use different versions of Python itself, without installing them as different named binaries or using shell aliasing, etc. Helpful to install Python 2.7, Python 3.x, 3.y, etc. and invoke each as simply `python ...`.
I check as well. However, the airline can/will change the aircraft at their discretion. Last time I didn't find out until I arrived at the gate. If you don't want to fly on the changed aircraft, I'm not sure what recourse you have at that point. Of course, ultimately you can not board, but there may be penalties.
If you had carry-on only, it might not bother them much. If you checked baggage, they need remove it, causing a delay. Although in principle, this would be "just as if" you missed the boarding call, I suspect if you tell them ahead of time (as in: "I'm not boarding this plane."), they'll try to persuade you there will be penalties. I don't know.
There must be fine-print in the contract of carriage, since the ticket ("product") purchase indicates the aircraft.
Perhaps one could verify the aircraft before check-in. If you don't receive a boarding pass, obviously there is no problem whatsoever, you just lose the flight unless you've paid top-dollar for a refundable ticket.
I was going to permanently save my browsering history by running all my browsers through squid. If squid's StorageManager supports it, I'd put page storage in Postgres, then use PG's FTS with a light UI around it.
I work with hypergraphs, where edges have an arbitrary number of nodes. I'm quickly looking through your documentation, Discuss, and GitHub issues/roadmap to try and find out if edges may have more than two nodes.
Yes, I point out AF447 as a perfect and horrific example of a problem which is really HCI (human computer interaction) / UX.
The lack of stall warning meant two different things: "not stalling", and "stalling so extremely it can't be sure, so don't report it"; as you say. I wondered if there should be a different sounding alarm for "can't determine". Or, the pitch of stall alarm could rise, such that pilots could tell "which side of the stall" the plane is on, so that entering stall from one side would side start with a very high pitch or very low pitch. (I'd guess there's a better way..)
So, in this case, it's more subtlety more tragic than you describe, because the pilot did correct the AoA, and nose down, but when he did that, the stall warning resumed (albeit from the extreme other "side" of the interval), confusing him: no alarm, alarm resumes, so he thought he "re-stalled" it and he pulled up again. This kept him mentally "stuck" in the extreme stall. They needed to "pass right through" the stall warning window, and come out the other side. They had sufficient altitude for this to succeed.
Certainly, for Canadians, going to France is very straightforward option.
You only need insurance and proof of finance means to support yourself and/or leave (return home); you can stay 12 months and extend to 24, possible 36 if you're studying too.
The OQO was mentioned elsewhere, I too wanted it for this years ago, along with a Pico projector and virtual/projection keyboard. Now that I've been disappointed by both the new MBP and the price of the current gen Google/Android phones, I've started wondering if I can spend $1000 on a new "phone" and use it for everything (with peripherals left at each site). I briefly investigated this approach just a few days and found Debian noroot and AndromiumOS (see also their related Superbook kickstarter, which did really well -- though personally, I don't want a laptop if I go this route). Quite a bit needs testing, but it seems promising, maybe one generation away still (USB-C/3.1gen2 everything, with power).