More app information

Just a random thought - but what if each app had a little icon by it which showed the number of open GitHub issues related to that app?

Obviously you don't want feature requests to count, but if there are open issues about bugs, maybe that's something that would be helpful for users to know?

I think all that would do is encourage devs to close issues perhaps sooner than they should, or at least be more aggressive closing them.

Perhaps the GitHub icon under the app icon should be a link to the dev's repo?

I've also noticed that people seem to be reporting app bugs to the main Espruino repo. Are you planning to manually tote up the bugs for each app? What if the dev has enabled Issues on their repo and bugs are reported there as well? I know I'd prefer that people report bugs for my app to my repo and not yours! I've recently updated my Readme to that effect.

I think it could be useful. I wouldn't be worried about devs closing issues prematurely - there is nothing to gain unless Bangle app devs start monetising the apps somehow.

I think the question about how they'll be counted is sensible though. Issues in the BangleApps repo could be tagged. As @andrewg_oz says it is easier to keep track of bugs on a separate issue tracker per app, but not all apps have separate repositories (not sure if it is even the majority, and I understand why).

I'd personally love to see more screenshots in the app loader, more detailed descriptions, and more apps with an upload to emulator button (not sure what decides that currently, and I probably won't care as much when I can access the real thing).

In terms of issue reporting, I think mostly it'll have to be on the main BangleApps repo - I'll try and mention the maintainers if I see anything. Otherwise it's just too hard - and also in the past it's been extremely likely that some apps get made and then not maintained after a while - and at least if issues are reported on the main repo I have a way of knowing that and maybe doing things about it.

And yes, I think screenshots is a big thing - I've been working on a way to do it automatically. The emulator thing is decided by the app creator - the issue right now is the apps need to be single-file apps, although it would be feasible to change that.

Re: descriptions - it's always an issue, but it would be amazingly helpful if folks could contribute more documentation if you find somewhere that's lacking. It's pretty easy to do. Even if you don't feel up to doing a PR, creating a GitHub issue at https://github.com/espruino/BangleApps and writing the docs in there is still very helpful - it doesn't take me long to copy/paste them

just my two cents, disclaimer: I have not had the privilege of using a bangle yet, so this is very much an outsider perspective and vastly influenced by the google app store:

what if each app had a little icon by it which showed the number of open GitHub issues related to that app

I don't think that will do much about the apps tbh, I dont think its an important value to decide by if I want to install an app or not.

There are other improvements the app store can face which are fare more valuable for the end user, imo. Listing them in decreasing importance.

0, Screenshots!!!

You talked about generating them automatically potentially, and thats a nice thought, but either for the time being or for apps which make use of harder-to-emulate states like different settings, different app behaviour, different sensor inputs the dev wants to show off, etc., I would definitely introduce a system of "put all media showcasing your app in this folder, and they will show up in the store". Then actually show them in the store, leading to my next point:

1, Read more... for all apps!

I like the current layout (Icon, name, version number, github link, etc.) for the overview, but then I would love to be able to click on the "app-tile" (stole that term from the html source), and have a page pop-up like the read more part - but for all apps, and standardized for all of them. In there, I would like to see a longer description of what the app does, the aforementioned screenshots / mp4 showcase of the app, then an (author) link if people want to, and maybe some more information like the size of it? One can play with that room if someone comes up with more information that would need to be standardized between all apps, but the less the better ofc, since everyone would need to fill these out in their submission to the app store.

2, Categories

The categories which exist in the upper bar are nice, but I would like to see them integrated into the pop-up screen as well, they give a great overview of what is an app about without having to read much. And maybe also require people to put at least one tag there, and make sure the app fits when accepting a PR.

3, Localization

I have read the localize tutorial and that works well for everything interchangeable within apps, but not for app specific strings. Coming up with a proper solution for this if I haven't missed it would mean e.g. to just have a strings.json file with all strings in the app mapped to each language code (so dict of dict), and then we can include the supported language of each app into the pop-up screen as well, and add a filter type for that.

4, Download stats

Mentioned before, just a thing to play with, very much not needed, and easy to abuse if one wants to, but hey.

The Pebble App Store (now Rebble App Store) displays a count of the number of times each app has been "favourited".

If I may, i like to see the date of the version shown in the app stores, as it allows me to know if it s a new one or not, when this is not an app that is actually installed on my device.
It gives an idea too of the app progress

Another comment I have to make relates to the ChangeLog file. It's a free-form text file, so it's up to the dev to format it. Currently, the examples/tutorials all show the ChangeLog sorted most recent at the bottom. A much better order would have been most recent at the top.

Most people only care about the recent changes, and once enough changes are made, they're going to have to scroll down all the time to see them.

Just a "Known issues" link (only if there are any) would be nice, so you can quickly click through to see known issues before installing.
I doubt manual tagging of issues would be workable, but maybe there is some nifty way to link to the "create a new issue" page with [app:<appid>]: pre-filled in the title? I think you can probably create an "app" issue template asking people to put [app:<appid>]: in the title?

I think the problem with download/favourite stats is not so much that they would be abused, but that people will try the most "popular" apps, so when an app gets a few "lucky" downloads it'll cause a self inflating spiral.

I agree that having the newest changelog entry at the top and adding dates makes sense.

Known issues" link (only if there are any) would be nice

I think thats hard to implement in the repo in an automatic way if you dont want to force developers to use some specific github issue setup. Otherwise developers have to do a commit/PR for each issue they know and then later one for fixing it.

Yeah. I don't think it will be easy to implement, but I figured that for it to count the number of open GitHub issues, there will need to be some way to list them anyway.

Sure, but that is exactly my issue with the idea, the way to list will always be a bit hacky.

I'd prefer issues to be logged centralled. Not sure how you identify the issue list for an App though. But a bug list can be misleading. As a developer of Apps I would love to get more user feedback and to know how popular / useful my app was. Favrourite counts is a good idea and might be easy to implement.

Not sure how you identify the issue list for an App though.

Well as rigrig said, one can label the issues semi automatically, so thats possible and shouldn't be too hard to get via GitHubs api in the background with some client side JS, as least if all developers agree to/expect issues for their app to show up at the AppLoader repo. Thats a simple matter of including it in the docs though, and well, have compliant developers.

Favourite counts is a good idea and might be easy to implement.

I doubt that. This means getting the favourites from users and saving that information on the server. This is not how githubs sites work (at least it wasn't when I used it), they are basically stateless from a server perspective. In order to save the favourite count so other people can see it, one either needs to develop an external hosted API or stop using github.io, which has the mayor downside of now allowing people easily to set up their own app stores.

ChangeLog file. It's a free-form text file

Just a note about this - it's not free-firm, there's a very specific form that all apps should use, and if they don't then the commit checks fail. I've had to change quite a few already ;)

The thing about increased info displayed is someone has to write that info and keep it up to date, and honestly that's usually not the fun bit of writing an app so it doesn't get done as much. The screenshots are pretty easy to add and that is being done now, which is a big help.

re: favourites/reviews/etc I'm always a bit iffy about sending things to a server when it's not super clear that is what is being done. I will add reviews at some point, and I'll do that with something on espruino.com/banglejs.com - perhaps only pulling in the reviews when the site is hosted there and leaving them off on GitHub posted versions?

The thing about increased info displayed is someone has to write that info and keep it up to date

Hm, if the changelog is required to have a specific from, I still very much agree with @andrewg_oz that oldest to newest is not the expected form of a changelog, why did you decide to do it that way?

honestly that's usually not the fun bit of writing an app so it doesn't get done as much

Okay, agree to disagree (I love writing docs and tell people how to use what I have created ;P), but I would argue that one can still require to put more info in the initial app submission which doesn't need to be updated. I mentioned a longer description of what the app does, the aforementioned screenshots / mp4 showcase of the app, then an (author) link if people want to previously, and I still think those hold up/should be required for every app and make sense in every app while not being too much work.

sending things to a server when it's not super clear

Agreed for the favourites, though I very much like the idea of counting favourites for apps. Maybe a pop up the first time, asking people to opt in to sharing their favourites with the world?

perhaps only pulling in the reviews when the site is hosted there and leaving them off on GitHub posted versions?

Hmmm, not sure I like this. Are you doing it already with other code in the repo? Otherwise you need to write this, it requires some kind of check, and it might confuse people why feature X doesn't work on their end. I would honestly rather have a dedicated database api repo and put steps on how to set it up/link it to the .io website then having code only run when the domain is banglejs.com or the hoster is not github.io