Add Financial Overview Visualizations to Collective Profile Pages

[iamronen]

Kick off and plan

Recording (TBC)

We spoke about the proposal below, the issues with respect to rendering and the possibility of sending reports by email to contributors instead, classification of expenses and the risk that we end up with a lot of fragmentation and our strategic design priorities around profile pages. Generally, the plan is to initially focus on use of funds:

• To drive the classification of expenses through tags (which we can rename if needed)
• To allow submitters to include tags when expenses are submitted
• To limit the ability of submitters to modify tags once submitted
• To show the most-used tags in the tag picker to encourage homogenisation but allow freedom
• To add visualisations to the 'budget' section that show expenses by tag and type, hidden behind the 'expenses' tab to remove issues with load times.

We acknowledge that there's value in showing information on how users are contributing (recurring contributions are much better for projects, so encouraging that behaviour is a priority), but for the moment, the focus is on how projects are using money.

Some quick sketches of how this might look:

Expenses page

Incidentally that graph is made with real data from the 'webpack' project. Note that metabase automatically accumulates tags that have a small %age representation into 'other' automatically. I think this is a pretty decent pattern.

If we wish to see (we may) how the project is changing it's spending over time we might want to show something a little more like this:

Expenses by year

Background & Context

This proposal emerged from:

1. Research into open-source projects hosted by OSC about what can be done to make it easier for corporate funders to fund open-source projects. One of the core needs that were identified was to gradually provide funders with more information about the impact of their investments.
2. A followup inquiry into tagged expenses on the OC platform (seed pitch and discussion ).
3. A proposal that surfaced on slack on how to visualize contributions.

Proposal

Add visualizations that provide an effective overview of a collective's contributions (incoming funds) and expenses (outgoing funds).

When a funder is considering funding an open-source project hosted as a collective on OC, they want to get a sense of how the project is doing financially (among other signals and indicators). They are trying to decide if the project is capable of handling funding. The current collective profiles provides:

• overall totals
• current balance
• a speculative (not clearly explained) yearly budget
• open/transparent ledger
• number of recurring funders at each funding tier

This information is insufficient and difficult to integrate into a coherent financial view that answers questions such as:

1. How long has the project been actively raising money?
2. Is the funding that it has consistent or erratic - what part of it is recurring and what part is one-time?
3. How does the project spend the funding that it currently has?

Ultimately, a funder is looking for funding opportunities that are most like to be impactful. These visualizations will not in and of themselves answer this question but they are one step in the right direction. Just having this data visualized clearly is a kind of badge of trustworthiness that a collective is managing its finances. The recently redesigned ESLint website and its donate page exemplify what this can look like.

Providing this as a given service on OpenCollective to collectives is also a badge of trustworthiness for the platform itself.

The proposal includes two visualizations:

1. Expenses
2. Contributions

It is probably preferable to offer the two together, however from the OSC perspective, expenses are currently more important.

Expenses

1: Data integrity preparations

At this point in time this proposal builds upon the existing tagging capability with the following modifications:

1. Signal "accounting" - change the label "tags" to "categories" in order to change the narrative from "just tag this with whatever seems relevant to you" to "select a sensible accounting category"
2. Limit categorizing to collective admins - collective admins are the ones creating context and order within the expenses. Currently this can be disrupted by expense submiters (payees) being able to modify expense tags. In the future, in order to protect the data integrity shaped by collective admins it may be necessary to limit payees ability to tag expenses (especially after expenses have been approved and tagged by a collective admin). This is NOT in the scope of this pitch.
3. Default Tags - in order to account for expenses that are not yet tagged, default tags should be added to them. This will ensure that all visualizations will have and provide some context - even for collectives that have not tagged their expenses or done so only partially. As collective admins encounter the visualizations they will be able to go back and tag expenses and witness the visualizations change. The default categories are derived from the way the expenses were submitted:
   1. Receipts
   2. Invoices
4. First Tag - in order to prevent double spending (when an expense is assigned to more than one category) we need to:
   1. Only use the first tag when creating the visualizations.
   2. Communicate in documentation that this is the case.
   3. Consider making it possible to indicate in the UI "this is the first tag" by mechanisms such as :
      1. Adding a visual queue to highlight the first tag (to emphasize that this is the one that will be used for accounting).
      2. Drag and drop manipulation to drag a tag to make it first.
5. Transactions within the platform to other collectives should be incorporated into this;
   1. Transactions from other collectives should be incorporated as contributions.
   2. Transactions to other collectives should be incorporated as expenses.

2: Visualization

1. By default the visualization is a pie-chart showing the aggregation of expense categories for the selected period.
2. By default the graph should appear loaded for the current fiscal year.
3. Enable the user to select a fiscal year (or all time accumulation).
4. Optional: enable the user to switch between pie-chart and bar-graph presentations.

Contributions

1. By default the visualization is set to "all time" + "summary" + "quarterly."
2. The user can choose to focus on a given year, to alternate between number of contributions and value of contributions and to change resolution "quarterly, monthly, weekly"
3. Both visualizations (count/summary) discern between one-time and recurring contributions.

Integration in Profile Page

1. Integrate both visualizations into one new profile section - "Financial Overview.;"
2. Select default placing in the profile page.
3. Default to displaying the section.

OSC Community Engagement

attention @RichardLitt

1. Add to documentation guidance about an initial set of suggest categories (+ crediting Nicholas Zakas and referencing the ESLint website as an implemented example) and make sure those categories are already in the platform (correctly typed) so that collective admins can easily find and utilize them.
2. Engage with first cohort of admins of collectives who have and use funding and tag their expenses (/ESLint, /transaidcymru, /webpack, /agora, /wwcodeportland, /wwcode) to communicate new feature and talk about how to complete or recategorize in order to communicate effectively with funders.
3. Select and prepare to engage with a second cohort (5-10) of admins of collectives who have and use funding but do not tag their expenses (after engagement and outcomes from first cohort) who have funding but are not yet tagging and invite them to also utilize this capability.

Future Potentials

1. Tools for customizing (scope, colors) and embedding visualizations on other websites.
2. Clicking on graph elements as direct links into the ledger to see the details of expenses and contributions.
3. Further refinement of visualizations to portray project expenses.
4. Emphasizing LARGE one-time contributions in relation to many small one-time contributions.

[natehn]

I love this! I think an issue I previously submitted, #5553, can also be an input into this work.

I think an idea to hold as we shape this proposal is that other kinds of organizations will want other kinds of metrics, so I would love for the way this is built to have flexibility around that. The above issue lists a bunch of metrics that are useful for organizations - though some would perhaps be more useful internally rather than for the public.

[iamronen]

@natehn

1. can you add to this pitch specific proposals for increasing clarity on the "estimated yearly budget" field. If you wish, I'm happy to connect and talk this through
2. I agree, there is potential for more metrics. My intention is that the initial capabilities described in this pitch become a doorway into being able to do and offer more.

[RichardLitt]

Engage with first cohort of admins of collectives who have and use funding and tag their expenses (/ESLint, /transaidcymru, /webpack, /agora, /wwcodeportland, /wwcode) to communicate new feature and talk about how to complete or recategorize in order to communicate effectively with funders.

This sounds good to me, and I am willing to hold this space and invite them in. Let me know when makes sense to start doing so.

[natehn]

@iamronen I think my main concern is that I would like people to know the specific function/equation that led to that calculation, since it is just that - a calculation. And I think it should be separated from the real data in some way

[Memo-Es]

I really like the feeling of this project! I think it has to do with a lot I've been hearing for some time now.
I do think, though, that it would need some preparation work before jumping straight into a solution. I'll elaborate:

This issue describes a problem very well:

When a funder is considering funding an open-source project hosted as a collective on OC, they want to get a sense of how the project is doing financially (among other signals and indicators). They are trying to decide if the project is capable of handling funding.
The information we currently provide with the Collective page budget section is insufficient and difficult to integrate into a coherent financial view that answers questions such as: How long has the project been actively raising money? Is the funding that it has consistent or erratic - what part of it is recurring, and what part is one-time? How does the project spend the funding that it currently has?

And then assumes that the straightforward solution to this problem is to add visualizations to the aforementioned 'Budget' section. I think this problem deserves some thinking + exploration work to rethink the budget section, which has plenty of room for improvement; then, with a more precise definition of that section, we can add some graphics and visual aid to the information displayed. Not to mention we already have a very similar project documented here: #3998.

I wouldn't jump straight into adding the data visualizations without investing some time structuring a better 'Budget/Transparency' section for Collectives. In the same way, we didn't start building #4893 immediately without clearly understanding how the contribution experience works as a whole and solving the original problem more holistically.

cc @iamronen @BenJam

[iamronen]

thank you @Memo-Es :)

1. Wow!!!

Great looking designs which means that if prioritized we even have designs roughly in place.

2: Process

1. I would have liked the work you did on Budget page design for Collectives (Transparency) #3998 to surface sooner.
2. I don't feel that issues are a good home for mature works like this, I feel it gets lost ... this issue is even labeled as "stale."
3. I would like to find ways to get better at holding this kind of information. Seeing 3998 made me wonder what else is out there designed that I don't know about.
4. If there are more such works buried in our issues, perhaps you can surface them by tagging them with something like "design-concept" and creating a board that presents them?
5. I would have liked to see "fat-marker" versions of this packed as pitches and offered into our collective space BEFORE committing precious design resources to the detailed work you've already done. In my mind, this detailed work should typically take place after prioritization and tightly coupled with the development implementation work (especially with detailed graphic work like this that will ultimately depend on what components dev will decide to use to implement the designs).

3: Strategy/Priority/Sequence

I agree with you that this will not directly solve the problem space. It is one piece of many - especially in the context of OSC (we have an extensive research document that we are currently summarizing into a strategy for the coming year that will soon be published).

I also agree with you that it would be better to implement this as part of a wider move of rethinking the budget section.

However:

1. There are more changes I would like to explore in the budget section (which are not currently reflected in the designs in 3998) regarding access to the ledger itself (which is not necessarily directly tied in with the overview visualizations).
2. I feel that an overhaul of the budget section would be better served after we take on the challenge you have raised numerous times of redesigning for a logged-in/logged-out user experience with clear differentiation between public facing profile and an "internal" work area.

I think that overview graphs can be approached as a contained scope and integrated into the existing collective pages as is. I think it will have immediate impact AND it will enable us at OSC to move forward with plans to engage with projects to tag their expenses accordingly. Then we can re-integrate and evolve the visualizations as/when we progress on the revamp of the collective profile page and the logged-in/logged-out experience.

I would be happy to allocate time already in the coming weeks to start shaping a pitch for the logged-in/logged-out strategy so that it is well defined and scoped and can be pitched for Q3S2. Then, during Q3S2 we can do a similar process for a revamp of profile pages that can be pitched for Q4S1. If, as was the case in this issue, you have already done some work on these subjects please do share it with me and lets get it ready for pitching :)

For OSC, waiting 3-5 months (2 or 3 cycles) with the overview graphs is too long.

[kaylarep]

This is a really great idea. Just wanted to add that its not only helpful to funders of OSS projects, but really to funders of any kind.

also, another note in response to @iamronen about potentially buried projects/issues: is it possible to add a step of human confirmation before issues are marked as 'stale'?

[Betree]

What's the benefit of having that on the public profiles? To me, these look like admin stats that are usually not helpful for random contributors visiting the page. I understand that having this as public info can be nice for transparency, but I would separate it to a different page (like /transactions or /expenses) as charts can significantly impact the page's load times.

[iamronen]

@Betree the research into OSC funders revealed that they look at collective pages as part of their funding-process. They look to see if a project is able to receive money (=on the platform) and if they are able to handle funding well (=the funding is more likely to be used effectively). These visualizations are intended to address the second point. The current available information (totals + ledger) do not address this well.

I think (though have not researched this outside of the context of OSC) that this can have a positive impact for other collective and funders. The ability to "at a glance" see a historical perspective of a collective's fundraising & spending says a lot about the sustained vitality and viability of a collective. I think that even private/individual sponsors may be interested in this in their decision to contribute to a project.

Also, as you point out, I think that visualizing information this way (verse manually digging into past expenses and transactions) amplifies the commitment to transparency.

As for its location on the collective page, that may change as we delve deeper into two related projects that @Memo-Es has been holding:

1. Separating a public-view and a workspace view.
2. The collective profile revamp.

As these two projects mature these visualizations (along with many other things) may change (but continue to be a valuable building block both in the present and in the future).

[alanna]

We should always default to things being public unless there is a strong reason something needs to be hidden.

[Betree]

I realize my previous message wasn't clear, so to clarify: my concern is not that the charts will be public (I agree we have no reason to hide them), but I'm trying to understand the added value of having that on the profile page instead of a separate one, like /transactions.

My concern here is the fact that charts have a significant impact on page load/render times. To me, the goal of the profile page is not to give full transparency on the collective's activity but to be a funnel to redirect people to the info they want to see (for most of them, /contribute).

To caricature my thinking, would you prefer:

1. Having a profile page with 3 charts that nicely summarize the collective's financial activity but load in 3 seconds
2. Or having a page with a small link like "View our financial activity" that renders instantaneously

I tend to prefer the second approach. Many (most?) people who arrive there are looking for a way to quickly contribute and already know the project for the page they're visiting. How many of them need to see a historic view of the financial activity before contributing? How many are going to be turned down if we increase the load time of the page? How many (mobile users) are going to be confused because the page they ended up on is too complex and "Contribute" ends up being hidden in a sea of information?

[alanna]

I would agree about putting it on a separate page and linking from the main profile

[iamronen]

@Betree thank you for surfacing the issue of performance price.

1: Performance

For me a good starting point for a solution would be something like a gradual page loading mechanism. The initial page could load as is with a placeholder indicating "loading financial overview" ... and then, whenever that is ready populate the page with the visualizations.

I feel this capability may serve us well in the future as we serve more processing intensive results (which are already visible on the OSC roadmap - see for example #5745 ) ... and if I've not mistaken I think already exists on some of our pages (I think I recall blank gray "card elements" loading before being populated with actual content.

2: User Experience

For OSC institutional funders these visualizations are more useful then almost everything else on the current profile page. I suspect this may also be true for some individual sponsors. Anyone who is asking "will my contribution" be impactful is currently in the dark. These visualizations will shed a lot of light into this darkness.

Moving these visualizations to another page will demand more work (finding where to click and clicking to a new page) from the people who can benefit from them and decrease the likelihood of people discovering it.

I also prefer to defer changing our page structures for after we've developed some kind of overall strategy (a project that @Memo-Es is holding and I hope we can advance soon).

Solving for performance by decreasing the odds of this information reaching eye-balls does not feel to me like a good trade-off ... it almost feels like it defeats the purpose of making it available.

3: Caching

In addition to the gradual page loading, I want to suggest thinking (longer term) about some kind of archival caching mechanisms that can reduce loads and increase load times. I am happy to talk more about this.

[Betree]

@iamronen We already have intensive caching on this page. The reason why I was referring to load/render time is that not only do we need to fetch the data (that part can be optimized, even though it's additional work) but we also need the client's device to render it. This cost can be a small delay until the page becomes interactive, but it can also slow down the device itself if not enough resources.

Another approach that @opencollective/design took in the past with host reports was to hide the heavy charts under a View historical data collapsable section. It helped to contain the performance impact (the data gets loaded & rendered only when you click on View) and also simplifies the UI.

I understand the need for OSC and the assumption that it will help their hosted collectives (at least the large ones) seem reasonable to me. I have some doubts that this will benefit smaller collectives, especially the ones under different hosts.
Overall adding them on the collective page is not a blocker for me, but please consider these issues seriously: this is the most fetched page of our website and loading/rendering time/complexity have an impact on project revenues.

[iamronen]

@Betree I want to make sure I understand you correctly: are you saying that the 3 second delay would be due to client rendering load (and NOT backend data processing/)?

I will also give more thought to the collapsible pattern you mentioned. It may be possible to couple that with some kind of low-load preview that tells a "preview story" of what can be expected inside ... something like summary information / useful stats that have value in their own right (instead of just "view historical data") ... so users can make an informed decision if they want to go deeper.

Another option to explore would be how to roll this out. Maybe we can find a set of criteria for collectives for whom this would be on by default and others would need to explicitly add it to their pages. This may (substantially) reduce initial loads as we roll out this feature. But I think a mid/long term working assumption should be that this is operational for most collectives aspiring to be real operational collectives (raising and spending money).

[Betree]

The "3 seconds" thing was a caricature, I can't estimate the impact without more precise specs. But surely:

• There will be an impact on the loading time (mostly when the page is not cached yet or when we clear the cache)
• There will be an impact on the rendering time (esp. on mobile devices)

The two solutions that you mentioned above seem to go in the right direction:

1. Have an efficient design that takes these concerns into account and tries to reduce the complexity
2. Rolling out the feature only for the right people, analyze the impact for different kinds of host/collectives

I won't be there to discuss this for the kickoff as it has been planned on a Wednesday afternoon, but @kewitz will be there to provide some engineering perspective.

[natehn]

@poohlaga mentioned that it might be helpful for you all to see some of the math in action. Here are some of the metrics calculated (with my limited skills) in Metabase (note: the dates have to be manually updated)

[BenJam]

Q3S2W2 update

Last week we had a couple of conversations about this project, I confirmed that it is indeed our intention to deliver something this sprint. @Memo-Es has pushed on with the design, based on previous thoughts and the pitch by Ronen. I would love for us to be able to start development this week if possible so my goal is getting to a place where engineering is happy to proceed.

[BenJam]

• reviewing the deisgns with @znarf @Betree
• discuss further work on expenses process to support
• discuss mods needed from eng side
• ? discuss engineering on the project

[Memo-Es]

Design update

This is the first design proposal I presented on the demo day on August 5th: https://around.co/playback/965e723a-161e-4825-ba24-39ffeefc9596?sharedKey=0b1fa27a-b031-4d9d-8194-1222738d7a14

After today's review meeting, I did some updates to ensure consistency in the experience and interface:

Expenses	Contributions

Takeouts

• We are releasing this feature for OSC only for the MVP
• We are including this feature as an opt-in, folks are invited to start using it and tag their expenses up to the point they are ready to display the data and turn it on
• This sprint cycle the engineering work will focus on spec out the project, including optimization strategies
• We should schedule the front-end development for the next sprint cycle

Next steps

• We will work on a complimentary design for the turned-off visualizations
• We will focus on having the design ready for implementation this sprint cycle
• On the engineering side, we will work the following weeks to spec-out the project

[iamronen]

1: Design

Thank you for these designs memo, they look good and feel promising.

1. We discussed the possibility to remove time filtering from the bar charts. They show an effective all time view. This would make implementation easier both in terms of UI and performance.
2. The time filtering feels like it is necessary for the pie-charts since it provides context to what is being displayed. I would limit this filter to "all time" or one selected year from the past.
3. I think we can avoid showing the index twice (once for each graph) on the same page. The two graphs have the same index and I think it can be designed as one element along the bottom ... which may also give space to showing more elements.
4. For expenses I think we should aspire to be able to show 5 or 6 tags + other.
5. Can the bar-chart on the contributions also be updated to include the tiers (and also relying on the same index)?
6. I feel like the tabs "expenses/contributions" could use better visual containment ... since they encompass a lot of screen real-estate (the graphs + leader boards). Not sure if this is a priority for this cycle ... maybe we can tend to this when we do the profile page revamp?
7. To my understanding we do not need a complementary design for collectives that do not opt-in - they will continue to see the same element that is currently displayed on profile pages.

2: Tags

I'd like to re-iterate the constraints we have around tags:

1. There should be no disruption to the way tags currently operate so as not to take away freedom from collectives/hosts who do use tags (however they use them).
2. For accounting purposes we need to have one tag which acts as an accounting category.
3. Expense submitters can NOT add/edit tags AFTER submission (after submission tagging is exclusively in the hands of the admins).

Here is a proposal for how to handle this on the UI:

1. Transform the "x" control (for deleting tags) into a dropdown.
2. In the dropdown display a "remove tag" control and add a "use for accounting" option.
3. Automatically select the "use for accounting" option for the first tag that is added.
4. Add a visual queue (eg: highlight) to indicate the tag that has been selected to be used for accounting.
5. When there is only one tag and the user tries to disable the "use for accounting" option respond with guidance "one tag has to be selected for accounting purposes"
6. When there are multiple tags, another tag can be selected to be used for accounting and that removes the selection from the previously marked tag.

@Betree / @znarf I suggest adding a field to the database for the one selected field (and this would require some data initiation choices to populate that field for past expenses).

[Betree]

I like the proposal above for tags uniqueness, the UX looks simple and the engineering part should be rather straightforward.

I however think that it's out of scope for this project. This feature still has a lot of unknowns (how are we going to motivate people to use this new tagging strategy? will they do it? how long will it take until people end up with meaningful values there?) and needs to be processed and iterated on by design, possibly with some user testing and feedback gathering first.

To simplify the design and implementation of this project, I strongly think we should proceed in smaller steps and not try to solve everything at once:

1. How can we display the data that we already have in a meaningful way
2. How can we improve the way we collect transaction metadata (incl. the tags uniqueness proposal above)
3. Update the charts to use this new data only on collectives that are using the new tagging strategy

In my opinion, this issue/project should be solely focused on (1). That way:

• We reduce the complexity of the project
• We can release (and thus try and learn) earlier in the process
• We have a fallback solution for all collectives that won't be using the new tagging strategy

Ideas for making sense of the current data

Tags breakdown

We can use a chart type meant to display a collection of non-unique values, like a Polar area chart. Compared to the pie chart, I don't feel like we're losing a critical aspect of the feature here.

Radar charts can also work

Historic view

A line chart can be used to represent the tag's breakdown, without requiring their uniqueness.

A bar chart (with optional line combo) also works.

[alanna]

Example of an actual graph I use to track spending in one of my OC hosts. Not sure it's the best design, just what was accessible in metabase easily.

What's missing in this graph is all the money we didn't spend, to get a sense of the full budget.

[Memo-Es]

Some thoughts before the demo

• I strongly agree with @Betree on the goal of designing this feature to be useful for everyone; this feature is very powerful to design for one host only. Not to mention my job is to grow the design of the platform having all users in mind.
• I acknowledge the issue of having more than one expense. I think we can solve that with a tag solution like the one @iamronen proposed here.
• I agree with @BenJam that the data we show should be based on money to be meaningful. I - lean towards the first set of graphs proposed originally; anyway, I'm exploring variations.

I will show my proposal after taking these points into account tomorrow in the demo.

[Memo-Es]

Design update

Proposal presented on the August 12 demo day. Here are some main ideas I used to build this proposal:

• List design first: In this proposal, we leave behind the tabs to swipe between "Expenses" and "Transactions," and instead, we have both Exs and Txs displaying both in columns, each with controls to set a specific time or change the visualization of the data you see on the list, a pie chart, and a historical view. The list view helps us to project the implementation strategy. We can start with an updated budget overview section without any chart visualization and add the pie chart and the historical view later in the dev timeline.
• About the tags: For the pie chart and the historical view, we have 2 ways of dealing with tags now as I see it:
  • Option 1: We implement a solution like the one @iamronen proposed here and we use only one tag for the budget display, or...
  • Option 2: We let multiple tags be accounted for the visualizations, and when we display the total amount per tag, we add up all expenses with that tag. In addition, explicitly say to the user that the amounts shown per tag include expenses that will reflect their amounts in two different tags and compare that with the frequency to display an accurate pie chart and historical view.
• About the consolidated budget I think that the budget of projects and events should be a total and be displayed in the "Today's budget" stat, i.e., if I raise 10k and decide to invest it in 10 different projects, we should show as the total budget of the Collective the total 10k, perhaps with a hint that it's split into 10 projects. @znarf feel free to add more details to this.

Budget / Expenses-List	Budget / Expenses-Pie chart	Budget / Expenses-Bar chart
.	.

Next steps

• Decide how we are displaying tags
• Decide how we will invest dev time going forward. My vote is to do the infrastructure work first regarding the consolidated budget plus the scoping of the final proposal to be ready to start the front-end part of the next sprint cycle.

[BenJam]

• respond with last feedback on above design, before working on mobile design
• hack up a prototype based on expense tag stats (API/frontened)

[BenJam]

@Memo-Es discussed on the call today — I don't think the frequency information is that valuable in the above. Proportions should value based in my opinion.

[Memo-Es]

Week 5 update:

• Empty states, finalize production-ready file
• Call out to get feedback from users

[Memo-Es]

Design update

About the settings page

• If we only display both options, and those options are boolean (on/off) I think a switch would be a better option than having dropdown menus
• The only one that actually makes sense as a dropdown menu is this new 'Overview' option because we would have the old version and a new version, so the second element @kewitz added is not necessary, nor is the mutual exclusiveness of those two elements.
• BTW this section of the settings will likely change after we do the Collective page update

Settings page

Some design fixes

• I should limit the number of tags displayed to 4 - 5, and after that, bundle the rest to 'Other' and 'No tag' after that
• I added lines recurring and one-time in the contribution breakdown
• To make it clearer, I added a subtitle to indicate one-time vs recurring and breakdown per tier on the contributions side, and the breakdown per tier on the expenses side
• Having in mind the budget consolidation conversation, I included as well a small help text under the main stats to account for the project and events under that Collective's budget, with a hide and show button

Details hidden	Details shown

cc @alanna @znarf

Figma file

[iamronen]

@Memo-Es

1. These designs feel overwhelming to ingest ... so many numbers and so much structure to figure out on the page. This almost has the opposite effect that we initially experienced when you first demo'ed this design "look at all the purdy colors" ... this variation is "eeeek"
2. I think that 4-5 tags may be too little, I would try to raise that up to 6-7 + other (and I think that other can include untagged). See for reference ESLint
3. Displaying the tiers separate from the recurring & onetime lines creates overload and disassociation. I would prefer to see one list that includes the tiers + one time contributions.
4. Regarding extended overall budget information to show projects and events:
   • While I appreciate you tending to this it feels to me like feature creep, It is not in the scope of the original pitch and I feel that the experience it generates diminishes the experience that the original pitch seeks to create, it feels like a distraction.
   • It may be better to revisit this somewhere in the revamp process, when we find better containers and correct placement for everything.
   • Just in case, I've included below a proposal (ignore numbers!) for a more quiet and informative layout for showing budget details for events and projects.

[Memo-Es]

Design update

After the first round of user testing calls, we did a simplification round and changed the layout to ease a load of information a person needs to process while going through the budget overview:

Note: If a Collective doesn't have projects or events active, it doesn't get displayed in the tabs

Expenses	Contributions	Projects	Events

I'm still polishing some design aspects, like adding empty states and mobile views.

cc @BenJam @alanna

[iamronen]

Nice integration @Memo-Es :)

1. I like that the time filter is encompassing the whole thing, but I am not sure that is clearly communicated in the layout. I guess most people will figure this out once they interact with it, but I feel there is some friction there.
2. Are "today's balance" and "estimated annual budget" effected by the time filter? I am assuming they are not. If that is the case, maybe there can be some kind of visual cue (eg: slightly darker background shade?) that indicates that?
3. In expense tags why have you chosen to show both "other" and "untagged"? Given that the number of tags is limited, I think those two can be integrated and leave space for another actual tag.
4. In expenses and contributions - what does the "historical view / 1 / 2" control do?
5. What happens when the number of projects or events increases? (though it may be less of an issue with events because there are less likely to be many active events)
6. The colors on individual events seem redundant since they are not reflected in the visualization.

[kewitz]

@memo @iamronen

• From a technical side, I like the previous design where there was only tabled data as the initial render. I think that reduces the loading time and burden on the user's device. Graphs take much more time to render and load than structured text.
  • If displaying tabled data is not necessarily what we want to go with, it would be nice if there was a way for us to render the graphs on demand meaning the user would need to expand the section to display the graphs.
• Related to Untagged/Other combination I think it is worth leaving untagged since it will only display in the table if it is really not being used. It also gives an incentive to tag everything.
• Unasked opinion: I'm not sure if I dig the centralized time filter and tabs picker. I don't think there's anything else centralized on the collective page.

[alanna]

Do the main expense and contributions views include events and projects, and then you can further break it down and see events and projects separately? I think the top desired use case will be an integrated view of the entire budget, and if the first screen does not show event and project funds by default it will be misleading.

I think a simpler design would be just contributions and expenses, drop the events and projects tab, and filter options at the top where you can select all (default), or select the existing events and projects from a list to view just that one in the graphs. Similar to the Collective filter at the top of the Host reports screen. If a Collective doesn't have projects or events this selector can not show.

Please add a tooltip telling people how they add tags to expenses or link to that page in docs so they can find out.

[Memo-Es]

Thanks for your latest comments! That was a WIP I'm not really sure to push to dev yet. That is why I wanted more feedback. I will work on the feedback I'm gathering from you and user tests and post an interaction soon.

[znarf]

It's now public, every collective can opt-in for the new version.

[kaylarep]

Some quick feedback:

• this is really exciting to have visualizations like this! great work :)
• For the 'Time' drop down, would it be possible to also have an option for 'Date Range'?
• In the Bar Graph view, when you hover over the specific year, could it hover the total amount? (Recurring + One- Time)?

• my instincts told me that the small icon images should also have descriptions of what they are when you hover over them (maybe at a slight delay? like after hover for 2 seconds, the description appears). I know its a bit obvious, but it could still be helpful.

Also here:

[shannondwray]

• Can we change the colours to something more OC, they are quite bright and seem a little tacky to me.

• On the 'Profile Page' in the settings can we change the language of the toggl to turn this on? aka. Standard Budget, Visualisation Budget?

• Should we tag Open Collectives Expenses so we can have this on our own collective page? and do this will all of our hosted pages?

[Memo-Es]

I'm doing a design refining round and leaving it published here tomorrow, it will mainly be polishing, and we can do some testing rounds and iterate on the usability on a future release. One important thing to note is that we use a graph library. That's where the small controls and typography use comes from, going forward I would like us to be able to generate those graphs ourselves.

cc @kewitz @kaylarep @shannondwray

[iamronen]

I have reached out to ESLint and asked for feedback ... and what follows is a combination of his (Nicholas Zakas) and mine:

1. The first thing Nicholas asked about was a tool to easily go back and tag expenses.
2. It seems that the limit on the number of tags displayed has not been implemented (see OCF for example).
3. It seems that the colors repeat themselves at a certain point (I'm not sure how many unique colors are currently defined) making it difficult to visually discern between tags.
4. I consider it a loss that the initial display does not show graphs. I think that makes a better impression, is more useful and is what most people will want to see thus forcing them to interact with the page instead of bringing them directly to where they want to get.
5. The zoom controls that appear in the line-graph mode are unnecessary here and therefore redundant and distracting.
6. Contributions do not show grouping by Tiers, adding tiers would make this much more useful.
7. The time periods in the filters are a bit ambiguous. For example: does "this month" mean the current calendar month or the last 30 days . This is somewhat clarified with the x-axis on the line and bar charts, but is not clear on pie charts. (I can imagine there are numerous ways to address this ambiguity).
8. Nicholas asked for more resolution in contributions - eg: see top sponsors - I think this would be somewhat mitigated if we incorporate tiers.
9. I think that integrating into this component top contributors / top paid people (incorporated into the time filtering) would greatly complement it and address some more of the things Nicholas asked to see.

[shannondwray]

I feel like the fiscal hosts' budget should also show how much revenue/contributions they are receiving from the fees they charge

[alanna]

See #5967

[Memo-Es]

@iamronen @BenJam I think we can close this issue and follow up on the feedback issue posted above

[iamronen]

Followup feedback issue: #5967