Metadata Editor Wireframes

[LanesGood]

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,

[RocketD0g]

Will have more substantive comments, but first I just have to say: THIS IS SO COOL!

[RocketD0g]

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:

• Calling out that some sensors/instruments could measure more than one pollutant. (e.g. a Beta Attenuation Monitor (BAM) can measure PM10 and PM2.5)
• But each instrument - or what is being termed sensor here - may (and likely will) have its own manufacturer and model (e.g. if a station measures PM2.5 and SO2, for instance, these will very likely be on two different devices/instruments unrelated to each other).
• To give some context, here's an image of the typical view inside an AQ station. These are separate AQ instruments, independent from each other, mounted on racks. Some of the instruments measure more than one thing, some only one. Each instrument has its own make/model associated with it. http://www.aqhi.gov.hk/api_history/english/backgd/images/1.jpg
• Generally, folks don't call these AQ instrumentation boxes 'sensors' - this tends to imply the actual sensing device that is part of an instrument instead of the whole instrument. I know "instrument" is kind of long though - what about using "device" instead of "sensor" here?

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')?

[LanesGood]

@RocketD0g thanks for your questions and comments. To respond to a few directly:

• I'm assuming that on the metadata search feature, cities and countries will also be searchable.
• We can certainly include a line of text or a CTA with an invitation to edit the metadata. As far as I understand your current thinking, the user will still need to be authenticated to edit
• Likewise, we can include this CTA/text on the OpenAQ locations card that can link to the metadata editor. However, the user will again need to be authenticated to be able to contribute metadata
• Finally, I'm still under the impression that "Stations" are taking the place of "Locations," which are currently housed under the 'Data' navigation item. The mockup above of the updated Location page includes the metadata, so "Locations" would display the station metadata by default.

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:

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

[RocketD0g]

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

[LanesGood]

@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

[RocketD0g]

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:

• Under "Device 2" where it says "Instrument Pollutants" I'd recommend "Pollutants Measured" instead.
• On "raw frequency", I think this is meant as the time-averaged period of each reported measurement, no? (Or 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!

[sethvincent]

Closing this as we've implemented these pages, and will follow up with more specific ui issues as needed.