Comments (12)
Short descriptions are now merged into main and slated for next week's release.
from meta.
Developers should be able to submit descriptions along with their app. These descriptions should follow a (potentially versioned) well-defined format in the unsigned repository metadata; HTML formatting will not be supported. For the initial implementation, developers should be able to submit a description for one of their existing apps including a short (~80 char max) description along with a significantly longer long description which can be sectioned into paragraphs.
from meta.
Rendering from the AST ourselves also presents another advantage: we can explicitly choose what to support rendering. For example, if we don't want to support images in the description, we can choose not to render them, or if we only want to allow two levels of headings instead of six, we can do that.
Limiting the format in this way ensures a degree of consistency across the board which makes descriptions both more aesthetically pleasing and, in my opinion, more useful since users can hold consistent expectations for what an app description includes.
from meta.
What do you mean? Developers will upload/update descriptions through the developer console (or eventually its API), so I'm not sure what could be re-used per se.
For AntennaPod, Triple-T is used to manage the metadata. F-Droid understands & respects the file structure: https://f-droid.org/en/docs/All_About_Descriptions_Graphics_and_Screenshots/#triple-t-structure
I guess what I had in mind is some uploader tool for Accrescent that leverages this file structure as well (or maybe even get support for release management in Fastlane for Accrescent).
wonder if Play Store has any guidelines for how developers should ideally write app descriptions? That'd be nice to see.
Here's what I could find:
- Google
- Requirements and recommendations (covering short description & images): https://support.google.com/googleplay/android-developer/answer/9866151#zippy=%2Cshort-description
- Developer Program Policies (all content): https://support.google.com/googleplay/android-developer/answer/9898842
- F-Droid
- Short description: https://f-droid.org/en/docs/Build_Metadata_Reference/#Summary
- Long description: https://f-droid.org/en/docs/Build_Metadata_Reference/#Description
from meta.
A few thoughts on this:
All apps should submit both a short and longer description.
Descriptions should not include:
- Images - Those should be their own section, either above or below the description.
- Links - There should be a dedicated links sections below the description. Developers should be able to choose from a dropdown of predefined link "types" (Website, Docs, Donate, Source Code etc.) and then put the link. Those sources should be automatically sorted by Accrescent regardless of the order that the developer submits them in to ensure consistency, and reviewers should check that there are no links in the description, and that the link labels actually make sense (i.e. the link for docs actually goes to docs)
We should have guidelines for how the descriptions should be structured to ensure that they are as uniform across different apps as possible. I wonder if Play Store has any guidelines for how developers should ideally write app descriptions? That'd be nice to see.
from meta.
Implementation has begun at https://github.com/accrescent/parcelo/tree/descriptions.
from meta.
If there will be website for listing/searching Accrescent apps too, the HTML format should be supported, so I think markdown format would be good as it supports paragraphs, lists, headings and eventually tables or images.
from meta.
Something like markdown would be ideal. The reason I call out HTML is mostly for rendering purposes. I'd rather not render untrusted HTML via WebView just for the app description. Sanitizing that for script injection etc. is another opportunity for error that I don't think is necessary for a feature this simple.
The source format doesn't matter as much for the website since the pages will need to be generated from the metadata anyway, although markdown may make that easier.
Looking into it more, I think we could use commonmark-java to create an AST, and instead of rendering it to HTML, pass it to Compose to generate a composable tree as described in this article. I really like that idea initially.
from meta.
In terms of where to source the descriptions from, it would be great if existing structures/folder locations used already by Google Play and/or F-Droid could be re-used, as to limit the effort for existing apps.
from meta.
What do you mean? Developers will upload/update descriptions through the developer console (or eventually its API), so I'm not sure what could be re-used per se.
from meta.
Just a hint: You might wanna take inspiration from the AppStream standard from the Linux Desktop world. Docs are here.
I'm no Android developer, but I guess it could be beneficial in the long term to at least come up with something easily convertible to/from AppStream metadata (and not reinvent the wheel, as the saying goes
from meta.
I'm deprioritizing long descriptions for a little while to prioritize infrastructure and scaling improvements, while are now reflected in the roadmap.
from meta.
Related Issues (20)
- Support app changelogs HOT 1
- App Monetization Disclaimer
- App screenshots HOT 2
- Add privacy policy to both the official site and to the app
- Explicitly label closed source apps as such HOT 5
- Add comparison to F-Droid and Obtainium to the FAQ HOT 1
- Rewrite developer console HOT 1
- Support developer/organization pages HOT 2
- Add comparison table HOT 15
- App channels (alpha, beta, stable?) HOT 3
- Support download counter(s) HOT 1
- Support "open source" tag
- Add Cryptocurrency address Donate
- Accrescent DNS wrong records about mail security HOT 1
- Support specifying an app's minSdk
- Add support for app archiving
- RFC: Repository metadata reorganization HOT 12
- Reduce icon file sizes
- Update guidelines and requirements on app sizes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meta.