[scribus-dev] Properties palette renewal

[cedric.gemy at gmail.com]

During LGM we have told we should work on the PP refactoring as fast as
possible. I apologize for being silent Duringing this time, but here i
am. So 3 bases :
1. Craig wishes : split PP in several palettes. Make those palettes
saving as space as possible. Am i right if i say very little palettes
that the user could drag to associate them in custom bigger ones (may be
a bit like in Gimp) ?
2. My old Scribus UI analysis which in my opinion is now very old, some
general idea could be take from it but usability change during that time
and Scribus too :)
3. our UI_IV_UI analyze from pasts years, which have to be reviewed

My opinion is that i'm OK with Craig's options :
- PP is too big : it cannot be displayed on some screens so we need to
find a way of making it smaller : splitting and having thin controls
might help both
- splitting will also help stop this boaring clickodrom with have made :
click everywhere to change a property. We should find a way to make
options more easily accessible for the user, make them thiner might help
displaying more at once, but might not be enough if there are always
subparts to click on. I would then be for avoiding those subparts as
much as possible.
- please, we should not fall in ID's situation in which there is so many
palettes so that non-professionnal are lost and that daily users still
click on the palette as we did in Scribus PP tabs. We might get inspired
from the ID properties top window, which condense many options for
frames and text in very little space.

That said there is still an amount of work. So i came back to old
documents in which we have written down our whishes

General wishes :
- we need to make each option type more visible : display Position as
option group or with separator
- shape on top of properties for frame conversion (mean img2txt,
txt2img, ... ? ie setting content type property)
- wouldn' it be better to have a lockXY button and and locjWHbutton on
the right of the fields
- We have line style that should be available from the PP
- so we keep a drop down list for colors ?
- Floating should have a quick margin field
- we miss stroke color and shade
 save more space :
- could rot and origin be placed at the right of WH
- If we write “Fill” and “Line”, do we need the icons.
- We could put an overprinting button on the right or at least the shade
value
- re-thing the way we display text styles
- when nothing is selected provide page properties (part of arrange
pages or not ?)


Concept - Current Properties Palettes
1. The Properties Editor is (normally) aligned to the right side of the
screen. It is necessary, that all properties can be handled even on
small screens, so the palette can not be too high.
2. The Properites Editor shows the properties for selected items.
3. We distinguish between Containers (Shapes, Polygons, Frames), Content
an Lines. Wouldn't line be parts of containers as they are same
properties as frame strokes
4. Content can be selected by doubleclicking the container.
//5. If a tool is selected, properties for this tool are shown (To be
defined).
6. Actually,  there aren't many tool options //so may be 5 is not so
important
//7. If no object is selected, and no tool is chosen, general (Page,
Document) properties are shown (To be defined) really good
//8. If several obkects are selected, align and distribute should be
displayed. We could do it for page to but we'd need some page handle
somewhere

Concept - Future
1. Palettes will certainly commonly be placed on the right of screen
which would mean vertical palette layout. But do we allow or do some
with horizontal layout ?
2. We should avoid clicks as much as possible : doing small palettes
could result in many clicks to activate them. We need to have as many
options displayed as posible
3. Make space saving palettes to help display more at once and provide
consistent layout and usability principle among palettes (which is
actually not really done in Scribus, each window having it's own way :
layer, PP, page...)
4. Provide a way to save the workspace (positions of palette) to provide
default layout (beginner, daily user, and allow user to do its own)
5. Workflow : display only palettes related to the selected item (would
mean hide some options on the fly and make user loose power on it),
there is always something selected, even page, so consider page as an
object
6. Content is selected by 2-click Container
7. avoid modal windows when possible : we have no reason to block the
user actions
8. make window available from the properties when possible (for example
: create an new color, a new style), avoid intermediate window if
possible (f.e. go directly to create color window without going through
the color manager) and avoid window if possible (create a style from
selection)
9. Python script should be able to create menu items or buttons in
windows to help having them at the better place and help integrate
interesting script in the scribus distribution i.e. don't provide the
user a technical approach but a work-driven approach

User interaction
================
we have to determine ho we want to user to interact among buttons,
contextual menu and window menu
actually PP only has buttons and options, if we do palettes, do these
palettes have a menu (like in gimp but unlike Inkscape, ID has both)
if palettes have buttons for actions, do we display buttons at bottom
(like ID or Gimp) or not. For general options, how could it be done
another way ? for actions related to an options wouldn't it be better to
have the button the nearest to that option. But this would result in
having lots of button : imagine the paragraph style with button on each
style line (but we already have this for layer options). Should we
consider Options =/= actions
Help the user work faster (in helping avoiding mouse movements)
 - Another options we have told about with claudia : having more options
displayed on canvas. Scribus already have it : resize frame, link tool.
We could imagine having there some image options on image frame. This is
may be the future : Gimp does this for text tool, and this is going to
be general on the web through CreateJs integrated in ckeditor and other
online editor
 - Have a better shortcut model. This is may be easier than the previous
list item. But actually Scribus provides shortcut to menu entries and
that nearly all. User should be able to access or modify options through
shortcut. If i want to review my text and set heading style, i don't
want to click the text, go to palette, click the style then go another
frame, and go back to palette. This is especially important for text for
which there are so many polishing work : designer often use shortcut to
change font, font-size, kerning...
 - Avoid unneeded or unwished action => go directly to wished action :
already told about this on 8. above.
 - a bit different because not so much on UI : provide frame styles (we
already have wand tool but don't provide updates), and manage splitted
document (we often need to split document because of scribus slowness
and it can be a big deal synchronizing page numbers, master page and
style on the files).

Keep Consistency
================
- actually windows are not all designed the same way. We should take
care not doing this for the new palettes
- provide the same options the same ways : for example text palette
should display the same options as style manager (if it survive)

Defining palettes
=================
palette size (especially width) :
palette margins :
font-size :
button size :
button icon size :
button icon color set :
default options size : spinbox, dropdown...
provide several size layout via preferences that could allow some users
to have smaller or bigger palettes


Items with different Properites:
some shapes arcs, spirals, ...
what do we do of :
- groups
- drop shadow
- table and cell : they are both container so consider as frame in the UI

We actually have 2 options :
- make as little palettes as possible with few options, like ID which
sometimes have only one displayed :(
- make medium palette that will have all the options related to an
object or content. This, in some way, keeps current scribus concept of
few palettes, but can result in some large palette too especially for
text. we also would need those palette to be context sensitive and
display only the available options for the selected object. In this case
how to we manage the screen layout : floating palettes, A above B, side
by side : A left to B?

i've already been promoting the idea of having at least 2 palettes :
- Container palette : we could find here page settings (if not in
arrange pages) and frame/line settings, place for align-distribute on
multiselection, may be some shaper properties for some special tool
(arc, polygon...) [well we have to find a limit !!]
- Content palette : text options, images options...

I don't know if it matches other members. If some want to ive their
mind, i guess it's time to. I've put this text on this pad
http://piratepad.net/WkhmFqjdn1 to help us see it clear.

cheers
Cedric