Pandora Standards

Should the Pandora have a set of agreed standards ?

  • Yes

    Votes: 76 85.4%
  • No

    Votes: 5 5.6%
  • Not Bothered

    Votes: 8 9.0%

  • Total voters
    89

Loon

Member
Joined
Jul 25, 2006
Messages
357
Hardly the most glamorous subject, but what I thought would be highly useful for the Pandora developers and community would be to get together a set of agreed standards. Things such as how to exit an application, how to change controls for left and right handed users, where to get the most up to date firmware and application files etc.

Here is what I think we need to decide :

1) An agreed method on how to propose standards - My suggestion is that proposed standards are posted on this forum with the post title being 'Standard Proposal - Brief description of proposed standard' such as 'Standard Proposal - Exit Application'

2) A method for debating then deciding on a particular standard - How about debate and counter suggestions on the standard proposal thread then a poll in a new thread based upon the proposal thread, this could be posted as 'Standard Poll - Exit Application'. I'd also be fine with an 'expert committee' having the final say based on the poll & debate.

3) A place to record agreed standards - The Wiki would seem a logical place for this.

It is appreciated that it will be up to individual developers to follow the standards only if they want to, my guess is most would choose to do so if we set up a logical and sensible set of standards. It is also understood that ported apps would not follow the standards without extra work.

Note : This is more or less a repeat of a post made in Oct 08 which seemed to get a fairly positive response then understandably slide into obscurity along with the delivery date for the Pandora.

Please don't make this thread a place to propose standards, if you want to do that then why not do it as per point 1 above? Lets try and keep this discussion about whether we need standards and if so what is the best way to discuss / implement them.
 
Last edited by a moderator:
i propose a standar: SOURCE CODE 7Z-ed inside the pnd file. If it has the source code, i want it, and not having to search for it for about an hour, just to find out the link is 404, or that the autor doesn't want to give it.
 
I've voted yes, but I can see both sides.

I'd like developers to have the freedom to create and come up with new ideas and solve problems in their own special ways. Forcing them to do things a set way might stifle this or even put them off from doing things on the Pandora in the first place (which none of us wants).

However, from a users perspective, it's totally frustrating to have to learn an interface when these things can be standardized. As long as the standard includes things like the ability to customise and skin then that may work.
The benefit for devs of standards though is that they don't have to sweat the small stuff so much and can concentrate on the complicated side of things.
 
I think for now, we could just do with identifying issues and having meaningful threads/polls about them.
At the moment we just get someone who doesn't like something posting "Is it rubbish? Yeah/Yes/Yup" :p

But yeah a formal system would be nice, perhaps modelled after Python's PEP.

laharl said:
i propose a standar: SOURCE CODE 7Z-ed inside the pnd file. If it has the source code, i want it, and not having to search for it for about an hour, just to find out the link is 404, or that the autor doesn't want to give it.
I agree that the source code should always be easily available, but I don't think putting it inside the PND is a good idea.
It's a waste of space for the majority of users.
It also doesn't actually make it easy to access, as the PND requires mounting to get at its contents.
(And 7z makes it harder again, since it requires special software to open)

An optional source code download on the appstore would be the best way to handle this.
(Look we're having standards debates already)
 
Last edited by a moderator:
Everyone is free to make Pandora apps their own way. Of course it is convenient for us to rely on certain standards so we don't have to figure out how to use a new app each time. And i think most of the devs would like to implement standards in their software to improve ease of use, but as it is now, we don't have any, but there are quite a few things that needed to be standardized (but never really were) on the GP2X/Wiz that are already predefined on the Pandora, like where to store the Roms (appdata directory) or which key combination to press in an emulator to get to the menu (Pandora key)

So let's be concrete: What do we actually need standards for?
The only recommendation i can think of right now is to use the X button as the "primary button" in games and emulators, but apart from that, i don't know what to add.
 
laharl said:
i propose a standar: SOURCE CODE 7Z-ed inside the pnd file. If it has the source code, i want it, and not having to search for it for about an hour, just to find out the link is 404, or that the autor doesn't want to give it.

<Facepalm>Laharl, please read the last paragraph of the initial post, you naughty demon prince you.</Facepalm>

@Mqark : Nobody would force the Devs to use standards, the idea would be to give Devs the opportunity to use them if they so desired and to have these standards, when agreed, stored in an easily accessible place.

@Fishbong : My theory is that we need standards to improve the user experience of the vast majority of Pandora users, especially when the device starts to displace the IPAD as the required item of geek chic ;)
 
Last edited by a moderator:
Yes purely from an end user point of view a set of control standards is what should be suggested for devs to follow. Of course everyone is free to write code as they see fit, but if we all follow the same control map standard at the very least it means that more apps/games/homebrew turn into something that you can pick and play as opposed to having to figure out every single button.
 
laharl said:
i propose a standar: SOURCE CODE 7Z-ed inside the pnd file. If it has the source code, i want it, and not having to search for it for about an hour, just to find out the link is 404, or that the autor doesn't want to give it.
Unfortunately most people don't want to download the source code for every single program that they download. It takes up too much room on your SD cards, plus not everybody is a developer.

Would be nice to be able to right click a PND file though and have the web site address for the source code opened in a web browser or copied to your clip board :)

Tripmonkey_uk said:
I like j6cubic's idea personally. Extend the PND system, so that right clicking the PND from within your file manager offers you some basic options..

1) Edit the programs main config file
2) Open the programs home page
3) Open web site address for the source code.
4) Profit??
 
Last edited by a moderator:
I think that there should be only a few key parts to the set of standards-

OS Interaction- The PND/PXML standards are a great start, but they need to be further defined. Also, where the program saves/loads data should be standardized further (though not forced). Developers should be discouraged from creating too many small files (this can cause issues with FAT/FAT32 file systems). Perhaps a few standard libraries or file formats to make it easier for them to save, but they will not be FORCED to use them. A library should be released ASAP which will allow programs to detect when the system's lid is closed, when it is about to be put into sleep mode or when the CPU clockspeed is modified. Developers should then be encouraged to make their programs function correctly in these different conditions (ie: going into sleep mode- save all data, pause application, stop all processing). Also, developers must all understand exactly what will hinder the operation of the Pandora AND/OR other programs so that their code will not negatively effect the user's experience/data/Pandora.

Interface- Developers should be encouraged to follow one of two or three sets of standard buttons (eg: one set- A = back/cancel, B = forward/OK etc.) AND/OR include a means of changing the key bindings. Some of the buttons/button combinations (eg: the 'Pandora' button) should not be used if the OS already uses them (you want to be able to minimize programs without worrying if the dev set that button to "Unpause").

Naming Conventions- Any files the user directly interacts with, or upper-level folders, relevant to the program should be labeled clearly, preferably with the version number in the name of the PND. But these standards should be allowed to evolve naturally and then defined when the community is satisfied- once more, not to force any developer, but to make it easier for them to get the program out into the community.

These are (of course) just an end user's idea of what is necessary- I'm sure that developers would want to add a lot to this list - but the key point is that if we do not define such standards, then end-users will suffer and the community may develop it's own poor set of standards (which may have serious issues or just generally be inefficient).

But Mr. Loon is definitely right in saying that very few, if any, of these should be enforced. I do not want to "box-in" anybody, I just want to ensure we have some consistency. It benefits us all to follow these- developers will have simple, well-documented options available to them and the end-users will never have to learn five or six different standards.
 
Here's a thought - why not enforce a standards "authority" at the app-store? And make it so the Pandora can only run apps that have been approved? That way, everyone gets the standards enforced!

And if a dev pisses you off, you can shift the standards and rules so that his app is no longer able to be downloaded/run!


... Now why has nobody thought of this before? ;-)

D.
 
Dunny said:
Here's a thought - why not enforce a standards "authority" at the app-store? And make it so the Pandora can only run apps that have been approved? That way, everyone gets the standards enforced!

And if a dev pisses you off, you can shift the standards and rules so that his app is no longer able to be downloaded/run!
We're already pushing it with the name, but if we did that Apple would totally sue. It would clearly be a copy. :p
 
Last edited by a moderator:
Dunny said:
Here's a thought - why not enforce a standards "authority" at the app-store? And make it so the Pandora can only run apps that have been approved? That way, everyone gets the standards enforced!

And if a dev pisses you off, you can shift the standards and rules so that his app is no longer able to be downloaded/run!


... Now why has nobody thought of this before? ;-)

D.

Shit, we'd better get rid of the SD slots & USB ports as well and lock down the OS so 'nobody' can bypass these draconian standards.... :p
 
Last edited by a moderator:
Nope. No point to it in my experience. Anyone who doesn't agree with the standard will ignore it or only comply with the portions of it that they find agreeable or convenient. And even those who agree with it will end up hacking up a half finished solution intending to comply with the standard after finishing the more important or interesting portions of their projects then forget about it leaving it non-compliant for who knows how long.

At any rate I certainly wouldn't comply with any standard I didn't agree with. And probably wouldn't bother to read them to begin with. In my experience standards are usually largely ignored or only partially observed. And partially complied with standards just introduce confusion.
 
Spectralist said:
Nope. No point to it in my experience. Anyone who doesn't agree with the standard will ignore it or only comply with the portions of it that they find agreeable or convenient. And even those who agree with it will end up hacking up a half finished solution intending to comply with the standard after finishing the more important or interesting portions of their projects then forget about it leaving it non-compliant for who knows how long.

At any rate I certainly wouldn't comply with any standard I didn't agree with. And probably wouldn't bother to read them to begin with. In my experience standards are usually largely ignored or only partially observed. And partially complied with standards just introduce confusion.
I don't think you understand what a standards convention is, or you've had some very bizarre experiences.
It's not like they'd be enforced. It is Open Pandora because you're expected to be able to do what you want. Standards are meant to be a guideline. Imagine you're writing your app and you think "what kind of file picker should I use?" You can either think you're being clever and come up with a solution that works, or look at the standard and go "hey, many people are using this method, and it seems to work pretty well, and is a suitable fit for my context as well."
Or you can say "this is the recommended method, but it doesn't fit my context. I'll follow the conventions that do fit, and invent stuff to better suit my application specifics as needed"
Or you can say "I'm going to go completely against the convention and confuse people even though the convention makes sense." :p
So we can either not bother, let everyone come up with their own conventions for everything, have utter chaos for the users; or work together to find some reasonable best practices that developers can use when it actually makes sense.
 
Last edited by a moderator:
I think that's an awesome idea! I don't think it would push developers into walls at all. I had an idea for a unified ratings system, but I got to see that get shot down in flames. I'm hoping that doesn't happen here...
But why not to either? Unified systems make things easier for all. This way, we have something to go by. You most certainly won't be forced into using it if you don't want to, it'll just be more of a suggestion.
 
WizardStan said:
It's not like they'd be enforced.

An unenforced standard is just so much hot air. The portions of the standard most people will comply with will be the things every one agrees on anyway and they will all be implicit and need not be written anywhere. Not that it does any harm I suppose. But the portions people have trouble agreeing on will have those who don't like the final decision ignore the standard. It makes the whole thing seem like a waste of time.

For example lets say 100% of people support the 'A' button being confirm. 75% Support the 'B' button to be cancel with the remainder split between 'X' and 'Y'. The standard would end up saying that 'A' is confirm and 'B' is cancel. But most of the devs who don't like 'B' for cancel still probably wont use it. So what does the standard accomplish? I guess those with no opinion on the matter might look up the standard and follow it, as you say. But I can't imagine a lot of people would have no real opinion on any design aspect that is large or visible enough to be discussed in a standard.
 
Last edited by a moderator:
Spectralist said:
For example lets say 100% of people support the 'A' button being confirm. 75% Support the 'B' button to be cancel with the remainder split between 'X' and 'Y'. The standard would end up saying that 'A' is confirm and 'B' is cancel. But most of the devs who don't like 'B' for cancel still probably wont use it. So what does the standard accomplish? I guess those with no opinion on the matter might look up the standard and follow it, as you say. But I can't imagine a lot of people would have no real opinion on any design aspect that is large or visible enough to be discussed in a standard.
That's fine if they don't use it. Such a standard wouldn't be for those that think they know better (whether they do or not is not part of this discussion), it'd be for those that don't know any better. You're designing your application and haven't yet decided on whether B is cancel or X is cancel. You look at the standard, it says B, you see no reason not to go with B so you go with B.
The 25% that choose to use X or Y do so at their own risk, risk of user backlash at choosing a non-obvious button. Unless it makes sense in the particular context that X should be cancel.
Consider the question "do we single click to choose a file, or must we double click?" The standard says a single click highlights, and double click actually selects. I have become very frustrated by applications which use "single click" as their method, frequently opening the wrong file because I'll double click on a directory which single clicks the directory to open it and then single clicks the file that was immediately under the cursor.
I could spend all day coming up with examples of where a common standard exists, and often for a very good reason, which some group chose not to follow and found it detrimental.
If you write these down, at the very least when a developer does something silly like putting the scroll bar on the left or something, you can point them to this written down standard and explain why it's a good idea that people use the same convention.
 
Last edited by a moderator:
Voted yes because I think we should atleast get basic installation instructions as standard on things downloaded from the appstore/archive. All I want to know is where do I put stuff, what do I call the bios and where do I put them so us noobs could actually enjoy installing stuff instead of it being a ball ache and having to ask everytime for answers is a pain. It should already be compulsory to provide atleast basic documentation but it isn't so if you are a dev PLEASE tell us how to install your apps/games and tell us what files we'll need and where to put them, thanks :)
 
We're never going to get a concensus on which buttons do what. But we could very well have an abstraction layer, a defined set of App button variables like:

APP_BUTTON_BACK
APP_BUTTON_CANCEL
APP_BUTTON_PLAY...

and a screen to set bindings so users can decide what button to assign. Then the standard just recommends using those bindings.

I believe standards are definitely worth it, it gives devs a consistant target to aim at and users a consistant experience. Obviously there would be nothing to stop people doing what they want, but if there were some simple, good defined standards I think "market forces" would prevail somewhat to keep things in line.

e.g. Given the choice between 2 pnds, one standards compliant and one not, a lot of people would choose the compliant one. Also people I think would be likely to rate non-compliant apps down and comment on them that they would be better with the standards. If the standards are sensible then I think you reach a state where, if you want people to like your game, app or port, you follow some of the recommendations.
 
Back
Top