Search results for:

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

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.

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

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.

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.

Yes now it works.

It is not editable

Since I bought myself a Bangle.js 2, I am very sure I will spend a bit of time with it, so I might as well write this experience into a wiki. I would be down to help.

GitHubs APIs are a challenge for itself... at least in my experience.

Hi, Im of no further help if this is actually the correct step or not, and maybe the app dev would love to get to debug the issue you have, but the how to reset tutorial is here: https://www.espruino.com/Bangle.js#reset­ting

https://poolitzer.eu

There is a forum post on the library: http://forum.espruino.com/conversations/­367445/