Core Apps » Bazaar

But they want fdroid to be essentially a client for fdroid.org: https://f-droid.org/forums/topic/different-banner/#post-6863.

I like this idea of making recommendations while in physical company; it's going against the grain of mobile where our relationships are getting mediated always by the cloud. Reminds me of how people love to share songs over Bluetooth in some countries.

So my initial thoughts, before thinking to much about it are:

• The UI definitely would be more modern, and in line with other modern Android apps
• I appreciate that reason behind prioritizing "swapping" apps (given your work on the Baazar project), but I still feel that the primary use would be for installing/updating from repos/collections.
• Having said that, I love the idea of encouraging people to share apps like this, rather than "Hey, check out this cool game, you should go download it from the Play store!"

As for separating the repos/collections so clearly: I think that it is inevitable that the client will move from a linux-distro-package-manager-style-interface ("Here is the apps, here is the details of each, you can install/update/remove them") to more of an app store type experience (by which I mean, my technically-illiterate parents would be comfortable using it to install apps). I also like the work you guys have done on packaging fdroidserver for Debian, and all the other work others have done on the server to make it easier for people to use.

Having said that, it doesn't feel like there is going to be enough public repos to make it worth the prominence in the UI. Currently, I always have F-Droid, F-Droid Archive and the Guardian Project repos enabled. I'm unaware of other repos that are available. I could probably do without the F-Droid Archive (I've never once installed an older version of an apk) and the Guardian Project has two orders of magnitude less apps available. The reason I mention the number difference is because the horizontal swiping (in the fourth screen in the image above) would work great for Guardian Project, but not so well for F-Droid. I guess if more boutique repos came online, then this UI would be great, but as the ecosystem currently stands, it may make things more difficult for many.

The above comments about repo prominence are probably more appropriately targeted at the home screen. It is less relevant for the pull out menu on the left, which I think is a great place to separate repos.

If I was to add a contribution, I'd suggest that the home screen concept is still a cool layout, and I'd rea!!lly love to see something like the following where tiles are coloured by the repo they belong to (with light pastelle, less offensive colours that the ones in my picture). Then, the colours could also correspond with the pull out draw on the left, to give a clear idea that "this app came from this source".

@carrie, I didn't really understand what you were proposing with the home screen until just now. Do you think it is confusing that the home screen shows all of the collections/repos merged into a single collection? From my perspective it makes things easier because people can just think in terms of which app, not where it comes from. I think the rest of your UI provides easy ways to get to specific repo/collection views, so people who want to think in terms of where the app is coming from can easily find and switch to those views.

FYI, there is also discussion on the fdroid forum: https://f-droid.org/forums/topic/primary-screens-for-swap-within-f-droid/

@pserwylo I think that this UI strikes a good balance between featuring the FDroid repo as the main repo, while making it friendly to multiple repos, whether those repos are static ones like the Guardian Project one, or whether they are an ephemeral, local connection to the repo on another person's device. I would like to see FDroid have a full ecosystem of repos like cydia, Ubuntu PPAs, Debian repos, etc.

• an Installed item on the sidebar menu, like the current one in FDroid, or My Apps in Google Play
• remove the sections based on repo/collection on the home screen. Perhaps it would make sense to have the home screen like how pserwylo sketched it, where the categories are represented. I still think its important to have a full screen view that only shows apps. That list could then be filtered by category or keyword. Perhaps this would be left to the list view, while the grid view would look like pserwylo's sketch.
• the App Detail view should have big Install/Update/Open/Uninstall buttons like in Google Play

Hello all, Thank you for your feedback and comments!

Regarding the home screen, I agree that if we list the separate repos in a side drawer menu, then it's quite redundant to do that again on the home screen. And, it doesn't make a lot of sense to do that since people will only have 2 repos initially (F-droid and their own). Also, they may never have anymore than that on a regular basis. I will do another round of iteration of these ideas, that will respond the remaining feedback in the thread and from our call on Wednesday.

@hans
RE: Do you think it is confusing that the home screen shows all of the collections/repos merged into a single collection? From my perspective it makes things easier because people can just think in terms of which app, not where it comes from. I think the rest of your UI provides easy ways to get to specific repo/collection views, so people who want to think in terms of where the app is coming from can easily find and switch to those views.

When I first used F-Droid I had no idea what the concept of repos was all about. In my original thinking about the home screen, I was trying to bring that concept to the surface. So that, when people use the app, they understand, "I'm shopping from multiple repos in one place. I can add more repos and have access to more apps." As compared to Google Play, where everything that's available is already there. I think there are other ways to get the concept across if it's important. I'm not married to the original sketch of the home screen. I think you have a good point of people simply thinking in terms of which app they want, and not necessarily where it comes from.

Do you think it's important that people understand the concept of repos—that they can get access to more apps through repos 'locally' (from people around them) and by adding a repo from the server?

The idea of multiple repos will be a novel one for many and it makes sense to expose it on the main activity. I'd suggest that the client start with a splash screen on first use instead of downloading the index immediately. A selection of repos would be offered to the user.

However, the confusing part is when one is confronted by two manifestations of the same version of a package. These quite similar APKs, from different repos, will be signed with different keys. Android handles this quite badly, requiring the user to uninstall the app before installing the one with the new signature; even adb backup won't work with different signatures. Not only that, but the descriptions and URLs offered by each repo may be different. How to hide this complexity from the end user strikes me as a really difficult, if not impossible, problem to solve. Ideally, each minor variant would have its own package name and app name, something which is actually achievable with the new gradle build system. A suggestion I put forward before is to treat apps from a repo as being in their own category: on the action bar in the App Details activity would be a special spinner (menu) to filter the details by repo, whenever there exists APKs from multiple repos.

Adding to the last point, even though the drawer (side menu) would work for filtering (each repo that has the APK can be highlighted in the drawer and the three short lines could be adapted slightly), I'd go for the spinner as it's more discoverable. Cluttering the content with links to other activities is even less preferable. Cluttering the search activity is also to be avoided.

As for nomenclature, repository is standard te rminology on the desktop and it would be preferable to avoid it, as it is not even a common English word. The type of user who will have the most difficulty using this app will probably never have used GNU/Linux computer (sad to say).

Also, local, ephemeral repos, make all this more complex. Such repos are likely to have APKs signed by somebody else, in contrast to repos such as fdroid.org. I don't doubt that repos will proliferate, but we'll always have with us the dilemma of a version in a repo newer than that which we have installed, whether with a new signature or not. So transparent navigation between repos should be a central principle of the UI, or else create a different app.

I just read the Core Concept page on the wiki where it says that collections can be non-app packages, such as books. A collection of books, apps and what-not is sensible, but a bit vague in comparison to the words the competitors use like store and marketplace (stall being the appropriate word in relation to the latter).

The Serval Project started work on p2p maps on a mesh network, but F-Droid could be good for this too. OBB files are not yet supported though by fdroidserver, though I guess the client wouldn't mind them. A interesting app is the single podcast version of Antennapod, a zero configuration podcast downloader for a single-url — that kind of thing deserves to be in a multimedia collection rather than an app collection.

@carriestiens: that's a great point about Google Play having a collection of apps that the user cannot change. I had not thought of that. So yes, we do somehow want to highlight to the user that they can go out and find other repos to add. But that somehow does not override that most of the time, users will just want to search based on apps and not think about where the app is coming from.

There is another related thought I had recently: Google Play has 10s or 100s of thousands of apps, FDroid currently has 1000. So I think it makes sense to keep FDroid's UI a bit simpler in terms of representing the overall collection because its a lot smaller and simpler. Hopefully FDroid will get as big, then later this idea can be revisited.

So all that said, just having the repos/collections on the sidebar might be enough exposure, especially when you can see "FDroid", then "My Repo". I suppose we could add a button on the sidebar that takes the user to the "manage repos" screen. There will be a couple of other repos there already configured, but not enabled. The user would just have to toggle the "FDroid Archive" and/or "Guardian Project" repos already there to add another repo to try out.

@daithib8 I don't think its possible to fully hide the complexity you describe from users, unfortunately. I think a nice clean way to handle the complexity of multiple repos, APK signatures, descriptions, etc. is by repo priority, and it turns out that FDroid already does it this way: most recently added repo wins. I think that's the right default. Perhaps it makes sense to add a UI for re-prioritizing the repos, but that doesn't seem urgent to me.

I think priority is currently more to do with which repo was last enabled rather than when it was added. However a UI can be put in place for setting priorities via Drag Sort List. But consider how this works with f-droid.org and GP repos both installed, with say Orbot installed via f-droid and ChatSecure via GP. If GP is the favoured repo and Orbot gets an update via GP, the user ticks 'ignore this update' as they don't want to uninstall the version they have. A day later f-droid.org publishes the update too but the user never sees it. This isn't too bad when you're talking about small repos alongside the f-droid.org one but it's too messy if there's another big repo. So anybody distributing a large repo with many of the same apps of f-droid.org should probably issue a different client; users will still get nagged for updates but they can tick the 'ignore all updates ' where appropriate. This will still lead to problems any time a signature switch does take place, and the user forgets to untick 'ignore all updates'.

A solution to this would be to set some kind of expiry date on updates. So the client offers updates with a signature change unless the originating index announces its intention to update the app within say, a month.

@hans I agree that finding other repos shouldn't override the fact that most of the time people will just want to search for apps. I also agree on keeping FDroid's UI simpler. And, third of all, I agree that having the repos/collections in the sidebar is enough exposure inside the app. I do think having a quick configuration in the setup would be helpful also in getting people familiar with the F-Droid concept and capabilities. For example:
screen 1: Welcome! [a sentence about how f-droid will make your life better / what it will do for you]
screen 2: Choose repos to get apps from
screen 3: Create your own repo to swap locally with people near you
home screen

How do I add the Guardian Project repo to the current F-Droid? I'm on the manage repos screen, and I tapped the '+' icon to add a new repo, but I don't know which address to put in..

Should be https://guardianproject.info/fdroid/repo (not sure what the fingerprint is sorry, but it isn't neccesary to get going).