Flowser: Interact Screen + Blocto & FlowFan's collections integration + UI & Technical updates

[monikaxh]

Flowser: Interact Screen + Blocto & FlowFan's collections integration + UI & Technical updates

Grant category

Please select one:

• Developer tools / services

1. Milestones & Tasks

1.1. Interact Screen

Problem: During (Flow) blockchain development, you often need to switch between multiple programs (your IDE, Flow CLI, Flowser,..), which can negatively impact your developing flow and productivity.

For example, you may edit the contract source code (in your IDE), redeploy this code (Flow CLI super commands will automatically handle this), test it out by executing some transaction/script (in Flow CLI), and review blockchain state (in Flowser).

This mental context switching is expensive, so ideally, you’d want to use as few tools as possible - your IDE for code writing, Flow CLI for managing the development flow, and Flowser for viewing and interacting with the blockchain.

This is also very similar to the traditional web2 development workflow (e.g., for client-side applications), where you use your IDE to edit code, a CLI tool (like [create-react-app,](https://create-react-app.dev/) [vite](https://vitejs.dev/),..) for managing development flow (rebuilding website source code,..) and your browser for reviewing the changes.

Solution: We want to build a brand-new screen for performing blockchain interactions (executing transactions or scripts). This could replace or enhance some Flow CLI commands like flow transactions send and flow scripts execute with an easier-to-use and more powerful GUI.

Main features:

• Automatically detect the type of interaction (either script or transaction) and show appropriate info after execution.
  • For transactions, we plan to show (all) the “effects” of the transaction, e.g., events emitted, errors (if any), storage state change (in the future), and other helpful info.
  • For scripts, we plan to show the script output in a nice programmer-readable UI (e.g., JSON viewer) and other info if applicable (e.g., errors)
• Automatically detect the transaction/script arguments and provide a smart UI for inputting values (e.g., if the argument is an account address, automatically provide a dropdown input with a list of accounts on the network)
• Better Cadence code editor (e.g. using [Monaco editor & Cadence language server](https://github.com/onflow/cadence/tree/master/npm-packages/monaco-languageclient-cadence))
• UI for viewing the non-linear history of interactions and state changes (similar to the output of git log --graph command)
• Perform actions on past interactions (e.g., revert to the previous state, duplicate interaction,…). This is closely connected with the snapshot management feature we implemented in the previous grant. We also plan to improve the overall reliability of this feature in this grant.
• Implement the possibility of adding templates for the most common transactions. This can be possible with community resources. This feature would be linked with milestone 2: Community to Community, Transaction Metadata.

Tasks:

• Parse transaction/script source code to generate a list of required inputs with their respective data types
• Build a smart account (Address) input, where the user can select an existing account from a dropdown-like UI (similar to how this is done in Flow Playground).
• Pre-generate a list of accounts that can be used during the development. Provide a way for a developer to generate additional accounts if needed.
  • Optionally store these accounts settings in a separate flow.json configuration (e.g. flow.flowser.json)
• UI Design:
  • Implement interact screen UI elements:
    • Past interactions,
    • State chart,
    • Interaction info,
    • Smart script/transaction inputs,
    • Transaction Status
    • Common transaction templates import
  • Smart History view design:
    Design a UI for viewing the non-linear history of interactions.
  • Support all the technical features
    (e.g., smart account inputs, generation of additional accounts…)
  • Action Status
    • In the case of Scripts, the data will be displayed in the same way we are displaying storage inspection
    • In the case of a Transaction, the result must be displayed

1.2 Community to Community

a. Transaction Metadata (Flowser & Blocto)

We will integrate [Blocto’s collection of audited Flow transactions](https://github.com/portto/flow-transactions) into Flowser. This will enable better support and documentation for some of the more standard/popular transactions.

With this integration, we will be able to define a list of common transaction templates. The data will then be used in the History view on the Interaction screen (see Milestone 1), as well as in the transaction table.

Tasks:

• Implement a list of common transaction templates on the interact screen (using the [Cadence transaction templates](https://github.com/portto/flow-transactions/blob/main/transactions/Find/bid.cdc)).
• Show a better summary of transaction logic in the transaction table (using the [transaction metadata](https://github.com/portto/flow-transactions/blob/main/transactions/Find/bid.json))
• Optionally provide a way for users to express interest in adding support for other transactions not listed https://github.com/portto/flow-transactions repository

b. Token metadata (Flowser & FlowFans)

Integrate [FlowFan’s collection of Flow token metadata](https://github.com/FlowFans/flow-token-list) into Flowser.

Token metadata will allow us to recognize more standard/popular Flow tokens and show their metadata in Flowser UI (e.g., links to documentation, symbol, logo,…).

Tasks:

• Show supported token icons where applicable (e.g., in token transfer info, event rows,…)
• Show metadata on the contract details page.
• Optionally submit a PR on https://github.com/FlowFans/flow-token-list that adds links to token documentation pages

1.3 UI Updates

a. Account address abstraction

Account addresses are not human-friendly, but we show them pretty much everywhere now. We want to provide a better abstraction on top of raw account addresses - account icons or names. Ideally, we’d want to use the same naming convention used in other Flow tools (e.g., flow dev super command).

Tasks:

• We will update the design all over the tool (Accounts table, account details, transaction table, transaction details,…) and present the addresses more visually.
• Autogenerate custom address avatars (or use the ones from fcl-dev-wallet) and show them next to account addresses, making it easier for users to identify accounts.
• Treat account addresses as an implementation detail.
  • Pre-generate a list of accounts that can be used during the development. The addresses of these accounts could change on every project startup, so we wanna show names that will always stay the same.

b. Improve transaction transfers info

Flowser is a graphical user interface, and we would like to focus on presenting the data more visually in this grant. With this idea, we would like to improve the transaction token transfer info, enabling users to make more sense of what the transaction is doing.

Tasks:

• Prepare a new design for displaying Transfers info, with the updates from the previous feature ([a. Account address abstraction](https://www.notion.so/a-Account-address-abstraction-5567b975f6b44a50b933019cd12430c9) ).

c. Transaction overview in table

Transactions do different things like:

• transferring tokens
• adding contracts to accounts
• executing other application logic
• …

If you look at the transactions table now, you are not able to see what each executed transaction did without examining the source code:

The idea is to display this information differently from other data, so you can quickly see the effect of a particular transaction.

Tasks:

• If available, use community-maintained transaction metadata ([a. Transaction Metadata (Flowser & Blocto)](https://www.notion.so/a-Transaction-Metadata-Flowser-Blocto-aee77fbeaf2c431d82b4314c0784fb86)). This will enable us to show a human-readable description of the transaction, e.g., “Send 1 FLOW to Alice”.
• Use transaction tags to indicate the type of transaction (e.g., NFT transfer)

d. Show uncollapsed view of transaction arguments

We show a collapsed view of transaction arguments (for complex data types like arrays or dictionaries):

Design today:

We should show a full data view, but there won’t be enough space to fit that data in a single line like we used to do (e.g., if the array has 5 elements). We will break that info into multiple lines when the data type is array or dictionary.

Example of how we could present the data:

e. Cleanup of the current UI

• Less clutter on tables

We will eliminate unnecessary information, update the address view, and add a better overview of what the transaction did (in the Transaction Table).

• Display non-clickable tabs differently and move "buttons" into tabs

Showing non-clickable tabs is confusing.

We will update the design of all details pages (account, blocks, and transactions) whew we will:

• Redesign “buttons” into tabs
• Present data with no additional details view (e.g., Collection in Blocs table) differently

f. Global search design

Global search will enable users to search for any kind of:

• transaction
• address
• account
• history item
• transaction template
• tag
• etc

We will design a modal for a global search.

Global search will be implemented in the future, but we will prepare the design in the scope of this grant.

g. Tags

Tags are a way to attach labels to different objects on the Flow blockchain. We are planning to implement tags for accounts, transactions, and events.

Tasks:

• Implement account tags:
  • service account - to indicate if the account is a service account defined in flow.json file
• Implement transaction tags:
  • Fungible token transfer
  • NFT transfer
  • … others, if applicable
• Event tags
  • Core event - to indicate if an event is a part of core Cadence events: https://developers.flow.com/cadence/language/core-events

1.4 Technical Improvements

a. Remove the need for manual transaction authorization

As of now, you need manually authorize every transaction that you want to execute using the fcl-dev-wallet modal. This is not ideal behavior for our upcoming interaction screen because it presents an unnecessary distraction.

Tasks:

• Follow the [FCL documentation](https://github.com/onflow/fcl-js/blob/master/packages/fcl/src/wallet-provider-spec/authorization-function.md) and implement a custom authorization function

b. Improve snapshot management

The current implementation of snapshot management is not as reliable as we’d like. Because this feature will be used in the upcoming [interact screen feature](https://www.notion.so/Documentation-01d7fc2f7fab4c30b5d59c85d16ceb88), it should behave reliably.

That’s why we proposed some changes to the snapshot management API in Flow CLI, which have now been implemented in the PR below.

onflow/flow-emulator#241

onflow/flow-emulator#228

The next step is to integrate these API improvements to Flowser. We also want to create snapshots automatically on a per-block basis.

1.5 Continued support, Maintenance & PR

Resolve (or provide support) any GitHub issues: https://github.com/onflowser/flowser/issues

We will support all active users and resolve any GitHub issues: https://github.com/onflowser/flowser/issues, maintain the tool with regular updates and continue with communication on Twitter.

2. Milestones & Tasks

Milestone	Deliverables	Timeline	Risks	Flow Tokens Suggested
(4) Technical Improvements	• The need for manual transaction authorization is removed • Snapshots are created automatically on a per-block basis	2 weeks		6,000
(1) Interactive Screen Implementation	Interact Screen for performing blockchain interactions (executing transactions or scripts) with all functionalities is designed and developed.	6 weeks		36,000
(2) Community 2 community	• Blocto’s collection of audited Flow transactions integration into Flowser • FlowFan’s collection of Flow token metadata integration into Flowser.	3 weeks		7,000
(3) UI Updates	• Account address abstraction • Improved transaction transfers design • Display the human-readable description of the transaction • Uncollapsed view of transaction arguments is shown • Tables are updated and contain less clutter • “Buttons” on the detail page are redesigned into tabs • Non-clickable tabs on the details page are redesigned • Design for a global search is created • Tags are designed and implemented	3 weeks	-	20,000
(5) Continued support, Maintenance & PR	Provide support for all active users, maintain the tool with regular updates, and continue with communication on Twitter.	4 months*	-	36,000 (9,000 monthly)

*Milestone 5 will start on day one and will be ongoing work for 4 months. It will be done simultaneously with all other milestones.

Total suggested USD amount: $52,500

Team

Github	Name	Role	Bio	Email
@bartolomej	Bartolomej Kozorog	Full stack developer	Passionate developer and CS student. Currently building Flowser tool and working at kazm.xyz - building a Web3 CRM platform	bartolomej.kozorog@gmail.com
@monikaxh	Monika Hriberšek	UX/UI Design + Graphic design	Proprietor @ Monikart; UX/UI Designer @ Flowser since Sep 2021; Designing: mobile apps, websites, social media content, NFTs. Additional experience: Product Manager @ Renault&Nissan Financing (~ 4y).	monika.hribersek@gmail.com

[alxflw]

thanks for the submission @monikaxh. @fotescodev will reach out to you to discuss this further

[monikaxh]

Awesome, thank you!

[monikaxh]

Hi @alxflw and @fotescodev! 👋
I just wanted to check if there are any updates. Is there any more info @bartolomej and I should provide?

[alxflw]

thanks for the ping @monikaxh. we're still gathering reviews. the spring break is delaying some of these. sorry!

[monikaxh]

Sure, no problem @alxflw! Thank you for a quick feedback! ✌️

[fotescodev]

Automated Snapshots is a great addition as well. Let's sync on Monday after we have reviewed this with @alxflw.

[bartolomej]

Automated Snapshots is a great addition as well. Let's sync on Monday after we have reviewed this with @alxflw.

@fotescodev Yeah, indeed! Maybe we didn't state that explicitly, but the automated snapshots feature is actually a prerequisite to the interact screen feature. That's because one essential idea behind the interact screen is the ability to revert to any previous interaction/transaction (read "block").

For this to work, we need a reliable mechanism to create snapshots for every new block. I believe we could do that at the (flowser) application layer, but I don't think will work reliably enough in all cases (e.g. if the block interval is very short we could miss some blocks).

So I believe we will need to work together on this and possibly other features in this grant if they require some work on the Flow tooling side.

[bluesign]

@bartolomej we have roll back to height now on emulator, so no need to take snapshot every block anymore. onflow/flow-emulator#309

But having a UI for this is great for UX.

[fotescodev]

@JeffreyDoyle I was wondering if this would work well with FLIX as well?