hasadna / accessible-graphs

The Accessible Graphs project
GNU Affero General Public License v3.0
17 stars 6 forks source link

Creating Google Docs and Excel add-ons #24

Open oferb opened 4 years ago

oferb commented 4 years ago

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.

S0AndS0 commented 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...

... 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.

oferb commented 4 years ago

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.

S0AndS0 commented 4 years ago

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.

oferb commented 4 years ago

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:

  1. Write something like ACCESSIBLE_GRAPH(A2:A30) to view cells A2 to A30.
  2. That would generate a HYPERLINK pointing to sensoryinterface.com with the data in the URL.
  3. They open that link, which opens in the browser, and they can view the graph in an accessible way.

I don't see how we can have an easy experience using the File API, as:

  1. It requires an additional step of opening the file
  2. They still need to choose which cells they want to view, in which sheet, and it's unclear how they do that since we don't have a UI for that.
S0AndS0 commented 4 years ago

For Excel in particular there may be a built-in text-2-speech options...

https://support.office.com/en-us/article/Converting-text-to-speech-in-Excel-3f2ca8c0-90e2-4391-8e69-573832ea7300

... 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.

oferb commented 4 years ago

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.

S0AndS0 commented 4 years ago

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...

https://support.office.com/en-us/article/Save-all-or-part-of-a-workbook-to-a-static-Web-page-5AD26DEE-8739-4D80-B9D9-CF0530AB1968

... 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;

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.

S0AndS0 commented 4 years ago

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

Attribution

oferb commented 4 years ago

So user flow is:

  1. In Excel, Save As and select HTML as the output format
  2. In browser, open file via website or extension

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.

S0AndS0 commented 4 years ago

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.