Aragon One product scope for 0.8

Major Aragon releases always try to include big items that make the user experience qualitatively better.

This is A1’s take on the items that we will focus for this release.

Timeline: Mid-July


In scope

Visual revamp for the Aragon client

A visual revamp proposal is being worked on by our design team.

Fundraising app

Intro

As it was planned and designed since the very first versions of Aragon.

Initially, we thought on building a very basic fundraising app in parallel to Aragon Black’s, but we think that it’s a better use of time to focus on Aragon Black’s initiative too.

Action items

UI for the Agent app

Intro

Agent allows Aragon organizations to interact with other contracts as its own entity. However, Agent is just accessible through aragonCLI right now.

Action items

  • Update the outdated design
    • Update to latest design system
    • Remove “browse dapps” tab
    • Remove “external contracts” for now, just do token balances and past transactions
  • Requires: at least a basic version of the Radspec registry
    • Or at least the function name (e.g. how MetaMask does it)
  • Integrate functionality to create transactions through the Agent into Frame. That will serve as a reference implementation for other signing providers to adopt

New onboarding

Intro

The current onboarding has some issues:

  • There are just two templates, and they are a bit confusing for users
  • Creating organizations requires two transactions

Action items

  • Revamp the onboarding experience
  • Revamp the onboarding templates
    • We should include not only templates with the default apps, but also with the Fundraising, Pando and TPS apps

Email notifications

Intro

This becomes essential when organizations are holding important assets or funds. Even more so when the Aragon Court is out. We should look into ways of providing real-time notifications.

This will just be email, no desktop/browser/ push notifications for now.

Related thread

Action items

  • Implement a screen in the client as an app or as part of preferences
    • Select which apps and events a user wants notifications on (a lot of apps organize this by "triggers" and "notification channel")
      • Need email authorization flow for subscriptions (ask supplied email if they’d like to subscribe)

UX improvements to the Voting app

Intro

The current voting experience could be greatly enhanced by including UX wins from our Survey app.
There are some issues we have detected:

  • The right panel is too small to display all proper information about a vote. Votes are important and should take the whole screen
  • Users want stats of the votes over time

Action items

  • Redesign app with survey UX
  • Implement modifying suport and quorum
  • Write human-friendly copies for support and quorum

Finance app features

Action items

Permissions UX enhancements

Intro

Aragon permissions are what makes Aragon great and fundamentally different from old-school legal entities.

However, being quite a new paradigm, users struggle. We have collected great user feedback, and it feels like it’s time to enhance their UX.

Namely, they struggle understanding:

  • Permission managers
  • What permissions an app has, vs which permissions are set on it
  • What are EVM scripts/kernel/other technical terms that are just mentioned in the Permissions app

Action items

We have collected great user feedback, and it feels like it’s time to enhance their UX.
Permissions should allow any user to intuitively understand what is the hierarchy and structure of any given Aragon entity.


Removed from scope

Aggressive caching

Intro

Loading an organization created 6 months ago and with more than 100 votings takes several minutes. This hurts user experience.

We should look for ways to make the first load almost immediate, and then increase trust over time when the client is able to verify more and more of the organization’s state. We could look into tradeoffs between centralized/decentralized.

Action items

  • Research and implement centralized state caching solutions that gradually lead to a fully trustless state over time

Reason for removal: Bandwidth

Voting

  • Allow to export votes in CSV
  • Allow to see all votes casted / voting analytics

Reason for removal: Bandwidth

Finance

  • Budget per token per accounting period
    • Notify user in UI of their accounting expenditures (how much is left, possible to make payments)
    • Important for users: No priority for payments, basically a race to get money out and other payments need to wait
  • Recurring payments
  • Pausing transactions:
    • Right now the contracts don’t support fully removing payments, so they can only be “paused”
      • Show all paused payments as if they were “archived”
    • In the future we can add full removals in to the contract to allow users to “delete” payments
  • Investigate ways for an organization to analyze budgeting
  • Investigate ways for an organization to analyze their expenditure

Reason for removal: Bandwidth

Optimistic UI

I think this is not that important with the Activity panel, but worth mentioning anyway.
Still needs design research.

Reason for removal: Bandwidth, design needed

Improved feedback for pending actions

Context: Showing Pending (Forwarded) Actions in Apps

Reason for removal: Autark will be the ones leading that effort

Meta-transactions

So users wouldn’t have to hold ETH or pay for transactions inside a given organization.

Reason for removal: Postponed since it needs smart contract upgrades, we will bundle them in a future release

Global kill-switch

Way to opt into an aragonOS global kill-switch that pauses contracts if a critical bug is found on them.

Reason for removal: Postponed since it needs smart contract upgrades, we will bundle them in a future release

13 Likes

Is this a Frame specific functionality or would users of other Ethereum providers e.g. MetaMask or Status Browser also be able to make Agent transactions?

It’d totally work on them too, but it’d need custom integration on their end

Is this something that would be appropriate for an EIP?

Usually the coordination cost of going through an EIP is way higher than just building something that gains adoption and becomes a de facto standard.

2 Likes

Who has the authority over the kill-switch for aragonOS? Seems very dangerous and centralized to me, if controlled by a central operator.

What coordination cost? You just define the standard and publish it in the EIP repo. The feedback process would be the exact same as if it were published in your own repo, and you get more visibility because it’s in a repo that a ton of devs look at for guidance on Ethereum-related standards.

I mean the possible back and forth with many different stakeholders who may like changes to the original implementation for it to adhere to their needs.
Anyway this is something that I think Frame should do/should be done at the signing provider layer.

My guess is that it would require a certain amount of ANT-weight to get activated. MKR has a similar process whereby if 5% of MKR-holders hit the kill switch the system goes into an emergency shut down. So that can mean one person holding 5%, of five people holding 1%. It’s not a perfect system because an attacker could theoretically borrow 5% of MKR, activate a shutdown and short MKR and make some profit. But, at the same time, a shutdown doesn’t necessarily mean a price drop since it is only temporary and it’s not easy to get your hands on 5% of a token’s total supply. You bring up a good point though, and I would be interested as well to hear what the plan is for Aragon’s implementation of this.

1 Like

It will be great to see a fundraising app on Aragon again. I should point out though that it seems Apiary will actually support a “traditional” token sale structure, so you may want to sync with them and make sure this other fundraising app wouldn’t be made redundant by this.

Good to know, I’ll certainly sync up with them. Even with that, there’s some front-end development that may need to get done, since we probably don’t wanna have a complex frontend (w/ bonding curves and stuff) for the simplest fundraising

We are still designing the mechanism, @facuspagnuolo from our team (cannot find his handle right now, will update later) is the one doing that now. Hopefully it will be decentralized enough so not a single entity can trigger it.

1 Like

This will always be designed and implemented as an opt-in, user-overridable feature:

  • Your organization is only hooked up to the killswitch if you want to
  • In the event of the killswitch being enabled, you can always override it locally in your organization to regain access

This is primarily something we (other Flock teams, security partners, etc.) would like to invoke quickly to prevent loss of funds or other dangerous behaviour while we’re coordinating on trying to press the button.

2 Likes

A few ideas / concerns:

  • Aggressive caching
    • It’s unrealistic we’ll have something that allows all organizations to immediately load, but for important ones (e.g. governance.aragonid.eth) there may be a server-side service that does the state reducing that users can opt into (perhaps opted in by default)
  • Notifications
    • I’d propose an email notifier as the MVP; I’d be surprised if something like this didn’t already exist
    • Real push notifications will be a much larger undertaking and we get 90% of the benefit with email
  • Meta-transactions
    • This will require another on-chain upgrade, which we may or may not want to do for 0.8 since the time difference is quite short compared to 0.7
  • Global kill-switch
    • Similar to above, will require another on-chain upgrade

A few frontend-only items targeting UX problems that are not in the list (in my order of cost to value):

  • UX improvements to the Voting app
  • Improved feedback for pending actions: Showing Pending (Forwarded) Actions in Apps
  • Optimistic UI
  • Customizable menu bar / app instance labels (either locally or persisting to a data blob shared across organizations)
1 Like

This feels like massive low hanging fruit to improve the experience of most users. If users want to run without server-side caching or run their own caching server that should be doable.

Most users are accessing Aragon through a centralized gateway (aragon.org), and querying the default node provided by the software. Adding server-side caching by default would minimize load on the default node, and make the ux much smoother.

4 Likes

That’s what I was talking about, yeah. And I agree with @lkngtn on making this a default on the centralized gateway.

We will start UX research on this, and see how it goes. If the experience is re-imagined from the ground up, maybe we don’t have time to have it ready for 0.8. If it’s small changes, I could totally see it happening for the release.

Totally, although that one was initially scoped for 0.7, so that’s why I didn’t include it here. Will see where to put it, maybe in 0.7.3.

I wonder if Autark was already thinking about this? cc @stellarmagnet

Yes we are definitely thinking about this, but “shared across organizations” – I assume @sohkai meant shared across the organization (and hence the greater aragon ecosystem)?

My thoughts around this customization are also related to the url slugs for the apps (and requiring the user to make the urls unique if two of the same app); I think wix’s design patterns will work well (simplifying though, for the Aragon app use case).

Screenshots from our Wix for autark.xyz (don’t judge… i manage our website now lol):

This item was in our immediate horizon and we were actually planning to begin development next week – do you want us to take ownership? We will aim to deliver it in time to make it into 0.7.3

1 Like

That makes a lot of sense! Updated the original post to reflect it

2 Likes

Another potential way of doing this is to run a database with a light authentication and API layer on top. Although the first load ever would still be slow, users could have the choice of uploading their cached state to this database to allow future users of the organization to fetch it (if they choose to do so).

It’s a bit heavy-handed for this particular use case, but the authentication layer could be the same as one suggested for pinning IPFS files: Aragon Network IPFS Pinning.

We’re starting to make changes to aragonAPI for local state caching that already allow this to be a natural progression from a local cache to a fetched cache. There are hooks available for the running webworker script to sanity-check the fetched cache (e.g. “why does vote 1 and vote 3 exist, but not vote 2?”) that will allow us to warn the user to discard the fetched cache.


Very early on in A1’s life a few of us were thinking about how to do this in a more decentralized way, but I posit that as long as we open source the database node, organizations would be free to run their own caching server with a more strict authentication layer.

1 Like