[Bf-taskforce25] Explorability concerns for our UI

[joe]

Basically I meant we should make things more discoverable, but not at
the expense of efficiency, yes.

Joe

On Thu, Jun 18, 2009 at 5:19 AM, William Reynish<william at reynish.com> wrote:
> Hi Joe,
>
> Oops, I managed to write a rather long mail here.
>
> When talking about ease of use or 'useability' in general, you can
> choose to either measure the quality of a given UI by looking at
> *efficiency* and *discoverability*.
>
> Depending on which of these you focus on, you'll reach different
> conclusions on whether a UI is good or bad. But these aren't
> opposites. Sometimes a more efficient solution is also more
> discoverable. (Discoverability also relates to familiarity, as more
> familiar interfaces will be easier to discover and understand.)
>
> For example, through consistency you get something that is both more
> efficient (because you can utilize muscle memory and routine) and more
> discoverable (because it is more familiar to the user).
>
> Also, with simplicity, a user interface will be easier to understand,
> and generally faster to use, because it means users have to worry
> about fewer parameters, or go through fewer steps to reach a certain
> goal.
>
> Many of the new UI features that have been developed for 2.5 seek to
> improve both parameters, by organizing information in a more
> consistent and logical way, so that users can actually predict and
> work out where things are. This was one of the most terrible things
> about the old UI - it was a mess! Additionally more non-modality also
> makes it faster, because of more smooth workflow.
>
> So, things are already getting a lot more discoverable.
>
> Take for example the new search tool in the top bar. It makes it
> really efficient to search for and bring up a tool super quick, yet
> also helps a new user who may think 'I'd love to smooth out this
> mesh'. He or she can now simply search for 'smooth' and get at the
> tool in question without having to wade through menus and buttons to
> find a certain feature. This is great, especially because it is really
> simple, which means you can predict what it will do. Users can
> understand the purpose.
>
> Now, of course, there is still some way to go before we have a
> completely ideal UI.
>
> In terms of discoverability, I think the bottlenecks are not really
> the tabs in the buttons window - they are fairly clear and their usage
> is quite obvious.
>
> This post by a first time user (using 2.4x) gives a quite nice look
> into what a fight it is for beginners to get started with Blender, and
> how utterly unhelpful our application really is:
>
> http://www.blender.org/forum/viewtopic.php?p=67273&highlight=#67273
>
> Sometimes I think it would be healthy to remember that this
> application is not only used by ourselves, the few developers and
> hardcore Blenderheads, but also by thousands and thousands of people
> around the world who don't have time to suffer though confusing and
> illogical UI's when all they want is to create stuff.
>
> One thing that may be interesting is to define a bar, saying this is
> what users need to know to be able to use Blender. When new users (I
> prefer not to use the term 'newbies') ask questions on BA.org, they
> often get this standard answer back: 'Read the fucking manual'.
>
> Should you really have to read through hundreds of pages to use Blender?
>
> I do think that it's OK to require some previous knowledge to be able
> to use it, and get quite far with it, namely what you can explain in a
> 10-15 min video. I think having a video (somewhere really easy to
> find. On the front page on blender.org, or linked to from inside the
> application on a welcome screen - not hidden on a third party web
> server) that explains the basics of Blender. View manipulation,
> translation, finding your way around the UI, creating simple objects
> and modifying them, rendering out a tiny animation. I'd in fact love
> to do this, closer to 2.5 release.
>
> We can then in a fair way require new users to watch that video. It
> also means we know exactly what a completely new user knows, and what
> to expect from them.
>
> So really I think the true bottlenecks in Blender's UI are a little
> deeper than the tabs in the buttons window, or the basic view
> manipulation hotkeys or translation. In 2.4x it was a major bottleneck
> with the *contents* of the buttons window which was laid out in the
> most hideous and confusing way. Hopefully this will no longer be the
> case. Now I think the major bottlenecks are:
>
> -Tools. Many tools have previously been dumped in the W-menu which is
> really just a dump for things no one bothered to think through
> properly. And of course the famed blocking workflow that will
> hopefully get more attention before 2.5 is released.
>
> -Preferences. Most new users would want to immediately find the
> preferences to set up the app in a way they see fit. It is impossible
> to find and completely hidden.
>
> -Lack of good help/Useless tooltips. Blender's tooltips often just say
> what the button label says - how is that even remotely useful? For
> example the Ray Tracing tooltip in 2.4x was 'Enable Ray Tracing'.
> Great. Wiki help page is alright in that anyone can easily help out
> making it, but it's a little hard to navigate and search for help.
> Perhaps a way to get information about a specific feature could be
> added within the application? Right-click on Ray Tracing -> More Info -
>  > page about ray tracing in the wiki.
>
> -Really confusing nodes system for materials and textures. The way
> material nodes relate to materials make me cry, because I get so
> confused by it myself. Not really a 2.5 target to improve this, I
> know, but some time after that, this is an area that needs love.
>
> -Generally feature bloat. All features in Blender will be defended by
> someone saying 'I use this!' so it's almost impossible to remove
> features once you've already added them. That's why one has to be a
> little careful when adding tons of new stuff (especially hacks, even
> if <insert open movie project> needs a feature before it's released!).
> For example the Auto-Keying Mode, and PR buttons in the timeline. Is
> it really useful? Or is it just more pointless stuff to learn? Also
> the 300 FFMPEG settings ;)
>
> -Feedback. Using a console to communicate important information to
> users isn't optimal. Instead an info area in main header can clearly
> communicate what the app is doing, or about to do if a users clicks
> current button.
>
> -OS integration. I still can't even copy text from the text editor and
> paste it into any text editor here on OS X. Not sure about other OS's?
> Oh wait I can - but hotkey is alt-C. Why? I also can't access the
> b.blend file because it is hidden (OS X doesn't really support viewing
> hidden files unless you are a UNIX wizard.)
>
> One of the things that I think would be a good idea, is to do more
> user testing. Commercial apps do this a lot, and they have to because
> they need to be able to sell their software. We don't have the same
> motivation, but even so. I don't buy the argument the 'Blender is only
> for Blender users, therefore we shouldn't care' - it's a little too
> elitist for my taste. As makers of open source software we should be
> more inclusive than that.
>
> Cheers,
>
> -W
>
> On 18 Jun, 2009, at 5:25 AM, joe wrote:
>
>> What with all the UI discussion going on, I think we're forgetting
>> about explorability.  While explorability isn't vitally important, I
>> think we can and should improve this quite a bit for 2.5.
>>
>> Some points I can think of off the top of my head:
>>
>> 1. We may want to consider have the buttons window tabbar display the
>> names of the tabs.
>>    This would probably require a multilevel tab bar, and of course we
>> do have tooltips, so it may
>>    not be necassary.
>> 2. Pie menus; if we have them, we can create nice contextual menus
>> that almost (or as) fast as
>>    hotkeys, muscle-memory wise.  Even better, they could be defined
>> by python, and people could
>>    write custom menus (like they do in maya).  I think this would
>> allow some hotkey popups to be
>>    clearer (e.g. wkey could become a nested menu, with e.g. verts,
>> edges, faces submenus).
>> 3. I think it'd be a good idea to use pie menus for the header menus;
>> I know this is nonstandard
>>   as hell, but I really, really hate long header menus (in any app),
>> *especially* when there's submenus.
>>   If we're going to use pie menus anyway, why not get the benefits
>> for header menus as well?
>
> That would be nice, but to be honest pie menus work best when there
> are only a few options in the menu. Pie menus are super efficient when
> you have between 2 and 8 options. With more than that you can't
> predictable make gestures that are precise enough. Doesn't mean it's
> not possible, but it would need some reorganization.
>
>
>
>> Those aren't all points for explorability, but I think they are
>> related, and would allow a more explorable UI (e.g. using pie menus
>> allows putting everything in header menus, without the pain of deeply
>> nested menus that e.g. I hear 3ds max has).
>>
>> Joe
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>