Design Discussion

_____________________________________________
Keith Re: Design for moves and strategies Wed,
June 29, 2011 2:35:43 PM

> Rub your finger up
> and down the screen. Take your finger off when
> it is on the left side of the screen to choose
> rock, middle=paper, right = scissors.

OK, so the rubbing doesn't really perform any
useful function. You effectively have three
buttons which are not displayed on the screen
so you're being vague about the boundaries
and you're looking for the unpress rather than
the press. I guess you just like the cuteness
of this.

_____________________________________________
Jarvis Re: Design for moves and strategies
Wed, June 29, 2011 2:57:34 PM

Well, there is an analogy between rubbing up and down
and the traditional up and down arm motion.
The traditional up and down motion has appeal for some,
but we don't want them to flatten their palm
to choose paper at the end of a downward thrust.
The web version activates upon clicking a radio button.
I'm hoping that rubbing makes you feel better than clicking.
What do I know?

__________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 2:46:56 PM

For the computer move strategy, the design should
specify exactly what each of the algorithms is, and
then there's the issue of whether you're going to
explain the algorithms to the user or not. Any
explanation belongs in a help file. You don't
need a help file if you don't explain, as you
can simply have several difficulty levels which
the user can choose. Then they have to guess
about the algorithms if they wish.

In any case. the design should specify exactly
what should be done in the implementation.

_____________________________________________________
Jarvis: Design for moves and strategies
Wed, June 29, 2011 3:11:56 PM

If count(rock) >count(paper) and count(rock) > count(scissors)
play paper // beat rock
else
If count(paper) > count(rock) and count(rock) > count(scissors)
play scissors // beat paper
else
play rock;

For the low level of difficulty turn the > to <

 _____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 3:51:56 PM

 > There are 9 positions vertically. y axis: 0=top, 8=bottom
> ...

I'm trying to imagine how to explain all this
to the user. Whatever the algorithm, I think
the explanation is not easy.

_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 4:10:04 PM

That is for the programmer. You have to explain rubbing to the player in terms of simulating an arm shaking motion by rubbing up and down on the screen. The book, Rock, Paper, Scissors, explains the three-prime shoot thusly, Players pump their arms three (two) times in unison.

_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 4:20:21 PM

> That is for the programmer.

You have a definite tendency to let the programmer
decide various things that I think the design should
specify. I prefer to debug the design before getting
into the coding.

It's fine for the programmer to decide how to explain
things, but the design should specify what is to be
explained, and where, like in help or just onscreen.

_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 4:32:54 PM

I meant the programming spec is in terms of nine vertical areas of the screen, not that it is up to the programmer to come up with an explanation. We can probably improve on the explanation of the rubbing. It currently resides in a single XML tag that fills the instructions screen, and I am hoping that changes in the explanation do not impact much work elsewhere.

_____________________________________________________
Keith: Re: Design for moves and strategies
Wed, June 29, 2011 4:47:17 PM

I'm still unclear about how the user gets started
the very first time. I have noticed several apps
that bring up an "explanation" screen after you
first install it. This could go over the rubbing
concept or anything else that the user needs to
know before starting to play.

You should not bury the explanation somewhere
that the user could miss, like in menu/help.
Most phone experts know to try that, but not
everyone will think of it.

_____________________________________________________
Jarvis: Re: Design for moves and strategies
Wed, June 29, 2011 5:07:42 PM

I am a minimalist about instructions. If I say too much, they just think it is too complicated.
Some things, if you don't say enough, they just sit there, stuck. So far, I don't think this is one of them. Maybe the instructions should pop up if there is a long delay with the scores all zero.

83 Games answer to Rock, Paper, Scissors

https://market.android.com/search?q=rock+paper+scissors&so=1&c=apps

I looked for a longer explanation. None of these games have very lengthly explanations. Here is one that needs some explanation.

https://market.android.com/details?id=net.badpixel.android.victoryv&feature=search_result

Jarvis: Design for moves and strategies

Design for moves and strategies
From:
Jarvis Rich
View Contact
To: Keith Rich ; Edith

With some work, I could put an image of rock, paper, and scissors under the feet of the stick-figure contestants.

These are rudimentary instructions and philosophy.

Rub your finger up and down the screen. Take your finger off when it is on the left side of the screen to choose rock, middle=paper, right = scissors.

If the phone plays a random strategy, you can gain no advantage by using a strategy. If it tries to win, it can be beaten. If you can beat it when it tries to win, you may find it harder if it tries to let you win.

Pictures from web version

http://phoneappprojectman.blogspot.com/2011/06/pictures-from-web-version.html

Design for startegy.

The simplest algorithm is to see whether the the person is favoring one of the three choices, and we program the phone to win over that. Aging the history, by weighting the next previous choice less by 5 percent, may help. A small abount of randomization may make the phone less predictable.

The next most simple algorithm is to see whether they favor one choice given their last choice or the computer's last choice.

Pictures from web version

person chooses rock
person chooses paper
person chooses scissors

Keith comments on alternate design

Re: Alternate Design Statement
From:
"kxr@netzero.com"
View Contact
To: ishtar@pacbell.net
Cc: edithrasm@yahoo.com; kxr@netzero.net
Jarv,

Yes, I think this is helpful.

Now, for specifics:

1) rub finger down-up-down-up-down
I don't understand this; how do you choose
what your move is?
2) consider multitouch input with 1, 2 or 3
fingers to make choice. Yes I know this
won't really work with the emulator. You
can have multiple input methods active.
3) display images of Rock, Paper and Scissors
and make the choices bigger or a different
color after choice. Show computer's choice
as well. In any case, the design should
really say what the screens will look like.
4) a bunch of your implementation belongs up
in the design section, like the strategies.
You really want to "design" everything that
you're going to implement rather than just
leaving important issues undesigned. This
goes back to the idea that the principle
that it is cheaper to debug the design
than to change things during implementation.

In summary, it should be possible to create and
debug the design enough so that you effectively
have a spec that someone else could implement
without any important ambiguities left to the
implementation stage. Of course, this does not
guarantee that implementation won't disclose
bugs in the design which can't or shouldn't be
implemented.

Keith

Jarvis alternative design

Alternate Design Statement
From:
Jarvis Rich
View Contact
To: Keith Rich ; Edith
Alternate Design Statement
Looks better on the blog
http://phoneappprojectman.blogspot.com

design of RockPaperScissors game goals     person versus computer     select either to play first     offer levels of difficulty     log person/phone/result history     show who won and why     keep score for a session of games     keep record of session scores     help should be unnecessary     undo user interface main screen - portrait only     choose instructions / play-level / philosophy     press go button game screen - portrait only     click on rock/paper/scissors radio button     rub finger down-up-down-up-down     stick figure's arms move up and down with rub.     balloon error message for incomplete rub.     display graphic showing winner and score.     press go button implementation Develop graphics     modify tic tac toe progressively morphing to RPS     modify web pictures to fit on screen.     substitute web picture for play-field.     play, see arm movement per pointer position.     see different graphic for win/lose/draw 3 pics.     see different graphic for win/lose/draw 9 pics.     cosmetic changes. Develop input handler     track movement by drawing free-form line.     require up-down threshholds for movement.     Score round on pointer-up instead of button. Develop strategies     predict favoring rock, paper, or scissors.     predict given previous win or loss.

design of TicTacToe game goals     person versus computer originally 4 dimensional tic tac toe changed to 2D showing 8 previous results     select either to play first     offer levels of difficulty     log player/cell occupied     show who won and why     keep score for a session of games     keep record of session scores     help should be unnecessary     undo user interface main screen - portrait only     choose play-level     choose person/phone to go first game screen - portrait only Develop graphics     differ from tic tac toe sample, show 9 playing fields.     show accumulated score, chosen difficulty.     button to continue play or start over. Suggestion to play on full sized field is good. while showing 9 fields with score now seems within reach. Actions     press one of the nine squares to make a move. Originally, press square on 1 of 9 play-fields for 3rd, 4th dimention. Now, press square on 1 of 9 play-fields current game.     blinks until I'm Finished button is pressed.     Until then, your move can be changed. implementation Main screen     add radio buttons for level of difficulty.     Learn to pass level of difficulty intent to activity. Game screen Develop graphics     modify tic tac toe progressively morphing from sample.     miniturize playing field, with 9 copies on screen. build actions logic     create data structures for score.     Achieve persistence for score, with phone movement     Achieve persistence for score, back to foreground

Keith presents two design files

Re: Project Management discussion, Phone apps

From:	"kxr@netzero.com" <kxr@netzero.com> View Contact
To:	ishtar@pacbell.net
Cc:	edithrasm@yahoo.com
	2 Files  Download All tttdesign.txt (1KB); rpsdesign.txt (1KB)

---

Jarv,

I've attached two design files, one for
TicTacToe and the other for RPS.  They
are not very different, but that's only
because I didn't think very hard about
how the RPS game ought to work.

The real design for RPS should build on
this by writing down several possible
ways to define the RPS user interface.

The paper prototype stage is where you
imagine how to play the game while
looking at imagined screens.

Anyway, I can see from my design files
that the actual input controls are a
rather minor part of the whole app.

design of RockPaperScissors game goals person versus computer   select either to play first   select computer smartness log order of moves taken allow undo allow multiple games   scroll through list of games keep track of scores user interface main screen portrait         RoPaSc    score         rock         paper         scissors       <=    <  >  => landscape         RoPaSc    score         rock <=    <    paper    >    =>         scissors actions press one of the RPS buttons to make a move press and hold buttons to unmove it < button - undo "person" last move     grayed out button if no undo available > button - redo "person" next move     grayed out button if no redo available <= button - scroll back to previous game board     grayed out button if no previous available => button - scroll forward to next game board     grayed out button if no next available press and hold any of the four buttons to act   repetitively as far as possible options menu select computer smartness select game count   before roll off of history help   explain actions implementation build user interface   main screen     portrait     landscape   options menu     help text build input handler   main screen     press actions     press and hold actions   options menu build actions logic   create data structures     as needed for actions

design of TicTacToe game goals person versus computer   select either to play first   select computer smartness log order of moves taken allow undo allow multiple games   scroll through list of games keep track of scores user interface main screen portrait         TicTacToe    score         nine         square         board       <=    <  >  => landscape         TicTacToe    score         nine <=    <    square    >    =>         board actions press one of the nine squares to make a move press and hold square to unmove it < button - undo "person" last move     grayed out button if no undo available > button - redo "person" next move     grayed out button if no redo available <= button - scroll back to previous game board     grayed out button if no previous available => button - scroll forward to next game board     grayed out button if no next available press and hold any of the four buttons to act   repetitively as far as possible options menu select computer smartness select game count   before roll off of history help   explain actions implementation build user interface   main screen     portrait     landscape   options menu     help text build input handler   main screen     press actions     press and hold actions   options menu build actions logic   create data structures     as needed for actions

Keith on Design for User before Programming Considerations

Re: RPS Project Management 101
From:
"kxr@netzero.com"
View Contact
To: ishtar@pacbell.net
Cc: kxr@netzero.net
Jarv,

I think you are not really embracing the concept
of designing the user interface before designing
the code. For example, in the TicTacToe game,
there is no real value in showing all nine boards
at once. If you just show one board at a time,
it will be much easier to operate since the places
you touch will be bigger. You can have some other
small "thing" that moves from board to board,
like tabs or a popup menu.

Keith

Jarvis on approach taken

Re: RPS Project Management 101

From:	Jarvis Rich <ishtar@pacbell.net>  View Contact
To:	"kxr@netzero.com" <kxr@netzero.com>

---

Thanks for your suggestions. I'm sure you can have more.

The UI issues need to be addressed.

For the moment they seem serviceable.

My approach was to start from Tic Tac Toe and try to find a path of least resistance.

Keeping the score and displaying it was the same.

I have the level of difficulty showing along with the result as DF=n, which is not great.

Currently that DF number is usurped to show the x horizontal position on cursor up.

It is not always right.

I had 9 graphical representations for win-lose-draw.

I found I could change them easily using MS paint to show on the emulator screen.

I had 4 up positions to show the arm being shaken.

Currently they try to show the Y vertical arm position when the touch is lifted up.

I plan to change the code to follow the moving pointer, and to require it to shake (go up and down) 3 times. It may need more points to look smoother.

At that point I think we have a working model, and then I would address the UI.

I would prefer no instructions to show while playing the game.

If people just stare at it, without touching the screen, it flunks.

If they touch the screen they will leave a visible trail of a scrape, and maybe they will know what to do.

I probably undervalue the menu, because of lack of experience with smart phones.

The #2 option is from the API Sample, and it has a 5 item menu.

I will have to see what I can make the options look like before I get enthused.

A historic review of the opening menu. It fitted in a square space and it worked both horizontally and vertically without the items all squirming around. I have been happy with enforcing a portrait view, so that doesn't matter any more. I think I tried making the radio buttons vertical, and I couldn’t make them as compact. The message below the radio buttons applies to the nine tic tac toe boards. It will go away when the current playing mechanism goes away. Maybe it needs to be changed for tic tac toe game, which is a very unpopular version of tic tac toe.

   

Keith other design suggestions

Re: RPS Project Management 101

From:	"kxr@netzero.com" <kxr@netzero.com> View Contact
To:	ishtar@pacbell.net
Cc:	kxr@netzero.net

---

Jarv,

I can iterate with other designs.

  1)  change the radio group to tabs; when you press a tab
      you get directly to that mode, and that tab remains
      highlighted so that you can see what mode you are in.
  2)  move the instructions and philosophy to the menu, so
      they have lower prominence than the real game modes.
  3)  you could move all five buttons to the options menu.
  4)  if you care about minimal screen presence, you could
      use a single popup menu.

Anyway, these are the sorts of issues involved in the user
interface design.  You can write them all down and then
stare at them until you can pick the one you like the best.

Keith

Keith on RPS Design

Re: RPS Project Management 101

From:	"kxr@netzero.com" <kxr@netzero.com> View Contact
To:	ishtar@pacbell.net
Cc:	kxr@netzero.net

---

Jarv,

I think some things are not clear at the
design level.

  1)  The choices 1-5 appear with some words
      and then with just the numbers in the
      radio group.  You should probably have
      the radio group be vertical with the
      words to the right of the buttons.
      Meanwhile, when you're in the game,
      the 1-5 choice is not visible as it
      should be.  The words below the radio
      buttons belong on the game screen
      where you need that info.
  2)  On the game screen, it is not clear
      what you are supposed to do to make
      a move.
  3)  The menu button currently doesn't do
      anything.  Perhaps the 1-5 choices
      belong there.

The general idea of that video is that you
could benefit from drawing on paper what
the various screens look like.  Then you
review what the player does to play the
game.

Keith

Jarvis notes on Keith's Video Notes

Mon, June 27, 2011 1:22:34 PM

RPS Project Management 101

From:	Jarvis Rich <ishtar@pacbell.net>  View Contact
To:	Keith Rich <kxr@netzero.net>
	RoPaSc1b.tgz (1212KB)

---

I attach a tar file that can run what I have.
It has and uses all the graphics, 
but you drive them by playing my tic-tac-toe game,
which has the board obscured by new graphics.

The playing board still has nine game-boards,
and you move from one to the next at the end of each game.
Soon it will be changed to use the whole screen.
 
When you lift up the touch device, 
the I'm done button is still required
(soon to be removed)

Win, lose, and draw counting is intact from tic-tac-toe.
Level 2 has an activity/view module from the API sample.
It will go away soon.
See if I have enough to tickle your imagination.


I replayed a youtube video I watched 

I think these principles also apply to project
management.  We've all known for a long time
how important it is to figure out what to do
before you jump in to start doing it, but it
needs to be remembered.
   That is an SDLC Waterfall belief.
   The point of Agile is to start much earlier.


The numbers at the left are time points within
the video.  I found it useful to go back to
review the ideas more than once.

How to build an iPhone app that doesn’t suck
in 10 easy steps
Steve Marmon
http://www.youtube.com/watch?v=ENyzcXRPeeI

key points:
  talk to users
    Lots of people, somewhere in a discussion of apps. 
  explore many designs
    Thanks for the book.
  iterate based on user feedback

03:12 step 1 Decide what to build.
    Don’t start with the solution
      Too bad. I habitually do this game in a new programming environment.
    What is the need/problem.
      Fun to play.
      Exercise to learn graphics, pointing device, Java libraries.
    Who is the user?
      Casual games for the non-enthusiast.
    What does the user need?
      Something to show someone else.
07:16 principle 1 Know your users.
      See above. 
07:54 step 2 Visit the app store.
    Look for similar apps.
      about 84 on the App Store
    see how they work
      Many are multi-user. That may be an extension of the current design.
    look for missing features or other deficiences
    Good artists copy, great artists steal - Pablo Picasso
      I stole from my own drawing. 
12:33 principle 2 Don’t build your app in a bubble.
12:34 step 3 Explore possible solutions.
    Address constraints.
      small screen
      less precise touch input
      typing is difficult
      usage is in short bursts
    Consider alternate controls.
      multitouch
      accelerometer
      gps
17:02 principle 3 Be minimal.
17:06 step 4 Sketch the user interface.
    Sketch many designs.
    Review designs (focus groups)
21:18 principle 4 Quality through quantity.
23:20 step 5 Build a paper prototype.
    Draw each screen.
    Go through scenarios on paper.
    Try “using” the app before writing any code.
       see: http://home.pacbell.net/ishtar/Game1



26:45 principle 5 Fail early to succeed sooner.
26:58 step 6 Fire up Omnigraffle. (drawing tool)
31:00 principle 6 Be pixel perfect.
31:03 step 7 Do it all again.
    The cost of making changes grows rapidly
      as you progress from design to code.
    Get the design as settled as possible
      before writing the code
32:21 principle 7 Remember that nothing is precious.
35:09 step 8 OK, you can finally code.
36:59 principle 8 Proceed top down, design UI, do back end data last.
37:00 step 9 Beta test your app.
42:04 principle 9 Test before you submit.
42:42 step 10 Release.

Keith notes on Video - Phone App

How to build an iPhone app that doesn’t suck

From:	"kxr@netzero.com" <kxr@netzero.com> View Contact
To:	ishtar@pacbell.net
Cc:	edithrasm@yahoo.com; kxr@netzero.net

---

Jarv,

I replayed a youtube video I watched some time
back, and here are some notes I wrote down about
it.  It is about iPhone, but the principles
apply to Android as well, although the tools
are different.

I think these principles also apply to project
management.  We've all known for a long time
how important it is to figure out what to do
before you jump in to start doing it, but it
needs to be remembered.

Keith

The numbers at the left are time points within
the video.  I found it useful to go back to
review the ideas more than once.

How to build an iPhone app that doesn’t suck
in 10 easy steps
Steve Marmon
http://www.youtube.com/watch?v=ENyzcXRPeeI

key points:
  talk to users
  explore many designs
  iterate based on user feedback

03:12 step 1 Decide what to build.
    Don’t start with the solution
    What is the need/problem.
    Who is the user?
    What does the user need?
07:16 principle 1 Know your users.
07:54 step 2 Visit the app store.
    Look for similar apps.
      see how they work
      look for missing features
        or other deficiences
    Good artists copy, great artists steal - Pablo Picasso
12:33 principle 2 Don’t build your app in a bubble.
12:34 step 3 Explore possible solutions.
    Address constraints.
      small screen
      less precise touch input
      typing is difficult
      usage is in short bursts
    Consider alternate controls.
      multitouch
      accelerometer
      gps
17:02 principle 3 Be minimal.
17:06 step 4 Sketch the user interface.
    Sketch many designs.
    Review designs (focus groups)
21:18 principle 4 Quality through quantity.
23:20 step 5 Build a paper prototype.
    Draw each screen.
    Go through scenarios on paper.
    Try “using” the app before writing any code.
26:45 principle 5 Fail early to succeed sooner.
26:58 step 6 Fire up Omnigraffle. (drawing tool)
31:00 principle 6 Be pixel perfect.
31:03 step 7 Do it all again.
    The cost of making changes grows rapidly
      as you progress from design to code.
    Get the design as settled as possible
      before writing the code
32:21 principle 7 Remember that nothing is precious.
35:09 step 8 OK, you can finally code.
36:59 principle 8 Proceed top down, design UI, do back end data last.
37:00 step 9 Beta test your app.
42:04 principle 9 Test before you submit.
42:42 step 10 Release.