Hi Oliver,

better late than never :-) Sorry...


Oliver-Rainer Wittmann - Software engineer - Sun Microsystems Inc schrieb:
Hi Jacqueline,

(...)

- page 4, line 34: Scrollbars become visible in the fields dialog,
if needed. I suppose, that the dialog is not big enough to show the
 headings in proper way, even if tooltips are implemented. I tried
to visualize how it looks like if we have 4 or more levels (see
screenshot http://projects.ooodev.org/qa/crossreferences.jpg). The
feature will be used in large documents with many headings and
levels. Is it possible to implement the dialog resizable?

We also notice this usability issue.
As far as I know resizable dialogs aren't possible in OOo. We also
thought about the width of the selection list box. But, because the
other panes of this dialog uses the same respectively a similar layout, we didn't want to confuse the user.
A colleague has made the following suggestion:
type:        format:
+----------+  +----------+  name
|          |  |          |  +----------+
|          |  |          |  +----------+
|          |  |          |
|          |  |          |  value
|          |  |          |  +----------+
|          |  |          |  +----------+
+----------+  +----------+

selection:
+--------------------------------------+
|                                      |
|                                      |
|                                      |
|                                      |
|                                      |
|                                      |
+--------------------------------------+

Then, we keep the three columns from the other panes and we got a big
list box for the selections.

Yes, this is a possible solution. As you already mentioned, an argument against this structure of the dialog could be the consistency to the other panes.

An alternative could be a similar design to the pane "database". I would prefer, if the boxes for type and selection are placed in the first row, to get the focus on the most important parts in the correct order: First I choose the type, then I choose a reference and after that I choose a format.

In the above example we have this order, this could be confusing:

1    3    4

          5

2

What about that:

type:         selection:
+-----------+  +-------------------------+
|           |  |                         |
|           |  |                         |
|           |  |                         |
|           |  |                         |
|           |  |                         |
|           |  |                         |
|           |  |                         |
|           |  |                         |
|           |  +-------------------------+
|           |  format:        name
|           |  +-----------+  +----------+
|           |  |           |  +----------+
|           |  |           |  value
|           |  |           |  +----------+
+-----------+  +-----------+  +----------+

This example would allow this order:

1    2

     3    4

          5

This is also not the best solution, I suppose. May be it would be helpful to ask the ux-experts.


- page 7, lines 85: Every bookmark will get a name with a unique
number: Is the number unique only in each single document or could
two documents have accidentally the same bookmark name? Avoiding
this would be important, if cross references are used in
subdocuments of master documents.

The unique number will be something, that is calculated from the current date and time plus a random number. It will be assured that it is unique in each single document. I figured out, that there are already problems with normal bookmarks in subdocuments of a master document:
- create sub document one with a bookmark named "Book" and a reference
to it.
- create sub document two with a bookmark named "Book" and a reference
to it.
- create a new master document and insert the two create subdocuments.
--> the bookmark of the second inserted sub document is renamed to
"Book1". But the reference in this subdocument still references bookmark
"Book". This is a defect. This defect can also be reproduced with a text document by including the sub documents as linked sections.

I think, we should submit an according issue and solve it separately,
because it affects already existing functionality and will not be
introduced by the direct cross-references to headings and numbered
paragraphs.

Ok, understood.


- page 7, line 88: Again master documents: Bookmarks are only
internally used and bookmark names aren't shown in the user
interface: Will there be a chance to find out the bookmark name?
This would be helpful, if cross references are used in master
documents between two subdocuments.

Currently, it isn't planned to make these bookmarks visible in the user interface of the Writer. But, you can find these bookmarks in the
OpenDocument file format.
Why do you need access to these bookmark names?
If you have a masterdocument containing sub documents with headings and numbered paragraphs, these headings/numbered paragraphs can be
referenced by the new functionality.

In fact, there is no real reason to make the bookmark names visible. I only had in mind, that there are problems with equal bookmark names in subdocuments of masterdocuments (your example above) - at the moment I can see my "own" names and see, where exactly the problem is. But if the possibility is small, that this happens, we don't need visible names.

Regards,

Jacqueline

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  • [sw-disc... Jacqueline Rahemipour
    • Re:... Oliver-Rainer Wittmann - Software engineer - Sun Microsystems Inc
      • ... Jacqueline Rahemipour
        • ... Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems
          • ... Ian Laurenson
            • ... Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems

Reply via email to