[Bf-gamedev] UI; Improvements and Customization

[Colin Knueppel]

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/20131008/3381d11e/attachment.htm