Special attribute "Native Pandora App" for the repo or PND-XML, so that native apps get the exposure

[Exophase]

I don't think adding new PXML fields would be useful, most released .pnds will never be updated and hence will never be flagged with anything. That's unless the PXML is modified by the repo itself, but that would be painful for milkshake to implement, plus there are .pnds released under closed licenses that don't allow modification of released binaries at all. I personally wouldn't like my released pnds to be edited by anything too.

Maybe the repo itself can have annotations?

Yes, ideally the license field is filled in correctly and sufficiently unambiguously. But it's kind of hard to make a repo viewing filter based on that field, because some people might write "GPL", others might write "GPLv2+", others might write "GNU General Public License v3", etc. Plain-text fields are not that easy to work with.

Nonetheless, it's a good place to start. I looked at the repo and it doesn't seem to even list license at all right now, so that should be changed shouldn't it?

Something like this might be a good path (some things maybe not, I dunno):

1) Enumerate all current values used for the license field to see what's used

2) Use database annotation overrides to group together ones that clearly mean the same thing (like GPL vs GNU General Public License)

3) Use database annotation overrides to list something for PNDs that have no license field but where the license is obvious

4) When PNDs are uploaded try to match it to one of the licenses in the database, ask the uploader if the match is okay, or if it can't match suggest to change the license (providing the list)

5) Have some builtin filter options with reasonable combinations of licenses

In practice I doubt that many licenses were used so this shouldn't be that much of a monumental problem..

 

[ssokolow]

Nonetheless, it's a good place to start. I looked at the repo and it doesn't seem to even list license at all right now, so that should be changed shouldn't it?

It's hidden in the "Package Contents" expander which always defaults to closed and requires a full page reload to open.

 

[foxblock]

First of all a "native" or "exclusive" application might not be superior to a port so filtering for that is not a good idea. Instead (and this probably is the main idea anyway) one would want to filter based on how well the software adapts to the Pandora (fullscreen?, touchscreen support?, button support?, nub support?, how well does the interface fit?, etc.)

There has been talk about a "Pandora Originals" seal-of-approval before and while I was in favour back then, I no longer am.

Such a seal creates a huge bias towards certain applications and while some are obviously superior than others this comparison is not as clear in all genres. Having a small pool of such applications might lead users to not try anything else and experience the full library the Pandora has to offer. (As an example see the "suggested" software list on pandoralive.info). Having a large pool is just as overwhelming as having none.

While I agree that the huge amount of available software can be overwhelming for new users, I think the current "top rated" and "top downloaded" lists on the repo do a good job and a seal like this is not the right solution.

Besides who would test applications and who would award the seal? This is quite a huge amount of work and everyone has only his own subjective opinion. Having a large committee is just as good as having the community to vote on stuff (which is already happening).

Rather I would slightly redesign the repo site to highlight positive apps every other day or week. (milkshake even did a mock-up of something like this way back, maybe he still has that graphic lying around).

This could highlight community selected apps, new releases, compo releases, the app with most positive votes that week, etc.

Due to the rotation and non-fixed list new users could try a new app every day/week/whatever and experience good software one after another.

One could also add a "similar apps" or "people who liked this also liked..." box to every app to encourage users to browse and discover new stuff.

Generally I also don't think the amount of apps is discouraging, rather than how apps are designed.

Some need additional data and don't provide a good guide on how to install that integrated into the app (i.e. it is hidden in the documentation, which sadly a lot of people skip), there is no consistency in the control scheme (almost every emulator uses another key for the menu, few games have a good tutorial or button overview, apps generally don't have this at all), the default PNDstore software is not great (and PNDManager is too bulky and dependency ridden to ship at the moment), descriptions are lacking, etc.

Addressing this is not a matter of adding just another field to the PXML spec though.

I support a filter for "free" and "open source" applications, this should be integrated (easily).

 

[porg]

Foxblock: "First of all a "native" or "exclusive" application might not be superior" to a port

1) I agree. But nevertheless I want the possibility to search for the one or other! There must be a way to easily spot native apps.

2) I agree with the rest of your reasoning, that qualitative/popularity judgement (such as a "gold standard" desired by @ParadisoShlee, @Kumaki) should be left to the crowd ("most downloaded", highest rating, reviews, etc).

3) Factual attributes however should be available in the repo. Meanwhile these have crystallized from the discussion:

Licence (@_wb_): Commercial, Freeware (free but not open), OpenSource, Mixed (PND and required data files differ)

Licence Detail: Apache, GPL, ...

Source Code (@ssokolow): None, External, Supplied-with-package

Basic type (@Neelix): Standalone, Requires-additional-data, Installer

Platform (@porg): Native, Multi, Port.