Overal Interface Issues

[san]

Hi fellow future pandora users,

I would like to suggest some overall interface issues I experienced with the gp2x which could be avoided with the pandora. I think there should be some constructive discussion on how we want to interact with the pandora.

Introduction
The general interface of the gp2x was made a lot simpler for new users with the introduction of GMenu2x. Once placed on the SD card, with the autorun file and the correct application links, it was a lot easier to run your favorite applications from a GUI with decent menu, graphics and icons.
There are a lot of very good emulators already out there for the gp2x. They do what they do best... emulate some old piece of hardware so we can (re)play some (retro) games. In some cases they had a very nice GUI which allowed us to do all kinds of nifty stuff like overclocking and changing render modes. This is off course handy when we try to get most out of our system.
When I show the gp2x to friends, people at the university or some non-technical people they are amazed about the capabilities of the system. But the interface makes it hard for them to directly work on it like they would on the original consoles/systems.

Suggestions
There are imho a few issues that make this unnecessary complicated for these new users. By addressing and solving these we could perhaps even ease the experience for the more technical users.

1 - Main Menu
Please include a menu like the GMenu2x by default. Nice icons, easy selection of applications and perhaps even some embedded applications (media player / image viewer) in this menu. This allows the user to do the basic stuff without learning additional applications. There are quite a few suggestions for the interface already posted on this forum and some do look promising.
The experience would even more improve if the menu would automatically recognizes the applications on the SD card and add them to the correct menu-tab (or what kind of sub-menu structure is chosen). Preferably all applications should have their own icon packaged with the downloads. Unfortunately this is not all up by the devs but I think if the collection of software available at the start already has this worked out in a nice way that most third party applications will follow.

2 - Rom Selection
The second thing I would really advice the devs is to make rom-browsing available in the main menu. It would be very convenient to select and load the rom (i.e. based on extension) with the preferred emulator. This way users do not need to learn 10 different interfaces for all the emulators if they just want to play a game. If the games would also have some cover-art, -picture, -case you could browse though them as if you are browsing though a physical collection (apple coverflow anyone?).

3 - Emulators Menus
Imho emulators should have little to no menu. Some settings require an menu but I'd recommend that it is kept to a minimum. The menus should be mapped in all cases to the same key so the user knows what button to press for all the emulators at once.
Save states should behave as much as possible as the real systems. Additional save slots for states could be usefull in some cases and on some systems but I recommend that all the emulators should behave like the real system. For instance the GBA emulator, which is a very nice application on the gp2x, has additional save slots. When I play advanced wars the game itself saves it state. Using these states would enhance the experience for new users and remove the need of an 'advanced' menu for basic functionality.
If on some systems there is no save option availible, for instance the mega drive/genesis, than I would recommend that all the emulators use the same keys for saving and loading.

I'm not exactly sure how this, technically, could be achieved. I think that some kind of application framework could help developers to tailor their emulator to fit the pandora perfectly.

Perhaps these things are obvious to you or you completely disagree. I'm only bringing this up for discussion. Up till now I haven't coded for the gp2x/pandora. I'm quite new to the scene and currently lack the time and knowledge to do so. I intend to do some experiments once I'm done with my thesis and a nice development toolchain is available for starting devs like myself.

Let's hear what you think.

Cheers,
San

 

[Chip]

Main Menu: I think it goes without saying that an easy-to-navigate menu system is pretty much essential. There is no way Craig would ship the finished product with nothing but a command line interface. Chad has already whipped up some very nice concept art for a potential interface. Whether the actual UI is based on his ideas or something else entirely (there has been talk of a direct port of GMenu2X), there will certainly be a simple menu system of some sort.

ROM Selection: I agree that a universal emulator frontend would be great, but I don't know that it should be mandatory or built into the GUI. We don't want to hold up more important software by focusing on something that is basically a luxury. If somebody does want to make a universal frontend with screencap / box art support and a slick interface like MAMEWAH or GameEX then you can always install it later. I know I will

Emu Menus: This is a bit sticky. Yes, it would be nice if everybody used the same menu shortcut key (perhaps the one labeled "MENU"?) and layout, but you can't force a standard. Everybody has their own preferences, and it ts the prerogative of the programmer to set up his/her program however the hell he/she wants. If somebody is simply porting an existing emu from another system, it's menus and save options will most likely depend on the original version's. I can't see somebody going out of their way to remove save options just to follow some artificial standard.

 

[fusion_power]

The second thing I would really advice the devs is to make rom-browsing available in the main menu. It would be very convenient to select and load the rom (i.e. based on extension) with the preferred emulator.

Many roms are zipped so this could be a problem. And NO, I don't want to unzip all my roms and waste SD Space.

Standards for a Menu are important. not a must-standard but something that is ALSO included. Many people forget, that a program should be able to have many variable elements like configuration etc. (look at your PC where it's easy to change the appearence of Windows/Linux etc...) And one of the config onto the Pandora programs could be always a standard layout for button usage or Elements on the screen etc. Above this, every program can have it's own unique controll and Interface sheme.

 

[Gilrad]

Maybe have folder-specific default application launch settings.

Like, in the folder SNES, have all SMC, FIG, and ZIP files launch the emulator. And different respective settings for NES, GBA, ect.

 

[Nilsiboy]

I don't know about the whole ROM launching thing... Sure, it would be nice, and as Chip said, maybe someone is going to create something like that, and many people would use it.
BUT: Shipping an emulator frontend with the system would make the Pandora look like just an emulation machine, which it isn't, as you all should know. It's much more than that.
Also, it could get the devs in a LOT of legal troubles.

As for the Menu, I trust the Dev team 100% that it will be great

 

[Pleng]

I don't know about the whole ROM launching thing... Sure, it would be nice, and as Chip said, maybe someone is going to create something like that, and many people would use it.
BUT: Shipping an emulator frontend with the system would make the Pandora look like just an emulation machine, which it isn't, as you all should know. It's much more than that.
Also, it could get the devs in a LOT of legal troubles.

As for the Menu, I trust the Dev team 100% that it will be great

Well it wouldn't be an emulation front end per-say. It could also be used to browse media files and launch them with preferred media player, or open text files with preferred notepad. It's essentially a file explorer

The way I could see it workingis this:

all filetypes are associated with an app, and launch wit that app when selected. HOWVER, each folder also has an option for zips. The first time a zip file is launced from any particular directory a pop up is displays saying something like "The file selected is an archive. When opening an archive from this folder, which application would you like to launch". When the user makes a selection a small file is created called "folder settings" which stors the information for latter reference.

If the user changes his mind about how he wants zip files to be opened he can simply delete the 'folder settings' file.

Of course this concept could be exanded by storing other information in 'folder settings' such as a different background picture for each folder, etc... and clicking on th file could launch a folder prefs editor.

 

[Nilsiboy]

Oh, okay, I didn't realize it was meant that way... still, your approach sounds a bit clumsy IMHO.
Why not take one more tap/button press to open any program you want to use first and then have that program display a nice list of all the files it can handle?
Sounds like much less trouble than editing a settings file for every folder you put stuff in...

 

[Kramy]

This sounds like a case for a .settings file.

It could have things like...

CODE
foldericon: "blah.png"
showonly-file: "*.bin, *.rom"
hidechildfolders: "data, bin"
autolaunch: "blahfile.exe"


Note on autolaunch: Prompts you to open the folder or launch the application. (Simple dialog) Default is opening the folder, so if you wanted to play the game, just tap left and press a key. Or something like that...

Oh, and there'd have to be an override button somewhere in the file explorer, so you could 'show hidden files' easily.

Aside from that...a .settings file seems like a good way to go? Coders could bundle them with the download for their apps, so it's transparent to the user.

 

[Pleng]

Oh, okay, I didn't realize it was meant that way... still, your approach sounds a bit clumsy IMHO.
Why not take one more tap/button press to open any program you want to use first and then have that program display a nice list of all the files it can handle?
Sounds like much less trouble than editing a settings file for every folder you put stuff in...

But you wouldn't be editing the file by hand. Whilst you could, it would work seamlessly. in the same way that you are presented with a list of available apps when you click an unknown file type in windows, a similar system would happen on the Pandora.

The folder.options file would be created automatically when you launch a zip file from within a folder.

 

[Arialia]

Or rename rom archive *.zip by for example *.znes or *.nes.zip

and *.znes / *.nes.zip associate with emulator of nes

 

[gaterooze]

Disagree that emus shouldn't have menus. Why shouldn't they if the dev wants one? You can have shortcut keys as well, but having no menu at all really cuts down what you can do. I personally like to boot up a "system" and play a few games on the same system, and fiddle around with sound, BIOS and graphic settings, etc , so not everyone wants frontend rombrowsing only.

 

[Shiny]

Disagree that emus shouldn't have menus. Why shouldn't they if the dev wants one? You can have shortcut keys as well, but having no menu at all really cuts down what you can do. I personally like to boot up a "system" and play a few games on the same system, and fiddle around with sound, BIOS and graphic settings, etc , so not everyone wants frontend rombrowsing only.

Why not have both? I've never used Linux before, but I'm assuming that it has support for command line arguments so implementing this extra feature would be trivial.

 

[gaterooze]

Why not have both?

Exactly what I mean.

 

[Arialia]

Disagree that emus shouldn't have menus. Why shouldn't they if the dev wants one? You can have shortcut keys as well, but having no menu at all really cuts down what you can do. I personally like to boot up a "system" and play a few games on the same system, and fiddle around with sound, BIOS and graphic settings, etc , so not everyone wants frontend rombrowsing only.

Why not have both? I've never used Linux before, but I'm assuming that it has support for command line arguments so implementing this extra feature would be trivial.


i agree both is better
file association and menu in the emu for settings, save state, load rom , also shorcuts can be said by menu

sorry but for me the best thing of microsoft has made is standardization of IMHO ( file menu, edit menu, help menu and the shocuts for cut, copy , paste , and save) in past ...

So i dislike new tendencies of no menus ( in Office 2007 , and new Internet Explorer :angry: beurk ) very not intuitive for me ( i lost ten minutes last month to understand how print in Office 2007 , the first time i use Word 2 it take me 2 seconds to see icon of printer and printing .... and 5 seconds to see option print in the file menu )

So if we use shorcuts for standard actions they must be the same as Old Windows, Linux

Ctrl-O : Open
Ctrl-S : Save
Ctrl-X : Cut
Ctrl-C : Copy
Ctrl-V : Paste
.......

And i dislike the start button of XP : too many things inside

i prefer the look of ubuntu : a menu for application, menu for folders, menu for system tools and another for quit/booting

 

[Kramy]

Big informative post.

I agree with Arialia; stick with the standards...and not just unix/linux standards, but what common users find standard.

Microsoft turned lots of Vista upside down. I find Office's interface wonky now too. I actually find myself using OpenOffice instead, because of the more friendly interface. (how is this possible? :huh: )

Start menu clutter is a pain; interface clutter is a pain. Simpler interfaces(perhaps with more "panels") are preferred to complex ones.

 

[Svartalf]

Emu Menus: This is a bit sticky. Yes, it would be nice if everybody used the same menu shortcut key (perhaps the one labeled "MENU"?) and layout, but you can't force a standard. Everybody has their own preferences, and it ts the prerogative of the programmer to set up his/her program however the hell he/she wants. If somebody is simply porting an existing emu from another system, it's menus and save options will most likely depend on the original version's. I can't see somebody going out of their way to remove save options just to follow some artificial standard.



Actually, you might want to make an artificial standard for the menuing- make it consistent to access, at least.

Underneath it may be all-bets-are off, but we should have a consistent "hacker" interface access method and a consistent save place, etc. Chaos isn't going to go over well- the most jarring and obnoxious apps on the Nokia N8x0 OS2007/OS2008 setups are the ones that don't work properly with Maemo and require something like a hardware keyboard to even USE the thing (DOSBox, for example...). In the case of the N810 and the Pandora, it's less of a problem, but it's still a good example because it's less useful even with the N810 because you HAVE to slide the keyboard down to use the app.

What makes Maemo a "winner" is that it's largely consistent throughout. If we can make things a little more consistent, it would be better, IMNSHO.