[scribus-dev] Properties palette renewal

[Gregory Pittman]

On 04/28/2014 02:52 AM, "Christoph Schäfer" wrote:
>> Gesendet: Sonntag, 27. April 2014 um 15:01 Uhr
>> Von: "cedric.gemy at gmail.com" <cedric.gemy at gmail.com>
>> An: "Scribus Development Mailing List" <scribus-dev at lists.scribus.net>
>> Betreff: [scribus-dev] Properties palette renewal
>>
>> 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
> 
> Salut Cedric,
> 
> I'm currently finishing the result minutes for LGM, so here's a summary:
> 
> We'll probably follow a mix of XPress (7+) and GIMP with some ingredients of LibreOffice, Calligra, Adobe CS, and an extra option.
> 
> This means:
> 
> 1) Users can select the displayed dialogue of the (then former) PP from a menu or select a relevant dialog from the Context Menu of an item.
> 
> 2) As in XPress or GIMP, they can attach other dialogues of the former PP to the current dialogue as well.
> 
> 3) More or less as in LibreOffice, they will be able to dock a (combined) dialogue to the right or left side of the screen (so the UI works as in Adobe's products, CorelDraw or Calligra Office).
> 
> 4) For future versions we need to decide whether we want an option to attach and dock dialogues horizontally (as per the Preferences) to adjust to different screen resolutions/display ratios.
> 
> 5) The "Text" tab of the current PP is probably the biggest UI mess of all, and it demonstrates that the approach used by XPress, InDesign and earlier Scribus versions, namely using a horizontal layout, which is separate from the other PP items, should be reconsidered. No decision has been made on this issue.
> 
> 6) We all agreed that the dialogues need to become much smaller. Craig has already added some experimental code to 150svn that helps to address this issue, but it isn't ready for use yet.
> 
> This is, of course, no complete reply to your message, only a summary of the LGM discussions.
> 

One thought I have about Properties and its subtabs is that it is very
inefficient to click a tab, then a subtab, and then maybe a sub-subtab
when all you was to do is click some button (toggle).

I wouldn't call it a hard and fast suggestion, but generally items in
Properties ought to be things that involve selecting from a drop-down
list or a spinbox setting. Otherwise, maybe they can be pulled out of
Properties altogether. In the text tab, there would still be too many
settings even if you completely pulled it out for its own palette.

Greg