When I add a friend, I hope to add an extra note telling me who is this person, or other important information. Otherwise, I won’t remember it, especially when we are not familiar with each other.
This would be a useful feature with respect to Blocks too. At this stage I guess we just need to keep our own notes though I’m not sure I would call someone I’m not familiar with a ‘friend’!
But OGS calls them a friend as soon as you add them even though they aren’t what you would call a ‘friend’
I wonder if it would suffice to have these sorts of notes be device-specific, or do we have to save them in the back end?
Back-end would be better as it’s not something that varies from device to device. “I only like you on my phone!” but it would still have some value as a front-end feature.
Front-end would inevitably result in queries as to why the info has ‘disappeared’ though.
If it works well as front-end, is it easy for anoek to incorporate it into back-end?
Kosh beat me to it but yeah just seconding, account bound rather than device bound makes the most sense.
As you both know, I wasn’t really asking “what makes sense”, but rather exploring whether a device-specific implementation would in some sense “suffice”.
That said, there has been an idea floating around for a while, which is “generic key-value-pair store”, which if implemented in the back-end would allow this sort of thing to be added at an account level without further back-end work.
I wonder if we are reaching the point of enough ideas like this being on the table to make it worthwhile, @anoek?
Hard to say. It would certainly be more useful than no notes at all, but at the same time it would also
Difficult to say whether the benefit would outweigh the cost…
I’ve not heard of this before, is it basically a string that you can copy from one device to another and it copies over the relevant data pairs/settings that you desire to be universal? or is it some background protocol that is more flexible and allows multiple front end features to piggy back on the same code?
The latter. It allows any front-end feature to say “I need to store this account based information”, and do so in the back end, without the back-end having to know what that info is for.
Excellent. There are definitely a lot of desired features that would benefit from that… hopefully the workload to add it in isn’t too high
On the scale of things it’s a very small back-end update.
There are pros and cons of adding it to the API.
One thing it would do is allow more diversity of client experiences - clients can start implementing non-game-mechanics features as they see fit. Diversity vs control
Essentially meaning the extra freedom the users have means we have less control over the overall UX? (just making sure I’m understanding you correctly)
Yes - for example, phone-app writers, and other-website-integrators (eg Baduk Club) would be able to do more and various things.
I mean… is our current UI/UX that polished that this is really a major concern? Maybe they could even implement some stuff that we can yoink kinda free, scattershot, beta testing that we’re not responsible for haha
Already some neat ideas have come from the apps, such as the in-line chat gobans on the iPhone app…
I didn’t mean to indicate whether I was concerned or otherwise, only pointing out what factors go into deciding whether to do it or not … just clarifying that I’m not taking a position on it, but I’m aware that it is a decision of this nature.
This thread feels like deja vu
many features have been loooong requested on this site, often accruing several threads over that time
Not just the request- even the comments are similar haha
Generic API support is a new one though. Cool. I didn’t even think about how third party clients could implement backend stuff that isn’t even on the site. I guess they can kind of already do this by setting up their own microservices, so I assume the main benefits are for developers of the official web client.
@GreenAsJade online-go.com/remote_storage.ts at devel · online-go/online-go.com · GitHub I put this together and put it up on the beta server. It’s fairly naive at the moment, no smart caching or syncing, it’s not clear to me if we need to go down those more complicated paths or not, it might just be best to keep it simple. I reckon we can try this out and see how it feels and go from there though.
It also makes it a ton easier to do account specific features because you are already logged in to ogs and this getting authenticated user data, as opposed to having to work about that is your own back end (which for example OJE had to deal with)