[Bf-taskforce25] User Preferences Mockup and Suggestion

[Rob Cozzens]

It seems like the only alternative to a floating window is taking over an
existing view... I can't stand that!There are certain tasks that make sense
for floating windows (dialogs): loading/saving, color pickers etc. and I
think preferences is one of those cases that makes sense with a dialog.

The non-overlapping paradigm makes sense for windows that you need to have
open all the time for you workflow. Anything that's going to pop-up
temporarily could be a floating window IMHO.

-Rob

2009/4/1 Brian Staub <brian.staub at yahoo.com>

> hi Brecht.
>
> i was hoping that a design based on my mockup would be able to scale based
> on the content, so if new options and sections are added the Pref Pane would
> expand accordingly.  I was hoping the upcoming Auto Layout Code could handle
> something like this.  Would Python be able to create the Pref Pane as it
> appears in the mockup without having to create a new Window Type in the core
> code?  (please excuse my ignorance, i'm not a coder and don't understand the
> difficulties).  i think having Prefs as a standard Window is rather
> obtrusive, having to resize windows and whatnot to change a Prefs setting,
> even if it's Automatice.  not to brag, but i think this is an excellent
> solution, and maybe worth a new Window type if Python can't compensate.  In
> addition, it could be incredibly unintrusive if all windows remain
> responsive while the Pane is visible.  also in my design, i liked the idea
> of the Top Bar being absolutely stationary (not dragable), which provides
> consistency because you can always find those options, Prefs, File, Edit,
> etc. in the same place all of the time.
>
> thanks for any consideration.
>
> brian
>
> ------------------------------
>   my site-click here to visit <http://invertednormal.wordpress.com/>
> ------------------------------
> system specs:
> OS X 10.5.6
> 17" 'Unibody' MacbookPro, 2.66 GHz Intel Core 2 Duo w/ 6MB shared L2 cache
> on 1.07 GHz FSB
> 4 GB DDR3 SDRAM
> 128 GB Solid State Drive
> NVIDIA GeForce 9600M GT discrete graphics w/ 512 MB VRAM and NVIDIA GeForce
> 9400M integrated graphics w/ 256 MB VRAM, 1920 x 1200 native resolution
>
> ------------------------------
> *From:* Brecht Van Lommel <brecht at blender.org>
> *To:* The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
> *Sent:* Wednesday, April 1, 2009 2:35:46 PM
> *Subject:* Re: [Bf-taskforce25] User Preferences Mockup and Suggestion
>
> Hi Brian,
>
> On Wed, 2009-04-01 at 09:47 -0700, Brian Staub wrote:
> > I've created a Mockup of how i think the User Preferences Pane would
> > work well (i'm not a coder, so this is just conceptual artwork)
> >
> >
> http://i307.photobucket.com/albums/nn291/bobStaub/preferencesPanelMockup00.jpg
> >
> > the idea is that when you click on the User Preferences Icon at top
> > left (or wherever), the Preference Pane does a "Shelf" Pull Down
> > animation like with some Mac OS X panes and the user gets access to
> > settings organized by tabs.  Other Panels/Windows are still responsive
> > (as to not interfere with non-modality) and the Preference Pane stays
> > open until user hits Escape (or whatever assigned hotkey), presses the
> > 'X', or presses the Preferences Button again which is highlited when
> > active.
> >
> > ...and there's a full screen shot, too.
> >
> >
> http://i307.photobucket.com/albums/nn291/bobStaub/preferencesMockupFlat00.jpg
>
> The idea at Wintercamp as I remember was that user preferences would be
> an editor like any other, in particular like a buttons window.
>
> There are a few reasons for this. First is that it is consistent and
> doesn't introduce a new type of window, we just do the same thing as the
> buttons window.
>
> Second, using panels means we can easily add more options. With the
> fixed layout as in the current user preferences and in your mockup,
> after a while it becomes difficult to add more settings without
> rearranging, and then you get a mess quickly. With panels it's easy to
> add something at the end, or add a new panel.
>
> That still doesn't provide a good answer to where the window should
> appear, replacing an existing editor often gives strange results. With
> overlapping you don't have that problem, but it also goes against the
> non-overlapping paradigm...
> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/UIParadigms
>
> > on another note, has it been decided what the max resolution will be
> > for icons?  since Jendrzych has a handle on the low res icons, I
> > thought i might try my hand at a higher res set.
> >
> > here's an icon i helped Jendrzych with
> >
> http://i307.photobucket.com/albums/nn291/bobStaub/shrinkwrapModifier7_00.png
> >
> > and for my own set at a higher res for the Shrinkwrap, i came up with
> > this quickly
> >
> > http://i307.photobucket.com/albums/nn291/bobStaub/shrinkwrap32px_00.png
>
> I think the attitude on this is, we'll wait and see if they are needed
> and what they are needed for. If they are added that will be as a
> function of some interface element that needs it.
>
> We currently have icons mostly for data types and settings. It's not
> clear where bigger versions of those would be used? For operators in a
> toolbar bigger than current headers they could be needed, but we don't
> have icons for operators currently, and there will be thousands of
> operators? We don't have a good answer to these yet I think, it will
> depend on design decisions that are not taken yet.
>
> Brecht.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090401/fb3aab9c/attachment.htm