aleixpol at kde.org
Mon May 28 01:40:21 UTC 2012
On Mon, May 28, 2012 at 3:15 AM, freemind <freemind at lavabit.com> wrote:
> On 28-05-2012 00:42, Marco Calignano wrote:
>> Sorry can you explain this point more?
> Which point exactly?
>> This game is meant for little children and you cannot let a kid wait
>> until another or even others finished. Plus the alternation of players allow
>> the kids to learn from one another. So IMHO it makes more sense how it is
> The alternation is silly and doesn't make sense, because when one fails the
> time starts automatically counting for the next player and it's not fair
> play. If you want a better multi-player you'll need network (or some other
> type of connection) and 2 or more devices.
>>> *Perhaps changing the background to something more colorful would be
> Because children like colorful things? Go check any kids application and see
> how colorful it is.
>> I do not think that this step configuration is a good thing for children
>> and in the developing phase we adopted for a layout that could reduce if not
>> eliminate the steps.
>> A solution (already suggested) to increase the board space for touch
>> device is the one that put the left menu on a sliding panel. So it comes up
>> when the user needs it and not when he plays
> Why do you say a step configuration is not a good thing? Have you tested
> this theory with actual children?
> Most of the kids' applications i've looked at have step configuration and
> they seem to be pretty successful. Why do you say otherwise?
> On 28-05-2012 00:48, Aleix Pol wrote:
>> Maybe, but a lot of nesting is not that helpful either.
> It's not really nesting that i was mentioning, look at my mockup, it makes
> things more simple and organized.
>> We're open to new artwork. Nobody says it's a delete icon, though.
> Well that's what that icon is used for in probably 99% of the cases. Just
> type in "delete icon" on whatever search engine you like and check the
> images. For quitting an application there are better icons in my opinion.
> You can look for more artwork here: http://www.iconfinder.com/
>>> *It's not intuitive to get back to the previous menu/screen when you
>>> the Info button.
>> Hm? Didn't understand this one.
> When i click on the Info button, how do i get back to the menu? There should
> be a return button somewhere...
>>> *There should be some kind of visual clue in the "game panel", that
>>> that the last row is a subgroup of the first row. Otherwise it appears
>>> each icon is a different type of game.
>> Agreed, we must find a better solution.
> I gave a solution in my mockup.
>>> *The gameplay for multi-player seems nonsensical if it's meant to be
>>> 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
>>> 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.
> That's fine, but like i said before, if we want true multi-player we need
> network and 2 or more devices.
> Everything else will be either not practical (your solution, IMO) or not
> really multi-player (my solution).
> Maybe if we paused the game until a tap on the screen (or a mouse click) so
> that the next player doesn't get penalized.
Multiplayer with different devices can be done and probably will
happen at some point. I still think the current behavior makes sense,
for instance (if I'm not mistaken) Pairs it's being used in a school
with a big screen. I like the idea of having two kids sharing it.
A device per kid is interesting for us, but we won't force it and
there's many reasons for that. i.e. Economical, social.
>>> *Perhaps changing the background to something more colorful would be
>> Like before, we're open to new artwork. I like this one for the
>> moment, I'm no artist, though.
> It's for children to like not you lol, so a background more colorful would
> be better IMO. I'm sure there are many good colorful backgrounds out there,
> you need to do a little research...Try flickr, kde-look.org, gnome-look.org,
Agreed, it's not for me to like or not. I didn't mean it like that.
I don't think we should be hunting for artwork in such pages. We've
got this one Made by Abhash. If you know anybody else interested in
collaborating with us providing artwork for Pairs, don't hesitate to
get in touch with us in this regard.
Said that, I think it's not good the bashing
>>> *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.
> Yea, the problem is the time that keeps counting. Maybe just a quit then...
>> 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.
> What's the problem of being selected and showing a delete icon at the same
> time? It makes perfect sense to me...
I've implemented a some solution, feel free to try it.
>>> 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
>>> 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.
> Like i said before, all other kids' applications i've looked at have many
> pages and that doesn't seem to be a problem.
> I understand your point however putting everything in the same screen can be
> confusing and thus worse.
> My advice is to give this application, as it is now, to some children to
> test. It would also be good to give the same application with the design i
> mentioned so we could compare, but that's not possible. :P
Yes, this application will be used by children already, I'm also
looking forward to any feedback. :)
> kde-edu mailing list
> kde-edu at mail.kde.org
More information about the kde-edu