Hi Lars,
Thanks for your thoughtful analysis. There are some great points in your e-mail and the document comments. Based on what you've brought up, it is clear that another round of editing is
justified for that document.
Your point about some remaining stories not informing the data schema is especially well-taken:
·
The infinite scroll should be relegated to the implementation document I've started.
·
There are a couple of references to "zooming", though they are somewhat incidental, they can be removed if you like.
·
I personally believe that centring could peripherally affect the data schema if we choose to support metadata that would inform that. For example, picture a visualisation that
centres your view based on your identity, or IP address, or something (this is an imaginary scenario!) — if the map were to automatically centre on CANARIE for me when I visit it, I believe it should be up to CANARIE to specify where the "centre" should be.
In our case, it might be southeast of the geographic centre to emphasize the cross-Atlantic and US links… maybe (or maybe not, but I believe we should be able to make that decision and specify it in the map metadata if we so choose). Open for debate of course.
To respond to a few other points you've raised in your e-mail and the document comments:
·
I actually think that the idea of showing only inter-NREN/inter-region/inter-continental links is captured by the story "Link Type Filter", though this exact use case has not
been mentioned. (Happy to add it.) Also, in reverse, by the "Inter-NREN Filter" story, which could be modified slightly to describe exactly what you suggest.
·
The idea of mapping virtual links to physical links is an interesting one. I think it bears more discussion. Do any current visualisations show this kind of detail? Do any
foreseeable implementations require it? Or is it maybe a good idea for Version Two?
·
I like your suggestion (in the document's comments) about link traffic type. I'll add a story about that, and call it, perhaps "Link Traffic Filter".
·
I do think that activity metrics may have an effect on our main data schema. I've been mulling over in my head (and with Tom at one point) the idea of requiring/providing a guaranteed-unique
ID for each link. (This would also support disambiguation/deduplication after data updates, among other advantages. There are, of course, disadvantages. To be discussed later.) In any case, somehow primary-key identifying a link and its nodes would be
required or at least highly beneficial for connecting supplementary data sources like activity metric feeds. I'd like to keep this in here, even if we don't get as far as developing a proper full schema for the supplemental data in the first round.
·
I believe that determining how the data is stored (distributed vs. centralised) may indeed have an effect on the data schema. This is why we included the "Access" story. If
it is unclear whether the story affects data schema, I think we should lean towards including it in this document.
Smaller notes:
·
Yes, I meant "sites that support eduroam WiFi".
·
The first sentence of the "Language" story is there so that it doesn't look like we forgot about the user in this story, and to clarify what is meant by the subsequent sentences.
I will distribute an updated document (with inline comment responses, in case this long e-mail was too hard to follow) shortly.
Upon reflection, I wonder if, instead of having a separate document for implementation-only user stories, we should include them in this document either in a separate section, or simply
identified as not affecting the schema development. Any opinions, folks?
--
Ryan
From:
Lars Fischer <lars@nordu.net>
Date: Friday, October 12, 2018 at 09:48
To: Ryan Davies <Ryan.Davies@canarie.ca>
Cc: GREN Mapping initiative <gren-mapping-wg@lists.nordu.net>
Subject: Re: [Gren-mapping-wg] User Stories Draft for Submission to GNA Tech
On 11 Oct 2018, at 8:36, Ryan Davies wrote:
Hi GREN Mapping Initiative folks,
We have had about two weeks to review the user stories document, and have made many changes to it, some of them obvious and some subtle. Attached, find the consolidated document, ready for submission to the GNA Tech WG for comment, along with our draft charter. Note that we are not seeking formal approval, only feedback.
Ryan, thanks for your work on this.
Reviewing this, I see some confusion between user storied focused on the end-user mapping application, and those focused on the data that must exist for the application to work.
We have previously agreed that our focus is on data format, representation, and exchange. Capturing user requirements for the mapping application is of course important; we need those to derive the attributes / meta-data
to record in the data exchange format. However, user stories that centre only on how the mapping applications works (infinite scroll, centering, zoom) do not inform the data requirements.
I think that in this iteration, we should focus on user stories that do inform the choice of data format and exchange, and we should make an effort to make sure the set if reasonably complete for at least a known set of
mapping applications. The way I like to think about this, we are not trying to derive the requirements for a mapping application; we are trying to derive the requirements for the data that will allow such an application to be built.
To this end, I not that you have removed two user stories
If we remove those, and the meta-data that go along with them, then there are types of maps that cannot be made from the data (i.e., without the first one, you can’t create the GNA map)
I’ve attached the document with some comments.
/Lars
--
Lars Fischer - Strategy & Policy, NORDUnet
lars@nordu.net, +45 2288 1729, @lpfischer