[Bf-taskforce25] Explorability concerns for our UI

[William Reynish]

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