[Bf-gamedev] UI; Improvements and Customization

[Brecht Van Lommel]

Here's some feedback as a developer:

A lot of customization is already possible by creating a custom
startup.blend, along with scripts and addons that run on startup. It
may not be a single file but it shouldn't be difficult to add a few
files to the configuration folder, or even to distribute Blender with
the configuration bundled?

There are some limitations in our user interface code though, that
make some types of changes impossible. Both addon writers and people
who want to customize Blender would benefit from work on the API to
make more customizations possible. And I think everyone agrees a
better toolbar with custom toolshelfs is a feature we should have.


However, personally, I think the challenge of making a complex
application emulate another application, or even making a task
oriented user interface, is underestimated. One reason is that I can't
remember any complex application emulating another in a satisfying
way. I've only ever seen it done poorly. Maybe you can link to some
examples where it was done well? In my experience, if you have to work
with a clone or restricted subset of some application, it's always
going to be frustrating.

If we talk about custom toolshelfs, key shortcuts, adding panels, and
making these easy to share, then I agree, that's a good idea. Beyond
that however, I'm a bit skeptical if anyone would actually invest the
time to implement and maintain that kind of thing, and get a result
that artists are happy with.


Brecht.


On Thu, Oct 10, 2013 at 9:02 PM, Colin Knueppel <colin.k.work at gmail.com> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>