[Bf-gamedev] UI; Improvements and Customization

[Colin Knueppel]

Thank you Jason and Brecht. It's encouraging that it seems some of what I
was hoping for can be done as the program stands.

To Brecht, I've been slogging through this very long audio dialogue about
the Blender UI.
https://soundcloud.com/andrew-price/episode-11-jonathan-williamson
Part way through, Williamson describes a drawing program that cloned much
of photoshops core functions and hotkeys, and used it to gain many early
adopters. They also discuss how many users used the maya presets to first
get introduced to Blender.

>From my perspective, as an animation lead, I have to consider who I can
hire. I might find some talented Blender users, but the vast majority of
people that apply at Unknown Worlds are these days Maya users, and still a
good few that are Max. For new hires and contract workers we bring in, we
need them to be able to jump right into production. We do not have much
loose cash to train people up. So, in our studio, if we adopted Blender, it
would be very beneficial if we could implement keys and layouts that laid
out tools and conventions similar to the other major packages.

To a great extent what you describe, key shortcuts, adding panels, tool
shelves, and making these easy to share, are really what I need. If I can
put the tools and the familiar hotkeys for a new hire all front and center,
the new hire can get to work with minimal knowledge. They'll have issues,
but it won't be showstoppers.

Now, if the new function allowed us to also load into our panels custom
scripts, we could get clever and also load pertinent trait sliders and make
some common buttons to aid artists. It might not be fancy at first, but it
could lead to some streamlined blender environment designs within a studio
over time.

Finally, to reiterate a point,
It would be important that these environments be easy to load and save.
With developers, you're rarely talking about a single knowledgeable user.
You're usually dealing with at least a few, and each with varying technical
aptitudes. In today's studios, you might also be working with people across
the globe who may work at different hours or with some language barriers.
The process of sharing these customizations needs to be extremely simple,
so that's why I'm asking for the ability to save and load these
configurations.



On Thu, Oct 10, 2013 at 4:25 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> 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
> >
> _______________________________________________
> 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/dcf45050/attachment-0001.htm