[Soc-2013-dev] Weekly report #4 UI Replay

Sat Jul 13 16:03:34 CEST 2013

The evaluation report has been moved from the wiki to my own website as the wiki wasn't the right place for it: 
https://ack-err.net/static_media/gsoc2013/toolbar_evaluation_rev_02.pdf

I've also added some sketches I made, perhaps they could get a bit of a discussion going: 
https://ack-err.net/static_media/gsoc2013/toolbar_sketches_rev_02.pdf

The plan for next week is to make more elaborate mockups.

Vincent

On Saturday, 13 July 2013 at 09:14, Vincent Akkermans wrote:

> Hi David,
> 
> Thanks for your feedback.
> 
> On Friday, 12 July 2013 at 22:13, David Jeske wrote:
> > On Fri, Jul 12, 2013 at 8:31 AM, Vincent Akkermans <vincent at ack-err.net (mailto:vincent at ack-err.net)> wrote:
> > > http://wiki.blender.org/index.php/User:Ack-err/GSoC_2013/Toolbar_Evaluation
> > > 
> > > Because that evaluation report is quite lengthy I'll be short here. Comments and thoughts are most welcome.
> > 
> > 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. 
> > 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.
> 
> Text is linear, one's reading of it ideally isn't. 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. 
> 
> There isn't yet a conclusion as to what should be done. That's what I hoped to discuss here. The next step would be to come up with design recommendations, after which concrete designs can be iterated.
> 
> I'd also like to point out the first line in the report: "The goal of this evaluation is to produce design considerations and recommendations for a redesign of the current toolbar (depicted in Figure 1).". 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. 
> 
> The "Glossary" is not a definition of terms, it is the framework on which the evaluation sits. 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.
> 
> > 2) I don't see the clear orthogonality you imply exists between "object-based" and "tool-based".
> 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. Perhaps tool-centric and object-centric would be a softer way of putting it.
> 
> > 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"
> Ok, will amend.
> 
> > 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
> Ok, fair enough. I'll add an example per definition so it can be related to the toolbar.
> > 
> > 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. 
> "It is included here because of its clean presentation of lists of properties."
> 
> 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.
> 
> In the discussion:
> 
> "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."
> 
> > 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. 
> 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.
> 
> If you don't like the narrative style I can change that, but that seems like nitpicking. 
> > 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. 
> 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.
> 
> 
> I'd like to hear your thoughts on the points I bring up for discussion:
> The toolbar could make better use of horizontal space, especially given that vertical space is scarce. 
> Scrolling should be reduced, perhaps by making the foldable panels into an accordion. 
> Better visual representation of hierarchical organisation would make it easier to scan the categories. 
> 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. 
> 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. 
> The tool shelf would be a better home for adding objects than the menu bar of the info editor. 
> 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. 
> 
> 
> 
> Vincent 
> _______________________________________________
> Soc-2013-dev mailing list
> Soc-2013-dev at blender.org (mailto:Soc-2013-dev at blender.org)
> http://lists.blender.org/mailman/listinfo/soc-2013-dev
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2013-dev/attachments/20130713/725c3b00/attachment.htm 