aleixpol at kde.org
Sun May 27 23:48:05 UTC 2012
On Mon, May 28, 2012 at 1:14 AM, freemind <freemind at lavabit.com> wrote:
> Saw this blog post :
> http://www.proli.net/2012/05/25/pairs-is-finally-in-kde-edu/ - and thought
> of giving my feedback on the UI design.
> Some issues, for me at least, that i found were:
> *Players' panel should include the "join" panel, since they're correlated.
Maybe, but a lot of nesting is not that helpful either.
> *A delete icon with no text is confusing, specially if it means to quit the
We're open to new artwork. Nobody says it's a delete icon, though.
> *It's not intuitive to get back to the previous menu/screen when you press
> the Info button.
Hm? Didn't understand this one.
> *There should be some kind of visual clue in the "game panel", that showed
> that the last row is a subgroup of the first row. Otherwise it appears that
> each icon is a different type of game.
Agreed, we must find a better solution.
> *The gameplay for multi-player seems nonsensical if it's meant to be played
> on the same computer/device. A better way to do it would be to let each
> player finish the entire game and then a chronometer would count the amount
> of time each player took and the one with lesser time would win.
Whenever I've played such memory games, it's always been this way.
It's not about competing about who is faster but being attentive to
what the other does as well. To me, it makes sense.
In any case, it has to make sense to the children who will use it
eventually and he who teaches them to play.
> *Perhaps changing the background to something more colorful would be better.
Like before, we're open to new artwork. I like this one for the
moment, I'm no artist, though.
> *There should be a way to pause the game while it's running.
Really? It's a fast game. Maybe it's just that it's stressful that the
time counts and we should remove the second counting all together.
Again, I'd like to know what kids think about it :P.
> *The delete icon for the player should appear on mouse click instead of
> mouse hover, so it can work on touch devices as well.
We agreed on the last e-mail that we want to improve Pairs on touch
screens. There's no doubt on that.
I doubt that this is the way we want to fix it, though. Player click
is already used for de/selection.
I thought of using hover when there's mouse and long press on touch
screens. I'm unsure about that, I want to get it running in an actual
device to figure it out.
> I understand that some things i pointed out are more technical bugs than
> actual UI design issues. But just in case i put them there.
> My suggestion is to change the game menu into a typical game menu. What i
> mean by typical is that at first we have the menu with options like Play,
> Scores, Get themes, About, etc. Each option, when clicked, would then show a
> new group of options (clearing the previous ones out, obviously). This
> leaves bigger space for the game icons for example, which is a good thing if
> we're on a touch device with a small screen.
> I also made some mock-ups, let me know what you think...
> It lacks many images (laziness), but i think you get the general idea.
> kde-edu mailing list
> kde-edu at mail.kde.org
I agree that we can make better use of the screen real state. It
becomes more notable on small screens like Aaron already pointed out.
On the other hand, I also doubt that making the application flow
through many pages is going to solve the problem.
It can make it more clear on the first use, but I also think it's good
that you open the application and "boom!" you're good to go.
More information about the kde-edu