Notices

The Miniature project aims to deliver a chess board that goes always with you, ready to let you play and learn wherever you go.

We have just concluded the Phase 0: Project setup that started with the thread Contributors needed: the killer free chess game for Maemo.

Here we focus on the first big item of the roadmap: Play games online. Easier said than done.

We have planned three phases to get there and we will try to focus as much as possible in each of them, one at a time:

1. Chess game basics, demonstrated off-line.
2. Online chess basics, targeting http://www.freechess.org/ first
3. Online chess advanced

Any kind of feedback and help is welcome. Feel free commenting here also other features in the roadmap or new proposals. Note that the pure developer discussion happens in the project mailing list.

DISCLAIMER: I'm contributing to Miniature in my free time without any link to my job at Nokia.

I'll add in a comment to this.

If your project is ever going to be ported to other handhelds/platforms with different display dimensions, then the entire presentation layout needs to be flexible as to how it appears on the screen.

I was thinking of two dynamic layout options and settings, one for landscape and the other for portrait mode.

Within these menus, every setting would be configured by the end user.

The board, size of board, where it's positioned, coloring, board coordinates being on/off, chess pieces, size of pieces, coloring, etc.

Also where the chat window is located, the size of it, font, font size, font coloring, etc.

Short cut keys, where on the screen, font, font size, font coloring.... stuff like this.

Basically every piece and part of the screen layout could be movable and arranged differently according to a person's preference. Maybe even have a "preview" mode before the user saves his configuration to make sure that's what he or she wants.

It might be overwhelming at first for a newbie to configure all of this, but if it's packaged with default settings and the ability to restore the them, this definitely might be the best direction for your project.

Actually, going back over my previous post, this even confused me a little.

Instead of two separate menus for portrait and landscape modes, perhaps it would be more simple to have only one menu.

Just have a screen layout save option.

This way a user could either load or save something like a portrait.ini or landscape.ini file or anything in between.

Not sure what the easy ground would be to implement this though.

For a user to drag and drop all of the possible windows on the screen would be terrible to program.

To enter in X,Y coordinates including height and width numbers for each window would be difficult for the user to understand.

@qgil
What are your thoughts on this?

This seems like the right progression but I'm not seeing a way to make it easy on everyone involved.

Cheers!

Configurable screen layout. Those are good thoughts, we should put it on the roadmap somewhere after the 0.1 release. There is already a landscape mode item on the list, perhaps we should extend that item to include "configurabe screen layout to support portrait/landscape mode on multiple devices" (then a list of devices, with links to their screen/display spec, because if it is only 4 or 5, we might still want to hard-code it and avoid a potentially fragile API).

I think I can see what you mean about this becoming fragile.

What if a user decides to place some window bigger than what would be allowed on the device? Pure hell I would imagine.

The point of all of this was is to have the entire screen display more open to the end users instead of the people who might port it.

Hope that makes some sense.

I think that to much customization possibilities are not good. If you let the end user decide about every single UI element that will become a big mess in two ways IMHO. (1) the user will get confused. I mean designing the UI is the (difficult) job of UI designers and you cannot expect every user to have the skills to do that. (2) In my experience such customizations are a huge source of problems and bugs and a real pain in the *** thinking from a developers point of view.

So in my opinion a well designed layout (or two that is) is superior to a badly designed customizable layout. And speaking about porting the application to other devices I think mikhas is absolutely right when he says hard-coding the layout for a few devices is still better than designing it open enough to fit for every possible device.

I wonder what do you want to customize in the UI? I can see a point of having the board on the left side instead of the right side if you are left handed but apart from that... what?

Is it so critical to have the names and avatars of the players above or below the board in portrait mode? There is a reason to have them on top: separate the board from the status area so you don't click accidentally on e.g. the clock or other system UI buttons.

Even if the pixel sizes might differ across touchscreen devices, the rough screen proportions will be overall similar. See for instance N900 vs N97 Mini. A fluid UI design should be usable and elegant in different devices without specific optimization. And this has nothing to do with user costumization.

This is the reason why we could need the help of UI designers. There are many rules like this, and I simply do not know them!

Good idea. Let's find a UX specialist with some interest in chess. I will ask tomorrow in the office.

Please have a look at the checklist of the Phase 1. Now is the perfect time to tell whether you are missing something important for the goal "get the Chess game basics in place and demonstrated off-line". Thanks!