[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Ideas for VPL
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-04-07 6:56:37
Message-ID: 200504062356.37199.sequitur () easystreet ! com
[Download RAW message or body]

On Wednesday 06 April 2005 08:45 am, Paulo Moura Guedes wrote:
> Hi,
>
> One of the thinks I always missed in WYSIWYG editors in general was lack of
> control. I always end up editing the source directly.
> In order to workaround this limitation I have some ideas that I would like
> to share, that go in a sense of directly manipulating the structure of the
> document.

That's the heart of the challange. We don't want to force users to go there.
>
> The document structure pane would be a building block in VPL edition (and
> who knows also in source?). For example, it would allow a precise selection
> of the nodes which is impossible to do in the VPL view. We could implement
> a shortcut to this, like shift - 2 clicks and 3 clicks (this in VPL view)
> that would select a node and all nodes at the level of the clicked node,
> respectively (I know Jens doesn't like standard double clicking as one
> can't tell the limits of a word :p).
> We should also allow other operations in the document structure pane like
> drag&drop (in the pane itself and to the VPL view also) with options like
> copy, move and cancel; removal of selected nodes and the insertion of tags
> (like in the toolbars) as child or next sibling of the current node of the
> document structure.

The problem with what you're saying is that you are now beginning to think 
more in the mode of what happens internally and how to expose this well for 
users. That's not inherently bad, but it's a shift that misses the point of 
VPL. Right now we have the Attribute Editor which enables a fair amount of 
power and overcomes some of the initial limitations of VPL. It is good for 
compensating for current design limitations and it is good that it exposes 
what is underneath to users so the whole thing is not so obscure.

What is bad about the Attribute Editor and the Structure tree from the 
standpoint of VPL is two things.
1) It's not really an organic representation of the document structure but an 
abstract representation which does not really weight the elements.
2) It does not physically integrate with the visual representation.

Even making the structure tree more interactive with the document, which I 
personally like, is not going to make in substantially more visually 
integrated.
>
> The document structure should be showed by default when VPL mode is
> selected, as it would be a fulcrum part of all the process. It should also
> be made more easy and intuitive to look at, by presenting the user options
> like using an icon instead of the tag text and setting a description, tag
> text,  icon; the option of setting the visible depth of the tree and some
> other things that an artist mind will surely think of.
>
> Feedback and suggestions are welcome.

I agree with Jens that we can't make it show by default. For one thing it 
would really alienate some users looking for a simple solution. It's very 
natural for you because now you are thinking in terms of nodes. We need to 
think in terms of visual interaction organic to the document.

This model has been discussed and there are several key factors.
1) Visual feedback for elements of a document. 
2) Direct manipulation of elements.
First of all, your observation of the problem with WYSIWYG solutions is 
fundamental to their approach. They don't have the foundational architecture 
we do and typically they also want to accomplish some different goals and 
focus on a different mind set. It's this approach that causes compromises we 
don't want that cause us to want to take control. What we have is a new 
problem of how to create the interface to our desired level of control that 
is possible with our foundation in VPL.

For instance when working in a div or table having some visual feedback like 
an outline showing that area is useful. However how to do this is a good 
question. Should we make this user configurable? When working with a div it 
should be possible to inspect it's properties. Should we have mouse overs 
feed a data inspector panel? Editing properties should be natural and this 
means context menus. Coming back to the div that means float, anchor and 
move. How about enabling drag positioning of absolute positioned divs?

There are a lot of questions to go through to find the right solutions and the 
assurance that it is complex and diverse enough that it will take some effort 
to get there... and of course not everyone will agree. ;-) I know it's lame 
but I've said this before...

Think about what's good about XHTML, CSS and PHP. Now think about what's good 
about a word processor. Now think about how web sites are constructed. The 
word processor is a simple and well understood interface, but the paradigm 
does not make a perfect visual web page developer because web sites aren't 
letters or brocheres. The ideal visual tool will use the power of good site 
design principles while being as much like a text processing tool as 
possible. So this also makes templates and CSS design important in VPL.

Eric
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]