aleixpol at kde.org
Tue May 29 02:14:36 UTC 2012
As I promised, I took some time to address these issues, maybe you'd
like to try it on a Vivaldi and see if it helped.
I couldn't test it yet from a touch screen. I'll try it on the exopc
at some point, but some of the constraints you observed won't apply
there either (like screen size), so feedback is still welcome.
On Fri, May 25, 2012 at 1:09 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Wednesday, May 23, 2012 11:26:53 Aleix Pol wrote:
>> Anyhow, please report us the issues you've discovered (either here or
>> bko) and we'll manage to sort them out.
> they are mostly design principles, so i'm not sure if they would work well
> into individual bug reports just yet. here are the things i noticed:
> * it relies on mouse hover in certain places. for instance, to remove a player
> you need to hover the item and then hit the "X". this works really nicely with
> a mouse, but not with a touch screen where hover events just don't exist for
> practical reasons.
Fixed, although I'm not very happy with the solution. Might change in
the future, but now it's possible to remove a player from a touch
> * animation timing. the animation that starts the layout of the board is
> reallllly slllloooooow. in practice, very few transition animations should be
> longer than .5s, and most should be more on the order of 1/4 to 1/3s. this
> gives the application a much nicer user experience. don't worry that people
> won't notice the wonderful animations if they are shorter.. our eyes are
> amazing. unfortunately our patience is short. :)
I basically reduced the animations duration, the change was very
un-scientific, so if you think it can be improved, just tell me.
> * hit areas should be bigger rather than smaller. on the game board, you have
> to touch the actual filled area of a piece. for pieces that are just outlines
> (such as in animal logic), this is hard even with a mouse. the hit area should
> be the entire space around the item to make it easily fingerable.
> * scalable UI. the graphics must always fit inside the window. the "New game"
> button will at times appear outside the window if it is not big enough. on
> devices where it will run full screen at native resolution, there is no answer
> to this other than "fit everything in the window, or make it scrollable". in
> this case, making it fit in the window is probably prefered (the new game
> button could perhaps appear on the left outside the playing area, where it
> normally is during a game? still, with more than one player's scores being
> shown, you'll want to make the scoring area scrollable.)
> * screen size may not be very big. this is the kind of game that should be
> playable on a phone, a tablet or a massive desktop. showing all the UI at
> once, with the left side, really takes away from the game play area. try it in
> an 800x480 window (Vivaldi's resolution) to see what it looks like. options
> include not showing the entire UI all at once (in Active apps, we often use a
> slide-in tray to hold things like "get themes" to keep them out of the way),
> making the game controls area on the left side use space more ergonomically to
> give more space to the play area ...
I tried to make the left controls more adapted to the Window width.
Hopefully this helps with running it on smaller resolutions.
> the above may seem like a lot ... but i really do think pairs is already in a
> pretty good state, it just needs that last 5% to make it sing and shine on
> touch devices :)
Maybe it won't shine yet, but let's see if we can get it to do some singing :P
> Aaron J. Seigo
> kde-edu mailing list
> kde-edu at mail.kde.org
More information about the kde-edu