Closed ranganathanm closed 9 years ago
From Julie:
During our GUI review of the admin pages, we discussed having the spectrum browser login page have the following buttons: Request Account, Forgot Password, Change Password, Register Sensor (currently, we have all but 'Register Sensor').
Now that the NIST users go directly to the map page and skip the spectrum browser login page, shall we add a 'Register Sensor' button on the top of the map page? ITS users could register a sensor either from the login page or from the map page and NIST users could register a sensor from just the map page.
During our GUI review we discussed that 'Register Sensor' page would have the following information for the user to enter: Sensor ID Sensor Key (must be unique) Sensor Admin Email System Raw (must match current transfer spec) System Proc (must match current transfer spec)
If the information is valid, there is not an existing request for the new sensor ID, and the sensor is not already registered: An email will be sent to the user to ensure their email is valid (so users are not spoofing whitehouse.gov). The user will have 2 hours to click on the link in their email (or the pending sensor request will be deleted).
Once the user clicks on the link in their email, the admin will get an email that a sensor request is waiting for the admin to enter the threshold id, the data retention id, and approve the sensor (must approve by 48 hours or temporary sensor request will be deleted). The admin needs to login to the 'admin' portion of the website and in the 'Sensor Management' page they will need to select a 'Threshold ID' and a 'Data Retention ID' (or create new items in the 'Default Occupancy Calculation Parameters' and 'Data Retention Plans' page first).
Once 'Threshold ID' and 'Data Retention ID' have been assigned to the sensor, then the admin can select the sensor and press 'Approve Sensor Account.' Also, at any point the admin can also select the sensor and press 'Deny Sensor Account'. Whether the sensor is approved or denied, an email will be sent to the 'Sensor Admin Email' which the user entered when trying to register the sensor.
Also, during the GUI review, Mike Cotton said that the 'Data Retention Plans' page (and thus the 'Data Retention ID' for the sensor) could wait until later and we do not have to create this functionality now. Only the Threshold ID is critical at this point.
To me, it makes sense to have separate admin pages for 'Sensor Management', 'Default Occupancy Calculation Parameters', 'Data Retention Plans', and 'Sensor Status' rather than wrapping up some of the functionality, such as thresholds, into the 'Sensor Management' since more than one sensor can use the same threshold ID and it might be nice to show the Threshold information on a separate page. If we want to have a 'pick list' on the 'Sensor Management' page of threshold ID information to help the admin with their selection, this might be nice as long as the 'Sensor Management' page does not become too cluttered.
From Ranga:
I don't think it is a good idea to to have untrusted users have the ability to request addition of sensors. I would prefer to have an admin page to add sensors and in case logins are supported, the logged in user can request a sensor to be added.
I am also leaning towards avoiding "Ids" of various kinds. There will be some repetition of data but I would like for all the data pertinent to a sensor to appear in the same page. I believe this would make for a less confusing GUI design rather than having the information distributed in multiple pages/tabs. It might be a better design to have a button in the place of the ID. When the admin clicks on the button, the corresponding page/form comes up rather than using an ID. It essentially achieves the same effect. I'll tinker a bit with the GUI.
I suppose we should be having this discussion on github. I'll cut and paste it there.
I would ask Mike Cotton and the team the question about whether or not we want users to be able to request new sensors or just allow new sensor to be created from the admin pages, since our original decision was to allow users to originate sensor requests.
If we want to avoid Id's and just have the system assign unique identifiers, that seems fine to me.
In terms of multiple pages/tabs, I would again ask Mike Cotton and the team about that, since those were decisions we made as a team during our admin GUI design.
Of course, we will need to assign a unique 'SensorID" and 'SensorKey' to each sensor for validation when accepting sensor data into our website.
New sensors created from the admin pages makes better sense to me.
ID's were used to capture a number of variables, e.g., threshold id captures Sys2Det, MinFreq, MaxFreq, and Threshold. I leave it to the discretion of the coder. Run w your intuitions Ranga.
Implemented suggestions. So closing.
Some questions:
If I understood the way you envisioned the addition of sensors, you would allow users to add sensors after they login (there would be an option to allow the user to do so).
How do you envision the flow in case there is no user login?
The threshold ID and data retention ID are not something the user can be expected to know about. Presumably, these would be filled in by the administrator.
I think we need an admin page for adding sensors in case the system is configured without login.
Thanks for your replies in advance.