@jounih , I agree – tags don’t work well and it’s not easy to relate them to the addresses : ) Initially, I wanted the address tagging solution to be generic enough so we wouldn’t have to throw it away once we get user profiles & org identity right. Also, whatever solution we go for needs to still be relevant after that, as we cannot count on everyone creating a profile, so labeling address will stay useful after we deliver the full identity story.

Another aspect that I think is really important, is to not give users the misleading impression that addresses can be edited… That’s why I was concerned about using the address badge to display a name… but now I think that using the popover title solves this issue. However, we must create clear component guidelines to ensure the address badge and popover are used consistently across apps.

So I’ve been working on this a bit more and I created 3 journeys:

• Add custom label – Users are be able to click on any address badge to open the address popover, then add a custom label (i.e.: their name) and this action allows other apps to use this information (that way we combine the ‘adding label’ and ‘giving apps permission to use it’ into one step). Then, the address badge and popover will display this custom label in place of the address.

@jounih , I agree – tags don’t work well and it’s not easy to relate them to the addresses : ) Initially, I wanted the address tagging solution to be generic enough so we wouldn’t have to throw it away once we get user profiles & org identity right. Also, whatever solution we go for needs to still be relevant after that, as we cannot count on everyone creating a profile, so labeling address will stay useful after we deliver the full identity story.

Another aspect that I think is really important, is to not give users the misleading impression that addresses can be edited… That’s why I was concerned about using the address badge to display a name… but now I think that using the popover title solves this issue. However, we must create clear component guidelines to ensure the address badge and popover are used consistently across apps.

So I’ve been working on this a bit more and I created 3 journeys:

• Add custom label – Users are be able to click on any address badge to open the address popover, then add a custom label (i.e.: their name) and this action allows other apps to use this information (that way we combine the ‘adding label’ and ‘giving apps permission to use it’ into one step). Then, the address badge and popover will display this custom label in place of the address.

• Manage labels – These custom labels can be managed from the user preferences modal and should be persistent across orgs visited from the same device. Users can import / export a .json file to share the custom labels that they created locally with other “members” of their org.

• Address badges – Users can choose what data source (locally created custom labels, 3rd party identity providers and Aragon user profiles in the future) is used to populate the address badges. We can use the 3Box API and ENS to automatically label the badge if the address is found on one of the providers. Also, they can reorder their preferred data source and change it over time. If none of those 3rd party profiles exist, then we default to the custom label or shortened address.

So I’ve been working on this a bit more and I created 3 journeys:

• Add custom label – Users are be able to click on any address badge to open the address popover, then add a custom label (i.e.: their name) and this action allows other apps to use this information (that way we combine the ‘adding label’ and ‘giving apps permission to use it’ into one step). Then, the address badge and popover will display this custom label in place of the address.

https://youtu.be/sSBRO5FxAU8

So I’ve been working on this a bit more and I created 3 journeys:

• Add custom label – Users are be able to click on any address badge to open the address popover, then add a custom label (i.e.: their name) and this action allows other apps to use this information (that way we combine the ‘adding label’ and ‘giving apps permission to use it’ into one step). Then, the address badge and popover will display this custom label in place of the address.
  https://youtu.be/sSBRO5FxAU8

• Manage labels – These custom labels can be managed from the user preferences modal and should be persistent across orgs visited from the same device. Users can import / export a .json file to share the custom labels that they created locally with other “members” of their org.
  https://youtu.be/VcRh_Hyz1AA

• Address badges – Users can choose what data source (locally created custom labels, 3rd party identity providers and Aragon user profiles in the future) is used to populate the address badges. We can use the 3Box API and ENS to automatically label the badge if the address is found on one of the providers. Also, they can reorder their preferred data source and change it over time. If none of those 3rd party profiles exist, then we default to the custom label or shortened address.
  https://youtu.be/Zptyk-HzVsE

The copy is still not quite right and there’s some screens missing but I think this works better than the tags. We can have a review on Monday and discuss further. I’m not totally convinced with having a modal for managing the preferences because I think it won’t scale well over time, but I guess it’s ok for now given that we only have 3 tabs.

Here’s the Figma file: https://www.figma.com/file/5QZ1KXczHAQhmTlUVDz8jv/Identity-/-Custom-labels?node-id=42:2

• Manage labels – These custom labels can be managed from the user preferences modal and should be persistent across orgs visited from the same device. Users can import / export a .json file to share the custom labels that they created locally with other “members” of their org.
  https://youtu.be/VcRh_Hyz1AA

nice! This is looking good @dizzypaty - let’s go through on Monday. We can have preferences full screen too

@ricburton The reason you are getting this feedback is because, in a multisig organization, the maximum number of tokens that you can assign to a given account is one, but this is not explicitly communicated before users try to take the action. You have a good point and it’s something we should discuss. If you want to assign more than one token per person, maybe you are looking for the democracy template.

@ricburton The reason you are getting this feedback is because, in a multisig organization, the maximum number of tokens that you can assign to a given account is one, but this is not explicitly communicated before users try to take the action. You have a good point and it’s something we should discuss. If you want to assign more than one token per person, maybe you are looking for the democracy template.

i think we should add some extra copy telling the user that the limit is per account and not per organization

which i think it is the message that one gets from reading that error message

Thanks for letting me know, @dizzypaty. We are experimenting with Aragon to run some of the functions of Balance. We hope to use as much of the tooling as possible and eventually move the vast majority of the organisation into a DAO.

@ricburton thank you for the feedback! I’d be really interested in understanding better your plans for using Aragon – would you be up for a call about this?

Glad you put this in the designs – this means that the TPS Address Book can also be hooked up here?

since the address badge have avatars, wonder if it would also be appropriate to attach a directory instead that includes json file and a folder of images? like in the json file it can have the image reference. not sure if that’s overkill, i can just see some people possibly wanting to customize that too, and if it’s easy enough to support, might as well.

since the address badge have avatars, wonder if it would also be appropriate to be able to attach a directory instead of a file. The director contains the json file and a folder of images? In the json file it can have the image reference per address. not sure if that’s overkill, i can just see some people possibly wanting to customize that too, and if it’s easy enough to support, might as well.

since the address badge has avatars, wonder if it would also be appropriate to be able to attach a directory instead of a file. The director contains the json file and a folder of images? In the json file it can have the image reference per address. not sure if that’s overkill, i can just see some people possibly wanting to customize that too, and if it’s easy enough to support, might as well.

since the address badge has avatars, wonder if it would also be appropriate to be able to attach a directory instead of a file. The directory would contain the json file and a folder of images? In the json file it would have the image reference per address. Not sure if that’s overkill, i can just see some people possibly wanting to customize that too, and if it’s easy enough to support, might as well.

Yes, I think it could potentially be another data source that users can choose from to populate the address badges. However, we still need to discuss how to handle those APIs and that part of the design will be implemented later (we are considering it a nice-to-have). For the first iteration we’ll focus on allowing users to add the labels from the badge popover and the import/export functionality in the global preferences.

@yalda Potentially, yes, you could create an “identity provider” that uses the Address Book (if the organization has one installed) to resolve addresses. Still working out what the API would look like, but I imagine they’d also be aragonPM packages that are “installed” (it’d be nice if they didn’t have to be on-chain, so this is another great use case for the organization metadata)

In the designs, the avatar you see is coming from the service provider API, i.e.: if you added a pic to your bio in 3box and we hook this service as a data source, the address badge could use it. We won’t plan to add this functionality now for the custom labels but the address badge component will support it so it can be something we add in the later.

@aquigorka here’s the update custom label preferences (with mobile versions too) https://www.figma.com/file/5QZ1KXczHAQhmTlUVDz8jv/Identity-Custom-labels?node-id=239:277

@aquigorka here’s the updated custom label preferences (with mobile versions too) https://www.figma.com/file/5QZ1KXczHAQhmTlUVDz8jv/Identity-Custom-labels?node-id=239:277