Replies: 2 comments 17 replies
-
|
Can we recommend developer for the job |
Beta Was this translation helpful? Give feedback.
-
|
Hi all! I haven't had much free time this past week to really parse this article well (past the title). From my POV, best approach for larger projects like this will be to understand community ideas and feedback (as we are doing here), and then translate informal discussions from here into a more formal, bullet-proof PRD that could be stored and versioned under https://github.com/asastats/docs and then cleanly referred to externally. In terms of PRD - I embrace a bit of an old-school style with bullet-pointed sections/requirements like 1, 1.1, 1.1.1, where lower branches of the tree's requirements basically translate into use cases. In the case of the sentences above from @ipaleka - I think I could translate that into this type of style, which would then potentially make it easier for the community to then expand and add additional requirements/use cases in line. |
Beta Was this translation helpful? Give feedback.
-
|
I'll do "bulleting" and will try to create a base document having most of the requirements. |
Beta Was this translation helpful? Give feedback.
-
|
P.S. @AlgoRhythMatic and others, this thread is probably going to become a discussion about our next client-side framework. If we for example find Flutter to satisfy our native or pseudo-native requirements for the mobile app, then Flutter absolutely has to become a topic for discussion about updating our website UI, as well as a candidate for technology behind our user widgets system. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! I know PRD approaches are subjective and stylistically diverse, but I am hopeful this approach will be inviting for people to easily consider individual ideas at a granular level - and then expand upon them. I'm happy to help work with you on it! As well, I think this work will be helpful for external, non-community folks to understand needs. |
Beta Was this translation helpful? Give feedback.
-
|
ASA Stats Mobile product requirements section is added to the main post body of this discussion. |
Beta Was this translation helpful? Give feedback.
-
As this thread didn't get enough friction, I had got a meeting this morning with Jay, an outsourced developer. We went through the app's requirements and agreed that he starts with the first phase. So, Flutter will be our mobile app framework and that presents Flutter on the Web as the first and logical choice for the framework used for the development of the ASA Stats user widgets (point 16. in our roadmap) and website's themes. |
Beta Was this translation helpful? Give feedback.
-
|
Good development. |
Beta Was this translation helpful? Give feedback.
-
|
I guess we all should start to research Flutter and its web capabilities in order to create our user widgets system. The main drawback for Fluter on the Web is its non-existent SEO capabilities, but we'll use Flutter only for the address pages - our SEO should be focused on the rest of the site anyway! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it would be good to have as much information about the feasibility of Flutter in creating the user widgets. SEO, if well done on the website would eventually trickle to the app with time. So I guess we can go ahead with Flutter for now. |
Beta Was this translation helpful? Give feedback.
-
Yes, we'll surely have research and discussions about that, but Flutter is designed as a framework for creating custom widgets so it's expected that it fits. Nevertheless, we should prepare a solid and bulletproof basis for our widget system first. Right now an obvious choice would be websockets and Flutter, but nothing is set in stone yet. |
Beta Was this translation helpful? Give feedback.
-
As you may already read in the ASA Stats Token utilization discussion, we're planning to sponsor the development of a multiplatform mobile app (iOS and Android) that will mirror at least current ASA Stats website's functionalities.
The following options were listed in that discussion:
a) we develop it by ourselves under our name
b) we pay for its development under our name (open source code copyrighted by ASA Stats DAO)
c) we sponsor its development under our name (open source code copyrighted by ASA Stats DAO)
d) we sponsor its development by a third party that will make their own brand using our API
e) we completely leave it to the market, counting that someone will eventually make it
This topic is pretty much prioritized among other tasks right now besides our API development and improving alpha NFT functionality. We're looking for ways to collect funds for that development besides selling the admpool ASASTATS on AMMs and we also should discuss how to approach the actual development. In the pre-DAO phase, there would be no ads on the website, but if ads inside the mobile app is the only way to get a mobile app published then ads gonna be. :)
Right now, a bounty on Gitcoin sounds like a preferable approach. Such a bounty's text may bring options b) and e) for the developers to choose from, of course with a budget for option b) to be bigger than option d) budget.
We should discuss here in this thread about preferred technologies used for the app development. We should probably insist on a native appearance for both platforms without insisting on actual Objective-C and Java as programming languages. If the developers will use a common framework that will render natively on both iOS and Android then we should be ok with such a solution no matter of the actual technology used (if it isn't some abandoned or obscure technology, of course).
Regarding the requirements for UI, we should probably insist on some type of pie graph, as well as stacked ASAs and NFTs in some kind of expandable sections. They have to use data by fetching our API endpoints. Please add up if you think there should be other requirements.
Last but not least, the mobile app development should start in parallel with the API development. A lot of development of such an app can be done without fetching the data from the real endpoints (we can provide the test data for the development) and also we'd probably be able to provide the testing API endpoints early in the mobile app's development phase.
Everybody, please provide your suggestions here or across our community channels (we'll copy/paste valuable suggestions here). Also, link this thread to advertise our need for the development to the third parties/developers.
ASA Stats Mobile product requirements
ASA Stats Mobile is an iOS and Android app that at least mirrors the current set of ASA Stats website functionalities.
All of the address page's data is retrieved from our API endpoint, so the app will fetch for example https://api.asastats.com/VW55KZ3NF4GDOWI7IPWLGZDFWNXWKSRD5PETRLDABZVU5XPKRJJRK3CBSU and a JSON stream with all the data will be returned. It is yet to be discussed the optimal way how the app itself will authenticate to our server in order to get permission for that API endpoint.
It is implied that the mobile app code is open-sourced so everybody would be capable of forking and creating their own version of the app.
We prefer native applications for both iOS and Android. Flutter and other frameworks that don't render natively are the backup options.
The ASA Stats palette consists of the following colors: #575757 #00c896 #005a34 #ababab #ff3769
Logo Logo dark
Global/system settings
Requirements
Besides streaming onchain data and using the user settings, there are some predefined global settings for the app used to define particular functionality and/or evaluated dApp specifics. It is expected that dApp fetches such a configuration update directly from the ASA Stats server to avoid creating a new mobile app version in order to implement a new provider or a new staking program.
It is expected that the mobile app ships with the initial configuration and that a configuration update brings only the currently changed configuration.
Index screen
Requirements
The app's index screen is a counterpart to the website's root page.
Users should be able to enter a public Algorand address or a collection of addresses (a bundle; up to 5 in this app revision) or pick from a list of already used addresses (something that website doesn't offer right now; a simple clickable list below the address input box will suffice).
Links to ASA Stats' social media accounts should be reachable either directly or through the menu.
UI
This first screen should completely follow a look and feel of a native app. ASA Stats would prefer native technologies like Objective-C/Swift, respectively Kotlin/Java for creating the app, but common frameworks can fit too if they try to mimic the native look and feel (for example, in the case of Flutter it is expected that iOS app uses Cupertino widgets).
The navigation menu should include links to app/website static pages.
Static pages
Requirements
The website's static pages (located at https://github.com/asastats/static-pages) should be accessible from the app's menu.
A static page may render a website's URL in a webview, without any additional programming from the client side.
UI
It is expected that static pages design changes to fit the mobile app presentation, without a need for additional mobile app development resources besides rendering a page inside a webview.
Address screen
Requirements
After selecting an address or a bundle from the index screen, the user is redirected to the address screen.
The address screen consists of four different sections:
JSON
All the information needed for the screen rendering is supplied under the main data object. The keys of such an object are the following:
header,asas,nfts, andnoteval.UI
After the header data, at least two views should be available to the user:
Show all
After the header, the rest of the sections are rendered just like on the website: ASAs, NFTs, Not eval, and Charts sections.
Tab select
Tabbed navigation with opened ASAs section tab as default should be rendered after the header. Users should be able to select the rest of the sections from left to right with the Charts section being the last on the right.
Header
The top of the screen should bring a centered total amount.
A list of clickable addresses is shown below the total. For a single address, by clicking an address a user effectively refreshes the screen. Clicking an address from a bundle opens only the selected address on the screen.
JSON
The main data object keeps all the records from this section under
headerobject.Among other things, such an object records the following data:
ASA section
The ASA section container should mirror the website's functionality: each item/row/ASA should get an always visible header row of basic information and by clicking on such a header row, the rest of that ASA's information is revealed below the header row.
It is expected that only a single ASA/row can be expanded at the same time.
JSON
The main data object keeps all the ASA objects from this section under
asasarray of items. For the rest of this document, a single row of data will be referred to asitem.Header row
The header row contains the following data from left to right (related alignments are in parenthesis):
item.amount(left)item.unit(left)item.icon(centered)item.value(right)item.currency(right)Data
The ASA data consists of three subsections:
ASA information
All the static/onchain ASA data, like
item.name,item.decimals, etc.dApp entries
Each entry in this array of objects represents a locked/supplied ASA amount to the related dApp. Such an entry may consist of the following values, ordered from top to bottom:
All the entries are sorted by value, with the highest on top.
Distribution
If there are multiple sources for the price information then they are shown in a separate subsection after the related dApp entry amount is clicked. The distribution section is an array of entries having the following attributes/values:
Each asset's balance entry shows its distribution subsection by default. To hide a distribution section, a user has to click the balance or related dApp entry amount.
Icon links
JSON will contain eventual icon links for an asset like an icon to charting apps, etc. The app's global settings and resources will get a predefined set of providers' icons.
NFT section
The NFT section container should mirror the website's functionality: each item/row/collection should get an always visible header row of basic information and by clicking on such a header row, the rest of that NFT collection's information is revealed below the header row.
It is expected that only a single NFT collection can be expanded at the same time.
JSON
The main data object keeps all the NFT objects from this section under
nftsarray of items. For the rest of this document, a single row of data will be referred to ascollection. A single NFT inside acollectionwill be referred to asitem.Header row
The header row contains the following data from left to right (related alignments are in parenthesis):
collection.amount(left)collection.name(left)collection.thumbnails(centered)collection.value(right)collection.currency(right)Data
The NFT collection data consists of one or more NFT entries/rows placed inside the section. Each NFT entry consists of two subsections:
NFT information
All the onchain and arc69/arc3 NFT data and metadata, like
item.name,item.thumbnail,item.urls, etc.NFT status
This subsection may bring the following entries from the top to the bottom of the related subsection:
listing
An entry that brings the amount and a link to the NFT market/gallery where the NFT is listed for sale.
auction
An entry that brings the current highest bid and a link to the NFT market/gallery where the NFT is auctioned.
last purchase
An entry that brings the very last price the NFT has purchased for, together with a link to the NFT market/gallery.
max purchase
An entry that brings the maximum purchased price the NFT has ever got, together with a link to the NFT market/gallery where the NFT is purchased. This entry merges with the last purchase entry if it represents the same purchase.
floor price
The smallest price the NFT is listed for, together with a link to the related NFT gallery/market.
Not evaluated section
All the assets that are not presented in the previous two sections should be rendered inside the "Not evaluated assets" section.
Only a simple header row is shown initially, while expanding the section shows all not evaluated assets at once, one below each other.
JSON
The main data object keeps all the NFT objects from this section under
notevalarray of items. For the rest of this document, a single row of data will be referred to asitem.Header row
The header row contains only the section title "Not evaluated".
Data
A not evaluated asset row consists only of basic ASA information (static/onchain ASA data, like
item.name,item.decimals, etc.) and the asset's balance in the account.Charts
Address screen charts show the ASAs and NFTs inside pie charts with a pie chart slice sized relatively to ASA/collection amount participation in that section's total value.
By clicking a slice, it is expected that the related ASA/collection item subsection is opened and centered on the screen. In that regard, it is expected that the colors of pie chart slices match the colored column bar in the related ASA/collection section.
There are three charts available:
Common chart
This chart consists of three entries: total ALGO balance, total value in ALGO of all ASAs, and total value in ALGO of all NFTs.
ASA chart
The first 15 ASA by value - or first 95% value-wise - get their own pie chart slice. The rest of the ASA are grouped under "others" slice.
NFT chart
The first 15 NFT collections by value - or first 95% value-wise - get their own pie chart slice. The rest of the NFT collections are grouped under "others" slice.
JSON
There are no extra data presented in JSON object specific to charts: all the values can be calculated from the rest of the JSON data, while the colors are read from the global settings.
Beta Was this translation helpful? Give feedback.
All reactions