My horribly unpolished 2 cents based around the idea of tagging:
http://gadgetoid.com/pandora/store1.jpg
http://gadgetoid.com/pandora/store2.jpg
http://gadgetoid.com/pandora/store1.jpg
http://gadgetoid.com/pandora/store2.jpg
Appstore Look
- Thread starter craigix
- Start date
second exodous
Advanced Member
I never thought of the Pandora not having many games, I guess that would affect how the store is search-able. I hope it will have more games, not just because it's more powerful but because it's more of a generic Linux and easier to port to.
streak
Active Member
Ah, forgot to ask. Will appstore have 2 version of pages [ pandora specific 800x480 ] and [ other ] or only one dynamic resized?
StreaK said:
I've also been wondering if some new elements in HTML5 will obviate the need for a special client frontend.
But, I guess the topic is pre-mature; the appstore definitely needs a web interface no matter what else happens, and it will have to have a definite structure, which Craig et al. are working out now; and HTML5 isn't out yet anyway.
Last edited by a moderator:
emil10001
Active Member
- Joined
- May 19, 2008
- Messages
- 669
gadgetoid said:
As far as I can tell, there are no tags in there. Just categories. My point was that when you break things down into categories, there will likely be certain things that don't fit neatly into just one category. Therefore, you can augment the categorization with tags, where multiple tag can be applied to each app. This allows the tags to get more specific than categories could be, while still allowing there to be categories for presentation purposes as well.
Example:
Title: Quake II
Category: Game
Tags: Game, FPS, Multiplayer
Title: Lerp
Category: Game
Tags: Game, Platformer, Puzzle, Exclusive
Last edited by a moderator:
bzar
A Commando
I'm just throwing this out here. It's probably a dumb idea, but I want to share it anyways 
. The typical way to get around the similar tag problem (sidescroller, side-scroller...) is to show the user tags similar to those he's trying to use (if available). Because there usually are gazillions of tags, it's not really feasible to show the user all the tags to select from. However, some tag types, like those describing genre, actually form a subset of the tags that probably is of a manageable size.
This got me thinking about categorizing the tags into genre tags (shmup, platformer, fps), content tags (multiplayer, campaign, casual), context tags (scifi, zombies) and so on. Now I'm not suggesting having both categories and tags, but rather a way to organize the tags to aid in finding the correct pre-existing ones if there are any. New tags can of course be added like in any other system if needed. The submission system could show the user all the existing genre tags (because there are few), but use the search-as-you-type functionality for context tags (because there are many).
It could also be worth it to consider having the possibility to link tags to each other based on for example similarity (possibly synonymity) or same context (eg. elves and orcs). This way the user could find out tags and get suggestions on search words.
Just putting these here out in the open
EDIT: Oh, and one tag category could be type (game, application, utility...). See the post above.
. The typical way to get around the similar tag problem (sidescroller, side-scroller...) is to show the user tags similar to those he's trying to use (if available). Because there usually are gazillions of tags, it's not really feasible to show the user all the tags to select from. However, some tag types, like those describing genre, actually form a subset of the tags that probably is of a manageable size. This got me thinking about categorizing the tags into genre tags (shmup, platformer, fps), content tags (multiplayer, campaign, casual), context tags (scifi, zombies) and so on. Now I'm not suggesting having both categories and tags, but rather a way to organize the tags to aid in finding the correct pre-existing ones if there are any. New tags can of course be added like in any other system if needed. The submission system could show the user all the existing genre tags (because there are few), but use the search-as-you-type functionality for context tags (because there are many).
It could also be worth it to consider having the possibility to link tags to each other based on for example similarity (possibly synonymity) or same context (eg. elves and orcs). This way the user could find out tags and get suggestions on search words.
Just putting these here out in the open
EDIT: Oh, and one tag category could be type (game, application, utility...). See the post above.
emil10001 said:
Confirmed: Worst horizontal tag cloud ever.
Last edited by a moderator:
laurencevde
Member
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...
Using that'll give us a fully functional app-store with all of the features we could wish with practically no development time...
emil10001
Active Member
- Joined
- May 19, 2008
- Messages
- 669
Laurencevde said:
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.
Last edited by a moderator:
craigix
Mega GP Mania
Laurencevde said:
No it won't. I'm not being nasty saying that. Now I'm going to sound like DaveC:
We have a portable system which is unique and a scene which shapes what we want from an appstore.
That kde apps/maemo site is a joke. It's a total mess. Try browsing that at 800*480. It's unreadable and has one of the worst used/wasted space ratios I've ever seen. Half the screen is taken up by that empty top banner. Nothing a Pandora user wants to know is there. The search function is a tiny, clunky mess.
I already looked at free file archives. Anything we tried to do with them would just look like a hack. They are not designed to run on portable devices and definitely not designed with something like the Pandora scene in mind.
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.
Last edited by a moderator:
craigix
Mega GP Mania
emil10001 said:
+1
Last edited by a moderator:
borgqueenx
Well-Known Member
I dont wanna roam all posts...but is there a theme decided already?
Tensuke
Active Member
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.craigix said:
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.!
Last edited by a moderator:
Awakening
Active Member
Tensuke said:
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.
Last edited by a moderator:
Christoph.Krn
Advanced Member
cobaltage said:
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:(This mockup is work in progress.)
beauty-get mockup by Christoph.Krn, on Flickr
Work in progress comments and ideas on this work in progress mockup:
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?)
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.
Last edited by a moderator:
craigix
Mega GP Mania
emil10001 said:
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.
Last edited by a moderator:
