Application discovery in the wiki / New Templates + page

mobian's wiki page uses the classification from linmob's app list; maybe we should use this?

Personally I don't really like the numbers linmob's app list uses. They don't seem to say anything other than "this is how well I feel it adapts" which I don't think really tells you anything. Maybe something more like what WineHQ uses for apps (though, I don't think that system is great either, but still better).

By Newbyte on 2021-02-19T17:25:25

Yes, I feel (unfortunately) exactly the same about linmob's (& mobian's) classification. Maybe it would be better to group them by support:

Upstream supports convergence
pmOS / Alpine packages support convergence through patches
- Every feature works (would require extensive testing) in these patched versions (I think Geary is already there? + Telegram)
- There are compromises (e.g. Firefox) or it isn't tested already
App is well usable but only through manual fixes by the user (like scale-to-fit in phosh and alike). --> Maybe: Add wiki page(s) to describe how to do this?
[Not usable on mobile]
[Broken, probably better to report it directly at aports or pmaports in this case as mentioned below]

The classifications in the App template follow roughly the same principle, I was only unsure about the sub-classifications regarding distro-supported apps (listed here).

By Alexander Brzoska on 2021-02-20T12:10:52

I think this sounds good! One issue I see is that there is nothing between "not usable on mobile" and "well usable with tweaks". There are some apps that don't exactly work well on phones but are somewhat usable. Some of which require manual tweaks (like SuperTuxKart: requires you to manually enable touch controls and has various issues) and others just work moderately well but don't have any tweaks to fix their issues right now (like Cawbird: requires tweeting to be done in landscape if I recall correctly).

By Newbyte on 2021-02-19T19:25:11

I've edited the app template again to center the convergence categories around this "support" idea. There are new identifiers which are (in my opinion) not as cryptic as the old ones. If you think the old ones were better, feel free to change it back. I'm rather uncontent with the wording at the moment, will need look over it again with a fresh mind. Especially using DT (desktop) for apps that don't run on mobile seems not like the best term, I think.

And unfortunately, there is still no category between "doesn't work on mobile" and "works well on mobile with tweaks", mainly because I don't know how to label such a category. Do you have a suggestion for that?

By Alexander Brzoska on 2021-02-20T15:34:25

I wonder if we should just use a slightly tweaked version of WineHQ AppDB's system: https://wiki.winehq.org/AppDB_Rating_Definitions

Platinum
- Works perfectly out of the box (and is supported for this purpose by upstream?).
Gold
- Works perfectly with distribution tweaks.
Silver
- Works excellently for normal use, but has some problems for which there are no distribution tweaks.
Bronze
- Works, but has some problems for normal use.
Garbage
- Problems are severe enough that it cannot be used for the purpose it was designed for.

What do you think? By distribution tweaks I mean tweaks that can be/are packaged.

There are new identifiers which are (in my opinion) not as cryptic as the old ones.

I think one issue is that "US" and "DIST" are not as intuitive as ratings based on a somewhat common system like rare metals. Sure, the "rare metal system" does not tell you what each rating exactly means without looking up their definitions, but I don't think it's possible to have a system like that without being verbose. Feel free to disagree though, I don't think this is an easy thing to get right.

By Newbyte on 2021-02-20T17:22:39

I think one issue is that "US" and "DIST" are not as intuitive as ratings based on a somewhat common system like rare metals.

Yes, that makes perfect sense. Abbreviations should be as intuitive and approachable as possible. I got so dug up with definitions that I forgot that :)

By distribution tweaks I mean tweaks that can be/are packaged.

Hm, if such applications should be included into the "Gold" category, it would also include apps requiring manual fixes that aren't packaged yet (if I understood correctly?). I think this shouldn't be the case since "Gold"-apps should imho require no interaction by the user. But maybe it would be useful to encourage users to package the manual fixes in pmOS through a note in the "Silver" category (if it's feasible to maintain APKBUILD's that only have minimal differences to upstream. i've never packaged anything though, i don't know what the best approach would be)?

Because of that, I didn't replace the definitions yet, only the category names.

I also thought about how to visually indicate categories:

Current version
Using small capitals (makes it easier to discern application name from category I think even though it looks slightly weird):
Moving it into the new convergence comment:

Maybe not that important, but I figured I'd ask here for opinions on this.

By Alexander Brzoska on 2021-02-22T12:31:18

Thanks for the mockups! I agree that US and DIST aren't clear, US makes me think of united states.

Ratings

Now that I see the mockups, I'm second guessing if there is really so much benefit in having the ratings there. Alternatively, we could just write on the app page if there are any issues with the app (regarding mobile or otherwise). We would not have space constraints there (no need to crunch it into a questionable "rating", or to explain it in a very short format which may lead to wrong impressions) and it would be easier to maintain - just update the wiki page of the app, no need to update the overview too.

As user deciding between a few apps, I would click through the wiki pages and possibly find a screenshot and more information about each app there, it should not be too hard to compare them. (And again, a simplified rating may give the wrong impression anyway, and it's hard to consistently rate all the apps, we would need a strict rule set and somebody who keeps an eye on them...)

With all that in mind, I think it would be best not to put any ratings on that page, and probably not mention how well apps work on mobile at all. If they don't work with mobile, then it's not useful to put them on the list in the first place (as it clutters up the list, let's rather have a list of apps that can actually be used).

Indications

I like the flag indication for apps that rely on proprietary networks / are not in line with postmarketOS principles. Here it would be good to describe where the app fails to meet our principles.

How about:

Giara - Reddit client

This app promotes non-free network services

https://gitlab.gnome.org/World/giara || giara

Inspired by F-Droid, e.g.: https://f-droid.org/en/packages/org.schabi.newpipe/

By Oliver Smith on 2021-02-23T21:01:30

Now that I see the mockups, I'm second guessing if there is really so much benefit in having the ratings there.

Probably because my HTML/CSS and Wiki skills are pretty bad ;)

We would not have space constraints there (no need to crunch it into a questionable "rating", or to explain it in a very short format which may lead to wrong impressions) and it would be easier to maintain [...]

Yes, these points are very valid. Also, as you said too, all those different labels and things might confuse a user using the list — the defining feature of ArchWiki's applications page is that it only shows very basic information and doesn't overload the user with unnecessary stuff. If anyone would like to see mobile ratings, they could still go to LinMob's list which is well maintained.

Ratings are now removed from the App template. If someone else wants to make a case for them (@Newbyte ?), please say it. It would be possible to create an "app infobox" template for app pages based upon the infobox template which includes basic information (like package, a screenshot, ratings etc.), if someone expresses interest in this.

If they don't work with mobile, then it's not useful to put them on the list

Hm what should we do then with the information from pages that are destined to be merged into the list? E.g. I've now removed many apps that are not suited for mobile from the Webbrowser category, these originally stemmed from the Web Browsers page. Maybe it would be useful to migrate them to an application page in Alpine's Wiki (even though, as far as my search goes, such a page doesn't exist yet)? Or to a new application backlog page in the pmOS Wiki?

I like the flag indication for apps that rely on proprietary networks / are not in line with postmarketOS principles. Here it would be good to describe where the app fails to meet our principles.

I've converted the conv_comment argument to an antifeatures argument (look at the app template for examples). It's possible to put multiple antifeatures on seperate lines (delimiting them with a colon), is this needed? I'm also thinking about an antifeature template to easily insert common antifeatures. Let me know what you think.

By Alexander Brzoska on 2021-02-24T17:10:07

If they don't work with mobile, then it's not useful to put them on the list in the first place

The problem is really that whether something works on mobile isn't so much a binary thing. You have things like SuperTuxKart where the menus are borderline unusable and the game has no touch controls unless you enable them manually, but once you get past the unsuitable menus and enable touch controls it's quite playable. Should this be on the list? I'd say so. But it's also somewhat misleading if users expect every application on it to just work on mobile as some applications — for now anyway — require manual tweaking, but work fine once that's done. I think we should have some way of signalling that something needs manual tweaks, or only partially works.

By Newbyte on 2021-02-24T17:09:08

If they don't work with mobile, then it's not useful to put them on the list

Hm what should we do then with the information from pages that are destined to be merged into the list? [...]

In general, pages that are not maintained and don't make sense anymore for the most part, could be copied to the user that contributed most to them (User:theusername/somepage) and then removed, mentioning the new page in the deletion message.

The problem is really that whether something works on mobile isn't so much a binary thing. You have things like SuperTuxKart where the menus are borderline unusable and the game has no touch controls unless you enable them manually, but once you get past the unsuitable menus and enable touch controls it's quite playable. Should this be on the list? I'd say so. But it's also somewhat misleading if users expect every application on it to just work on mobile as some applications — for now anyway — require manual tweaking, but work fine once that's done. I think we should have some way of signalling that something needs manual tweaks, or only partially works.

Good point... if we go with your version, then we are back to some kind of rating though. I don't have a strong opinion regarding keeping only mobile apps on the list or not (as mentioned, it's hard to draw the line), or if they should get a "works well on mobile" rating. @Newbyte, @alpabrz, can you come up with something reasonable for that?

Maybe have not being mobile friendly as antifeature listed just like other antifeatures?

In general I'm very happy how the list and templates are coming along, and I wonder what you can come up with regarding this.

I've converted the conv_comment argument to an antifeatures argument (look at the app template for examples).

Looks great, thanks @alpabrz!

It's funny that you have used the :golf: emoji now, I meant that as placeholder for the red flag you had (but also looks nice in the wiki, at least with my current machine's fonts).

It's possible to put multiple antifeatures on seperate lines (delimiting them with a colon), is this needed?

Yep, this is needed. As in the "spot" example you have.

I'm also thinking about an antifeature template to easily insert common antifeatures. Let me know what you think.

If it is not too cumbersome to implement / maintain, then that's a good idea! We will need the same antifeatures texts over and over.

By Oliver Smith on 2021-02-24T23:42:34

Took me way longer than anticipated to answer to this

In general, pages that are not maintained and don't make sense anymore for the most part, could be copied to the user that contributed most to them (User:theusername/somepage) and then removed, mentioning the new page in the deletion message.

Great, I'll try to do that then.

Antifeatures

There is now a template for that: Template:AppAntifeature and its alias Template:appaf, to simplify referencing. Feel free to add any antifeatures to that template or improve its "code".

Noteworthy change in the app template: The delimiter for seperating multiple antifeatures is now :: instead of :.

I'm still torn about the definition of "uses proprietary web services" since there are some applications that depend on such services (Spot, Giara) and others in which you may choose to use proprietary services, e.g.:

~~Firefox: Pocket's server code is AFAIK still proprietary, but they are in the process of open-sourcing parts of it here and it seems that they plan to continue this effort.~~ Nevermind, mobile-config-firefox!3 (merged) solves that.
KTrip: Uses KPublicTransport which may (if you choose to!) query proprietary provider backends.

Another case where I'm not sure is GNOME Maps, since it uses per default Mapbox's Tiling Service which AFAIK is not FOSS.

Any ideas about that? Should the discerning property be whether the proprietary service is opt-in or opt-out?

Mobile categories

Right now antifeatures are used to mark applications not optimized out of the box for convergence / mobile use (i.e. apps not belonging to the Platinum or Gold categories) because antifeatures are easy to add. It might be viable to reintroduce categories later though, at least on the app pages to have a more granular differentiation. But since in most cases they already contain instructions on how to tweak apps for mobile use I'm unsure about whether that's needed.

What about adding Apps that are broken in some pmOS configurations?

E.g.

Chromium: Doesn't have Wayland support and fails at the moment in Wayland-based shells (at least for me, and I've seen similar complaints in the chat + pmaports#998).
FreeTube: Similar problem since it uses Electron.

In the long run this should of course be patched upstream or at the distribution level, but should we exclude such apps from the list even when there's a wiki entry explaining how to fix it?

Implementation

There are now many new app entries on the wiki page which follow abovementioned conventions. Most of them are tested on Phosh with x86_64 (QEMU) and aarch64 (PinePhone). These entries are mostly accumulated from the various preexisting pages. Any Apps that didn't make it into the main list (because of lacking mobile support or other issues) are put on this page.

Contribution Guide

For someone who wants to add apps to the list, a page which explains general guidelines and intentions of the applications list might be useful. There is a first draft of such a page available here. The guidelines are roughly based on discussions here and postmarketOS' principles. When it's ready, I'll move it to a subpage of the application list and link to it.

By Alexander Brzoska on 2021-03-08T10:33:03

Whoa, thanks again for all the effort you have put into this!

There is now a template for that: Template:AppAntifeature and its alias Template:appaf, to simplify referencing. Feel free to add any antifeatures to that template or improve its "code".

I've changed this:

4: This app seems to be no longer maintained. (either the project frankly states this or ~~the last release longer than five yeas ago and~~ there is no noticeable recent activity)

It's hard to give a timeframe here, and five years is clearly too long (if there is one month without answers to critical issues/any other activity, I'd consider it "no longer maintained"). But let's simply not give a timeframe here, and let people use common sense.

The rest in that template looks good to me!

I'm still torn about the definition of "uses proprietary web services" since there are some applications that depend on such services (Spot, Giara) and others in which you may choose to use proprietary services [...] Any ideas about that? Should the discerning property be whether the proprietary service is opt-in or opt-out?

Good question. How about we make two "antifeatures", one for "depends on" proprietary service, and one for opt-in (only a lightly worded warning for the later, since that's not as problematic in the eye of a person who wants to use free services)?

I'd prefer that over not mentioning at all that this software may use proprietary services, even if it is "just opt-in".

Right now antifeatures are used to mark applications not optimized out of the box for convergence / mobile use (i.e. apps not belonging to the Platinum or Gold categories) because antifeatures are easy to add. It might be viable to reintroduce categories later though, at least on the app pages to have a more granular differentiation. But since in most cases they already contain instructions on how to tweak apps for mobile use I'm unsure about whether that's needed.

I like how you've implemented it, with the same antifeatures template it is easy to use and to maintain. we could refine it more later on if that should be necessary.

regarding broken apps:

In the long run this should of course be patched upstream or at the distribution level, but should we exclude such apps from the list even when there's a wiki entry explaining how to fix it?

If there is a clear path towards fixing it, and it results in a good improvement for postmarketOS overall (i.e. not some random app that probably nobody will use even if it was fixed), I think it makes sense to include it in the list. This also gives it some visibility, maybe somebody wants to streamline the fix then. (With that being said, I'd like to avoid having a list that mostly consists of non-working apps. so there's a balance to be struck, you can probably figure something out with your own judgement :) )

Contribution Guide

Looks good from a quick glance!

With all the effort you've put in here, I think we'll mention the wiki page and contributing guide in the next podcast episode (will be released towards end of month) to give it some visibility. Great work!

By Oliver Smith on 2021-03-09T21:37:05

Good question. How about we make two "antifeatures", one for "depends on" proprietary service, and one for opt-in (only a lightly worded warning for the later, since that's not as problematic in the eye of a person who wants to use free services)?

Done! Added this new antifeature to apps that I know of.

With that being said, I'd like to avoid having a list that mostly consists of non-working apps.

Yes, some apps should probably be removed from the list. I feel like the bar of quality lowers a little bit when testing around 100 apps, of which some are just barely working :) I'll try look over the worst contenders again with a fresh mind the following days.

Contribution Guide

... is now moved to the main wiki.

With all the effort you've put in here, I think we'll mention the wiki page and contributing guide in the next podcast episode (will be released towards end of month) to give it some visibility. Great work!

Very honored, thank you! Some publicity is nice, to have new opinions coming in from more diverse users and use cases, right now everything is a little bit Phosh-centric, e.g. at the moment there aren't any default apps from more niche DEs such as SXMOs included. And don't forget to mention @Newbyte and Railroadmanualjimmy from the Wiki (and yourself!) too, without extensive input this app list probably wouldn't have gotten so far! That being said, there is still a lot left to do. But at least the skeleton is mostly done.

By Alexander Brzoska on 2021-03-15T15:29:07

Thanks for working on this, @alpabrz! Indeed, the apps related pages in the wiki need an overhaul, and arch linux does have nice templates. I like the applications by category page you have created, and the aports and pmaports templates (cool with the small PMOS text).

I've changed the link from the main wiki page for apps to point to your pretty new page, instead of the apps category

I suggest to move the big TODO blocks into this issue (or other issues where it makes sense, or just removing), reading a wiki page that starts with a big TODO list is distracting and oftentimes it may not even relate to the information listed below.

To answer some of the questions:

Maybe merge with Applications (include all info from that page here)?

Yes, please merge both pages, in the style of your new page :)
Can you also merge the Games page into this one and leave a redirect?
There's also a potential apps page... not exactly sure what to do about that, I guess leave it for now and maybe long term transition to only have your page and creating issues / merge requests for potential apps instead of having it in the wiki. but there was a lot of work put into it apparently, even recently, so just deleting it isn't so nice. (can somebody ping User:Unah and point them here?)

Checking whether described apps actually work.

Maybe add a (non-distracting, just text) note right before the table of contents, that explains how people should add their experiences of whether an app works or not.

I suggest to file an issue (in pmaports) if an app does not work in postmarketOS, but they would like to use it (and are ideally willing to look into it), and link to the issue on that page with a note about what does not work.

And if an app works, add a brief description about how well it works. For example, Firefox is very usable for basic webbrowsing with mobile-config-firefox, but some advanced features are broken. (mobile-config-firefox#3 (closed) and mobile-config-firefox#4 (closed))

Firefox — Extensible desktop browser, requires manual fixes to work on mobile.

The mobile-config-firefox is shipped by default in postmarketOS, where firefox is also shipped by default (Phosh, Plasma Mobile, Sxmo). Manual fixes sounds like users need to do manual fixing, but that's not the case, can you reword it?

Giara

Move to "Clients for proprietary protocols"?

By Oliver Smith on 2021-02-17T18:25:01

Firefox — Extensible desktop browser, requires manual fixes to work on mobile.

The mobile-config-firefox is shipped by default in postmarketOS, where firefox is also shipped by default (Phosh, Plasma Mobile, Sxmo). Manual fixes sounds like users need to do manual fixing, but that's not the case, can you reword it?

Not him, but done. Let me know what you think of this wording.

Giara

Move to "Clients for proprietary protocols"?

The "Clients for proprietary protocols" sits under the "Communication" subsection and Reddit isn't really a communication app in that sense. I was a bit thrown off by this at first too (it becomes a bit unclear when you have subsections this deep) but I think it makes sense as-is.

By Newbyte on 2021-02-17T18:25:01

Not him, but done. Let me know what you think of this wording.

Great!

The "Clients for proprietary protocols" sits under the "Communication" subsection and Reddit isn't really a communication app in that sense. I was a bit thrown off by this at first too (it becomes a bit unclear when you have subsections this deep) but I think it makes sense as-is.

I'd argue, the protocols are for communication. the free software alternative, lemmy builds on a free software protocol. In any case, I think it's good to mark software that relies on proprietary protocols / APIs / websites as such, in order to promote open ones. Maybe somebody can come up with a good wording, that's clear?

By Oliver Smith on 2021-02-17T22:23:04

I'd argue, the protocols are for communication

That's not my point. I'm saying Reddit is not quite the same type of service/protocol as e.g. Telegram or Signal. I do agree that we may want to clarify that Giara uses a proprietary backend though.

By Newbyte on 2021-02-18T10:10:56

Thanks for the extensive feedback, everybody! And sorry for the late response.

I suggest to move the big TODO blocks into this issue

Done! Because people should be aware that this page isn't even close to finished yet, I've linked to this issue. It'll only probably take some time for me to get through the TODO since I'm working relatively slow.

In any case, I think it's good to mark software that relies on proprietary protocols / APIs / websites as such, in order to promote open ones.

+1. Theoretically, we could add a seperate "relies per default on proprietary services" subsection for every category. However, this could become a hassle in the long term since there might be many such applications in most categories coming in (e.g. sometimes music players automatically fetch album covers etc. from Google / some unfree music service). Another idea: Just use some kind of visual representation that mark all apps which do not adhere to pmOS' principles; we might then add some subcategories for specific violations (e.g. like F-Droid does):

Tag

Background Color

Any thoughts about this? I prefer the background color since it's just a stronger visual indicator, even though it looks like straight from the 90ies ;) We may use a tag later to indicate apps shipped via 3rd party distribution channels (like Flathub or AppImage etc.).

And if an app works, add a brief description about how well it works.

That sounds like a great idea to provide better information regarding convergence. There is now a new (optional) argument conv_comment in the app template for this purpose, but the categories still do remain, for the sake of simplicity and easy reference.

Feel free to object all visuals of proposed changes, I'm not a design guy :)

By Alexander Brzoska on 2021-02-22T13:12:14

Should we add cli applications (right now, everything is focussed around GUI apps)?

Describing CLI apps would be more useful for the alpine wiki than here.

By Oliver Smith on 2021-02-17T17:11:24

Something I'm thinking about is what word we should use to describe applications that can adapt to various form factors (prominently handsets and desktops). This article uses "adaptive", which makes sense but is a bit ambiguous (what do they adapt to?) and not something I see often. In web development the term "responsive" is usually used, but that could also mean responsive as in responds quickly to input. Convergence (which in this context would be "convergent") seems to be what's commonly used in the mobile Linux community[1][2][3][4], maybe we should use that instead?

By Newbyte on 2021-02-20T15:50:44

Thanks for the hint! I was not aware of these semantical uncertainties. Edited the page to use this term, hope it's fine.

By Alexander Brzoska on 2021-02-20T15:50:44

Another thing I've been thinking about is whether we should suggest installing applications via Flatpak on the wiki. Flatpak is entirely supported in Alpine and has the benefit of that upstream can handle packaging (which means we can work on more important things), but I understand is controversial. Personally I'm for doing this at the very least with free software applications distributed as Flatpaks, but I understand if you feel differently.

By Newbyte on 2021-02-18T11:57:56

As an example of how this might be handled I added an entry for Spot (a Spotify client) under Multimedia. It includes a Flathub link utilising a new Flathub template I created. (It's not currently packaged in neither pmaports nor aports, so I couldn't really link anything other than Flathub anyway)

By Newbyte on 2021-02-18T11:57:56

Because there have been some critical stances on Flathub in the project (e.g. https://wiki.postmarketos.org/wiki/Flatpak, https://gitlab.com/postmarketOS/postmarketos.org/-/issues/94 and https://wiki.postmarketos.org/wiki/About_postmarketOS#Prefer_free_software_services) it would be probably wise to mark such applications that are not shipped by pmOS or alpine (this would also then cover applications using AppImage etc.). We might use a tag or something for this. But maybe it's overkill and it's enough to add a note at the beginning which mentions that and encourages users to package these applications for pmOS / Alpine.

By Alexander Brzoska on 2021-02-22T13:23:25

Maybe:

This app needs to be installed from a third-party Flatpak repository.

By Oliver Smith on 2021-02-23T21:01:35

There's also the https://wiki.postmarketos.org/wiki/Web_browsers page which we probably want to merge into this one.

By Newbyte on 2021-02-18T17:27:24

changed the description

By Alexander Brzoska on 2021-02-19T17:06:32

changed the description

By Alexander Brzoska on 2021-02-19T17:29:39

changed the description

By Alexander Brzoska on 2021-02-19T17:38:27

changed the description

By Alexander Brzoska on 2021-02-19T17:39:06

changed the description

By Alexander Brzoska on 2021-02-20T12:10:25

changed the description

By Alexander Brzoska on 2021-02-20T16:01:38

marked the checklist item All information from old applications page as completed

By Alexander Brzoska on 2021-02-22T19:11:23

marked the checklist item App category as completed

By Alexander Brzoska on 2021-02-22T20:47:47

changed the description

By Alexander Brzoska on 2021-02-22T20:48:44

changed the description

By Alexander Brzoska on 2021-02-22T21:58:40

marked the checklist item Games page (possibly ask Martijn Braam & Nergzd723 before merging) as completed

By Alexander Brzoska on 2021-02-22T21:58:46

changed the description

By Alexander Brzoska on 2021-02-22T22:09:53

changed the description

By Alexander Brzoska on 2021-02-22T22:11:19

mentioned in merge request cast.postmarketos.org!7 (merged)

By Oliver Smith on 2021-02-23T20:32:42

Application discovery in the wiki / New Templates + page

New Templates

New "applications by categories" page

Child items ...

Activity

Ratings

Indications

Antifeatures

Mobile categories

What about adding Apps that are broken in some pmOS configurations?

Implementation

Contribution Guide