[Kde-games-devel] KPatience, select deck dialog idea and mockup.

Parker Coates parker.coates at gmail.com
Tue Apr 21 15:50:56 CEST 2009


On Tue, Apr 21, 2009 at 8:30 AM, Dmitry Suzdalev wrote:
> Let's make this a mockups thread :)))
>
> Yesterday I proposed another design (attached).
> Some notes about mockup:
> 1. When deck has both front and back suites, both icons are available
> 2. Decks which are "backside-only" are marked with some special (yet
> undecided) markup and have only "use as the backside" icon.
>
> Parker had some nice ideas too - about having two GHNS-like listviews one
> next to another.
> (Parker, would you post them here, so others can review?)

Okay, I've attached my very rough mockups. Please, no laughing at my
graphics skills. The first one shows the default state of the dialog.
The second shows the dialog after checking the "Choose card backs
separately" box, which is just the opposite of the current "Lock
frontsides to backsides" box.

I like that the previews are embedded, because 1) we don't end up
showing the same image in more than one place 2) the user gets a
decent preview without actually having to select the deck. This is
common to Eugene and Sean's mockups as well. Other than that, I think
it's a pretty straight forward solution that should seem familiar to
users who've used the GHNS or Plasma "Add Widgets" dialog. As for the
exact information, shown next to each item, I'm not particularly set
on the text there, I just reused what was in the GHNS dialog.

> Yesterday we had some discussion on #kde-games.
>
> I argued that showing two separate lists views for fronts and backs looks
> like an overkill to me - too complex interface, dialog gets too big.
> While Parker had a point that having both fronts and backs shown together
> would make it easier to compare them.

The size argument is a legimate one, for sure. The complexity one, I
don't really buy. I feel the added complexity of having to switch
between separate screens to do this simple task, more than makes up
for whatever clutter is saved by placing the fronts and backs on
separate screens.

> it-s and Half-Left came up with their own ideas which were also presented in
> this thread.
>
> Some more thoughts I have:
>
> 1. First of all i'd personally remove this "separate backs" feature as it
> really complicates not only UI, but user workflow too. Too much options to
> choose from IMO.

This has been discussed on the list in the past. [1] At the time, most
developers seemed convinced that unified fronts and backs were a good
idea, while Matthew Woehlke argued the against. Eugene decided to ask
"the people" and got a firestorm of responses claiming that this is
the single greatest feature in KPat. [2] So there will be
unpleasantness whether we keep this feature or get rid of it.

Personally, my vote is to remove it. It would simplify a lot of things
and also ease the introduction of GHNS. In fact if we added GHNS
support at the same time we remove separate backsides, then that might
mitigate some of the user outrage. Unfortunately, we're already past
the soft feature freeze, so I'm not sure if that can happen for 4.3.

> 2. If we leave this feature, I'd consider it a "power-user"-like feature and
> having it not necessarily available right from the start sound good.

The flip side is of course, if we bother doing the feature at all, we
should probably do it right. So we shouldn't make such users jump
through too many hoops. (Not that anyone has suggested such an
implementation here.)

Parker

[1] http://markmail.org/thread/utc7ohedtn7vqghv
[2] http://my.opera.com/it-s/blog/2009/04/18/patience-to-back-or-not-to-back
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cardselector-locked.png
Type: image/png
Size: 79826 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20090421/cb6e505b/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cardselector-unlocked.png
Type: image/png
Size: 94595 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20090421/cb6e505b/attachment-0003.png 


More information about the kde-games-devel mailing list