[Bf-interface] Workflow workshop, agenda topics and preparations
Jaggz H
jaggz.h at gmail.com
Sat Nov 19 20:36:34 CET 2016
I'd like to add some topics for the outline (and discuss in dedicated
threads). I'm introducing them more verbosely than should be placed in the
outline.
1. *Settable position of Pop-up Menus (and mouse-out delay)*
2. *Easily-assigned keyboard macros (vim-like?)*
3. *The potential for temporary setting of operator features/options
(macros may suffice)*
4. *Registers (for many things, including macros)*
*Details:*
1. *Settable position of Pop-up Menus (and mouse-out delay): ...*So
on-screen keyboards can be used by those with disabilities (or touchscreens
only) without the kb overlapping the menu. (This likely entails a
user-settable position, and a mouse-out delay or a click).
2. *Easily-assigned keyboard macros* (vim is my model for this -- a key
to record or set the macro, followed by a letter to which the macro is
assigned, and something to play it back).
3. *The potential for temporary setting of operator features/options.*
Examples: When you're repeatedly moving items in a chosen transform
orientation (say, shift-ZZ), each move requires g<shift>zz</shift>. which
quickly magnifies the amount of keypresses needed Temporarily allowing the
zz restriction so only g is needed is one option. *Macros are a
potential alternative to this, if the options/features are accessible by
the macro.* This would also be usable for features like
insert-edge-loop's "even and flipped", etc.
4. *Registers:* Like the vim-method of macro recording, lettered (or
numbered) registers can be used to store the assignment of:
1. Macros
2. Cllpboard items (store objects in lettered clipboards)
3. Selections (instead of using vertex groups, the selection can be
recorded to a register)
4. 3D cursor positions
5. Viewpoints (instead of cameras)
6. Fields: Values in fields in various locations can be saved to a
register by mousing-over and hitting the record key, followed by
the letter
to assign it to. [Semi-globally] a keystroke, followed by the
letter, will
set that field back to the recorded value.
On Fri, Nov 18, 2016 at 5:20 AM, Paweł Łyczkowski <pawellyczkowski at gmail.com
> wrote:
> My take on agenda could look like:
>
> 1st day: Since UI in big part visual, and during discussions it's
> difficult to show how ideas work (one has to describe), I would make the
> first day talks with access to the projector. Topic of talks would be
> directions one wants to push. There's 9 participants, so there should be
> enough time for 1h per participants - 45 min talk, 15 min
> questions/clarification/quick opinions. That is - if everyone participating
> requests a talk (by mail, during next week).
>
> That would be a warmup day, with time between it and the 2nd day to digest
> the ideas.
>
> 2nd day: Discussion day. Since UI talk can go off the rails very quickly
> the discussion should go topic by topic, from a predefined list. So,
> something like Bastien proposed. That's my rough take:
>
> - Paradigms and general direction
> - Blender 101
> - Discoverability and help (tuts/tooltips/documentation)
> - Screen layout and general GUI
> - Layer Manager [2] and Outliner
> - Modifier list [6]
> - Brecht Bar [3]
> - Screen Layouts, editing modes and tabs (including Topbar Tabs [5])
> - Sidebars (customizing sidebars)
> - General customization (hiding parts of GUI?)
> - Display Settings - UI vs new viewport
> - Workflow
> - Data handling (fake user and data loss, asset management)
> - Multi-mesh editing/UV mapping
> - Setting properties of multiple objects
> - Container objects [4]
> - UDIM
> - Texture Painting (layers?)
> - Snapping and Proportional Editing
> - How operators work, how tools work [1]
> - Interaction
> - Keymap, especialy keymap core (mouse buttons, navigation, selection)
> - Keymap editor and it's issues
> - Widgets
> - Pies
> - Sticky Keys
> - Add-ons
> - Code related discussion
>
> And, most important:
> - Priority (It's probably inevitable that there will be more ideas than
> 2.8 can handle. We should decide on a couple of items that are top priority
> then)
>
> 3rd day: Decisions announced by module owners and working on concrete
> solutions (or at least drafts). Here breaking into groups would be good I
> suppose, with at least one dev (that can mock up prototypes in realtime
> maybe?) per group.
>
> Let me know what you guys think.
>
> Cheers,
> Paweł Łyczkowski
>
> Additional reading:
> [1] - https://wiki.blender.org/index.php/Dev:Ref/Proposals/
> UI/Tools_Workflow and https://developer.blender.org/T37554 - Tools
> Workflow by William Reynish, https://docs.google.com/document/d/
> 1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit#heading=h.xira9p9pbv78
> - Adding Tool Mode to Operators by me
> [2] - https://developer.blender.org/T38384 - Layer Manager proposal by
> me. https://wiki.blender.org/index.php/User:Julianeisel/
> GSoC-2016/UI_Design - Julian's Layer Manager doc
> [3] - https://wiki.blender.org/index.php/Dev:Ref/Proposals/
> UI/Top_Bar_Reshuffle Brecht Bar by Brecht
> [4] - https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-
> NLs5weQKLkjqmgpA/edit#heading=h.k20w9k3djv7c - A Container type object by
> me.
> [5] - https://developer.blender.org/T39835 Topbar Tabs by Julian
> [6] - https://developer.blender.org/T38178 Modifier List
>
>
> On Thu, Nov 17, 2016 at 11:58 AM Bastien Montagne <montagne29 at wanadoo.fr>
> wrote:
>
>> Hi,
>>
>> Disclaimer: I’m starting fresh from initial mail again, since I’ve seen
>> mails going already in way to much details, imho (Sebastian… ;) ). My
>> point being: topic is way to broad and complex to be discussed in a
>> single thread, would make it impossible to follow. So I propose to keep
>> this thread only for the topics definition, and planning/agenda (in
>> other words, the schedule of the workshop). For further detailed
>> discussion of a topic or another (like, keymap, various types of
>> customizations, 101, etc.), please start new (or use existing) threads.
>>
>> So, here is first draft of how I’d see things for the weekend:
>>
>> - Day I & II: Tackle each topic, from both sides:
>> -- "Usability" side: Reconfirm existing UI/UX paradigms, check if
>> we need to make some of them evolve, and define new needed ones.
>> -- "Technical" side: Based on designs laid out by usability
>> discussions, check what needs to be changed/extended/added to our UI/WM
>> code (not thinking about tiny implementation details here of course).
>> - Day III: Would keep it 'empty', can think of several ways to use it:
>> -- Potentially extra time to finish discussion on some topics if we
>> ran out of time in first two days.
>> -- Handle unforeseen topics, questions etc. that may have arose
>> during workshop.
>> -- Maybe spread in smaller groups to refine work on some specific
>> topics.
>> -- Write/review first draft of final reports (though most of this
>> work should be done in days after workshop, of course)?
>> -- ...
>>
>> Some more organizational notes/questions (we do not want to be too much
>> formal, but think agreeing on that could be useful and save time):
>>
>> - Do we want to work in a single big group, or several smaller
>> groups? (personally, I would say one single group for first two days,
>> imho it’s important that everyone has minimal knowledge of all topics'
>> discussion, even if not directly interested to actually work on it. Then
>> more freedom for the last day… ;) )
>> -- If we go for several smaller groups, we could agree on the "at
>> least one artist and one dev in each group" rule?
>> - Do we accept talk? If yes, how long should they be at most?
>> (personally, would keep them short, maybe as introduction of some
>> topics, think we mostly need lots of discussion to agree on designs)
>> - ...
>>
>> And now, the topics (I put them in a hierarchy tree, that’s obviously
>> somewhat subjective, also probably have forgotten many points… and it
>> does not mean branches are not related to each other!):
>>
>> - UI/UX
>> -- Do we need new UI widgets? Extend/Rework some existing ones?
>> (also thinking about proposed talk from Paweł, here)
>> -- Do we need to extend or modify some interactions with operators
>> (modal ones? heavy computations ones?)?
>> -- Review recent new UI features (custom manipulators and pies
>> mainly), how to use them in “default” Blender and not only as optional
>> new things?
>> -- ...
>> - Customization
>> -- Do we agree on the need to have a place in UI where artists can
>> dump random settings and operators?
>> --- If yes, how to do it (position? with tabs? with panels?
>> floating or not? etc.)?
>> -- Make macro operators part of customization possibilities?
>> -- ...
>> - Workflows
>> -- What is part of/defines a workflow?
>> --- keymaps?
>> --- UI items (panels, menus, ...) - i.e., exposed/visible tools
>> and data/settings?
>> --- Custom manipulators?
>> --- Screen layout?
>> --- Visualization settings (like different draw modes in
>> viewport…)?
>> -- Do we replace (mostly viewport) modes (edit, sculpt, paint etc.)
>> by workflows?
>> -- Do we reuse/extend existing workspaces (screens) feature as
>> workflows, or do we keep them separated? Or do we keep workflows inside
>> single space area?
>> -- ...
>> - Blender 101
>> -- I see it as a specific workflow, roughly, should we use it as a
>> kind of guinea pig of workflow project?
>> -- ...
>> - Code-related questions
>> -- Is custom spaces part of/needed for this project (custom spaces
>> would be definable from py, similar to how panels or UIList work
>> currently)?
>> -- Do we need to rework the notifications system?
>> -- ...
>>
>> Again, this is own first draft (based on previous mails and own
>> knowledge), most likely forgot or overseen many things… You are more
>> than welcome to add, move, remove, comment, suggest, whatever (even to
>> say this is complete piece of trash ;) )… But please, let’s keep this
>> thread onto agreeing on organization/agenda/topics points, and *not*
>> about detailed topics' content discussion/proposal/etc., really think we
>> should keep this into separated threads (like the one already started by
>> Mike regarding Blender 101).
>>
>> Also, we may end with too much for three days, we can always trim down
>> later and focus on biggest/most important topics first, leaving smaller
>> ones for online discussion, if needed.
>>
>> Cheers,
>> Bastien
>>
>> Le 06/11/2016 à 18:02, Ton Roosendaal a écrit :
>> > Hi all,
>> >
>> > The workshop will be here in Blender Institute, 25-27 November.
>> > Confirmed participants are:
>> >
>> > - Jonathan Williamson
>> > - Pablo Vazquez
>> > - Julian Eisel
>> > - Paweł Łyczkowski
>> > - Daniel Lara
>> > - Sebastian Koenig
>> > - Bastien Montagne
>> > - Brecht van Lommel
>> > - Mike Pan
>> >
>> > I'm very happy to confirm that we'll get additional development support
>> from Aleph Objects (Lulzbot 3D printer) to hire people for coding and
>> designing work. Work would be on '2.8 workflow' in general, but result
>> should lead to a release-compatible Blender version that's configured to be
>> suitable for kids or occasional users to make 3d prints. That's the "101
>> project" Mike Pan will be working on.
>> >
>> > In the coming weeks we should check on the planning for the workshop
>> days, the agenda, and do a lot of preparations. Hopefully we can discuss
>> and review existing proposals as much as possible.
>> >
>> > Let's throw random ideas in this week, then I come with a more
>> structured proposal by end of week.
>> > OK?
>> >
>> > Laters,
>> >
>> > -Ton-
>> >
>> > --------------------------------------------------------
>> > Ton Roosendaal - ton at blender.org - www.blender.org
>> > Chairman Blender Foundation, Director Blender Institute
>> > Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>> >
>> > _______________________________________________
>> > Bf-interface mailing list
>> > Bf-interface at blender.org
>> > https://lists.blender.org/mailman/listinfo/bf-interface
>>
>> _______________________________________________
>> Bf-interface mailing list
>> Bf-interface at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-interface
>>
>
> _______________________________________________
> Bf-interface mailing list
> Bf-interface at blender.org
> https://lists.blender.org/mailman/listinfo/bf-interface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-interface/attachments/20161119/c7e33aae/attachment-0001.htm
More information about the Bf-interface
mailing list