Design Android UI

[SergioLuis]

Developers: @ugedo @jhvargas3112 Reviewers: @mikelcaz @SergioLuis

---

Design the Android User Interface.

This means: design it, do NOT code it. The functionality the UI must cover is:

• Load a game from the system's file manager.
  • Take a look at how you can upload files using Google Drive.
• ~Quick load a recent game.~ Load a saved game.
• Play the game
  • CHIP-8 uses 16 keys, from 0 to 9 and from A to F.
  • CHIP-8 uses a 64x32 monochrome screen. Be sure to maintain the aspect ratio in the game.
• Quick save a game.
• Screenshot the game's screen and share it (using the Android API. If you need examples, take a look at how you can share a tweet on its official Android application).

You can upload the mockups to a top-level directory in the repository. We'll use this issue to discuss them.

[SergioLuis]

@jhvargas3112 @ugedo You can start with this task right now.

[jhvargas3112]

Apart from knowing the emulator's basic functionalities an the nice to have functionalities, at the moment i have the doubt about the roms's administration, which i consider like basic functionality. WelI, i propose that when the emulator starts, it searchs all the roms located on the system and shows them on a list element. Then, the user will can do the typical actions (delete, move, start a game ...).

[jhvargas3112]

On the other hand, Mikel propose to create 2 prototypes. One for large screens and other for small screens. On this way, on large screens we will have to use a board to show games's roms and on small screens we will have to use items lists.

[SergioLuis]

Some minor points:

• First: we agreed on using english as the primary language for the repository. We can discuss that point once again, but until then, please, use english. I think the effort (which I'm doing, too) will be rewarded sooner or later, one way or another.
• Second: if Mikel has any suggestions, he can use this thread himself, as it's purpose is to have a public forum to shape up the user interface.
• Third: we are discussing over thin air, as I don't see any mockups.

Having said that, this is my advice about the part of the interface you are facing trouble with: don't try to reinvent the wheel. Plenty of emulators have already dealt with these issues. I suggest both of you to take a look at their solutions. Install them on your phone and play with them for a while. Find the points where they excell and think about where they do fall short.

• My Boy! - GBA Emulator
• Visual Boy Advance GBA Emulator Free
• John GBA Lite - GBA emulator
• GBA+ Pro Emulator (easyROM)
• PPSSPP - PSP emulator

I'm particularly interested in how the John GBA Lite emulator handles the user library. Each game has a related screenshot. I think that each screenshot was taken while the user was interacting with the game. This way, we could almost guarantee that the screen has a relevant image at the moment of taking the screenshot. Bonus point: this solution would work great with different sized screens. We can make the game's thumbnail as large as necessary, and we can have a flexible number of rows and columns on the grid.

I also really like how the My Boy! - GBA emulator application handles quick loading. Each saving file also has a screenshot, alongside a name, and the exact date it was created at. This way, the user can quickly identify the save state they're interested in, and, just like in the previous example, this can be easily adapted to a wide variety of screen sizes and aspect ratios.

[jhvargas3112]

Yes, i like that each game has a related screenshot. The idea of the roms board or list, should be inspired by the SuperRetro16 game emulator. Well, we can aggregate the game screenshots both for the roms list and for the saved games. Obviously each saved game should have a date and an hour.

Mockups comming soon...

[mikelcaz]

@SergioLuis May you clarify what is "quick load" and "a recent game"? Thanks.

PD: Oh, sorry. Google Drive?

[SergioLuis]

@mikelcaz done. Changed quick load for load a saved game. I talked about Google Drive to point out that Android already has a standard user interface to select files from the file system. We are not implementing a "file manager", so I'd like to clarify some points:

• The application does NOT look for ROMs in the system. The user does.
  • We can think about doing this later on, but I don't want to traverse the entire FS in order to find two or three ROMs at most.
  • Implementing this can get tricky really soon. We could only rely on the file extension to identify ROMs, and we could hit some walls, as runtime permissions (starting on Android 6.0), while traversing the FS.
• The ROMs can be arranged in a grid. Each ROM is represented by a screenshot with a title, as proposed before.
  • The grid is responsive by design, and there are grids in the Android's UI framework that provide a lot of functionality to handle the ROMs, like rearranging items or deleting them.
    • Allowing to rearrange ROMs can save us from implementing things such as "favorites". The user could put the ones they play or like the most at the beginning of the grid.
  • In the future we could provide both a grid or a list, depending on the user preferences.
• The first ROM in the grid should be the first one the user added.

So, we would have a grid with games and a grid with saved games. Name proposal: Game library and Saved games.

[mikelcaz]

Adding:

• Usually, players get confused between save and load UI, being too similar. I think they suffer something similar between the game library and saved games UI. Both sources of misunderstandings should be avoided regardless the final form of the UI.
• Beware color coding. Users may be color blind.
• What is prioritary, loading a saved game or starting a new game? If it is left to users habits (instead of taking our choice), the last used should be prioritary.
• Please don't use dark colors if there are not part of some thematic feeling (like an arcade machine skin or something like that).

[SergioLuis]

@mikelcaz Do you want to actively work on this task along with @jhvargas3112 and @ugedo?

For the color scheme I had something ATARI-like in mind: brown, black, grey, red... and a rainbow ribbon somewhere.

[mikelcaz]

PD: I should clarify a little bit what I am thinking with the "what is prioritary" part.

The kind of games you may write in Chip-8 usually are of one single genre. Hardcore games. Of those some users may prefer playing without saving a single time, or start all over again.

So continue may not be appropiated as the "always first" option.

[mikelcaz]

After talking yesterday, I propose the next behavior:

• Every time the player uses the saved games UI or saves a game (explicitly or *quitting the application), that UI is set as prioritary.
• Every time the player uses (or returns to) the game library UI, it's set as prioritary.

If the player saved a game (launched from the game library UI) and quited the game (but no the application), the game library UI should be shown first for predictability. Making the player change to the saved games won't be as cumbersome as the opposite scenario, too.

But if players quit the whole application (they are in a hurry or want to stop), the saved games UI offers them the chance to continue where they left off.

The good part is: in case a player wants to stop but returns to the menu instead, the situation is a blip. One user indication just the first time, and everything goes back to normal the next times.

*(Maybe this could be disabled through options? But I consider it a nice feature to have).

---

But.

We should specify what is the sorting of the saved games UI, which I suppose will end being a grid too (there is a correspondence with the sorting of the game library UI?). So my proposal is secondary to this, and should be considered after deciding this, no sooner.

[mikelcaz]

About that last point:

Saved games. How many games of a single "title" can be saved? Just one, or several ones? Cause if you have 3 titles in your library (A, B, C), the grid could be like: [A, B, C] and the saved games UI could be like [] (empty).

Then you start playing. You like A and C, but not B. With the time, the saved games could be like [A1, A2, A3, A4, C1, C2, C3]. A little bit chaotic, if you ask.

We should consider this stuff carefully, and be sure that cannot lead to confusion (saved games UI is not photo gallery UI, and saving vs. loading should be clearly distinguished without "color coding" them or relaying on a text label).

[jhvargas3112]

@mikelcaz the case you shown is true and it's probably that generate a litle bit confusion. So, i propropose 2 alternatives:

1. Saved games are sorted by title game and date of saving.

2. Saved games administration could be handle on two grids: the first contains a grid of titles and the second grid contains the saved games for each title, sorted by date.

[SergioLuis]

Here are my thoughts about the grid sorting politics and displayed data:

• For games:

  • The first one being added is the first one in the grid. This is, the top-left corner.
    • The games are displayed in the library in the same order the user added them.
    • In the future, we could add sorting options: by played times, by date added, alphabetically... whichever we think makes sense. We could even give the possibility to show the games on a list instead of on a grid.
  • For games, we should keep and show the following information:
    • A screenshot (as mentioned before, we have to discuss a heuristic on when to take that screenshot).
    • The name of the game. At first, it will be the name of the file, without the extension, but it would be nice to let the user modify it in the future. It is a nice to have functionality, but I'd like the UI mockups to reflect it.

• For saved games:

  • The first one is the newest one. This is, the last game the user saved.
    • I think that users would usually like to continue their most recent game.
  • For saved games, we should keep and show the following information:
    • A screenshot of the game at the moment the user saved the game.
    • The date when the game was saved.
    • A title, that the user can edit while saving (for example, My highest score to date, or perfect game so far). Default's title should be something like [game title]@[date].

BUT, I think we are getting ahead of ourselves. This is an iterative process, and we don't have any mockups yet to comment on and change.

[mikelcaz]

Your statements are mostly describing the previous proposal, but not addressing the problem.

@jhvargas3112 Sorting by title name (first) won't fix anything, but will be inconsistent with the game library UI.

Example: game_library = [C, A, B], saved_games = [A3, A2, A1, C2, C1].

C was added first, then A, then B, and 3 is newer than 2, etc.

The second alternative makes me wonder why the game library UI is separated in first place (and I think it should be, at least right now, as I may change my mind on this aspect).

@SergioLuis I understand that you rewrote the game library part for avoid misunderstandings. I mostly agree with that part (except about removing the extension). I would add: top left corner as first element shouldn't be assumed (even if as example made the trick).

The saved games part. Displaying by date (first) regardless to what game belongs that save game is not a good idea IMHO. And it doesn't fix the problem anyway.

Example: game_library = [A, B, C], saved_games = [C2, A3, A2, C1, A1].

In a proper solution is desirable that:

• The player can continue with the last game as soon as possible (a save game can be updated, changing its date).
• The player has not to go though saved games of other titles searching a particular save game of the title he really wants (consider the previous saved_games array, with saved games of 100 titles, searching A1 at the end).

[SergioLuis]

@mikelcaz about this:

a save game can be updated, changing its date

I don't think it should. A snapshot is a snapshot, and cannot vary. If the user continues from that snapshot, they can create a new one, but the old one is not modified. I would be angry if my perfect game is overriden, and because handling more options (save game / update saved game) would add complexity, I suggest to keep saved games as simple as possible.

And about this:

The player has not to go though saved games of other titles searching a particular save game of the title he really wants

We could add the option to search both games and saved games. But still, I think the odds are that a user would want to continue the last game they saved, and following the criteria I described, it would be the first one in the grid.

[mikelcaz]

@SergioLuis I disagree with the first part. But don't mind for now, we will discuse about that later.

The second and prioritary part. I consider that a patch, and as you state, the criteria satisfy the first desirable feature, but not the second one.

I consider using the @jhvargas3112 proposal with a little change, and using two grids without tabs. The first one is the game library UI, and selecting one game, a second with saved games should appear. That UI would include a "new game" button, so the user wouldn't be much overwhelmed.

Of course, that not provides the second feature, but I believe it is a promising starting point and will be easier reach a solution that give both at once.

PD: May we initialize the grid with an offset? We could make it show the last used game.

[mikelcaz]

About the saved game grid: we should reflect somewhere the selected game.

One of the elements of the grid could be the "new game" button.

[jhvargas3112]

here is the UI prototype for the "Librería de juegos" section. Any suggestions will be welcome.

[mikelcaz]

@jhvargas3112 We should consider seriously making this stuff in English from the next mock up. All of us have overlooked it ; )

Definitely, game library means 'biblioteca de juegos' (as in "Lugar donde se tiene considerable número de libros para la lectura"). So our game library is a place that collects a considerable number of games waiting to be played.

I'm not sure if this information should be shown (and how) at screen, but here we have a progress making everything be less than two taps or clicks, and removing some clutter in the process (hooray!).

On the other hand, I have no idea about what is the purpose of the notification zone. So, what is it?

Plus: I hate that kind of menus with all my soul. Can we consider something like Windows 8 and a lot of Android managers? Using a menu bar with icons, so would be possible selecting and viewing more interactible elements (no overlapping), and take advantage of the Fitts' Law (for touch screen and mouse in one stroke).

It's nice to see we are on the right track.

[jhvargas3112]

Here is the English version.

[jhvargas3112]

This is the prototype for the game running.

[ugedo]

Here is the Andrid UI prototype for the "Saved games" section. List and grid versions. The first entry is a new game option. The games was order by date, descendant.

[jhvargas3112]

Finally, this is the basic prototype for the game running and keyboard layout. There is a doubt to considerate for the screenshot functionality:

Screenshot functionality take an image only of the game section and this aumotically is saved in the sistem. After, user can share this whereever he wants.

[ugedo]

Ok @SergioLuis, @mikelcaz, this issue is already waiting for the review to close.

[SergioLuis]

About the grid: I'm not a fan of popups. I also find the Resume (Reanudar) option in the popup troublesome: the user has to long-press a saved game to resume it? It should be the default option, not hidden in a second-level menu.

I like the Delete option, and I did not think about the Export one, nice catch!

Could you redo that screen moving the Delete and Export options to the toolbar? Hint: check what WhatsApp does when you long-press a message inside a chat.

[mikelcaz]

Yes, that's what I meant when I said that about "I hate them with all my soul". That kind of options should be on the toolbar.

Multiple selection would be great, and I insist on adding a checkbox there for selecting/unselecting all the items, like many Android file managers do.

On the running game UI: please, don't put the reset button there. It's too easy pressing it by mistake. What's more, I would move that kind of options (reset, snapshot, save) to the matrix keyboard placement while the game is paused.

I propose moving the pause/resume function to the game screen itself (as a video on YouTube). The top screen bar could be deleted (or just use the standard toolbar).

[SergioLuis]

I'm closing this issue. Further discussion on the topic will go on the issue of the actual implementation of the UI.