I can't emphasize enough how much I have learned this week. I have ended up a huge leap forward, but have gotten there by taking several small steps.
FORWARD STEP ONE:
I'm happy to say that I kept myself in check by reminding myself of the dilemmas I wrote of in the previous post. It was especially helpful in keeping my priorities straight. I put the app together step by step and I made sure all of the components WORKED before spending time on how they LOOKED.
FORWARD STEP TWO:
I have another dilemma to add to the list:
Dilemma #7: Computers don't recognize - they compute. Learn to distinguish between behaviors that can be recognized and behaviors that can be computed.
I learned this lesson the hard way. My initial idea for an app was a game in which you attempt to fill the canvas with a paint color without touching a jumping sprite. I worked on it step by step, but when I got to the last step, I realized that the computer had no way of computing that the canvas was filled with a different paint color. There was no trigger to signal the app to say "You Win." The human eye could recognize the canvas being filled - but I was unable to come up with a workable way of computing the information so that the app could understand it. Perhaps one exists, but my attempts failed. I tried several solutions, one of which was to place hidden ball sprites onto the drawing canvas which would then be "disabled" with a touch. The idea was that when each of the balls had been touched (or disabled) that the app would then have a trigger for initiating a "You Win" screen. But that left the problem of either the balls all being disabled but the screen not being completely filled with color - or the screen being filled with color without all of the balls being disabled. I tried other ideas but they completely changed the game and were boring in comparison. So, I fell back on my list of dilemmas: big ideas + low skills = amateurish solutions = no good! Perhaps a solution is possible - but not for me right now. So I decided to scrap the idea and try something more feasible.
FORWARD STEP THREE:
And I am happy to say that I found a great alternative! I developed an app that solved a real-life problem (for me at least). A creative warm-up exercise I often do is to have someone draw a few random squiggles and lines on a piece of paper. I then use those doodles as an inspiration for a drawing. The problem is that there isn't always someone else there and it's not the same doing it yourself. So I made an app that scribbles something random for me!
And despite my frustrations with failing in my first attempt at a drawing app, the lesson I learned from Dilemma #7 helped me to understand the blocks editor even more. I approached the design of the app in a much more computer-logical way.
For example:
Recognizable behavior = draw a random line.
Computable behavior = define a point "x" and a point "y" and define a range of values for "x" and y" by creating a mathematical equation (for example "random integer times a random fraction.") Luckily, the app inventor fills in most of the rest!
FORWARD STEPS FOUR TO MUCH MORE:
By prioritizing the components necessary, I was able to tackle each problem without being overwhelmed. I first created a skeleton of the most necessary components and behaviors, and because I tested the app EVERY TIME I made a change - I was able to make a new list of unexpected sub-problems that I encountered. I did not change them immediately (unless they were high on the priority list) but I noted them and went back to them later.
In addition to what was learned in the Paint Pot tutorial, with this app also I learned to:
create my own colors
adjust the size/width of a "dragged" line
use variables and lists to do all sorts of stuff!
use invisible triggers to "trick" the app into doing something (for example: initially, when the user
pressed the "New Inspiration" button - the app prompted the user with: "Do you want to lose the
drawing forever?" whether or not the drawing had already been saved. To change this - after an
image has been saved, the font size of an invisible label button also changes - and thus acts as
the trigger for the app in a control: "if font size =x, do blah blah; else do bluh bluh")
use the TinyDB function to "remember" canvas background images - enabling me to clear user
drawings while keeping the initial generated "squiggles" as well as to save user drawings
create procedures, helping me to reduce block "traffic"
use labels and arrangements for spacing
create menus by using the "List Picker" functions
create a text box where users can type in their own file name for their saved drawing
consider the order of the block behavior instructions (what is listed first, happens first - and this
sometimes makes a big difference in the outcome of an event)
consider every little detail imaginable...wow...computers are stupid!!!
I am so happy with how much I have learned! It took a lot of time and effort but I have big ideas, so.... :)
Till next week,
Kristie
FORWARD STEP ONE:
I'm happy to say that I kept myself in check by reminding myself of the dilemmas I wrote of in the previous post. It was especially helpful in keeping my priorities straight. I put the app together step by step and I made sure all of the components WORKED before spending time on how they LOOKED.
FORWARD STEP TWO:
I have another dilemma to add to the list:
Dilemma #7: Computers don't recognize - they compute. Learn to distinguish between behaviors that can be recognized and behaviors that can be computed.
I learned this lesson the hard way. My initial idea for an app was a game in which you attempt to fill the canvas with a paint color without touching a jumping sprite. I worked on it step by step, but when I got to the last step, I realized that the computer had no way of computing that the canvas was filled with a different paint color. There was no trigger to signal the app to say "You Win." The human eye could recognize the canvas being filled - but I was unable to come up with a workable way of computing the information so that the app could understand it. Perhaps one exists, but my attempts failed. I tried several solutions, one of which was to place hidden ball sprites onto the drawing canvas which would then be "disabled" with a touch. The idea was that when each of the balls had been touched (or disabled) that the app would then have a trigger for initiating a "You Win" screen. But that left the problem of either the balls all being disabled but the screen not being completely filled with color - or the screen being filled with color without all of the balls being disabled. I tried other ideas but they completely changed the game and were boring in comparison. So, I fell back on my list of dilemmas: big ideas + low skills = amateurish solutions = no good! Perhaps a solution is possible - but not for me right now. So I decided to scrap the idea and try something more feasible.
FORWARD STEP THREE:
And I am happy to say that I found a great alternative! I developed an app that solved a real-life problem (for me at least). A creative warm-up exercise I often do is to have someone draw a few random squiggles and lines on a piece of paper. I then use those doodles as an inspiration for a drawing. The problem is that there isn't always someone else there and it's not the same doing it yourself. So I made an app that scribbles something random for me!
And despite my frustrations with failing in my first attempt at a drawing app, the lesson I learned from Dilemma #7 helped me to understand the blocks editor even more. I approached the design of the app in a much more computer-logical way.
For example:
Recognizable behavior = draw a random line.
Computable behavior = define a point "x" and a point "y" and define a range of values for "x" and y" by creating a mathematical equation (for example "random integer times a random fraction.") Luckily, the app inventor fills in most of the rest!
FORWARD STEPS FOUR TO MUCH MORE:
By prioritizing the components necessary, I was able to tackle each problem without being overwhelmed. I first created a skeleton of the most necessary components and behaviors, and because I tested the app EVERY TIME I made a change - I was able to make a new list of unexpected sub-problems that I encountered. I did not change them immediately (unless they were high on the priority list) but I noted them and went back to them later.
In addition to what was learned in the Paint Pot tutorial, with this app also I learned to:
create my own colors
adjust the size/width of a "dragged" line
use variables and lists to do all sorts of stuff!
use invisible triggers to "trick" the app into doing something (for example: initially, when the user
pressed the "New Inspiration" button - the app prompted the user with: "Do you want to lose the
drawing forever?" whether or not the drawing had already been saved. To change this - after an
image has been saved, the font size of an invisible label button also changes - and thus acts as
the trigger for the app in a control: "if font size =x, do blah blah; else do bluh bluh")
use the TinyDB function to "remember" canvas background images - enabling me to clear user
drawings while keeping the initial generated "squiggles" as well as to save user drawings
create procedures, helping me to reduce block "traffic"
use labels and arrangements for spacing
create menus by using the "List Picker" functions
create a text box where users can type in their own file name for their saved drawing
consider the order of the block behavior instructions (what is listed first, happens first - and this
sometimes makes a big difference in the outcome of an event)
consider every little detail imaginable...wow...computers are stupid!!!
I am so happy with how much I have learned! It took a lot of time and effort but I have big ideas, so.... :)
Till next week,
Kristie