<div><span style="font-size: 12px;">The evaluation report has been moved from the wiki to my own website as the wiki wasn't the right place for it: </span></div><div>https://ack-err.net/static_media/gsoc2013/toolbar_evaluation_rev_02.pdf</div><div><br></div><div><span style="font-size: 12px;">I've also added some sketches I made, perhaps they could get a bit of a discussion going: </span></div><div>https://ack-err.net/static_media/gsoc2013/toolbar_sketches_rev_02.pdf</div><div><br></div><div><span style="font-size: 12px;">The plan for next week is to make more elaborate mockups.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Vincent</span></div><div><span style="font-size: 12px;"><br></span></div>
<p style="color: #A0A0A8;">On Saturday, 13 July 2013 at 09:14, Vincent Akkermans wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>
<div><span style="font-size: 12px; ">Hi David,</span></div><div><span style="font-size: 12px; "><br></span></div><div><span style="font-size: 12px; ">Thanks for your feedback.</span></div><div><span style="color: rgb(160, 160, 168); "><br></span></div><div><span style="color: rgb(160, 160, 168); ">On Friday, 12 July 2013 at 22:13, David Jeske wrote:</span></div><blockquote type="cite"><div>
<span><div><div><div dir="ltr"><div>On Fri, Jul 12, 2013 at 8:31 AM, Vincent Akkermans <span dir="ltr"><<a href="mailto:vincent@ack-err.net" target="_blank">vincent@ack-err.net</a>></span> wrote:<br><blockquote type="cite"><div><div><a href="http://wiki.blender.org/index.php/User:Ack-err/GSoC_2013/Toolbar_Evaluation" target="_blank">http://wiki.blender.org/index.php/User:Ack-err/GSoC_2013/Toolbar_Evaluation</a><br>
</div><div><br></div><div><span style="font-size:12px">Because that evaluation report is quite lengthy I'll be short here. Comments and thoughts are most welcome.</span></div></div></blockquote></div><div>
<br></div><div>IMO, the biggest opportunity for improvement is that the report ordering is upside-down. This report should be written as "a. What should we do? THIS!" -> "b. Background on why? This is why." .. It would be nice to read your thoughts and conclusions without reading lengthy terms and observations about software packages (some/all) of us already know. </div></div></div></div></span></div><div><span><div><div><div dir="ltr">
<div>I recommend starting with "what is the toolbar used for" "goals for the toolbar" and "key opportunities and comparisons" (from the review of tools). This way we will immediately know what your goal is, and what tangible thoughts and recommendations you have so far. Only after that you can append Background and Glossary.<br></div></div></div></div></span></div></blockquote><div><br></div><div><span style="font-size: 12px; ">Text is linear, one's reading of it ideally isn't. </span><span style="font-size: 12px; ">I intend to add an abstract or summary is at the start, but the report isn't finished yet so it would be silly to write it now. I'll also add a little menu at the top (if anchors are possible) so that the structure of the text can be readily seen, and it is easier to skim and skip. </span></div><div><span style="font-size: 12px; "><br></span></div><div><span style="font-size: 12px; ">There isn't yet a conclusion as to what should be done. That's what I hoped to discuss here.</span> The next step would be to come up with design recommendations, after which concrete designs can be iterated.</div><div><br></div><div><span style="font-size: 12px;">I'd also like to point out the first line in the report: </span><i>"The goal of this evaluation is to produce design considerations and recommendations for a redesign of the current toolbar (depicted in Figure 1).".</i> <span style="font-size: 12px; ">I understand you are keener to move to the actual recommendations and start talking about designs (so am I), but this is an evaluation, not a design document. </span></div><div><br></div><div><span style="font-size: 12px;">The "Glossary" is not a definition of terms, it is the framework on which the evaluation sits. </span>It helps to introduce concepts into the discussion and also a way of thinking for those that aren't familiar with UI design and usability.</div><div><span style="font-size: 12px;"><br></span></div><blockquote type="cite"><div><span><div><div><div dir="ltr"><div>
2) I don't see the clear orthogonality you imply exists between "object-based" and "tool-based".</div></div></div></div></span></div></blockquote><div><span style="font-size: 12px;">I'll give this a little bit more thought to see if I can make it clearer, or if there is perhaps an underlying dimension that would be clearer. I don't think I imply orthogonality though. I'll amend to make that clearer. </span><span style="font-size: 12px; ">Perhaps tool-centric and object-centric would be a softer way of putting it.</span></div><div><span style="font-size: 12px;"><br></span></div><blockquote type="cite"><div><span><div><div><div dir="ltr"><div>3) In "modifier stacks" you twice use the word "application" as if applications are either 100% or 0% modifier stacks. I recommend changing this to "parts of applications" or "modes of interaction"</div></div></div></div></span></div></blockquote><div>Ok, will amend.</div><div><br></div><blockquote type="cite"><div><span><div><div><div dir="ltr">
<div>4) I think many of the opening "definitions" sections would make more sense if put in the context of "goals of the toolbar", rather than listing abstract toolbar characteristics</div></div></div></div></span></div></blockquote><div>Ok, fair enough. I'll add an example per definition so it can be related to the toolbar.</div><blockquote type="cite"><div><span><div><div><div dir="ltr">
<div><br></div><div>5) I'm no expert on Apple Motion, but your description of the object-properties system there sounds more like Blender property-sidebar-transform and Blender properties-editortype object-transform and modifiers -- than the Blender Toolbar/Operator panel. The net-result is that I don't follow your observation about how Motion's property system leads to fewer tools -- or how it might apply to blender. </div></div></div></div></span></div></blockquote><div><i><span style="font-size: 12px;">"</span>It is included here because of its clean presentation of lists of properties."</i></div><div><br></div><div>I think I state that there are fewer tools because it isn't an application that is very tool-centric, not because of its presentation of properties. Blender's operator redo panel is a list of properties as well, and so we can learn from how lists of properties are presented and interacted with.</div><div><br></div><div><span style="font-size: 12px;">In the discussion:</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;"><i>"The operator redo panel could follow the design of Modo and Motion, whereby labels and widgets are not interspersed vertically. Labels would sit on the left, and widgets on the right."</i></span></div><div><br></div><blockquote type="cite"><div><span><div><div><div dir="ltr">
<div>6) The narrative description of Modo's choice to use "edit and confirm" semantics for operators, and your trouble with them, are a bit unnecessary except maybe in a rarely read appendix. </div></div></div></div></span></div></blockquote><div><span style="font-size: 12px;">You don't say why they're unnecessary. I find it an interesting paragraph because it shows how such a similar application and such a seemingly small change in interaction style can cause the interaction to become modal. Also, I cannot describe the functioning of Modo's toolbar without pointing that out. It is arguably a more important property of Modo's toolbar than the visual representation of it. For example, there would ideally be a way for Modo's toolbar to show the active tool somehow (after having changed tabs), whereas this is not necessary in Blender. It is also a consequence of using tabs to organise lots of buttons, and if that option is considered for Blender, then this modal interaction should be avoided. That's hard to do if it hasn't been noticed this could be a problem.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">If you don't like the narrative style I can change that, but that seems like nitpicking. </span></div><blockquote type="cite"><div><span><div><div><div dir="ltr">
<div>7) "scrolling is evil" is not a factual or appropriate statement in a report like this. You mean something like "scrolling creates challenges". However, your next words are flawed because we can not talk about challenges of scrolling without talking about an alternative solution to the problems it addresses. <br></div></div></div></div></span></div></blockquote><div><span style="font-size: 12px;">I'll amend to make it more objective. You seem to say my words are flawed because I'm not discussing an alternative to scrolling? That doesn't seem logical. My next words are characterisations of scrolling without relating it to alternatives. Therefore they would still be true even if no alternative existed. One could say that, if there were no alternatives, the section would be superfluous, but saying there are no alternatives is unfounded and therefore it isn't.</span></div><div><br></div><div><span style="font-size: 12px; "><br></span></div><div><span style="font-size: 12px; ">I'd like to hear your thoughts on the points I bring up for discussion:</span></div><div>
<ul><li><i> The toolbar could make better use of horizontal space, especially given that vertical space is scarce.
</i></li><li><i> Scrolling should be reduced, perhaps by making the foldable panels into an accordion.
</i></li><li><i> Better visual representation of hierarchical organisation would make it easier to scan the categories.
</i></li><li><i> Horizontal space could be used better by showing the
appropriate short cut next to the button's label. This way the buttons
could also act as a shortcut cheat sheet.
</i></li><li><i> Sparing use of icons (e.g. an icon per group) could make
scanning a long list of buttons easier. One would want to avoid creating
long lists or grids of icons as they would become hard to distinguish.
</i></li><li><i> The tool shelf would be a better home for adding objects than the menu bar of the info editor.
</i></li><li><i> The operator redo panel could follow the design of Modo
and Motion, whereby labels and widgets are not interspersed vertically.
Labels would sit on the left, and widgets on the right.</i> </li></ul></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Vincent</span></div>
</div><div><div>_______________________________________________</div><div>Soc-2013-dev mailing list</div><div><a href="mailto:Soc-2013-dev@blender.org">Soc-2013-dev@blender.org</a></div><div><a href="http://lists.blender.org/mailman/listinfo/soc-2013-dev">http://lists.blender.org/mailman/listinfo/soc-2013-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>