Made an edit to be more specific.
Great to hear itās finally on the roadmap!
Will you allow for customisable pen boundaries when ranking comes in? Do you envisage that ranks are the āonlyā way to sort a pen, and if not, will customisable pen boundaries be developed for other pen-split methods?
Again one of the data points we are seeing quite clearly from the mass of ranking data we now have - and something that we kind of knew intrinsically, is that variety across races for how pens are determined is really key to great experiences. If your ranking is really accurate, but there are only big static thresholds used to determine pens, you will end up having the same repeatable race experience that you have today. Allowing for variation is critical.
Weāve also found that doing better than expected is more rewarding for more people than just doing well within a race. If someone feels rewarded for coming 28th (because they were expected to come 34th) that is really powerful, rather than simply scaling reward based on finish position. Of course quality of riders that you beat then determines the severity of your ranking increase (also depending on the confidence level of your existing rank).
Thanks for the update @xflintx, I initially read āScoringā and assumed it meant scoring within a race - i.e. sprint/KOM points and the like.
Reading again that doesnāt seem to be the case, but is there any work going on to move the segment points system out of Zwiftpower and in to the main client so that we can have live scores in a race, as I feel like Iāve seen in some of the elite broadcasts?
Thatās the current thinking, yes; regardless of what method we use to rank or score a race organizer (Zwift, community, etc.) should be able to set the limits of a pen/subgroup to fit their needs.
As Iāve said before, I think you and I (and many others who are probably just lurking) have the same ethos in mind in that regard. At the end of the day people need to feel like they have something to chase when they race, be it a podium, simply finishing in the top half, a ranking upgrade, whatever. The scoring and ranking system should facilitate easy identification of your progress and provide you a platform to find the meaning in your racing as your goals and your fitness evolve.
At least thatās where I hope weāre both coming from
This 100%. Iām always happy to see as many riders of all abilities show up as do for our uncategorized Herd Winter Racing series. Iām fighting for 30th place and quite happy on most courses - when I was in shape, was duking it out in the top 10 on courses that suited me.
Great news!!!
As a race organizer - I donāt want to move it out of ZwiftPower, I want to LINK ZwiftPower and the Zwift event. I do want the live scoring, but I donāt want to have to do a change request with Zwift Support to set it up.
A new tool would be fine, obviously, but as @stuart_lynne said - ZwiftPower is great as it is. It does NOT need graphic design.
@xflintx This all sounds really promising and encouraging. As an advocate of what has been worked on and discussed at zwiftracing.app it great that you are looking at this method too.
My only slight concern is some of the feedback you may get on your ranking system. Some of the loudest voices complaining about zwiftracing.app ranking system are those that will no longer sit at the top of a category winning week in week out. Which is exactly why a success based ranking system is needed. Hopefully you can work out what is good feedback.
Final question. Is this to be implemented this season? Or do we wait until winter 2023?
Zwiftpower has lots of useful information, but it isnāt really that great. Racers shouldnāt have to look at a website after the event to find out what their result was, it should be right there in the game and actually include ALL of the riders in the race, not just those who ticked a box somewhere.
Zwiftpower is also a pain in the rear-end to use as a race organiser. There is plenty of room to improve the management of race scoring/rules/series etc and it should be done in one place.
As a race organiser I can already set my route/laps/(some) rules in the event management system without submitting a change request so it makes sense to do more in that.
i agree results should be available in game through companion or zwift client itself but I would still like to see a website version available with the full data like zp has.
Whether that is what zp is called now or some other url on zwift does not really make a difference as long as the functionality and data is all there.
Companion is fine for looking at a single result and having to start up zwift itself is a bit silly so a web based results system is still top priority iād say.
Iām with Sandy on this one. Zwift Power is outdated, buggy, and not really intuitive. The best place for all of that info is in the Zwift ecosystem designed from the ground up, but ideally without any reduction in capability / available data. That is probably impossible for early instances.
Ideal situation is things like results, profile information, etc is native in the game, and then the bigger data pieces (leagues, data analysis, dashboards, organiser controls etc) live in a Zwift racing web portal.
It isnāt great. Iām talking about the data presentation and data analysis that it allows, and how you can get to just about every bit of data from a race in 2 or 3 clicks.
The Primes table is still sideways for some bizarre reason, but other than that, itās pretty goodā¦
Zwiftpower should become the Zwift version of TrainingPeaks for the end user - Single pane of glass where all Zwift data can be interrogated and viewed. Its basically needs to include a boat load of power bi graphs for the end user to show a mixture of Intervals.icu & TP.
Race organisation needs to be created within Zwift and simplified over the current spaghetti junction of options within Zwiftpower.
@xflintx Thank you for some very useful, open and honest replies to this thread. Iām very encouraged. More transparent communications like this, please!
I agree with Stuart
Is there scope to implement dual recording requirements within races, with both power sources being connected through Zwift? It would make it much easier for race organisers, and would help to avoid unintentional DQs when someone forgets to push āstartā.
This is entirely different in a fashion, but isnāt something that is in scope (although I absolutely see the benefits) - it would be a significant functionality change.
My one suggestion here is to put the API at the center of your plans. Make the API first and have Zwift developers use the same API that community developers access. Implement every feature on top of that API and donāt work around it. Think about the authorization, rate limiting, scope of access for different use cases, and privacy issues in the API from the beginning. Enable event organizers and developers of third-party visualization systems to do what they want to do via the API. Version the API so that significant changes donāt break software built on top of an existing API version, and communicate the capabilities and changes through developer documentation.
Although if a comprehensive API was provided then Zwift would not need to build anything as the presentation could be built by external contributors, with natural selection probably choosing the best. If you build it they will come.