App Store UX

[DerZyklop]

The concept says:
"It should be decentralized as well, so there could be an "app server" app for GDC to host your own app repository. A user could then subscribe to that server using its URL and could browse, buy and download apps directly from there."

This sounds to me like: You go to a retail shop (App Store) where the shelfs are empty. You don't see any products, until you say which manufacturer (developer) you want to subscribe to. But to do this, you have to go to other Places ("The 10 Best GDS-Apps!"-Blogposts and stuff) to get to known some manufacturers.

One of the reasons why AppStores are so successful, is that the Users don't have to know anything. They know that there is this one place, where they can download every app (..okay, not every, but thats how it is in their understanding) and there are the Top-Lists and the recommendations.

If we could build something decentral that works just like the App Store described above, it wouldn't preclude the feature to add additional URL's from developers, who don't want to be listed in the regular GDS App Store.

What do you think about it?
And how could this technically work? Something like #24?

[DerZyklop]

Developers could set a flag in the app.json file to define wether a app should be listed in the store, or not.

[lukasbestle]

By writing that part of the concept, I didn’t mean that shelfs will be empty at the beginning.
There just must be a way to add additional repositories.

Jep, it could work like in #24 - but that would mean the shelfs are empty at the real beginning when you didn’t yet connect to anything.
So we might need to define some discovery & monitoring nodes, so a new GDS can at least get a list of app stores right at the beginning.
I don’t really like the idea of a hardcoded centralized discovery & monitoring node, though.

[augustl]

FirefoxOS is a good model here. There's a button called "app store" that gives you Mozilla's app store. But developers can write their own app stores, and you can distribute/install apps outside of the app store.

At the bottom line is the manifests that lets you install web pages to the phone as apps.

[augustl]

Also, in my opinion, the ability to easily install apps you discover elsewhere is a big step forward imo. There's already a lot of discoverability of SaaS web apps. In the vein of not trying to solve too many problems at once, I don't actually think an app store should be in the first milestone of a working 1.0 version of GDS. The most important thing is that it's easy for non-techies to host their own apps :)

I'm not saying app stores is a bad thing, I think having an app store (or many app stores) is a benefit.

[lukasbestle]

I don’t think we should go for multiple app stores in the first place.
This will happen and must be supported, but it’s much easier for the user to search, browse, buy, install and update apps from one single app store.
That’s why we need additional repositories - they have a URL the user can enter into the app store to give the user access to tons of additional decentralized app stores without having to use different UIs.
This works well for Synology DiskStations and is an easy way to keep everything open.

[augustl]

I agree that it makes sense to have a single app store as a part of our default GDS implementation. And even an API so that other implementations can show the same apps, etc.

As long as the method of installing apps is made so that it doesn't matter if it comes from an app store or anywhere else, we're good to go :)

[lx4r]

I agree to @vis7mac and @augustl that we should have a single app store.
Another important benefint of having just one appstore is in my opinion that the permission request messages (e.g. "App X needs to access your mails") all look the same.
I think this is important because it's easy for the user because he get's used to it and because we can try to prevent "evil" developers from not exactly telling the user which permissions an application in a custom app store needs (e.g. the message could just say "Install" and wouldn't tell the user about the mail permission but would just get it when he clicks "Install").

[lukasbestle]

In my opinion, the permission request messages should not be part of the app store but rather of the core.
This would make installing apps from a file (like .apk on Android) possible.

But yeah, before even downloading apps, the user should already know what the app wants.

[augustl]

I think it's important to support installs outside of the app store.
When I said that we should only have one app store, I really meant that
the default implementation should only have one app store in it. But
everything needs to be protocol driven, to avoid lock-ins.

On 10.11.2013 10:29, Lukas Bestle wrote:

In my opinion, the permission request messages should not be part of
the app store but rather of the core.
This would make installing apps from a file (like .apk on Android)
possible.

But yeah, before even downloading apps, the user should already know
what the app wants.

—
Reply to this email directly or view it on GitHub
#36 (comment).

[lukasbestle]

Exactly! Every app store should have a file format as base, but everything around it (payment, browsing etc.) should be decentralized.
If we want to define protocols and then create a reference implementation, this will even be required: The reference implementation will have an app store and every other implementation might have a different one.
Yet, we have to ensure that the UX of each app store feels the same and it’s easy to migrate existing apps to another app store/GDS box.

[lx4r]

Ok, you're both right. I made a fallacy.
I totally agree with what Lukas said: The permission request should be
displayed by the core if a user installs an app regardless of wheter
he installs it from an .apk or from an appstore.

[timkaechele]

Why not using kind of homebrew-formula like repositories, that handle all apps. There could be one official App Store Repository, that is completely curated and has a strong code review, to protect users from malware. i guess 99% of the new apps using version control use git anyway, so that would be a no brainer, The main App Store Repository would not contain any real application code. It would reference to the {app|package}.json that provides all the important app informations. Adding a new App Store Repositories would be handled with a simple UI -> insert Repository URL.

Actually I don't understand the idea of supporting several app store apps, looks to me like one of those, »make it open« overkills. There's nothing wrong with cutting down confusion for the end user, one app store app, many app store sources that contain the apps.

[lukasbestle]

I totally agree with the idea of having one app store and multiple sources.

But there's one problem it creates: If we curate apps, it's centralized again.
We need to decide if that's what we want.

Of course, it is actually decentralized as you can add different repositories, but the main idea is centralized again, as the main repository is hosted centrally (on GitHub? Do we want that?).

[piranna]

Being the code of the App Store open source I don't find it as bad being centralized, since if it gets down any other one can clone it and get it up. Another alternative would be to have synchronized "Federated App Stores", so there would be several of them but all have the same apps, only that each one has the extra features they want. Paid apps would be a diferent issue, but maybe in that case it would be one of this "extra features" of a particular App Store, due to comertial agreements, commisions and so...

What about using Mozilla Marketplace as basis and/or inspiration? Maybe there would be a lot of code that can be reused...

[jnv]

I think the repository model of most Linux package managers wasn't mentioned -- which is kinda like Homebrew, but less assuming / more robust.

Say there are some default repositories. You could easily add new repositories (like Ubuntu PPAs) and see all available software in a package manager (like Aptitude). The software could be shipped either in complete packages (like APK, Deb, RPM..) or just provide build recipes (like aforementioned Homebrew or Gentoo's overlays).

However, the nice thing about Mozilla's Open Web Apps manifesto (used by Firefox OS) is that you don't need a marketplace at all: the app can just call a JS API which shows an install prompt to the user; such process is completely decentralized.

[piranna]

I talked about Mozilla Marketplace just because I had in my mind the Ubuntu App Store... ;-)

[lukasbestle]

Apps being able to install from the web is quite limited to devices with a display. You can decide if you want to visit the site or if you want to install it.
A server is different: An app doesn't work if you don't install it.

I like the idea of having a decentralized app store living everywhere. We need to make sure there's no way of scamming there (manipulating the repository), though.

Regarding payed apps: Why don't we use a Kirby-like business model (try as long as you want, pay when you use it)? This would make paying for apps not a problem of the repository (it could list these apps anyway).

[timkaechele]

While relatively awesome in the context of Kirby, Developers who honor the invested work into a product, how it simplifies their work and the fact the they can put the price on the client's budget. I think that the »we trust you, don't be an asshole« Model doesn't work very weil in the consumer Space, it could end up like the android App Store where everybody fears even the smallest fee and downloads some cracked version. I really like the Kirby model, but the problem with it is trust, developers who developed sth. don't want to end up with 2 sales because everybody else cracked or used it as a demo forever.
Well the the homebrew like app repository doesn't have to be centralized. It is based on git, generally something that is build for decentralization. So I agree with @piranna approach.

[lukasbestle]

That's right. But how would you handle payments, then?
Per repository? Per app?

[piranna]

@vis7mac, as I told before, I would find a good balance that paid apps are per-store extra features, so this would allow some management and also some "exclusives" while at the same time free apps can be available on all the markets, all the time.

Think of it as a global repository of public, free apps, and later several paid, closed repositories, all of them accesed using the same API, that's the only point that "centralized", a common API for everybody to access to the global open repo and register the closed ones. This way anybody can build its own market, since they would be just client apps that use that API, no more.

[lukasbestle]

But how? :)

[jnv]

Apps being able to install from the web is quite limited to devices with a display. You can decide if you want to visit the site or if you want to install it.

That's true, web apps are really simple scenario, I've just mentioned as an example of a distribution decoupled from the central marketplace (well, this and EXE installers/DMG apps).

For the payment, consider also how the recovery should work: what if I lose my server? How can I recover my previously purchased applications? Can I install them on an additional server? If so, how to prevent an abuse?
The Firefox Marketplace approach is to tie in your payments with one marketplace. Ubuntu ties your payments with their Ubuntu One account but on background, you get a private repository for each app you have purchased.
I think this ultimately leads to some form of identity management tied into a “marketplace API”, which would verify your previously purchased apps.

[lukasbestle]

But who would verify and store your purchases?

And how would you prevent cracking?
Simple answer: You don't.

I read a study saying that people tend to buy software without DRM and if it doesn't annoy you more likely than a software with DRM.
So maybe trusting the user and not applying crazy DRM with crazy restrictions (like Adobe or Microsoft do) can be a simple solution.

Why don't we do it like Sublime Text? It displays a message every couple saves to remember the user to buy it. There could be a area in the app store called "unpaid installed apps" doing that.
Many people will buy software if it's good, even customers. This forces developers to create good software to get paid, which will prevent the creation of scamming apps.

There's always a percentage of illegal users of a software, but making buying complex doesn't help there.

[piranna]

Agressive ideological point of view, but by far the simplest solution and I agree on it. +1, maybe later if need arise it could be considered another revenues posibilities.

[lukasbestle]

We might just need to test it.

I don't know if it will actually work, but if it does, it's better for the customers than any other method. And that's what matters. :)

[jnv]

At none point I have suggested that the goal is to prevent cracking or force some terrible DRM upon users. It's a common observation that DRM schemes hurt the legitimate users in the first place. But distribution based DRM can be somewhat mutually beneficial—for example Steam, which gives me a permanent access to purchased games in exchange for some limitations. There are also DRM-free stores like Humble Bundle or GOG; still centralized, but I can always come back and download my purchased games.

And your suggestion, @vis7mac, as much as I would love to see it work, still doesn’t answer what happens if I need to recover my purchased applications. In Sublime Text's case (and even Kirby's for that matter), everything rests on developer's shoulders. He had to add the nag screen, setup payments, create account system etc. And users have to keep track of their licenses and maintain updates.

[lukasbestle]

No, that wasn't directed to you specifically. It is just another problem. :)

Yeah, making sure people keep their purchased license is totally separate from the way you purchase an app.
In my opinion it is totally legit to store this information on the GDS of the developer (in an "app distribution server" handling purchases and downloads), it doesn't need to be decentralized. You could enter the URL of the developer's GDS as a repository and you have access to all apps by that developer.
The app distribution server would be an app from the base GDS repository anyone could install.

If that GDS is confirmed to be down from several places (important to prevent firewall hacking ("making it being down")), that means that the developer does not sell the apps anymore, so it's automatically free.
If it is up, the app store asks there if the license was bought.

The "user ID" to ask for could be a public key generated for each box.
A backup of the key pair or contacting the developer directly would be the only ways to restore your purchases (which will be fine in most cases).

[DerZyklop]

Are we more or less on one mind how the AppStore should work? If so I'd propose to open a new issue to discuss the management of app-purchases.

[jnv]

Yes, that makes sense. It also opens up the market for third party servers in case you wish to offload distribution or wish for better reliability. There could be even license mirrors.
Really crazy idea would be to store purchases in Bitcoin-esque blockchain, but that certainly doesn't help with privacy. :)

I think another concept should be considered too—donations instead of purchase. This is what Mozilla did with Firefox Add-ons and it kinda works with Gittip and Flattr; I think it also goes better goes with GDS's concept, assuming the most of the software will be free and open-source.

[lukasbestle]

I don't think most software should be free (but open-source, of course!).
Normal customers expect products to have a price tag. Otherwise, it's the same problem as with data silos (Google etc.): You sell your data.
Of course, that's not what we do or want to achieve, so selling the software makes it possible to deliver actually great software without hidden income.

Regarding the block chain: Why not, they are unique IDs you can't track in the end.
But I don't think we need to do that.

[timkaechele]

@DerZyklop Well I don't think so. the general implementation is still open.

@vis7mac The „add the repository url“ approach for payed apps looks really complex to me. That would mean you have to actively search for paid apps. Not very appealing.

@jnv The Donations thing could work, but as a developer it is a downer to rely on donations. You develop something of value so you should get paid for it, otherwise no developer decides to program sth. for the GDS in the first place.

I totally agree with @vis7mac and the user id idea. If the app hosting server relies on git and gitolite you could add the public key of the buyer to a read-only list and grant them access. The app itself could be backed up on an external drive/usb-stick. If you want to install it on another server via the app store there should be a panel for adding another public key, you could limit the amount of registered public keys.

I agree it doesn't solve the demo problem, but actually I don't see a good solution. My only approach would be that the developer hosts a special demo version that automatically deletes itself after a period of time or has only a limited functionality.

Even if you are using some kind of DRM it should stay convenient for the user, so it doesn't limit him drastically, so that users don't try to break out.

[lukasbestle]

@timkaechele Regarding the "add repository URL" problem: Yeah, but we could create repositories of developers or apps, so that's not a problem.
The only important point is that developers host their code and payment themselves.