[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic