[Bf-gamedev] UI; Improvements and Customization

Thu Oct 10 21:02:19 CEST 2013

I created this to send to the commiters group. I don't believe they
accepted the proposal for viewing. I'm posting it hear to see developer
response. Rather than making it a UI discussion, I've framed it as a
feature. I'm curious if the reasoning is compelling?

It would be a great feature for developers to have the ability to easily
load layout, interface preferences and panel scripts with one file.

By allowing these three things to be modified by one file, it allows the
whole environment to be customed to particular tasks. This makes creating
environments to speed new workers into Blender possible. Also, by making it
as easy as one file to load, it becomes practical for a studio to deploy
over multiple workstations or to satellite workers. Additionally, it
encourages sharing, which may allow studios to collaborate on tools and
other panel innovations.

Practical example:
Say we hire a modeler that's very familiar with ZBrush. In preparation for
their arrival, we get to work on the environment they will use. With the
layout, we remove timeline and other general use panels. We then recreate
the left, right, top and bottom bars you'd see in many art programs. We
create subdivisions in those sidebars and populate them with a script that
calls graphical icons and ties them to blender functions. We custom some
panels to show material representations of the current sculpting brush.
Another panel to custom the Brush behavior. Other panels to show the
various brush presets you can select from, and so on. We then go into the
user interface and mimic hotkeys from zbrush. When the new hire arrives,
she or he will be greeted with a somewhat familiar environment to get
started. He or she then can just get to work, losing little productivity
and getting them comfortable with some of Blender's great capabilities.

Now lets say that hire is used to retopology and UV Unwrap in 3dsMax. We
could go through a similar process, recreating the environment, hotkeys and
some tools. With the ability to easily load the environment, they could
swap back and forth between the function of modeling and the retopology and
UV Unwrap in one file with relative ease. Again, they'd lose less time
learning Blender, but get to appreciate the tool.

Let's say one year down the line, our artist is really digging Blender.
They've gotten deeper into the functions and they see potential for ways to
use the program like no one would have expected. With this feature, they
could innovate a new layout and tools with Blender. They could even share
that design with other studios or the community and enrich the program for
everyone, or impress other studios with the program's versatility.

On Tue, Oct 8, 2013 at 7:17 PM, Colin Knueppel <colin.k.work at gmail.com>wrote:

> But consider the process in total
>
> To follow the current system:
> User loads a file
> Saves the layout or tool
> Loads new file
> Selects that new layout or tool
> If user has custom keys for task, they need to load those as well
>
> Compare that to:
> Load a UI, presets and all
>
> Each task in the current circumstance is not hard, but it amounts to
> needing explanation. Any user can understand the load UI, as we all know
> how to load files. However, with the current system, many users would need
> to be walked through the reasoning and steps to implement any new layout or
> custom tool.
>
> Consider this process from a studio standpoint. We create a suite of tools
> and layouts to address our various hires. We end up with 3 Maya based
> layouts (modeling, uv/rigging/texture, animation), 3 max based layouts, 1
> texturer focused layout and a couple compositing layouts (one to replace
> premiere). We have 12 workstations we want to deploy it to. Load 9 files
> across 12 workstations, saving out each layout and save interface presets
> where they can be easily loaded. Also, teach each user to access interface
> presets and what that means. Alternatively, hire a tech to create a
> deployment system (cost out of pocket and always trial and error).
> Also, with Unknown worlds, we employ people from literally around the
> world, Australia to Austria to England to US (east, middle and west) and
> for a while the Philippines. People aren't even functioning at the same
> time of day and often have some language barriers that cause hickups.
>
> Compare that to:
> Save the file. Send it to each employee. They then just load it.
>
> The current system isn't hard, but it's not without some logistical
> problems. The act of deploying becomes a burden. This discourages the
> practice.
> If you made the experience encapsulated within a file, it becomes
> something that people can simply share, use and learn from.
>
>
> On Tue, Oct 8, 2013 at 6:22 PM, Jan Albartus <albartus at home.nl> wrote:
>
>> Hi Colin,
>>
>> When you save a blend file the whole current screen lay-outs are saved
>> with it, including additional custom created lay-outs. You can clone the
>> current layout by pressing the + sign next to the drop-down list. This
>> will make sharing of lay-outs easier. Personally I find my self
>> resizing, splitting/merging and changing the window content as needed
>> during the use of Blender. I think this would cover most of the need for
>> save/load layouts.
>>
>> The lay-outs are listed alphabetically, but can be reordered by
>> (re)naming or numbering.
>>
>>
>> On 2013-10-09 01:04, Colin Knueppel wrote:
>> > After having a conversation with Albartus on Steam, I realize some of
>> > my idea exists in Blender, and that I need to describe how my idea
>> > differs and is beneficial.
>> >
>> > Blender currently contains a panel layout option. This is a good
>> > portion of what I was suggesting. It allows users to toggle between
>> > different workflows and creates decent customization.
>> > The next step of the feature would be adding save out and load in of
>> > layouts and organization options. Save out and load in inbuilt with
>> > the layout function would make sharing layouts easily done within the
>> > program. If I were to innovate a change in my layout, I could then
>> > simply save the desired layout and share over google chat with a
>> > coworker. It encourages mod'ability between users. With this ability
>> > to share comes the need for organization, as the number of layouts
>> > might bloat. Folder groupings could allow shared traits to be
>> > consolidated for ease of finding. If those folders could be toggled
>> > open and close, it reduces clutter. Folders may also allow saving out
>> > groups of layouts for fast deployment or portability of users between
>> > machines.
>> >
>> > The second step, now that you allow saving and loading as well as
>> > grouping of layouts, is to allow those layouts to also load interface
>> > options. Since we have the option now to have multiple layouts grouped
>> > and organized in an uncluttered and manageable way, you can now allow
>> > for more schemes and thereby more freedom with those schemes. Allowing
>> > users to also load preset interface options, like hotkeys, would allow
>> > individuals the freedom to figure out their own workflow that works
>> > best for their task. In a more practical application, as an employer,
>> > I could tailor the control system of my custom layouts to make
>> > teaching new employees Blender easier. For instance, I could tailor a
>> > texture layout that is reminiscent to photoshop users, and I could
>> > tailor an animation environment that's reminiscent to a maya user.
>> >
>> > Step three is adopting true mod'ability in the UI. This UI layout
>> > loading not only loads panel layout and interface presets but then
>> > also custom panels with their own scripts. This way, someone with
>> > adequate scripting knowledge could build their own user interface.
>> > They could create a toolbar, dedicate panels to certain tasks or
>> > whatever innovation they feel is needed. This would, for instance,
>> > allow an individual to repackage features in a streamlined fashion.
>> > Someone could create a sculpting UI, putting the tools most pertinent
>> > to the task in a dedicated bar with a dedicated window to brush
>> > presets. It might also open up innovation, like autoriggers built into
>> > the scheme. Tools programming could be democratized and shared, and
>> > Blender devs could use it as test beds for other innovations, too.
>> >
>> > These features would not supplant existing UI, but be an additive
>> > system that works with classic Blender. If someone wants a classic
>> > feature in one of these custom UIs, they need only drag out a division
>> > and populate it with the classic tools they desire. If they do not
>> > like the hotkey scheme, they can set them back to default and resave
>> > the layout. It allows classic power users to keep the program as they
>> > like, but then gives enthusiasts and production companies the ability
>> > to tailor the program to their needs in a share'able way. (Be a mighty
>> > nice feature for Steam Workshop..)
>> >
>> >
>> > Albartus did voice a concern about creating varying control schemes.
>> > If people do not use a common key set, could confusion hinder
>> > adoption? I cannot answer that, but I ask an opposing question.
>> > Wouldn't opening the UI to share'able modding create further user
>> > enthusiasm for the program? I believe the potential for innovation is
>> > more powerful than the concern of uniformity, and I know if this
>> > feature existed, at least some of us indies would adopt the program
>> > and pool together to get the most out of the feature.
>> >
>>
>> _______________________________________________
>> Bf-gamedev mailing list
>> Bf-gamedev at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20131010/90bb0c44/attachment.htm 