-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: update blip drawn coordinates to be in ascending order within rings #311
Comments
I was going back through the Tech Radar PDF reports archive earlier today, and it seems that this ordered behavior was first introduced in the official reports from Volume 10 onwards. |
Thanks for this, @setchy! This is on my "radar" too in terms of new features. I'll chat with the team about it. |
Thank you so much @marisahoenig! |
Hey @setchy! Following up on this, as you noted, we have this behavior in the official TW Radar. I'm going to explore how easy it is to carry over that implementation into BYOR and try to implement that. But, it's worth noting that the rest of the team is currently working on other features for the Tech Radar and this is not at the top of my list at the moment, so it may be a few weeks until we can get this update in. I'll keep you updated as I work on it. Cheers! |
Thanks @marisahoenig for the update. If there is anything I can assist with, please let me know. Otherwise, I'll keep my eyes out for further updates 👀 😄 |
Hi @marisahoenig - any hints on what logic changes might be required to support this ordering of blips? Happy to lend a coding hand to implement if I can be pointed in the direction used by the TW public radar |
Hey @setchy. Sorry for the delay. It would be awesome if you have time to work on an implementation. I realized our internal codebase and BYOR have some underlying differences, all the way down to the programming language (internally, it's in Ruby). So, the implementation will need to be different regardless. Before we display the Radar, we need to sort the blips by quadrant and then by ring (the final list should be alphabetized within each ring). Internally, we sort the blips and then put them all in a JSON to display. For BYOR, users have the option to use a JSON, which I think would be the perfect use case for this. However, it would be great to make it work for the CSVs/Google Sheets too. I think this logic may need to live in the |
I've had a quick POC and although I've sorted the blips alphabetically, I sense there is more too this. My hunch is that it's within the way the blip coordinates are calculated - ie:
I've tinkered with different Is there anything special about how the internal implementation handles blip coordinate and collision detection? |
Oh, super interesting. Yes, this definitely has an impact. Internally, we automatically figure out the theta of each blip, but we manually control how close/far a blip is from the center of the Radar (the radius). This is because how far/close the blip is actually has some meaning for our volumes. However, it looks like we have the location automatically randomized for BYOR — both the theta and radius. I think BYOR would need to:
|
PR #322 raised for drawing the blips in numerical order |
I've also split the alphabetic sorting of blip names into #330 |
I noticed there is a difference between the order / placement of blips when comparing the latest official Thoughtworks Tech Radar - Vol 27, vs the BYOR Radar using the Vol 27 sample dataset
On the official Thoughtworks Tech Radar the blips are nicely drawn in ascending order from left to right within each ring.
While on the BYOR version, the blips are randomly drawn within each ring.
This random placement within the BYOR version makes it harder for users to locate the blips.
This issue is to update the BYOR implementation to match that of the thoughtworks.com/radar and make the drawn positions more predictable / orderly.
The text was updated successfully, but these errors were encountered: