Why are we trying to reinvent the wheel if there are already perfectly well functioning systems out there that we can use, such as opendesktop.org and its accompanying sites, like kde-look.org, kde-apps.org, gnome-look, maemo-apps, and more. Using that'll give us a fully functional app-store with all of the features we could wish with practically no development time...
I think that there are several reasons why it would be better to have a specifically developed app-store for the Pandora. First off, none of the options that you listed have anything to do with selling apps, at all. Second, we are going to be using a handheld device; such devices warrant an interface that minimizes the number of steps it takes to find the content that you are looking for. Third, I don't know if you have ever tried to find something specific on one of those sites, with only a vague idea of the name/category that you had found it in before, but it isn't always easy to find things. I remember looking for several wallpapers or window themes and spending more than 20 minutes searching because of the categorization of things on those sites. While I generally like the content on those sites, finding things is not always easy, partly due to the fact that they use categories and not tags, which is why I have suggested the addition of tagging to apps in the pandora app store.
Wait until you see the Pandora appstore. You will understand why it had to be built from the ground up. You will see the advantages - and if you don't like something about it we can all fix it quickly. The chances are you will even be able to skin it.
We are doing internal testing on the appstore now and will be doing something public soon.
Suggestions are still welcome, I rewrote a huge chunk of it today based on a recent suggestion.
I would just like to give a HUGE Thank You to you, Craigix, for putting so much time into the Appstore--something many users think is trivial, but is really one of the most important alleyways of content distribution available for the Pandora, and in many cases what will help decide its fate. Plus, it's so good to hear that you spent much time rewriting some of it based on a recent suggestion, that's just ANOTHER indication of how much of a community-driven project this whole thing is, and it makes me smile. So props to you, Craigix and co.!
I would just like to give a HUGE Thank You to you, Craigix, for putting so much time into the Appstore--something many users think is trivial, but is really one of the most important alleyways of content distribution available for the Pandora, and in many cases what will help decide its fate.
I agree, just take a look at the iPhone and Xbox 360. A well working content store can be a huge benefit for any device. It makes it easier for customers to find content and allows the creators to earn some fame and make some cash. An appstore will increase the userbase and attract creators but will also require users and creators to be successful, thus it is important to sell a lot of units.
[quote name='cobaltage' date='30 December 2009 - 03:02 PM' timestamp='1262181764' post='792923'] I've been wondering lately if the app store can eventually take the form of a video game style interface controlled by the game controllers. Not like a video game itself, but like a loadout or options screen within a video game. Either built within a browser or maybe with a local frontend application that communicates with a server.... I just think that would be cool, and consistent with the Pandora's design. [/quote]
Hmm. I already noted somewhere else that I was planning on a project called "beauty-get" (or "beautyget"). It was meant to become an entertaining and not too boring, appstore-like solution for the Pandora which would be better suited for games than a usual package manager and more fun to use than a www-based solution would likely be.
Suddenly I didn't have much spare time and eventually had to drop that project, but now I'm really curious about how many people would actually be interested in this. Back then I already began creating some parts of the user interface (I always create the interface first, unless there is none of course :) ) and did some brainstorming, so here are some impressions:
Work in progress comments and ideas on this work in progress mockup:
Spoiler
beautyget view "category"
Input: • Swipe Finger/Stylus up/down (kinetic) or use analog controls to scroll. • Move Finger/Stylus left on an item to scroll through available screenshots and videos ("showflor items", screenshots to the left, video(s) to the right) or use analog controls (left/right) to scroll the highlighted game. • Tap a game's "More" button or use Pandora buttons to open the detailed view (opening view "game-showfloor"; The middle game is automatically highlighted at all times for button control reasons). • Tap the rating bar of an item to immediately rate it. • Tap "Back" button in navigation bar to get back to view "category-selector". • Tap "Close" button in navigation bar to quickly fade to view "beautyget-quit" and close beautyget.
Guidelines for content developers: • Ideally, screenshot 0 of your game should show a typical (usually main-) menu (if applicable), screenshots 1 and 2 should show typical ingame action (if applicable), screenshot 3 should show ingame action, either typical or uncommon (if applicable). Only EITHER screenshot 2 or 3 should show something different if necessary. (unless any of that doesn't make sense in your particular case, of course) • Is your "game" a "utility" or some other kind of non-game? Use meaningful screenshots then. You should crop AND scale your screenshots so they reflect important "parts" of your software. Screenshots 0 and 3 should show parts which demonstrate what makes your software special (if applicable, otherwise treat them similar to screenshot 2), screenshot 2 should show a part that IN ADDITION shows the user what kind of software it is that you're giving her (text editor, emulator, media player, IDE...). Screenshot 1 should be focused solely on communicating what kind of software your software is (Any way to accomplish this is a good way in screenshot 1, as long as the user "gets the idea". Be creative and don't have fears to try out weird ideas in screenshot 1, but only do this if it's not a game or it WILL look silly!). • Usually it is NOT a good idea to put the icon of your software in any screenshot or show it in any video over an extended period of time. • Your game should have at least four screenshots. If there are no screenshots (or less than four), your game's entry in beautyget won't look nice. Of course, the more screenshots, the better (as long as they're not weird). There don't have to be any videos at all for your game, but having at least one video (video 0) for every game out there would be nice, wouldn't it? :) • Ideally, video 0 should contain a good amount of ingame action and be no longer than 20-30 seconds to quickly demonstrate why the user may find your game interesting (unless any of that doesn't make sense in your particular case, of course). • Any video except for video 0 should have a short description that is no longer than a yet to be determined number of characters (maybe 140 would be a good choice?). Video 0 will not have a description. • Any game can have an unlimited number of screenshots and videos as this is not critical to traffic. • I will create a simple, quick and visual overview of these guidelines to make it easy for developers to understand all of them so we can hopefully enjoy a mostly coherent experience throughout beautyget.
Thoughts on rating: • Installing an item will automatically remember it as "to be rated positive (68/100) if not uninstalled within 24 hours, to be rated positive (85/200) if not uninstalled within 48 hours, to be rated positive (95/100) if not uninstalled within two weeks" if the user did not manually set any rating (50/100 == neutral rating; (< 50) == negative rating). When uninstalling an item, view "item-ratealot" wil be displayed, asking the user to rate.
Server-side(?): • For every showfloor item there is for a game, the server will create a very low resolution version (202x121 Pixel, called "category view showfloor items") and compress them to further reduce traffic caused by the category view's features. Screenshots 0, 1, 2, 3 and 4 will be compressed into one file ("category-view-showfloor-initial"), with subsequent screnshots being compressed in chunks of four (or less, if there are less left) which will be called "category-view-showfloor-" followed by a number, beginning with 1(screenshots 5, 6, 7, 8 will be compressed into "category-view-showfloor-1", screenshots 9, 10, 11, 12 will be compressed into "category.view-showflor-2"...). Videos will not be compressed to chunks but instead recoded by the server (with a yet to be determined quality) in the process of scaling them down. • "showfloor-whenhasitlastchanged": Whenever a game is updated on the server, the server will check if any screenshot or video ("showfloor items") has changed. If so, it will update the showfloor-whenhasitlastchanged value.
Thoughts on loading: • Screenshots and videos ("showfloor items") will be cached and always displayed from cache first. Whenever a showfloor item is determined to be displayed soon (see below), its game's showfloor-whenhasitlastchanged value from the server will be compared to the locally cached version. If they don't match, all of the game's showfloor items will be deleted from cache and all of the game's showfloor items that are determined to be displayed on the screen soon (see below) will be updated in cache, every finished file will then be updated in the UI as soon as it has finished downloading. • How to determine how many (and which) screenshots of which games should be loaded so the user has a "fluid" and "snappy" experience that feels as if there wasn't any dependence on a server: Whenever a category view is being opened by the user, beautyget should first download screenshots 0, 1, 2 and 3 ("category-view-showfloor-initial") of games 0 to 8 (one after the other in order of appearance in list) to measure the average download speed and determine how many ms it takes to download one "category-view-showfloor-initial" (this value should be kept up to date from that moment on). By using this value and the current scrolling speed (downwards of course, as the user will see the top of the list at the beginning), we can on the fly update the number of additional category-view-showfloor-initial to download (again, one after the other in order of appearance in list) so that ideally the four main screnshots of games that are entering the screen from below as the user is scrolling along the list are already loaded the moment the user scrolls to the game (whether the files are already in cache or not should not be taken into account by the calculation). There should be a buffer (size yet to be defined, what about 6? I really have no idea here) of additional game's category-view-showfloor-initial that should be loaded in advance in case the connection to the server suddenly gets slower. However, in any case not more than 40 upcoming game's category-view-showfloor-initial should be loaded at a time. (Should downloading be stopped completely in case it is being detected that the user is "going crazy" with the kinetic scrolling?)
Sorry, that text is pretty messy and random (and may read and look weird, I often "fusion" the processes of brainstorming and creating "final status content snippet drafts" to be able to communicate my ideas to others and keep the ideas flowing :) ), it is not yet meant to be any documentation or something like that, it's simply "absolutely unfinished". The only reason I'm posting this is that I'm trying to give you the idea of what beauty-get would be, with my question being:
do /you/ think enough people would be interested in using something like that?
I don't really have time to finish the ideas, do some quality control, implement everything, test it, create documentation etc., but the main problem is that currently I don't even consider trying to continue this because I'm in doubt that enough people will use this to be able to build up the needed "ecosystem" for it to actually be useful (possible server-side implementations, screenshots and short videos for most software by their respective creators, some users for the voting feature would be useful :) ).
Part of this is due to the fact that this project has been in the drawer for a pretty long time and seems a bit obsolete to me now. Yet I still think it might be a great appstore-like solution for multimedia and entertainment focused uses, and last but not least I myself would of course really like to actually use this to browse opensource games and other Pandora content. So now I really don't know whether to ultimately cancel or try to continue this project.
Edited by Christoph.Krn, 04 February 2011 - 11:19 PM.
I dont wanna roam all posts...but is there a theme decided already?
AFAIK, Craig was asking for help with that.
@craigix What was the suggestion that drove you to rewrite a large chunk of the appstore? Do you have any thoughts on the tag suggestion?
It is related to the search, tags work anyway if you put them in the description box.
I really like doing this appstore because it reminds me of working on 320*240 systems, working out neat ways to get everything in to the space but not for it to look cluttered.
