Open oferb opened 4 years ago
Replacing the URL search parameters with either browser sessionStorage
or localStorage
seems like a better idea to me, better performance and more friendly for privacy. I'm not a big user of Excel or GDocs, but I certainly can comprehend why this would be a popular feature. Here's some documentation I could find with a bit of searching...
https://developers.google.com/gsuite/add-ons/editors/docs/quickstart/translate
https://stackoverflow.com/questions/8238407/how-to-parse-excel-file-in-javascript-html5
... seems to be relatively straightforward for Google Docs, and for Excel yet more external libraries. Probably would be best to look into licensing restrictions/conflicts prior to incorporating Excel parsing. But over all this seems like a really good idea to explore further.
Thanks! If not URL params, how would we get the data from Excel/GDocs into the page? We could send it as a POST request to the server with a unique ID, and then client uses that unique ID to fetch it back, so that way it never shows up in the URL, BUT it means we need to process and store it on the server, which is not something we really want to do.
Sending data to server not within the same domain is difficult, for good reasons, so it's probably best to avoid using methods that circumvent these restrictions. Really there's no need for a server to be involved beyond making the markup and scripts available, because all the necessary features, so far, can be done client side.
Excel files could be read into a browser via File API, parsed within the browser, and any states that need saved could go into individual browser's localStorage
or sessionStorage
. No need to involve a second page load, no need to send POST
requests, and better still is that parsed data will remain on the client side. Here's one guide I could find on the File API...
https://www.html5rocks.com/en/tutorials/file/dndfiles/
... And for Google Docs, it'll likely require either a browser extension or exploring what API they've available for JavaScript.
I think from a user's standpoint, they're now using Excel, and within Excel, they want to view a certain range of cells. I think the best thing would be to have them:
I don't see how we can have an easy experience using the File API, as:
For Excel in particular there may be a built-in text-2-speech options...
... I'm more than a little apposed to sending data from an Excel document to a remote server; there are to many ways that can go wrong.
Reading some hints over on StackOverflow -- Convert Excel file to HTML, it may be possible to have clients pre-convert by saving as HTML. If this is possible then it solves much on not having a UI, and data yet again can remain on the device that owns it.
Let's assume this direction is technically possible. Can you describe the user flow?
With the link option, it's just following a link. I'm trying to see if what you're describing adds any complexity on the user.
Keep in mind that our target population is everyone, not only tech-savvy users.
For Excel the client would need likely need to Save As
and select HTML as the output format. Importing could be done via web-served JavaScript or via browser extension. Here's more information I could find on what this project would then be expected to parse...
... I think the best option is via browser extension, because this would allow for many more features and far fewer privacy related questions from being raised.
Outline would be;
Export Excel from Office as HTML
Open browser and import
Select cells or sheets to be parsed
That all stated it's probably a good idea to explore built-in options that Excel may already have, it could be that Office/Excel is capable of doing most of what be needed, in which case focusing on Google Doc Sheets could be a more prudent use of time.
Re-using existing code maybe possible via, tafia/calamine
; "An Excel/OpenDocument Spreadsheets file reader/deserializer, in pure Rust"....
https://github.com/tafia/calamine
... Web Assembly is a target that doesn't seem throw errors, yet...
cargo init .
tee -a Cargo.toml 1>/dev/null <<'EOF'
calamine = "0.16.1"
stdweb = "0.4.20"
wasm-bindgen = "0.2.58"
[lib]
crate-type = ["cdylib", "rlib"]
# [build]
# target = "web"
EOF
cargo build --target=wasm32-unknown-unknown
git add .gitingore Cargo.toml src/main.rs
... The src/main.rs
file is the entry point
Build/Test Commands
Compile and start development server...
cargo web start --target=wasm32-unknown-unknown
Or build with...
cargo build --target=wasm32-unknown-unknown
So user flow is:
What I was thinking of is, Excel add-on would create a link, e.g HYPERLINK
in Excel:
https://support.office.com/en-us/article/hyperlink-function-333c7ce6-c5ae-4164-9c47-7de9b76f577f
User would click and it would open browser, with data passed in url.
If we go on to develop an NVDA add-on, the website that the url points to, could be hosted on localhost, running on a local server.
Another option for Microsoft Excel support would be to utilize the built-in JavaScript API...
https://docs.microsoft.com/en-us/office/dev/add-ins/excel/excel-add-ins-worksheets
... For Google Docs I think it may be best to check the web-page source code that such documents generate and write a browser plug-in to add features.
Creating addons, so that you could automatically create the sensoryinterface.com url from these docs. Url length limits should be enough for most cases. Especially if we somehow encode numbers in binary form, instead of the current string form.
The add-on would work kind of like SUM(), where you mark a set of cells and it sums them, just, instead of sum, it will create a hyperlink to our website with the data in the url.