najadojo
commented
3 years ago What happens when the 15mins (why that amount) expires?
Closed KenEucker closed 2 years ago
najadojo
commented
3 years ago What happens when the 15mins (why that amount) expires?
KenEucker
commented
3 years ago @najadojo The wireframes don't tell the entire story here. This first iteration of the Vue App is meant to be pretty basic so we'll see how much scope of the queue is actually able to get covered. At any rate, this is the first draft and it's becoming clear that there will need to be a lot of documentation on how the queue works. Hopefully, we can all work together to come up with a good UI to tell this story, inherently. When designing the user flows, we came up with a use case matrix of the queue and how it could be configured by a BikeTag Ambassador. There are 16 different permutations of configuration allowing for many different types of gameplay. There's a whole lot going on here that won't be covered in the wireframes, at least in this first round, but here's a quick run of what I'm thinking:
The queue can be configured to be auto-timed, untimed, or user timed. This allows for a dynamic user experience enabling user input on each round for the "winner" as well as "first to queue" and also for BikeTag Ambassadors to throttle certain gameplay in order to open up/respond to the greater community.
When a user sees the queue time that is the amount of time left before that user's tag is accepted as the "winner". A winning tag is a, and this is the important part, is a completed tag including a found tag and a new mystery tag. This being the case, you won't see a timer until after the first image was queued (for the second queueing user). At this point, when a user is "first to queue", the site can be configured to allow the user to set the queue time (defaulting to 15 minutes to keep the radius of play tight). This would allow users to say "I've got a new place 5 minutes away and I'm going to tag it!" or to open up the gameplay to allow for a "longer" tag or to be open to being "sniped".
The queue time is the amount of time that users can submit or "queue" a new tag in order to be considered a "winner". Once the queue time runs out, and if there is only one user in the queue, then the "winner" automatically goes to that user if they are able to complete the tag within that time. ( we may also include a buffer time of 0.5 * queue time to allow for the #1 queued user to complete the tag). If more than one user queues during the queue time, then the winner of that round is the first user to submit a completed tag with both the found location image and the new mystery location image. If, by the end of the queue time, or queue + buffer time, no tag is completed then the queue is flushed and the round opens back up to anyone and everyone. It is at this point that the previous users can "requeue" their found locations and race to submit the newly acquired mystery locations.
Users can sign up for browser notifications and get notified whenever the queue changes, for just the one tag they are queued in, or in my case for all rounds played. BikeTag Ambassadors will also be able to get these notifications that will allow them to respond to new tags (and the need to verify them) faster. That also brings up another feature that the queue introduces and that is the ability to gate submissions to meet a certain: standard or lack of repost or to fit a narrowed theme for a short event time, or etc... BikeTag Ambassadors ultimately choose the winner of the tag once the queue feature is completed and this will allow us to more actively curate/moderate the games.
ykyu
commented
3 years ago Whoops, okay, here's the feedback I wrote this morning + more thoughts at the bottom about the queue system.
--
UI looks good for the most part. I think the new font choice helps a lot.
I think the "blue" bicycle in the How explanation could be made a lot brighter and that the green grass background and probably be removed (so it's just plain white) -- saturation-wise the green and the orange bike are very close, so if the image is greyscale, they're barely distinguishable. Worth considering the accessibility impact?
My main concern is the queue system not being clear/intuitive since there seems to be minimal explanation. "Queue" by default implies that order matters, so from the queue page, it's not clear that it's still whoever uploads the second part of the tag first that "wins." (Indeed, I think I misunderstood this for a while in our various comment threads!)
The queue system's primary goal is (correct me if I'm wrong!) to minimize the effect of two or more players trying to complete a tag at the same time, resulting in images being uploaded in a weird order, such as Player A-Proof, Player B-Proof, Player B-New. By allowing players to upload the two pieces of their tag at different times, there's a lower chance of that happening (basically no chance?).
This goal isn't obvious in the interface though. I don't know that it needs to be, but I do think it's important to be clear that being first in the queue doesn't mean you've already won.
I'm also not sure what "15 minutes remaining" refers to. I'm guessing that a queued found tag expires in 15 minutes and at that point the player needs to re-queue? Maybe because of the way the site reads Imgur upload order? (I'm not sure of the specifics of how that works with the queue system.) 15 minutes seems pretty short if you want to move the tag more than a few miles, but I don't know how cumbersome a longer expiration might be.
--
Aside from that, for Archived Tags -- it's not clear to me whether clicking on the images or the numeric header for the tag will lead to the single tag page, but I think it should be the latter. Clicking on the images to go to the direct image seems more intuitive and it's unclear what additional information the single tag view has that the archive view doesn't.
Leaderboard -- Is this just going to show each person's most recent tag (proof+new)? Seems good, if so!
User Profile -- This is currently the same as the single tag view, which I'm not sure was intentional. Might be better for the user profile to list tag pairs similar to the Leaderboard page so you can scroll through a user's entire history of tag pairs. Might also be fun to include some basic info like "date of first tag" and "date of most recent tag" which should be gettable from the tag history.
Users List -- "Players" might be a better term here? Not sure what image will be displayed for users in the list, but most recent mystery tag probably works.
About -- Line graph really intrigues me! Something like the current city's trend VS biketag overall or biketag average trend would be really neat.
Donate -- Also a fan of this bar graph, but I am just a fan of graphs and charts, haha.
Hints? -- Missing from Submission flow and How explanation slides. :o
Submit to Reddit -- I assume this screen would only show if the user has previously already authenticated with Reddit somewhere? Otherwise, more screens needed to walk through the auth process and/or explain how/why Reddit is involved at all (e.g. "Share your new tag to [City's] cycling subreddit so others can start looking for it!" or something).
Oh, ToS probably needs a link from the main city index in addition to being linked from the submission page.
-- Queue system:
I think this is the part that's unclear/unintuitive:
This allows for a dynamic user experience enabling user input on each round for the "winner"
Your three examples for what happens when a timer ends were:
I understand that there are probably additional permutations depending on specific options that are being worked into the system, but with the above three, I'm not sure why a timer is needed at all? If the first person to complete a set is going to be the winner regardless, why does there need to be a timer? Is it just to flush the queue after a certain amount of time?
I think the public timer is really confusing and could be stressfully interpreted as a deadline to get to a new tag location. There could be a simple note to the tune of "Your found tag has been saved! It will be flushed from the system if you don't submit a new tag within x minutes. However, you can resubmit the found tag if a new tag hasn't been set yet after x minutes." I also think the default should be 30-60 minutes instead of 15.
The queue system and its options might needlessly complicate the game in cities that aren't hypercompetitive like Seattle seems to be, so I think most, if not all, the options associated with the queue probably aren't necessary as a default. It'll be definitely interesting to test the options with Seattle specifically though, haha.
KenEucker
commented
3 years ago @ykyu all great feedback, thank you! I will try to touch on some items but I'm happy to keep this conversation rolling as we hash out the wireframes. I think the final draft will be completed by next Friday and if there's anything we can change/add/tweak at this point in the process then all the better!
considering the accessibility impact?
I LOVE THIS. Thank you for linking that site! We can reach out to the person who designed these and keep those who are color blind in mind for the how-to. That's super awesome, thank you!
The queue system's primary goal is (correct me if I'm wrong!) to minimize the effect of two or more players trying to complete a tag at the same time, resulting in images being uploaded in a weird order, such as Player A-Proof, Player B-Proof, Player B-New. By allowing players to upload the two pieces of their tag at different times, there's a lower chance of that happening (basically no chance?).
This is one reason for the implementation of the queue, but there are several great reasons for the solution and I have a feeling that all regions will use at least one permutation of the queue. At the very minimum, the queue is to be introduced so that users don't get to automatically change the image on BikeTag.Org just by submitting the image. The queue gives the BikeTag Ambassador the opportunity to stop potentially malicious use or incorrect in some way tags. This also opens things up for the BTA to edit the tag if corrections are needed before making the posts to the social sites (Reddit). So that's one of the reasons for the queue. It's not so much that users MUST complete the tags within the allotted queue time, but that the queue provides a way for users to say "I'm actively going for this tag, who else is?" and for others to be able to interact with that process.
Another reason for the queue and this is where a lot of considerations have been made, is to reduce the mystery behind getting sniped. It will be a lot more obvious to those who are playing the game that others could potentially snipe their tag. I think of the queue, in this case, as a way to say "I've already got the current mystery location and here it is, I'm on my way to my next mystery location idea and this is how long I think it will take me". This is an advanced use of the game, sure, but it's also a way to extend a courtesy for tags that you feel less competitive over. @AndrewPardoe could go queue up a tag and plan to move the tag across town 45 minutes away. For a region where the "first to queue" user can set the queue time (a configurable permutation)(maximum unknown), one could set the queue time to 45 minutes to denote that they intend to finish the tag within that time. Someone can always drop in and snipe the tag by completing it before Andrew is able to finish his tag AND the original gameplay remains intact.
The above strategies also allow a user to complete tags "in the blind" and to not use the queue at all, completing the tag immediately with both images at once and hiding the fact that they are actively solving the current tag. Again, the queue isn't necessary, but it does allow others to participate even if they don't get to be the "winner". It would also give us an opportunity to provide awards for "most sniped", because then we would actually have a mechanism for recording users who did get sniped on a certain tag.
Finally, when the queue is flushed everyone can resubmit their tags, and a new queue is created. The queue doesn't lock anyone out until it ends (and then only during the buffer time in which anyone queued is able to complete their queued tag). The "first to queue" can continue to be back to back to back "first to queue" all with 15-minute default queue times and still be the only person playing and have there be little to no impact. Also, allowing the queue to reset means that people can't just queue it first and then pick it up whenever they want later to be the winner. They must complete the tag within the SAME ride.
Users List -- "Players" might be a better term here? Not sure what image will be displayed for users in the list, but the most recent mystery tag probably works.
"Players" is a much better language! We will use that. The image we will show on players' profiles will be the most recently submitted tag, yes. There will be more options provided to users in the future -- hopefully, by the end of the year, one said feature is the ability to set your own user profile pic to any of your previously tagged tags.
About -- Line graph really intrigues me! Something like the current city's trend VS BikeTag overall or BikeTag average trend would be really neat.
I'm excited about the graphs as well. Current city trends vs averages and all the things! I'm not sure if any of the graphs will make it into version 0.9 but we'll see!
Hints? -- Missing from Submission flow and How explanation slides. :o
Do hints need an explanation? They will still be present. We hope to add enhancements to how hints are used/displayed but that's not currently a priority. Expand on what you mean here a little bit more, if you can, because maybe there's something I don't see that you see?
Submit to Reddit -- I assume this screen would only show if the user has previously already authenticated with Reddit somewhere? Otherwise, more screens needed to walk through the auth process and/or explain how/why Reddit is involved at all (e.g. "Share your new tag to [City's] cycling subreddit so others can start looking for it!" or something).
We already submit to Reddit on behalf of the user. No authentication required. This final "social share" screen will give Reddit users the option to "post on your own behalf" and then be provided with the BikeTag Text Template and your tag data. If you choose, which is automatic right now and not a denotable option (but certainly one available to anyone), to have the tag posted on your behalf this option is for that. The toggle button is yet undecided in functionality but has something to do with this. As for what we view Reddit as, when it comes to the BikeTag Game, is a place for discussions. Reddit is where the BikeTag.Org tags are posted for discussion. Much like Imgur is where we post images and Instagram will be one where we post images and links to the game elsewhere. The game is independently playable on all platforms, but, the way I see it, the only reason to provide a social share integration (like we do with Reddit) is if it solves a problem we don't want to solve ourselves. I don't want to manage user comments on the internet and I don't want to store them on other's behalf. So we let Reddit do that.
Oh, ToS probably needs a link from the main city index in addition to being linked from the submission page.
Of course. It's not exactly required but it's something that we feel is important. The way that our TOS will be positioned will be to refer to the TOS and privacy policy of the platforms we integrate with; copying notable parts of those policies into our own and calling them out. Additionally, we will provide the TOS:DR; information directly into our TOS. I want to try and follow Google's initiative to make a TOS that is very human-readable and fits on a single page. You can see some of this on the breakdown of our expenses here: https://biketag.bike/biketag-expenses/
I think the public timer is really confusing and could be stressfully interpreted as a deadline to get to a new tag location.
Again, not a deadline, but let's all work together to make it less confusing, eh?
ykyu
commented
3 years ago Queue Language
Ah, okay. I think I understand the various motivations behind the queue a bit better now, so main issue is just clarity and communicating this to the end-user in a succinct manner. Having lots of configurable options is great, but the more complexity there appears to be on the front-end, the more friction there is for new players.
On the Queue page, maybe something like "Queuing your Found photo lets others know you're on your way to set a new tag!" I think this works to let the player know they'll 1) be alerting others that they're on their way, and 2) they still need to finish the tag set.
Could include a (?) icon and/or learn more link for further explanation, especially in cases where other options are turned on.
"Try to set the new tag within 30 (or whatever) minutes. It's okay if it takes longer, but you may need to re-queue your Found photo." "How long do you think it'll be before you reach your new tag?"
I still don't really think showing the timer is necessary. If the queue expires, there can just be a message like "Queue has expired" and then either "Queue Found Tag again?" or "A new tag has already been set!" if the player was sniped.
Also, "You are number one in the queue!" again sort of implies the order matters. Maybe "You're the only one queued right now" instead? And then "3 players are queued right now. Ride to your new mystery location!" if there are multiple queued.
"3 players are queued right now. Submit your new mystery location to finish the round first!"
Hints
Oh, I didn't have any specific concern, just wasn't sure how the field to include a hint would appear in the UI since all the shown fields look pretty balanced as-is, without the hint. I guess it'd just be a "include a hint?" field above "enter your name."
Post to Reddit
I guess my point of confusion was whether pressing the "post" button would take me to Reddit, where a post is pre-filled for the appropriate sub, and then I still need to manually post to Reddit from the browser/Reddit app, assuming I'm logged in from my phone -- or if the app would auto-post for me based on prior authentication.
KenEucker
commented
3 years ago @ykyu thank you so much for all of this. It's clear that you're beginning to understand the nuances behind the queue and the language you've come up with is really great. You're literally, (proper use of the word!), writing the queue into existence!
These wireframes were thrown together in about 2 hours, from me, before I sent out the first draft. I will take some time to update these wireframes and include all of the language and feedback that is added to this ticket over the next week. Thank you all so much!
I guess my point of confusion was whether pressing the "post" button would take me to Reddit, where a post is pre-filled for the appropriate sub, and then I still need to manually post to Reddit from the browser/Reddit app, assuming I'm logged in from my phone -- or if the app would auto-post for me based on prior authentication.
Por Que No Los Dos?
If you look at the "queue image" page, there is a Reddit toggle. My thought was that we could use something similar to ask the user "do you want to post to [Reddit] yourself or may we post on your behalf?" with "auto-post on my behalf" set as a default (configurable). Toggling that radio off will show a different dialogue at the end that includes a "copy to clipboard and take me to Reddit" button instead of a "post on my behalf" button like you see in the wireframes draft. This will also be the flow for the rest of the social integrations as they come to light: twitter, Instagram, etc...
since all the shown fields look pretty balanced as-is, without the hint.
And that's because it was the extent of what I could whip together with the mockflow tools + my skills in building wireframes at the moment. I might improve these skills soon enough, but the intention for these wireframes was to have something ready for a meeting with a developer regarding the design of the Vue app and the direction I am envisioning for it. That meeting was today and the project has been kicked off, but we can still benefit by improving the wireframes. (Also, these wireframes are especially helpful in building how-to instructional images which we use in the BikeTag project for the BikeTag Ambassador playbooks).
Your feedback greatly improves the project and I appreciate you all!
AndrewPardoe
commented
3 years ago Queuing moves some of the communication from the Reddit page to the app. For that reason, it's a good idea. For example, people will sometimes ask "is anyone going out for this tag yet?" Putting this info in the app simplifies play in that it only requires a player to participate on one platform (the app itself.)
The goal is to change the interactions players have with the app and each other. The queue itself--and the timer--might be unnecessarily complex.
Interactions where the queue doesn't help anything:
The only scenario I see where a timer is needed is where you want to set a time limit on placing new tags. I think you said Houston has a 30 minute time limit to place a new tag. Personally, I prefer that the chance of being sniped acts as the natural time limit.
ykyu
commented
3 years ago @AndrewPardoe
Player A gets Found tag and sets New tag: The queue serves no purpose here. It's existence complicates the play in this basic case.
I don't think the queue complicates this case as long as the language is clear. Player A still uploads a Found and New tag. Doing it on two screens instead of one isn't worse and may get rid of this weird bug I was getting.
The other two cases just give more information to players; it's still up to players to decide how they want to play.
I'm kind of ambivalent on the idea that more info is more helpful -- I sort of like not knowing whether someone else is going for a tag and having it be "Schrodinger's Snipe," as it were, at times. Will the tag have changed by the time I get to my intended tag? Don't know until I get there! But I don't think the extra information is detrimental.
A tag has been sitting way out east for a day or so. Player A posts that they are going for the tag. Player B, relieved, doesn't feel the need to go ride for it just to keep the game going.
Player B feeling relieved seems kind of like a non-issue? I don't think games are as in danger of going stale as one might fear.
But yeah, I agree the timer is largely unnecessary (to be displayed). It's fine for it to exist, and seems necessary, on the backend as a limit on the queue and a way to flush it regularly.
AndrewPardoe
commented
3 years ago I don't think the queue complicates this case as long as the language is clear.
I'm of the philosophy that anything added to UX complicates the UX. I like your language, but I still don't see that the timer adds any value.
I sort of like not knowing whether someone else is going for a tag and having it be "Schrodinger's Snipe," as it were, at times.
Agreed. I like the metagame: does this look like a "high snipe" kind of day?
Player B feeling relieved seems kind of like a non-issue? I don't think games are as in danger of going stale as one might fear.
There are times when I've gone to get a tag out of the feeling "well, no one else is going to bother with this one, and it's easier for me." Agreed that someone will do it at some point. And with latertagging, I really do want to catch them all.
KenEucker
commented
3 years ago @AndrewPardoe
Thank you for the feedback! To be clear: not all options that you see in these wireframes are mandatory in the interface or gameplay. As we evolve the queue and work out it's more complicated details, I think we will end up with something that is both intuitive and adds value.
Queuing moves some of the communication from the Reddit page to the app. For that reason, it's a good idea. For example, people will sometimes ask "is anyone going out for this tag yet?" Putting this info in the app simplifies play in that it only requires a player to participate on one platform (the app itself.)
While some seasoned players may be comfortable, and have an account, with going on Reddit and asking these questions, I wouldn't say that doing so is actually interacting with the game. It's more narrow than that and more or less outside of the scope of the game. Adding these features to the app brings that kind of gameplay to all players and I think that is important on its own. While we use Reddit for the "discussion" of each round, there are elements to the discussion that occurs which can be, and this is our attempt to do so, brought into the gameplay. Until that is integrated with the game it remains, more or less, a nuance of some of the games being played.
It's important for me to outline the fact that the queue is not being introduced solely to address "sniping". The Seattle community is the community that I see most often uses this language and most of the other regions don't even have a name for it (because the frequency of this occurring is so low). It's happened in Portland maybe twice? The queue is being introduced for several key reasons that pertain to the process of validating/accepting/posting a newly submitted tag. The queue also presents many opportunities for the community to mold and change the game in ways that suit each region. If Seattle's ruthlessness in sniping one another is hampered by seeing a timer on the UI, you can turn it off and continue to "snipe in the blind" to your heart's desire.
Player A gets Found tag and sets New tag The queue serves no purpose here. It's existence complicates the play in this basic case.
Incorrect. Again, the queue serves many purposes. In this case, it may not affect that individual player's flow of using the app to submit their tag for the next round if no one else is involved in the current round, but their image would be queued regardless. We probably need supporting language for all 16 permutations to live inside the how-to so that the different ways that it is configured can be appropriately conveyed to end-users.
Regardless of whether or not someone else jumped into the queue before the first queued player submits their completed tag, the gameplay will change immediately for all users who expect that when they create a new round on BikeTag.Org that it will show up immediately on the homepage. This will no longer be the case. Because of this, users will need to be placed into a queue while the BikeTag Ambassador has their own availability to approve/post the new round, and they will need to know that they have been placed in a queue. Again, regardless of whether or not the information provided to them makes their experience better, the queue remains and the game should adapt to the fact that the queue exists.
The game shouldn't just pause because one person queued an image. The queue must exist, thus, a player will be forced to queue their found location. If a user submits a new tag and then the round is "sealed", but the BikeTag Ambassador doesn't see the email notification within (X) minutes, then no one can continue playing the game for that same X minutes until the new round is posted.
Player A gets Found tag. Player B checks the app, sees that A has Found tag. Displaying the fact that A has Found tag gives information to B. Does B want to grab Found tag and set New tag quickly? If so, the queue may help B snipe A. If B was intending to grab a Seattle tag and move it to the Eastside, B may decide not to bother playing.
Also incorrect, from my perspective, but I may need some more discussion around this to see your point.
If player A goes to the app and queues the current tag, and this is the important part, and wants to open up the possibility to be sniped by player B then player A can choose to queue their image as soon as they take the picture at the current mystery spot. If player A wants to not be sniped on the current round, they can just go to their new mystery location and upload both the found and new mystery images at the same time. This eliminates the notion of "the queue may help B snipe A without A's consent to be sniped". Everyone is privileged to a spot in the queue if they play the round in a reasonable amount of time, but no one is privileged to the first spot in the queue.
If player B hasn't started playing yet, sees that an image has been queued, and intended to move the tag farther away then gives them time to get on their bike and bike to the current mystery location, then B can just get over it. I don't see any reason why player B is owed anything in this case just because they were hoping to move the tag far away today. Player A is first and thus the queue respects them for being the first to queue. If player B was first to get the current mystery location, and then sees player A queue first (because B wanted to play "in the blind") then at least B knows that their sneaky strategy is being actively foiled and it gives them an opportunity to maybe not go as far as they planned and just win the round if they can.
Player A gets Found tag. Player B gets Found tag. Player A sees (or gets notification) that B has posted Found tag. A must decide whether to quickly set the New tag or continue to their intended tag, increasing the chance of B sniping A.
This is mostly correct, in that anyone can be sniped at any time before submitting a completed tag. That is true now and will remain true for... forever? There's really no way to ensure that people can protect themselves from being sniped. The queue doesn't add that protection for the "first to queue" nor does it add that protection for the "last to queue". The queue simply adds a way for others to choose whether to go out on a 15-mile bike ride with a goal in mind only to find out, 5 miles in, that there's "nothing to gain anymore". The queue, even in this case, can offer more to a player playing the game than the game currently offers. That player can still jump into the queue if they are fast enough to do so before the tag is completed, which, I believe, is enough for most people who have been "sniped" to feel included as much as the "winner".
It is my hope that the queue will be looked at more as a way to join others actively playing the current round, today, and to see the game being played in realtime, anytime; rather than a way for players to gain an advantage over one another.
KenEucker
commented
3 years ago More comments:
A tag has been sitting way out east for a day or so. Player A posts that they are going for the tag. Player B, relieved, doesn't feel the need to go ride for it just to keep the game going.
While this might create a case in which no one completes a tag that day, because something came up and player A didn't complete the tag and player B chose to never leave the house, I am certain that the queue is not intended to help with games going stale. In the slight chance that this occurs and the queue somehow makes the round last longer that would be hilarious. I look at this from a completely different perspective, though, in that the queue could be used to incentivize players to complete a stale round.
There are games that were started in the last 3 years that have gone stale. While I track those subreddits, I haven't involved myself in a conversation with those communities to attempt to revive those games because I have nothing to offer them; (the app doesn't suddenly make a tag location easier to find, I don't live in that region, the game was started by other people...). When we implement the queue, we could introduce incentives for 10 people to all go out and search for the current mystery location by doing something like the following:
"Hey there [Miami BikeTag], the last round has been sitting for a while so we wanted to try and encourage the round to move ahead by offering BikeTag stickers to anyone who is able to join the queue this week!", then the BTA could set the queuetime to 1 week and start it immediately (or go out and queue the tag to incentivize even more). This is a way to use the queue to allow people to play the game in a way where "winning" the round isn't even the goal.
Latertagging (though this would be an easy modification)
@AndrewPardoe. It isn't discussed here at all but I wonder if you mean that the queue introduces an opportunity to record latertagging? I don't fully understand what you mean by the term latertagging and would love a definition. I've talked about the option to "RE-Tag" a previous round, which is to Retrieve an Existing Tag. Retagging would allow completionists like yourself to "catch-em-all" and be able to have that credit be reflected on your player profile. Maybe that's the same thing you're thinking of? With RETagging, the queue isn't really involved. What the queue does introduce, however, is a way to record if you've been sniped, which is based on the same information you might be thinking.
I'm kind of ambivalent on the idea that more info is more helpful -- I sort of like not knowing whether someone else is going for a tag and having it be "Schrodinger's Snipe," as it were, at times. Will the tag have changed by the time I get to my intended tag? Don't know until I get there! But I don't think the extra information is detrimental.
@ykyu exactly, and you can still Schrodinger snipe APardoe anytime you want by just not queueing your tag until you're ready to submit the completed tag all in one go. The extra information, for someone like you, doesn't change your goals in playing the game. I think, from this perspective, what the queue does is help those who might really be excited by the game remain involved and excited in the game instead of the current use case of "Well, every time I get on my bike to go play BikeTag I always get sniped by u/kiriska so I'm not going to try anymore. I will watch the game because it looks cool, but I can't find a way to participate :("
But yeah, I agree the timer is largely unnecessary (to be displayed). It's fine for it to exist, and seems necessary, on the backend as a limit on the queue and a way to flush it regularly.
The timer wouldn't necessarily exist in all queue configurations. While the timer is active, displaying the timer really is only for players playing the active round. When the timer is not active, then users don't see a timer. When the queued has been "sealed" by the presence of a completed tag, users will still have the option to complete their tags up until the winning tag is approved, but they will see no timer. While this would result in discarded "new mystery location" images, for those users who did not "win the round", it opens up the ability for BikeTag Ambassadors to run game events in which the first to complete a tag is not always the winner. (imagine playing a "riddle" version of the BikeTag Game where users must also answer a riddle when they complete their tag. Only the first person with a completed tag AND the correct answer to the riddle would be designated the winner).
The timer won't be tracked on any server, as we run a no-database strategy that I am fond of, so there's no need for it to exist on the backend in any way. We are able to read the data to infer the state of the game, so there is either a timer based on the configuration of the game or there isn't based on the data present in the queued image album.
I feel like the intent of the timer is being lost here, the timer is for players to interact with one another. If a default time of 30 minutes is set for the game and players cannot modify the timer upon submission, then the timer doesn't need to be displayed as long as the queue is configured to be auto-accepting of the first completed tag. In this case, there's no time limit on anything but completing the tag (which can be explained to the user without "timer" language and without showing a time on anything, and they can requeue each time the queue expires as much as they need to).
IF a region has the queue configured to allow users to set the queue time, (more advanced use of the queue), then the timer will show for every single round that is played once an image is queued, regardless of what the user sets the timer to, until the round is "sealed". In this case, players will be encouraged to set a queue time that reflects the amount of time they think it will take them to submit the completed tag. The purpose of doing this is to interact with other players of the round.
IF a region has the queue configured to 1 hour as a default time and users cannot set their own queue time, because the BTA "needs at least an hour from getting a notification to be able to respond to the game", then a timer isn't exactly needed to show the end-user about their involvement in the game as much as it is a way for the BTA to say "this tag will be accepted in one hour".
You see, currently, when a tag is submitted on BikeTag.Org the following happens:
Because of this, the user flow feels like:
The truth in the matter, of what occurs on the backend with BikeTag.Org and Imgur.com, in conjunction with direct interactions from a human being (BikeTag Ambassador or... me), is that the process looks completely different on our end:
The implementation of the queue will change the process for everyone involved, both players and BikeTag Ambassadors. Most importantly, however, is how much it will change my life. I can go on vacation?
Because of the changes, and the complexity, involved, this will be a slow rollout in which BikeTag.Org plays catchup to the queue functionality implemented in this BikeTag Vue App. At the point in time in which the BikeTag Vue App has been properly vetted by the people involved in this ticket (which will track the progress of this 6-month project), we will roll out the App as the primary way for people to play BikeTag for all BikeTag.Org regions.
Given how much of the work on this project ends up being completed by myself, and the fact that if I were to get hit by a car on my bike that BikeTag.Org would just crumble and fall without my constant attention and deeply embedded operating knowledge. Given that I do, in fact, get hit by cars on a frequency higher than 0 per year, these changes are for the better of the project. Since I am the only person dedicated to the development of this project, and I failed to meet my featureset goals for 2020, I have chosen to invest $200 of my own money, while unemployed in a pandemic I might add, to commission the scaffolding and delivery of a working prototype for the BikeTag Vue app which will become the new way to play the BikeTag game for all BikeTag.Org games.
This will be a tiered rollout that will not replace BikeTag.Org until feature parity is reached and we are able to implement broader systems for the BikeTag project to manage it's API and server implementations. Future plans include the ability to play or view more than one region within the app, but the app that you use/download will be region-specific until it can replace the global view that BikeTag.Org has been offering the community. Expect to be able to play the game using the BikeTag app later this year, but know that the gameplay on BikeTag.Org, as far as I can see right now, will move slowly and remain mostly in tact until 2022.
AndrewPardoe
commented
3 years ago @ykyu, here's an example of what I meant about "being relieved". In this conversation one player is urging other players to go grab this tag. Again, not a big deal--we're not going stale around here!
@KenEucker, by "latertagging" I mean picking up a set of all the tags that have ever been placed. If I queue a tag, but don't finish the round before another player (or the timer, I guess), my queued tag could still be used as an entry in my complete set of old tags. Also, I could "queue" for an old tag that's already been claimed as a way to submit it to my latertag list. This would only be if you wanted to support latertagging in the app.
KenEucker
commented
3 years ago @AndrewPardoe Ahhhh, okay, I see. Your idea of "latertagging" is a little bit of a misconception of the queue. The queue is only for those who competed in the round. While "once queued, always queued" seems like it would give you what you're looking for in terms of "latertagging", I feel that is out of the scope of the queue.
What the queue can do is hold on to all tags that participated in active rounds. This means that some people, who participated in a queue that expired but did not "requeue" during the winning queue, will lose out on their participation being tracked here but I don't think that is as much an edge case that would be useful for capturing the data in this way. I'm currently building a new BikeTag event for this spring/summer, which I plan to come up and run in Seattle, that will use the queue in such a way as to allow players to "retag" older tags within a queue that would do this sort of capturing of an edge case. So there's that.
I believe the primary way that players will be able to "latertag, as you see it with how it will be implemented, outside of the queue and outside of a queued round for an active game, would be to submit a "retag" which will be a completely different ui allowing a player to submit a tag attributed to an existing player only (their verified account). In other words: you have to win a round, or in Seattle's case -- be allowed to win a round, before you can "retag".
That feature will come after we begin to implement "badges" or "awards" in order to utilize the data that will tell us just how much you, @AndrewPardoe, have completed the BikeTag game. I look forward to when the app is stable and the process is as automated, running smoothly, as possible; because that will allow us to start implementing some more of this fun stuff we have on our roadmap!
ykyu
commented
3 years ago @AndrewPardoe
@ykyu, here's an example of what I meant about "being relieved". In this conversation one player is urging other players to go grab this tag. Again, not a big deal--we're not going stale around here!
Oh, yeah, I definitely didn't mean that feeling relief never happens, only that it's a non-issue. Players preferring that other players pick up a tag that's inconvenient to them will always be a thing, but I think that's kinda irrelevant? There will also always be other players (me) who want to bank on others not wanting to go after a tag as a reason to specifically go after a tag, lol. (Though I clearly misjudged Ikea being an "inconvenient tag.")
I love latertagging as a metagame but yeah, it seems out of the scope of the intended purpose of the queue and seems better as something to implement further down the line.
KenEucker
commented
2 years ago Wireframes were handed off to a designer.
A user analysis was done on the new app with amazing feedback.
The final design and style guide to be delivered for this app next week!
I've created the following wireframes for the initial user flow design of this project. The menus, buttons, icons, fonts, images, and placement of all items are subject to change. Ideally, these would all be designed to be a single, coherent, design where the items make sense together.
For all assets, use the items provided in these issues if something is available that works: https://github.com/KenEucker/biketag-website/issues?q=is%3Aissue+is%3Aopen+label%3Adesign
Specifically, these items: https://github.com/KenEucker/biketag-website/issues/96 https://github.com/KenEucker/biketag-website/issues/79
First (rough) draft of the wireframes: BikeTagApp_WireFrames.pdf