Re: [kidsUI] Alfredo's idea

[Terry Hancock <hancock@earthlink.net>]

Alfredo Kengi Kojima wrote:
> 
> On Thu, 13 Apr 2000, Doug Loss wrote:
> 
> > Alfredo Kengi Kojima wrote:
> >
> > >
> > > - the text area is the white rectangle in the canvas. It would
> > > always have the "input focus", so that you dont need to
> > > first click on it to be able to type, as is common with
> > > most applications. I think it shouldnt be scrollable too;
> >
> > I agree about the scrolling. As to the focus, is it possible to make all
> > keyboard input go there automatically but keep the cursor (mouse pointer)
> > focus in the image area?
> >
> 
> Yes, I was thinking of making keyboard focus stay at all times
> in the textbox. The mouse cursor would not be able to take focus
> away from there, so you can move it anywhere.

The key point here is that the mouse controls the drawing & the
control buttons, but keyboard input always goes to the text box.
Right?

> > > - the scrollable area on the top of the canvas is where the
> > > pages of the book will be stored. Each page that has been
> > > drawn is stored there. To switch to another page you click
> > > in the desired one (a scaled down image of each page should
> > > be drawn on each of those squares representing the pages)
> > > There is always a blank, white page at the end of the list,
> > > so, to create a new page you just click there.
> >
> > I think the blank page should show as such, not just as an empty spot in that
> > area.  I think that's what you mean, but I wanted to be sure.
> 
> Yep, that's what I meant.
> 
> > > Im not sure, but
> > > maybe it would be good to remove the scrollbar from the
> > > page list, as it could be a bit confusing, but it would
> > > limit the number of pages possible (dont know if thats
> > > an important limitation). There also could be other ways
> > > of representing pages that dont fit there...
> >
> > When we think about those other ways, let's try to make sure they're general
> > ways of indicating that there's more information available than what can
> > currently be seen.  Could we do something like a frame around that section
> > that resembles the edges of a book, so you can see extra pages on the right
> > and left?  You could click on those edges to turn the pages.  That might be
> > easier for a child to understand than the concept of a scroll bar, although it
> > might require too much dexterity to use to be the best idea.
> 
> I have some difficulty to picture that. Could you do some quick mockup
> with some paint program to illustrate it?

Hi, the attachment shows a concept of this "scrollbar" with
a book-type look.  The only thing that bothers me about it is the 
"split-in-half" look of the book, but I think the meaning will carry.

One thing I've noticed, is that kids will pick up pretty quickly on
whatever symbol you choose, as long as they're distinctive.

> Another alternative would be to make the whole workspace look like
> the page of a sketchbook and allow flipping of pages when you click
> at some part of it. I didnt develop the idea much, as I think having
> a shrinked view of each page of the book readily visible is better..
> 
> > > - the box below the crayonbox would have some image-stamps.
> > > They would work as another tool, you click there and
> > > whenever you click on the canvas, it will 'print' the
> > > selected image. The button labeled "stamp box" would
> > > open a window with many more images. I think it could
> > > give a selection of stamp-sets, where the whole group
> > > of image-buttons would be replaced with the ones in
> > > the chosen stamp-set.
> >
> > This is also how I was thinking.  We should also have a button for backgrounds
> > analogous to the one for stamp box, that would allow the child to pick from
> > background images.> >
> 
> We'll have to change some stuff to be able to fit that in the
> window. Maybe there wont be enough space to put a selection of
> background buttons always visible, like for the stamps, so
> it will probably have to be a button that opens a dialog that
> shows you the available backgrounds for selection. I think that's
> not too bad, as I suppose stamping would be a more frequent
> action that changing backgrounds.

Make sure to use a dialog box slightly smaller than the screen, so that
it's clear that the storybook is still there.  Flipping to a new screen
and back sometimes freaks the kids out (they think they've lost their
work).

> > > - gray box at the right of the list of books is for administrative
> > > tasks, or creating new storybooks and loading old books. Saving
> > > would be performed automatically, whenever you load a new
> > > book or quit the application. Whenever you create a new book,
> > > it asks for a name of the story you will start. They would also
> > > have graphical icons, instead of (or in addition to) text.
> >
> > We should also have it offer a choice of icons for the story, so that when the
> > child wants to reload it he or she can see both the icon and the text.
> 
> Either that or we could use a shrinked view of some page of the
> book to represent it. Maybe the cover page of it.

Either is okay.  The icon approach is nice, because very young kids
will be making picture books only.

> > > The load dialog would show a simplified list of the stories
> > > by name and have a box with a preview area, showing a quick
> > > view of the contents of the story book. No directories, paths
> > > or anything.. Maybe a way to throw away a book would be good
> > > there. I'll try to make a mockup of this dialog later.
> >
> > The load button could have a bookcase icon.  When you click on it, the "shelf"
> > opens up and you can pick the book you want to work on.  The standard trashcan
> > could work to delete a book, so long as things could be recovered from it
> > (standard mark-for-deletion and purge behavior).  Perhaps we could limit
> > throwing books away to drag and drop from the shelf to the trashcan.  Then a
> > child would have to go to the bookcase, open the shelf, and get the book
> > before throwing it away.  This could limit inadvertent deletions, and would
> > have a relation to the physical actions that would accomplish the same thing
> > in the real world.
> 
> I think that's good.
> Btw, how easy for a child is drag and drop?

I recommend avoiding drag & drop. Instead, click at origin, animate
object
moving with the mouse cursor, then click to drop.  Real drag & drop
(with
the mouse button depressed) is a little confusing, but especially
requires
more coordination.

-- 
Terry Hancock
hancock@earthlink.net
http://home.earthlink.net/~hancock/index.html