-
Notifications
You must be signed in to change notification settings - Fork 24
Why keep the form and map separate
Original question: What if we design it so there is only a map. The map always shows the existing pins/ GeoClusters as discussed. By default, the form appears on the right side, and it is blank. A user can enter a new work order simply by filling out the form and clicking “Submit New Work Order” (or similar button). If the user clicks on an icon, data from that site populates the form. A user can edit the form, and the button at the bottom changes to “Save” instead of “Submit New Work Order”. We would also need a button that allows allows you to clear the form to add a new work order.
- Is this a good idea?
- Would it be relatively trivial to do?
- If so, should we do it now, or later? If we do it later, I will need to re-record help videos, and we would change the UX midstream, which may cause confusion.
Answer from Andy: Here is why we need a separate map and form.
Reason 1:
Geocoder is unreliable. The farther you are from us and eu urban centers, the more unreliable it becomes.
We have a separate map because when you enter an address we drop a pin where Geocoder tells us to.
When this is wrong, a user can drag and drop the pin.
Can you imagine finding that pin among 5000 or more sites?
Even worse it will almost definitely just disappear into one of our magnifying glasses.
Either way, it's visually lost to our user, which means we would be indirectly eliminating this feature.
Reason 2:
A common use case is for someone to enter form data over and over. For instance a call center.
If we load the pins from the map (or do the database GeoCluster algorithm that dhruv introduced ) we are running pointless map queries over and over and over.
Our dB can take that now, even if we wouldn't want to. When we have 100k sites, this could effectively be as dangerous as a ddos attack.
As far as specific number go, think of it this way. If we have 100k sites and we have a call center that loads the form 1000 times in a day, that would mean in that day alone we scan 100 million sites, just for the call center, who have no need to interact with them.
Reason 3: Ui/Ux clutter. If I'm on a page to add data, how does seeing magnifying glasses help me? Adding data is different than interacting with data (on the map). Each page should and currently does have it's specific task.
Tl;Dr
-
we couldn't double check Geocoder this way. This would be enough of a loss for me to be against this proposal.
-
We'd incur a huge database penalty (even with GeoCluster we would at least have to scan and compute with every site in a disaster. Which in a 100k site disaster could bring down our system by effectively self-ddos-ing). This makes it so we literally can't do this. We would ensure that the app can't scale.
3)Ui Ux clutter. Adding data and interacting with data are two jobs. Seeing magnifying glasses doesn't help me add data.
This is a conversation that's come up a few times. I'm glad it's being documented for the future.
If there are any questions or compelling arguments, let me know.