The concept remembers me to photoshop, as seen here: I like the idea of an onboarding screen, where the user can choose options what he wants to do. There's no way for the software to know which was the "real" old colour - the colour before the slider change, or the colour after the slider change but before the value change - so the "old" colour doesn't have any real meaning. Imagine you move a slider and change a value to get the new colour. NOTE: If the Colour Palette was non-modal - and therefore all adjustments were made "live" - there would be no need for an "Old/New" display. That would do me fine and dandy, for now anyway. (See the very crudely-made attached mock-up.)īasically, combine the two dialogs, make the combined dialog non-modal and change its orientation to vertical. I would suggest making it a thin vertical strip which could be docked to the side of the main window without getting in the way of what the user is doing. If this new Colours Palette was a wide window - as in some of the examples supplied - it would take up too much screen space if it was constantly open. If I could leave this "Colours Palette" open and make adjustments on-the-fly it would make Scribus so much more easy to use and could even help to bring new users in as it's more what they are used to in other applications. the same as the Layers palette - then editing colours would be made so much more simple. If the two dialogs could be combined and that combined dialog was made non-modal - I.e. Having to open a modal dialog and then another within that to edit a colour and to OK them both before seeing what a colour change actually does is a real pain, and can add many more clicks than is necessary. It's the colour editing functions that I have a problem with and my main problem is with the modality of the dialogs. It could be improved but I think any changes in this area would make for a far larger change that is necessary and might have too many existing users complaining. Things could be moved around a bit but the method of selecting a colour is relatively easy to understand for beginners and not a huge problem for experienced users. I don't have any real problem with how colours are selected via the PP. A lot could be done to improve colour selection/editing but I think some basic changes would make a big difference. In the interests of simplicity - and to avoid the alienation of existing users - I would suggest that, at first, the UI isn't changed too radically when it comes to colour selection/editing. That will be a big rock, but it is dueable.īTW: this UI updates can be make independently of the IndigoDock integration, because it will work in the current Scribus user interface too. remove clutter in text editing section (focus on most important settings, all other stuff are advanced settings for a second level) styles (gradients, color sets, paragraph styles, character styles, table styles) I think it is not posible to replace only one "feature" with a new one without updating another one, because all is releated - more or less.Ībout the scope I think we can focus at first for property panels (content and frame) and connected features. If you have specified problems you can solve it. I think to get valuable user feedback is the hardest part in UI-Design. All the feedback here is very helpful to understand how Scribus will use and where are the biggest painpoints / frictions in UI.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |