[sugar] Write Activity.

[Eben Eliason]

Hello -

> We have almosts all the features requested in libabiword for this. The
> only one currently missing is rotating the image, but this should not be
> too hard to implement.

Another note on the image:  the rightmost icon in the image toolbar is
a "toggle caption" button.  I don't know if this is already supported
or not. It should auto-format the image with the appropriate padding
and provide an area beneath it for adding caption text, automatically
placing the cursor in the caption area. Optionally, the rollover for
this button could have a checkbox for "treat as figure" or something,
automatically numbering the figures in a document.

> What is the time frame for implementing this?

We're working on getting an API together for the controls in the near
future as well.  It would be better if development ran parallel to the
creation of the necessary controls so that work doesn't need to be
redone to incorporate the proper widgets later.  It also depends
heavily on an API for tabbed toolbars, which isn't yet available.

> I notice that undo/redo is only available for text, whereas all the
> manipulations shown in the mockups can be undone/redone. Does it make
> sense to provide undo/redo for all toolbars or even on the menu bar?

Actually, the undo/redo buttons reside inside the "Edit" toolbar,
which isn't specific to text at all.  They should map to anything at
all that sits in your changeRecord stack.

> Do you intend that different toolbars are automatically changed upon
> context? For example, if a user clicks on an image, does the toolbar
> change to "image" automatically?

Absolutely.  This is one of the key ideas behind this toolbar design,
which hopes to virtually eliminate the need to switch editing contexts
via the tabs themselves.  Clicking on an image, table, or within text
should automatically select the corresponding toolbar.  Selecting text
inside a table cell, or inside a caption should likewise select the
text toolbar.

> Regarding "insertTable", I think our little inserttable widget which lets
> the user interactively size the dimensions is easier and more intuative
> than selecting x and y dimensions.

The numbers here represent the number of rows and columns in the
inserted table, not the dimensions of the table itself.  I'm not
familiar with your current functionality, though, so it would be great
to see that.  Also, these dimensions would be set to some default
(like 3x3) and only appear on secondary rollover.  They wouldn't be
required; clicking on the button directly would insert a table with
the default (or last set) number of rows and cols.

> Regarding the table toolbar, there are two entries shown with "100" and
> "24", which appear to be size in percent of the width of the page of the
> horizontal and vertical dimensions. Is that correct? I wonder if these are
> neccessary? It seems a rather esoteric idea to young children. The width
> an heights of the columns can be adjusted by dragging the column and row
> seperators on screen.

This is true;  It's not strictly necessary.  The general idea behind
these controls is that I might want every row to be twice as tall as
the default, and there's no good way through direct interaction to
tell a bunch of rows to be the same size.

> In there place you might want to provide buttons to merge and split cells
> horizontally and vertically.

Interesting point.  I hadn't really considered merging and splitting
necessary for most use cases, but perhaps people use that more than I.
 I'm open to this if people agree that this is a needed feature.

> Regarding the page margins, could you clarify how you would like this to
> be displayed on screen? Currently we suppress the top, bottom, right and
> left margins to get the maximum amount of text on screen. To show margins
> we go into what we call "print view" which is what the text will look like
> once printed. Given this, do you intend for write documents to be printed?
> If so should we enable printing for Write?

Well, we're certainly not designing with printing in mind.  We expect
that most content with be both created and consumed digitally.  For
that reason alone, even if we have such a preview we should certainly
not use "print preview" to describe it.  It could be the case that we
don't need margins at all, though the format bar certainly has the
room for it, and I personally see margins as a design tool just as
relevant for digital content as for printed material.  Since the view
toolbar provides a way to zoom in and out, if we keep margins perhaps
a specific zoom level could be something to the effect of "tight fit"
without margins...

> Thanks very much, it is an interesting design and it's nice to a get a
> direction.

Glad you like it; sorry for the delays.  We've been spending
considerable time on nailing down the look of the controls and the
toolbar interface itself.  Please feel free to critique it, offer
suggestions for a slightly altered feature set, etc.  It can certainly
evolve from here.

Finally, here are a few issues that aren't addressed in this design
that we may need to add later:

1) Annotations. We hope to provide an annotation system for crossmark
documents so kids and teachers can write notes "in the margins" of the
pages.  It would be ideal if both read and write had consistent
implementations for this in the UI.  The general idea at present is to
have a small (45 px wide) gutter in the left margin of the activity
which contains a heat map of sorts for each block of text, indicating
how many annotations it has.  Clicking in the gutter could reveal the
annotations and allow for editing or creation of new ones.

2) Headers.  Since everything is digital, the crossmark spec focuses
on headers - just like wikis - instead of pages as the primary means
of navigation.  Since the reader will support dynamic TOC generation
and navigation, it seems only natural that the write activity provide
a means of creating (and navigating by) these headers.

3) Crossmark editing. Since the goal is to use crossmark as the
underlying format, it would be nice to be able to expose the crossmark
source for a document, perhaps with a toggle button under the view
toolbar.  Additionally, one should be able to input crossmark
directly.  There are two interesting ways we could make this work
across the views.  We could have a crossmark interpreter of sorts
which would take a string of text typed with asterisks as in  *bold*
and automatically render it as bold when in formatted view.  Also,
when in crossmark view, it would be great if all of the tools (insert
table, insert image, add row, etc) still worked, but worked by
inserting the proper crossmark markup directly.

- Eben