Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation and persistance? #194

Open
Denubis opened this issue Oct 30, 2019 · 8 comments
Open

Documentation and persistance? #194

Denubis opened this issue Oct 30, 2019 · 8 comments
Labels
usability usability is important because our users will not be current R users

Comments

@Denubis
Copy link

Denubis commented Oct 30, 2019

I was just helping one of my students deploy this app as part of her workflows and we were running into problems with persistence and loading data into the shiny app. While I got part of the way with looking at the unit tests, it'd be amazing having a minimum working example of:

  1. Persistence of session. Where a user can clean their R environment (simulating a fresh start of their computer) and can pick up coding documents where they left off.
  2. Preloading variables. You mention a pdf->txt workflow as part of your readme. The student had a 100 files she would have liked to have preloaded. Having a minimum example of "And here is how you get to the "Humans doing work" part of the interface quickly would be great. (And then exporting the data automatically when done, for bonus points.)

This application shows quite a lot of promise, and I'll watch it with interest.

@elinw
Copy link
Collaborator

elinw commented Nov 7, 2019

In terms of persistence do you mean? Are you talking about while in Shiny or using the command line functions? Everything is saving all the time so actually I'm not sure what the session would do in a Shiny context.
All you do to load files is put them in the folder and run the import function when setting up the project. After initial set up you have to import one at a time, but I'd have to hear more about the problem you are describing.

I'm not sure what you mean by exporting the data? How often would we do that? As it is we are saving backups every time you save new coding in your document. I think having to click a button to export is probably not a bad idea although I'm willing to hear the case for saying to do something different.

@Denubis
Copy link
Author

Denubis commented Nov 7, 2019

In the Shiny context, there wasn't an obvious way to return to state in a new shiny run. It looks like the project vanished and specific codes applied in the previous session didn't apply.

In the command line context, being able to run an Rscript which does the equivalent of clicking various setup things so that the user is presented with documents ready for coding would be amazing.

I've got a feeling you already do the two prior things, we just couldn't figure out how to achieve them with the present documentation.

In terms of exporting data, the user story could be:

"As a user, when I'm done coding, I close the shiny app and the remainder of my Rscript then automatically goes through all coded documents and exports them into csv and txt automatically"

When the student gives her presentation, I'll link what she's produced here.

@elinw
Copy link
Collaborator

elinw commented Nov 7, 2019

Hm well what it does is save them in a data frame. When you start again it reloads your data frame. If you want to export so you can use in another application, you click the export button.

When you import before starting the shiny app all of the documents in your folder are read in as are any files you have with code definitions or units.

@elinw
Copy link
Collaborator

elinw commented Nov 7, 2019

Also we are definitely thinking about what happens when closing Shiny, which is surprisingly somewhat complex to think about. We first need to delete all the objects from the environment because it's bad practice to leave them there. Then we need to add some kind of message. I guess we could create the zip file or something. But it's not a big deal in R for your student to do write.csv() .... but you would probably want to do it for all the separate data frames. Maybe they could go on tabs in a spreadsheet? It's an interesting thought.

@Denubis
Copy link
Author

Denubis commented Nov 7, 2019

In regards to the saving to data frame, we weren't getting any persistence. Every time we invoked the app from Rstudio, we would have to re-navigate to the project.

Being able to get dataframes out would be amazing. Do you have a worked example of this I/O?

Thinking about this discussion, we're almost certainly invoking the shiny app incorrectly.

@elinw
Copy link
Collaborator

elinw commented Nov 7, 2019

Corrected
https://docs.ropensci.org/qcoder/reference/qcode.html
Actually if you launch from the project folder and use the use_wd=TRUE option you will already be right there. But qcoder is designed so you can use it on many projects at once, so yes every time you have to pick which project you are working on. I guess at some point we could figure out a way to make a list of old projects but the idea is you should be able to start a project from any folder or eventually a shared folder or use a remote source for reading in texts (but we are not there yet).

@elinw elinw added the usability usability is important because our users will not be current R users label Nov 10, 2019
@Denubis
Copy link
Author

Denubis commented Nov 11, 2019

https://github.com/MQ-FOAR705/Sophie-Avard-Proof-of-Concept Is the student's documentation around the thing.

@elinw
Copy link
Collaborator

elinw commented Nov 17, 2019

That is excellent!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
usability usability is important because our users will not be current R users
Projects
None yet
Development

No branches or pull requests

2 participants