The Pandora is primarily a gaming console. Not all gamers [at least un the USA] know or even have herd of emulation,ROMS, etc.,. The Pandora is 'user friendly' for tech savoy people like yourself.
The problem is people like you cannot see past their ball sacks to see the other half ; the not so tech savoy.
We all agree that the Pandora has to become more userfriendly, that's for sure, but there are various ways of doing this.
Right now, various devs spent months just thinking about the specs and defining them, which opens the path to MAKE the Pandora more userfriendly.
The approach I (and multiple devs took) are:
1. Think about what would be great and nice. We thought a simple system similar to modern phones (like iPhone) where you can simply click on an app to install it or get a description, screenshot, etc. and work yourself through different categories would be ideal. This is our goal. (DONE)
2. Define all the needed specs to reach that goal - but in a way to keep them flexible. If in the near future more options and features are needed, the old stuff needs to stay compatible. This is what we did. (DONE)
3. Start coding the BACKEND. The backend it the techy part: It does ALL the communication between the repo and the software on the Pandora. It is there to handle all the basic functions, this has nothing to do with the user. (MOSTLY DONE)
4. Then work on the FRONTEND. The frontend is basically what the END USER will use. It's the UI. It will use the functions of the backend to get all the needed information and handle the functions for the user in a user friendly way (i.e. like on the iPhone, the Appstore program you rung). (BASIC WORK HAS STARTED, BUT IT'S NOT PRETTY YET)
The advantages of doing it like this are the following:
* Devs can easily use the backend and code a new frontend (GUI). So it's possible to quickly code various tools to install software, with different features and looks. As long as it uses the backend or follows the specs, it will work without any problems.
* Multiple sources are easily possible (like with Ubuntu). If someone wants to offer special packages, he can create a website following the defined specs and everyone on the Pandora could use their favourite frontend to install or update the stuff from there as well
* As defined specs are flexible, the whole system is future proof. Adding new stuff without breaking old things is possible.
* Everything is documented. Any dev can work on it. If some devs leave the scene, others can continue. As long as their stuff follows the specs, it will just work.
The disadvantages of doing it like this are:
* It takes a while. You need to carefully think about what you're doing and write that stuff down, so others can collaborate or continue to work on stuff someone left.
* Specs can be a bit complicated. The more features you include, the more complicated it becomes.
Right now, the status we are in is:
Steps 1 - 3 are pretty much done. The backend is getting some tweaks here and there, but it works.
Step 4 is currently being done. PNDStore exists which can automatically install and update programs directly on a Pandora which is connected to the net without any knowledge.
All you need to do is select the game you want to install, click on "INSTALL" and that's it.
It's not yet pretty, but the basic interface is working without any issues.
So the only one missing in this whole thing is a nice looking UI.
The one we have is fully functional and it couldn't be any simpler (Select game, INSTALL or REMOVE. Or choose to UPDATE all apps. That's it. Simple as that).
Other things to make the Pandora more user friendly are:
* Create a nice Tutorial which should be on the main website - as well as an optional quick tutorial on the unit itself (both being worked on).
* Solve the issue with datafiles... some games or emulators need datafiles. Those can't be delivered WITH the games, they need to be installed by the user. How to make this easier is something we currently are discussing.
So the most important step for us was the defining of the specs. If they are good, everything coded around them is compatible and just works.
This is being used in Linux desktops, for example:
If you are a Linux user, you might know there are different GUIs: KDE, Gnome, XFCE, etc.
You can select whatever GUI you want on your PC, you will always have all your apps and programs in the startmenu.
This is because there are standard specs (FreeDesktop).
If one of those GUIs did implement their own specs, then either this GUI wouldn't show all apps or the other GUIs wouldn't show all apps.
Whatever would happen, the user wouldn't just understand where his apps have gone. They wouldn't appear in the menu.
Now Craig chooses his own way. He plans on redoing it completely new.
This is not a bad thing, if he comes up with something that works way better then what we have here, I'm sure no one would mind using it.
Time will tell what the users want and what will be more userfriendly.
He plans to keep it as simple as possible, also in the backend (no complex specs like we have).
This has the advantage that his code itself will be simpler and can be written faster.
However, it may lack features that may prove useful sometime in the future. But as we don't know if we ever need these features, this might be fine as well.
I think both ways are good - let's see what will work out for the users.
If Craig wants to try to improve it by doing his own GUI, then sure, why not? If it's better, great!
Anything that anyone does helps the other.
Craig mentioned some things regarding user friendlyness on this thread (i.e. standard rom paths, PNDs work in root folder as well) which we picked up and have either included them or are discussing about how to properly include them.