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

Client-side UI for JSON/CSV/XML export #674

Open
dethe opened this issue Nov 10, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@dethe
Copy link
Contributor

commented Nov 10, 2017

This is the issue for design of the UI (if any, see below) integrating data export into the site.

Note: A valid solution for this may be: there is no UI in the site, only documentation for the API.

If we do want to integrate this into the UI of the site, the first step must be a sketch of where the integration will be and how it will work, before any development work is done. We can discuss and iterate on the sketch until folks are happy with it.

When and if the sketch is approved, technical considerations for implementation are:

  1. Developed as a PR to be merged into the main codebase
  2. Uses HTML/CSS/JS based on existing Participedia code and styles. State, if any, managed via React.
@mjones204

This comment has been minimized.

Copy link

commented Nov 14, 2017

We intend to implement this feature by integrating it into the site's UI. A demo is currently in development which will hopefully provide insight into how we think the feature could be implemented. Regarding the sketch, we are refining our ideas on this feature's appearance and how it could integrate which we will share with you soon.

@mjones204

This comment has been minimized.

Copy link

commented Nov 23, 2017

RE: Sketch

Integration

Regarding the design and placement of the export button. I assume the black download icon that currently displays on the site homepage:
image
is intended to be used for this purpose?

How it could work

Assuming that is the intended export button, it currently appears on the 'All', 'Cases', 'Methods', and 'Organizations' tabs. We were thinking that if, for example, the user presses the button while browsing the 'Cases' tab, a modal box could open up to export case data (and likewise for the other tabs).
We were thinking of something along these lines:
image
where the user is able to select which fields they want to include in the export. That's the general idea, but we are looking at developing a more appealing and practical method of field selection, since the barrage of checkboxes is rather crude.

@mjones204

This comment has been minimized.

Copy link

commented Dec 1, 2017

Possible UI designs

1. Horizontal Scrollbar

A simple, no nonsense horizontal scrollbar where each field is given a checkbox to allow selection and deselection. The 'Select all' checkbox can be used to quickly select or deselect all fields.
image

2. Selector

Two lists represent the included and excluded fields. Users can intuitively select/deselect fields for inclusion/exclusion. Groups of fields can be quickly selected/deselected by clicking on the group name. Hardly any code required to set it up, although it does require the use of a third-party library (multiselect.js)
export-ui 2
9621e119f0d496897027bd69a281127a

@andreadelrio

This comment has been minimized.

Copy link
Contributor

commented Dec 1, 2017

I like option 2 a lot better. The horizontal scroll on option 1 makes it hard to see all selections at once. Also, I'd check out this module for option 2. The multiselect functionality might be useful https://jedwatson.github.io/react-select/

@Jetroid Jetroid referenced a pull request that will close this issue Jan 22, 2018

Open

Implement Data Export UI #712

@jesicarson

This comment has been minimized.

Copy link

commented Mar 13, 2019

@ascott @dethe @davidascher this is probably a good a place as any to mention issues around data export as outlined by @scottofletcher / @plscully in this memo. In particular, the memo outlines the current state of xyz data having 18 different fields for location alone, a red flag that I was reminded of by Alanna's recent xyz front-end fix of the location duplication issue (#909) and the issue she posted about location data cleaning (participedia/api#463).

Also, finding this issue when looking for issues about "data export" reminded me that a UI was proposed (maybe even built?) that could potentially serve as "faceted search" and allow users to download only the data they need.

I realize this may be a larger conversation, and can be placed on hold for now as we address localization, but its come up a few times lately with team members needing access to exports and I wanted to possibly address it in relation to some of the other database issues that seem to be coming up. Thanks!

@plscully

This comment has been minimized.

Copy link

commented Mar 13, 2019

@jesicarson Thank you for this. The more I think about the team's needs -- especially as they begin working on research projects to discuss at the June meeting, about which they will write papers in the ensuing year -- the ability of the average user to conduct faceted searches seems even more important than localization. That said, I am not suggesting we delay localization, only that we need to make it possible as soon as we can for users to conduct nested searches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.