WIP First draft for Charging Station Socket Type quest#6732
WIP First draft for Charging Station Socket Type quest#6732mcliquid wants to merge 5 commits intostreetcomplete:masterfrom
Conversation
So far running and tagging is working, UI is not beautiful, but works.
|
#5164 For reference
Aye, we would need to tag the amount of sockets, since that is normally what the value of the |
|
|
@westnordost @paulklie Thank you for your feedback so far. I started reuse the maxweight-Quest but I have some UX-related questions. I thought it would be cool to show all possible sockets and for each one selected an input gets visible and you can insert the number. But in the end it seems to be a waste of the available screen-area. I'm wondering whether it wouldn't make more sense to display all sockets below each other and only save the ones in which a number is entered?
I just read it as I was typing after switching to number input. But I can also dismiss the commit? |
|
After testing the quest a few times, I am left with three options UI-wise:
Current behaviour: For each selected socket you can specify the number of sockets: Check Tagging: |
|
While option B might be slightly faster for the user, I find it better for consistency when the UI is similar to maxweight.
That's not how maxweight form works, though. Have another look at the form. Maxweight-alike would look something like this 
But I am really not sure whether we shouldn't keep it simple and just ask for which are present at all, tag |
This would include a quest for each possible socket right? So 10+ new quests, which seems a bit excessive to me. Also it would result in alot of changsets, which might lead to other users complaining. Imagine a charging station with 3 types of plugs, we would now have 4 change sets for adding these sockets instead of one. |
No, it would be just one and the same quest type that would pop up several times in a row for the same object (if that station has several different sockets) |
|
Also such a solution would require a lot more time for the surveyor. Since they would spend additional time selecting and submitting the quests. |
Okay, now I'm confused. Do we have different versions of the quest? Anyway, it's your repo, you have the force to decide. |
|
The quest form would then decide for which of the missing socket types it is going to display the
UI. Or alternatively, it would ask for all at once (necessarily pre-filling those that already have been defined). E.g. However, that would make the exception case more difficult to handle: I.e. what if the listed types are not correct? |
No, you have the same version of the quest. But you see, there is not a dialog that asks to input the number, you input the number on the main form but select the maxweight sign type in a dialog. You can also add several signs and remove them again using the trashcan icon. |
Okay, the only difference: The maxweight quest displays an additional dialog box, which I solved in a single view. The path for the user is virtually identical. |
Not true. Including OK button tap and taps related to the keyboard, for a hypothetic charging station with 2 type2 and 1 domestic, there are about 12 taps for the maxweight UI vs about 12 taps for the mutliple quest UI. maxweight:
atomic quests:
|
|
@mcliquid 's "option B" has of course by far the fewest taps: just 5 for this example. |
Pro maxweight / "option B"
Pro atomic quests
|
|
My opinion so far: Option A – Similar to MaxWeight (Add → Select type → Enter number → Repeat)Super heavy UI for objects with 1–2 connector types Option B – Directly in the grid with +/- buttonsDefinitely the fastest UX (fewest taps), ideal for frequent 2–4 types, but UI quickly becomes confusing with >4 types Option C – Multi-select → then number per type (two-stage)Clear distinction between type and number but requires more taps and doesn't really offer any clear advantage. Atomic Quests (D?) (first type yes/no, then separate number quest)Simple implementation, simple UI - but more changesets, more quest popups in total, intermediate states possible if "amount quest" is not activated. My biggest fear would be that Person A tags the different sockets and Person B then has to enter the numbers, but has a different understanding of the sockets, making it unnecessarily complicated to "correct" this. Just like with the sidewalk (ah, no, wrong, sidewalk is completely different here → recording starts all over again). The question is whether, in reality, charging stations with more than 3-4 different types are really more common than rare. And if that were the case, then you should probably make a comment with pictures anyway. And that would put me personally in favor of option B. But: I don't know if I can manage to create such a UI myself. |
|
TL;DR: My current favourite is "Atomic Quests (D?) (first type yes/no, then separate number quest)". But "Option B – Directly in the grid with +/- buttons" have some nice advantages (but also a huge disadvantage that it is time consuming to use; unless it is modified to allow me to enter "yes it exists, but with uncounted number of sockets" (which makes it even more technically challenging to implement).
Another advantage of that option, is that it would allow for easy counting of bigger stations (i.e. you could just walk from charging point to charging point and simply press "up" arrow on appropriate type -- for all others methods, if there are more then few of different chargers, you'd likely have to count them somewhere else1 and then enter the sum in the app, which is unusable IMHO (unless on very small charging stations)
Doesn't the address number Quest allow for increasing/decreasing housenumber by arrows? Could it be used as an inspiration?
True. But it also allows for other quests which would benefit from that method. 🤷 I'd much prefer if one could also set it to
This would also be preferable from "⚛️ Atomic quests: Per quest, only one thing should need to be answered by the user." guideline IMHO.
It isn't my fear. After all, if the numbers were likely to be counted differently due to different understanding, then such data fails verifiablility principle and is ill-fitted for OSM anyway (and we should stick to unambiguous But I don't really think such miscounting should be happening often (in which case this is not really a problem).
Only if you enable them. 😉 As a bicycle user, I'd stop at electrical car charger station mostly to use air compressor (or buy something at a shop) and be off. So while average electric car user will likely linger for at least half an hour (so has ample time to count stations and micromap everything), I'd be mostly affected by "🐿️ Easy answer: Users are out and about and impatient" tenet. IOW, I'd add what types of car be charged, but not count them (i.e. I'd have all the counting quests disabled in my my most used preset). If only way to solve quest was to count up all different types of sockets, I'd most likely just fully disable that quest so they'd be left fully unanswered. So that is a huge disadvantage; unless that "option B" (or whatever) allowed me to easily answer
This is another benefit of "Atomic quest" approach.
This is however biggest (if not only) possible negative of "Atomic quest" approach that I recognize. But it boils down to how many users are like me which would only add partial information. (and whether we thing if partial information is preferred to no information for such people, and how would the I would wager that there are significantly more electric car owners visiting those charging stations -- but how much of them are SC users, and how much of them are fully happy with their proprietary charging apps on their mobile phones (and don't care at all about OSM data having the details) is hard to tell. 🤷♂️ In any case, it would be borderline (but not really violate) "🚧 Established tags only: No new or unestablished tags should be introduced through StreetComplete" -- the value Footnotes
|
| nodes, ways with | ||
| amenity = charging_station | ||
| and bicycle != yes | ||
| and motorcar != no |
There was a problem hiding this comment.
Would it be possible to ask for man_made=charge_point as well, and exclude all amenity=charging_station areas that contain a man_made=charge_point? Or is that too difficult or not worth the effort?
My thinking is that for bigger charging stations that are mapped as areas with separate charge points, it is much easier to answer the quest for the charge points individually than having to sum up all sockets from all charge points to answer the quest once for the whole charging station.
There was a problem hiding this comment.
Yes, should be possible like this:
val hasChargePointsInside = mapData
.filter("nodes with man_made = charge_point")
.any { cp ->
val cpGeom =
mapData.getGeometry(cp.type, cp.id) ?: return@any false
bounds.contains(cpGeom.center)
}
if (hasChargePointsInside) return@filter false
Hmm, indeed not as bad as I though. Though I would still argue that the seperate quests require more time since the user will need to read more text (question text for every socket) etc. |
|
I would like to point out that the vast majority of charging stations have very few sockets. For example, for the most common socket, type 2, less than 2% of stations have more than 6 sockets: https://taginfo.openstreetmap.org/keys/socket%3Atype2#values. And 93% have 4 or less. Additionally, in my experience, the places that have more sockets, tend to be larger charging stations. A user who is here is more likely to be driving, and maybe also waiting to charge, so would have more time available to count all sockets. Thus I do not think we should be planning to much around these rare cases, and more around the default case: smaller charging stations with 1-4 sockets. Asking for the amount here might also improve data quality, as simply asking for what sockets exist might lead to users only checking a few sockets, and not surveying the entire (larger) station, and thus missing some other socket types. If they are also asked to count them they might be encourage more to check every charger. Another advantage of a "maxweight" type solution is that it is easier to correct mistakes. |
|
Another point on data quality:, imagine a scenario when using the atomic solution: a charging station with type2 and type2 combo chargers. These look quite similar and can be confused.
An advantage of a maxweight solution is that every "possible" socket is always visible, thus a user is less likely to confuse them. |
|
To better evaluate the UI requirements, I ran a Python-based analysis of the current OSM data in order to better understand common cases and edge cases. Using Overpass Turbo, I retrieved all TL;DR: On average, 1.47 sockets per charging station are tagged. DetailsRiding the data-rollercoaster, we do have 175,594 charging stations worldwide. Of these:
This means the analysis measures the number of documented, present socket types per charging station. Distribution
Observations:
The following stations have 6 or 7 documented socket types:
By the way: I assume that the two “7” objects are duplicates of each other. Implications for the Quest UIThe data shows:
Since we already know that there are usually only 3-5 relevant socket types per country, I have given it some more thought and would suggest the following UI (rough copy&paste mockup): |
|
I don't quite follow how from that finding (on average a charging point or station has 1.47 different socket types), you arrive at the conclusion that this UI best fitted. |
|
The following things are difficult with this UI:
What's extremely convenient, however, is of course the number of taps/swipes. On average, just 3.5 taps + 0.5 swipes |
What I meant to say is that first of all, you usually only select between 1 and 2 sockets, and then you can prefer a UI that focuses on 1-type and 2-type cases instead of a UI that allows for an infinite number of combinations. Multi-type cases are important, but secondary in this quest. Extreme edge cases are negligible and can be solved with notes. I wanted to show a UI that works according to the KISS (keep it short and simple) principle and only covers the most important aspects.
This is already the case for many quests, such as smoothness, surface, recyclingType, etc. This should not be an obstacle.
I would simply overwrite these values with a number and display them as “missing” (empty) in the UI.
In my opinion, this can be disregarded (based on the data). If we further consider stations with at least one documented To summarize: On average (rounded) worldwide, there are 2 different socket types and 4 sockets (plugs) in total per charging station. Does that make sense for you? |
|
Well, I think I have not such a strong opinion on this. Your suggestion is convenient. It needs few taps and due to it being so quick to use, there'd be little desire by the likes of mnalis to commit early (i.e. tag Alright, it looks like you've made your mind up about this. You are welcome to implement it and I'll merge it. The following composables might help you in your implementation:
The Stepper Button is a +/- arranged vertically, to be put to the right side of a text field or label. If you think an input like The data model you'd use within the charging sockets form composable would be a mutable state of a If you haven't yet, maybe before implementation it would be a good idea to review the "getting started" documentation of Jetpack Compose, especially regarding best practices. Since the entire composeable-widget codebase in StreetComplete has been written with that in mind, you might also just learn from existing code. At the "top level", i.e. directly used in the |
...lin/de/westnordost/streetcomplete/quests/charging_station_socket/AddChargingStationSocket.kt
Outdated
Show resolved
Hide resolved
|
maybe better question to ask would be "how many" ? |
|
I have identified some additional things that need to be taken into account: affecting quest filter and applying tags
affecting applying tags only
Given the complexity involved with solving point 4, I think it is better to not ask this quest at all if any Point 1 and point 2 could still be done, but the filter must be crafted cautiously to only include deprecated socket keys and supported (non-domestic) socket keys with a Otherwise, only point 5 is strictly mandatory. |
That was just a mockup, no final UI proposal ;) I note down:
or a vertical stepper to the right of the number (like StepperButton) That means a version 1.0 has:
Note on the scheduleI've ruined my entire dev environment once again. I suspect it was fatal that I forked SCEE first and then later tried to fork StreetComplete alongside it, which doesn't work at all. In any case, my personal StreetComplete repo has completely detached from upstream and I can't reconnect it (only one fork rule) and I can't access the correct SC master branch via the (still functional) SCEE fork. I have no idea how to solve this yet, but at the moment I can't upload any new code. |
Well, maybe have two different directories, one for SCEE, one for StreetComplete, if they deviate that much (😢) |
It is more space saving. I am a little concerned however that it may not be crystal clear to which a |
my typical problem is Android Studio having some leftover data from other version - and stubbornly compiling SC with SCEE app id. In my experience deleting all files except .git folder and doing |
|
With the help of @Helium314 and GitHub support, I managed to fix the git environment yesterday 🥳 In the meantime, I just kept playing around with the UI and currently ended up with this approach, which I find quite practical. On a current Pixel phone, 5 sockets are displayed without any scrolling. |
|
Well, looks fine so far. It is unfortunate that the most important thing for deciding which to select is now quite small. The name is (much) less important. For the record, I still slightly prefer the atomic quest solution, especially after having done some research and found that the list of socket types that could be found in some countries may be rather long. Examples include India first and foremost, but as most countries outside EU and China don't seem to mandate a certain socket, the situation there can be quite topsy turvy - any e-vehicle producer bringing their own system, basically. Still, even France has not only the three type2 ones, chademo and dimestic, but also two types of type3, i.e. in total 7. Your UI excels most when the list is short and when more different socket types are supported by each station. |
Okay, fair enough. That clearly means back to the beginning, two separate quests, one just asks what, the other how much? Any other requirements? |
|
I guess that having such display in areas with reasonable variety of plugs and atomic ones in less normalized ones would not be viable? (atomic quests also have problem of increasing chance of misidentification of plugs, compared to case when multiple designs are shown in one go) |
Quick fix: Only show the quest in countries that already have advanced charging station development. The wild growth that some states currently have will not be sustainable in the long term. |
No, it doesn't. I said, for the record. You seem to prefer your current solution and as I said, I do not have such a strong opinion about it that I wouldn't accept your PR with your UI. |
In such a situation an atomic quest also has issues, since it might lead to users needing to answer 8 quests to add the sockets of a station (and thus 8 changesets). |
|
I just noticed, by the way, that in your last screenshot of the UI, the socket type was especially small because it (still) included the hexagons |
Yes, in that case it always makes sense to read the corresponding text as well:
|
6 participants
That was a wild journey through compose 🤣 This is really a very early prototype. The app runs and you can select multiple plugs - so far, so good. Currently, however, everything is static; there is no distinction between countries. The socket selection also needs to be expanded and then linked to the future
countrymetadataYAML. But you can already get a feeling for how it could work in the future.This brings us to the tagging question:
Is it sufficient to tag each socket with a
yesor would it be necessary to add an input field to the UI for each socket so that the number of sockets can also be specified? However, this could appear visually chaotic.Closes #5164