Closed LanesGood closed 5 years ago
Will have more substantive comments, but first I just have to say: THIS IS SO COOL!
Again, this is awesome @LanesGood, thank-you! A few comments below.
For the wireframe directly below:
What happens if you put a city or country name under "Search Station ID"? Does that only search bar only accept the station ID form? My guess is that it will be rare that a user would have the knowledge to put the station ID in precisely.
Will it be possible to filter by city, as well country either here or after you have selected a country? My guess is that a user may want to see if the stations they know are in their city are all listed there, so I could see folk especially wanting to have a 'city view.'
For the filter area called "sensors", I suggest calling it "Pollutants"
For site types, I'd consider having a filter box "unlabeled" in case someone wants to use that filter as a tool to go through and find out where info is needed.
I really like the metadata completeness feature.
My two cents and would be interested to hear from others: I'm not sure how much folks will actually search through the system for station heights.
I wonder if there could be some sort of invitation to edit? Like "Do you have information about this station? If so xxxx...."
Station List with Filters
For the wireframe directly below:
Public Page
On the authentication piece, I like that it can be configured for not requiring approval for someone to edit. Figure it will makes sense for us to start off that way - auto approval - and ratchet up the authentication piece, in terms of manual approval, if we see that is needed.
On the revised OpenAQ locations card: It's awesome having the info in there too. Is there any way to invite someone to edit the metadata via the editor if they have additional/corrected info? Basically, is there a way to link these pages to the editor? ** This may be outside of the purpose of this wireframe, but I'm wondering if we should have a 'metadata' choice on the upper right hand bar (or to have that piece under 'data')?
@RocketD0g thanks for your questions and comments. To respond to a few directly:
As for the other comments on naming conventions and filter/search features, I'll modify the existing mockups with your suggestions.
On the question of devices/sensors, should the metadata page display all instrument-level data? My thought was that the station metadata page will display any of the data that is input using the metadata editor. According to the metadata schema sketch, this has the potential to be quite verbose. I propose the following:
Great on all this, @LanesGood, and thanks!
On this section,
On the question of devices/sensors, should the metadata page display all instrument-level data? My thought was that the station metadata page will display any of the data that is input using the metadata editor. According to the metadata schema sketch, this has the potential to be quite verbose. I propose the following:
- the metadata station page should display all available information
- the Location page on OpenAQ should display only the instrument type, model and manufacturer: the pollutants are already displayed in the existing information.
- the metadata editor can be updated to allow users to enter all of this metadata on a single instrument/device as a sub-process in the form, and then click an "add another device" button to continue adding multiple devices per station.
I like your proposal. I hear what you're saying on the station metadata pages potentially becoming too verbose, and I don't have a great thought on addressing that. My guess is that the most number of instruments we'll likely see is 4 or 5 (this could still look like a lot on a page, just throwing out numbers for context).
@RocketD0g, the updated mockups are below.
It does seem like we'll need to come to a common definition of "Station" vs. "Location", as well as "Instrument" vs "Device" vs "Sensor"
Metadata Editor:
Station List w/Filters I'm not certain that 'city' is a necessary filter field for the Station List page, as the table is searchable by city, and the "Country" and "City" columns are sortable. I've left in the Station Height filter and column for reference, but these can be removed if determined unnecessary.
Station Page w/ CTA at bottom
OpenAQ Location Page - includes callout for metadata editing
Thanks, @LanesGood.
On:
It does seem like we'll need to come to a common definition of "Station" vs. "Location", as well as "Instrument" vs "Device" vs "Sensor"
My two cents is that we go with "Location" instead of "Station." Mainly because a) this is what we've been using previously and b) I think semantically, you can argue that how we are defining spots in our system is at its core by location (e.g. coordinates) rather than a station. Don't feel super strongly though, and agree it is good to just be consistent with one or the other.
My other two cents is we go with "Instrument" instead of the other two, unless it is too long, in which case, my second choice is to go with device. "Sensor" does tend to imply a specific thing in the AQ community that is not quite what we're going for in a more general sense here.
I've put a few comments below too.
Metadata Editor:
averagingPeriod
in our data format?) If that's the case, this is technically different than a frequency. I would suggest wording as, "Averaging Period" or "Measurement Averaging Period," if not too wordy.Station List w/Filters
I'm not certain that 'city' is a necessary filter field for the Station List page, as the table is searchable by city, and the "Country" and "City" columns are sortable.
Make sense
I've left in the Station Height filter and column for reference, but these can be removed if determined unnecessary.` If we do include that, I think there could be confusion on how it is worded. Folks may wonder if it means inlet height of an instrument or the altitude of the station. I'd suggest wording "Station Altitude".
Station Page w/ CTA at bottom Love the CTA!
OpenAQ Location Page - includes callout for metadata editing Great!
Closing this as we've implemented these pages, and will follow up with more specific ui issues as needed.
We're pleased to share wireframes for the metadata editor….
The metadata editor would live on its own sub-domain (eg. http://metadata.openaq.org). Where the main OpenAQ website is mostly used for consultation, the user of the metadata editor is expected to contribute data.
Station list
The station list is optimized for quick identification and searching across the stations. This list will also contain information on metadata completeness. This provides contributors with a quick overview of completeness, and those stations that require most attention.
Station List
Station List with Filters
Station page
The station page contains a full overview of its metadata. This is public. Authenticated users can sign in to edit the metadata of individual stations.
Public Page
Logged In View
Station editor
The station editor allows logged in users to directly edit metadata of a station. Station ID information, comprising the unique station ID and station location information, is not editable but is pulled from the data source.
A note on authentication
While the metadata editing experience should be as accessible as possible, some form of authentication is necessary to avoid contributions by bots, or vandalism at larger scale. We propose to rely on a third-party tool like Auth0 for authentication. and provides a lot of flexibility, and can be configured so it doesn't require approval
Revised OpenAQ.org Location Page
The current openaq.org location page will display updated information, including the unique Station ID and additional information collected on each station,