I've been watching ship building videos and seeing very similar patterns between them independent of user experience. What I'm noticing is a lot of time spent with navigating the UI. My background is partly in user experience (UX) so I'll approach it from there, and I'll try to keep this compact. UX in general for our purposes can be broken down into:
1. Mouse movement (distance between clicks or drag operations and total distance to complete a desired action)
2. Mouse clicks
3. Scrolling
4. Typing
Ideally you record someone using the ship editor and then for various actions try to minimize the above such that common actions take as little movement, clicks, and scrolling as possible without making the experience convoluted.
For reference, the ship editor:
Currently users start by moving the mouse to the far left tree, clicking to open folders (multiple clicks) and/or scrolling up and down (quite a ways) then clicking parts to pull them into the editor. (They can also search, but this requires typing and its own delays). This whole process takes around 5 to 30 seconds in practice each time because navigating to a part puts the tree in a new state at a possibly different scroll position. (Navigating from one part to another part is not a fixed delay and depends on where they're located in the tree). That said users are learning to duplicate (even navigating around to find a part they already used to duplicate it) rather than navigating the tree, so there are workarounds. I digress, onto solutions:
Hotbars
Add a hotbar system into the UI. Basically allow users to drop a hotbar square into the tree. This could be created from the Toolbox. Users would click on a "create hotbar item" and drag one onto the screen. Hovering over the new hotbar item would have a tooltip with "Drop part here to create shortcut or hold to move". Dragging hotbar items would snap to other hotbar items and the edge of the screen. An example of ad-hoc hotbar placement:
By default the developers would setup a hotbar layout that fills the peripheral UI with common parts. Users would then customize this for their own preferred layout.
Hotbars eliminate most navigating to the far left of the display, clicking folders to expand them, and scrolling. (If you want to learn more about mouse movement look up Fitt's Law). The big picture goal is hotbars reduce the distance moved and offer a consistent box to aim for. (In my example I used 48x48 pixels with a 2.5 pixel border). The other added benefit is users learn where items are in contrast to scrolled trees which create inconsistent hitboxes forcing the user to scan the tree while moving the mouse. The big picture is hotbars allow for one mouse move and one click for parts versus a lot more mouse movements, scrolling, and clicks for the same part.
Extending Beams and Plates
My next suggestion is related to reading text, scanning lists, and estimating distance. All of these actions have an inherent delay. (Also humans make mistakes when measuring distance which causes its own delays). This is prevalent when watching users select beam lengths and plate sizes. What if most of this could be removed?
A possible solution is to allow users to click on the snap points of any beam and extend it into a new beam or grow an existing beam. The goal would be that building a ship doesn't require a user to drag and drop beams of a fixed length into the editor. This removes delays caused by selecting the wrong beam. An example implementation would be the user drops a beam into the editor which selects it. At the ends are an orange square that when dragged grow/shrink the beam. On the faces around the beam at the snap points would be new beam magenta squares that when dragged creates new beams. Refer to this drawing:
This also scales if diagonal beams are added later. You'd just have magenta squares on the edges where dragging would create a diagonal beam:
Rectangle plates would function similarly with grow/shrink squares. The user could drag and drop a plate into the editor put it in place then click the drag squares to quickly fit it.
Conclusion
All of these additions reduce the amount of movement for the mouse and number of clicks. You aren't dragging, rotating, snapping, etc beams or plates as often and accessing parts from hotbars means common parts are quick to pull in. Anything I missed or changes that would make common actions even faster?
1. Mouse movement (distance between clicks or drag operations and total distance to complete a desired action)
2. Mouse clicks
3. Scrolling
4. Typing
Ideally you record someone using the ship editor and then for various actions try to minimize the above such that common actions take as little movement, clicks, and scrolling as possible without making the experience convoluted.
For reference, the ship editor:
Currently users start by moving the mouse to the far left tree, clicking to open folders (multiple clicks) and/or scrolling up and down (quite a ways) then clicking parts to pull them into the editor. (They can also search, but this requires typing and its own delays). This whole process takes around 5 to 30 seconds in practice each time because navigating to a part puts the tree in a new state at a possibly different scroll position. (Navigating from one part to another part is not a fixed delay and depends on where they're located in the tree). That said users are learning to duplicate (even navigating around to find a part they already used to duplicate it) rather than navigating the tree, so there are workarounds. I digress, onto solutions:
Hotbars
Add a hotbar system into the UI. Basically allow users to drop a hotbar square into the tree. This could be created from the Toolbox. Users would click on a "create hotbar item" and drag one onto the screen. Hovering over the new hotbar item would have a tooltip with "Drop part here to create shortcut or hold to move". Dragging hotbar items would snap to other hotbar items and the edge of the screen. An example of ad-hoc hotbar placement:
By default the developers would setup a hotbar layout that fills the peripheral UI with common parts. Users would then customize this for their own preferred layout.
Hotbars eliminate most navigating to the far left of the display, clicking folders to expand them, and scrolling. (If you want to learn more about mouse movement look up Fitt's Law). The big picture goal is hotbars reduce the distance moved and offer a consistent box to aim for. (In my example I used 48x48 pixels with a 2.5 pixel border). The other added benefit is users learn where items are in contrast to scrolled trees which create inconsistent hitboxes forcing the user to scan the tree while moving the mouse. The big picture is hotbars allow for one mouse move and one click for parts versus a lot more mouse movements, scrolling, and clicks for the same part.
Extending Beams and Plates
My next suggestion is related to reading text, scanning lists, and estimating distance. All of these actions have an inherent delay. (Also humans make mistakes when measuring distance which causes its own delays). This is prevalent when watching users select beam lengths and plate sizes. What if most of this could be removed?
A possible solution is to allow users to click on the snap points of any beam and extend it into a new beam or grow an existing beam. The goal would be that building a ship doesn't require a user to drag and drop beams of a fixed length into the editor. This removes delays caused by selecting the wrong beam. An example implementation would be the user drops a beam into the editor which selects it. At the ends are an orange square that when dragged grow/shrink the beam. On the faces around the beam at the snap points would be new beam magenta squares that when dragged creates new beams. Refer to this drawing:
This also scales if diagonal beams are added later. You'd just have magenta squares on the edges where dragging would create a diagonal beam:
Rectangle plates would function similarly with grow/shrink squares. The user could drag and drop a plate into the editor put it in place then click the drag squares to quickly fit it.
Conclusion
All of these additions reduce the amount of movement for the mouse and number of clicks. You aren't dragging, rotating, snapping, etc beams or plates as often and accessing parts from hotbars means common parts are quick to pull in. Anything I missed or changes that would make common actions even faster?
