Kepler UI Discussion: Archived Comments

STATUS

The content on this page is outdated. The page is archived for reference only. For more information about current work, please contact the GUI Group.

Overview

Comments on the Kepler UI from Dec 2005-Jan 2006.

Comments

Comments from Shawn Bowers made Dec. 18th, 2005:

Note: I noticed none of the usability pages have a spot for comments -- but they probably should.

Given the above, it is not clear why the design is "better" -- it would be great to see not only the proposed design but also a short description of (1) what invidual items require a change; (2) what criteria justifies each individual change; and (3) how the specific change solves (2).

The current issues are fairly high-level, e.g., "unify visual language" and "improve readibility". Also, it isn't at all clear how the current design solves these problems ... and why the particular design was chosen over others that may solve these high-level problems. The "professionally designed graphics" case seems like a non-issue -- and doesn't fit with the others. In particular, it is not clear what actual problem this solves, and instead sounds like a solution not a rationale.

Also, now that I'm looking at the teal/yellow color scheme I think there may be a problem. In particular, the use of the yellow "folder" colors for both datasets and for the actor library categories may be confusing -- and visually "off." For one, the use of the same icon to represent data and categories seems to suggest some similar functionality ... when in fact, they represent two very different things. Second, I have never quite been sure why the data symbol is a folder. It seems like a more standard symbol would be a cylinder "disk". It might be useful as well to make a change to the color of data versus the color of the folders in the actor lib. I would actually argue as well for changing the symbol of the folder icon in the actor library as well, since these seem to suggest file folders, which they are not.

I also think that it is great to have some color palettes. But, I think the current palettes and their mapping to symbols is too limiting. I would like to see more variation in the use of color within Kepler, especially for actors. I think initially there was some discussion about this -- which has never been addressed -- that has to do with the trade-off between extreme uniformity and extreme heterogeneity. For large workflows, and when comparing different workflows, too much uniformity makes these look overly homogeneous, i.e., it becomes difficult to quickly understand overall organization and function. This issue becomes especially problematic for comparing two similar, but slightly different workflows -- my concern is that they will be essentially indistinguishable, making this important task extremely difficult for users. The current design does not seem to address these issues at all.

Also, I think that a potentially better color (than teal) to achieve uniformity would be white (with a black border) for actors, as opposed to a solid teal background. I personally don't "like" teal as a color -- others "love" teal. I think few people have such feelings about black and white. The point is that we may literally turn people off to kepler simply because they have particular feelings and emotions associated with the color ... (it sounds silly, but it is true -- it is strange aspect of human nature). Besides white, I think primary colors may be better -- but again we get into a "touchy feely" area. Diversity of color can also solve this problem, which is currently what ptolemy uses.

Comments from Matthew Brooke made Dec. 20th, 2005 - In response to Shawn's request that I comment...

In General Terms:

I consistently see recurring themes in User Interface design discussions, and have gradually come to the conclusion that many of these themes are the result of a disconnect between the way graphic designers, usability designers and software developers all perceive the issues. Since I tend to overlap all 3 areas ("jack of all trades, master of none" ;-), I can see the validity in opinions from all sides. Please bear this in mind while reading the following comments, because I am not demeaning any particular group - I am just telling it as I see it. Also, excuse the stereotyping. When I say "graphic designers" I mean *most graphic designers, etc... :-)

=================================================

The major, take-away point I'd like to make is that UI design is a combination of:

1) usability testing & UI conventions
2) "logical" thinking
3) graphic design & touchy-feely emotional "stuff"

Remember that:

• No one item stands alone - it is always a combination of these things
• Item number 3 should never be under-estimated or dismissed out of hand. Graphic design is not science, and cannot always be analyzed, categorized or justified. It is, however, no less valid or valuable than scientific thought - it just has a whole different approach, which may be unfathomable to non-designers.

=================================================

To a large extent, the UI layout and functionality is determined by the "usability testing & UI conventions"; the "logical thinking" part comes into play more when we are dealing with UI situations for which a precedent has not been established. "Logical" thinking, in this context, is trying to predict and cater to the way the user will interact with the software - to make sure the app works as the user "expects" it to. Note that this is the not the rigorous logical thinking that developers and philosophers do. "Conventions" and "graphic design" can sometimes override cold logic, since ultimately, the UI is meant to appeal to "people", and "people" typically would not care that Directors in the actor library have the redundant word "Director" in their titles, whereas actors do not, for example. To we developers, that seems like a glaring inconsistency. However, consider how many of the successful commercial software packages have inconsistencies in the UI, or don't do things the way developers logically would. There are sometimes good usability reasons to include inconsistencies.

If users' abilities and visual preferences fit on some kind of normal distribution curve, then we are aiming at the peak. Software developers are outliers (and proud of it!), and it is hard for us to accept that we are not, and do not think like, "typical" users (even if we *think* we do). As Shawn pointed out, however, we need to define exactly who is near our distribution "peak" for Kepler, lest we aim at the wrong target...

Since Kepler/Ptolemy are quite unique, there are many cases where precedents have not been set, which is typically why many discussions have arisen. Discussions are a good thing, especially if all sides understand the "take-away" points above, and discuss accordingly. It is important that developers continue give feedback during these discussions, since UI people may not appreciate the intricacies involved (especially given kepler/ptolemy's functional uniqueness). It is generally a UI designer's goal to simplify, so developer feedback can help to ensure this simplification doesn't remove essential functionality.

Graphic design & touchy-feely emotional "stuff" is the item that I hear many developers underestimate or dismiss as unimportant. Paradoxically, it is also the issue that people argue about most, since everyone has a strongly-felt opinion. Visual language carries strong meaning (@see "semiotics"), and is intimately linked with the emotions (@see "fine art"). The most difficult aspect of being of a good designer is to detach from one's own emotional preferences and provide a design that is "good" - sometimes using colors or techniques that the designer doesn't personally "like", for the benefit of the design.

A whole Pandora's box is associated with what is "good" design (interesting view from a developer:). However, using formal design guidelines, an experienced designer can typically create a design that is judged by the majority of unbiased users as "acceptable". Developers (and some usability people) typically do not possess graphic design experience, nor do many have a knowledge of formal design guidelines, yet we feel that our opinions are just as valid. This is the reason that large, successful software companies hire trained professional graphic artists and usability experts to design their UIs, instead of asking their developers to do so.

Again, I am not trying to demean developers (since I am one). Most people, developers or otherwise, have strong feelings and opinions about visual design; however, we should carefully consider whether our graphically-untrained, subjective opinions should be given equal weighting with the experience and expertise of professionals who are hired specifically to address these issues. Visual design decisions cannot always be enumerated and explained on a point-by-point basis; however, we must never fall into the trap of considering such design decisions as invalid or less important because of this. In the UI world, "Design by Committee" almost invariably results in all parties making a compromise, and a "compromise" UI will never be an "excellent" UI.

From website research, users typically make up their mind whether they like an interface within the first twentieth of a second, and "The lasting effect of first impressions is known to psychologists as the 'halo effect': if you can snare people with an attractive design, they are more likely to overlook other minor faults with the site, and may rate its actual content ... more favourably"...
full article: http://www.nature.com/news/2006/060109/full/060109-13.html

My Personal Assessment:

The current application, with the disparately-colored icons and primary colors, does not appear to have the same professional pedigree as popular commercial software that users typically encounter. This falls into the realm of "graphic design & touchy-feely emotional stuff", and may be judged unimportant by many people on the team. However, the appearance of the application has an immediate and subliminal impact on the first-time user, that sets the level of expectation, tolerance and comfort for the remainder of the user's experience. It can mean the difference between a user being tolerant towards other difficulties (workflows that crash etc), or simply just giving up and never using kepler again. User testing proves this - see description of the 'halo effect' above.

With this in mind, I think the teal icon set is an incremental improvement over the old version, but may or may not be the optimal solution. Ultimately, it might be feasible to go with a more varied, but carefully controlled palate of allowable colors for the icons, still keeping the "designed" look. The bottom line is that we now have a system that allows us to change icons easily - even substituting entire sets of icons, so future design changes would be easily implemented if necessary. We are all accustomed to using color to distinguish between actors, but a brand-new user might easily attune to using symbols instead. Perhaps we should move forward by allowing usability testing to tell us how the icons should best be colored or redesigned, if at all, instead of trying to make that call ourselves, since we are all far from being objective... :-)

I think Shawn's comments about the color teal vs. black and white are strongly dependent on personal preferences. I personally prefer teal icons to to black and white - and the next person we ask will undoubtedly prefer puce or pink icons :-) Even though I don't like teal all that much, I can see that the color scheme "works" together and looks professional, without me having to "love" the UI. We will never create a UI that appeals visually to everyone; again, we're aiming at the peak of the normal distribution. Provided we stick to an appropriate color scheme and avoid colors with stereotyped or cultural "meanings", I think personal preference is secondary.

I agree with Shawn's comments regarding the folder icons - we are using folders to denote data and to "contain" actors in the library, and maybe this could potentially cause confusion (the user may wonder why there is data in the actor library??) - although I'm not sure if that's just my developer head working overtime... Laura?

Comments and insults welcome

Some brief additional comments from Shawn Bowers on Matthew Brooke's comments ;-)

I would like to see some "usability testing" on different variants of icon choices -- especially given the new capability to easily swap in and out icons developed by Matthew. However, forming a group of "users" to test at this point is problematic: We haven't clearly and definitively defined who the target users are for the Kepler vergil-based interface (on which the icons will be displayed). My contention is that scientists *won't* be the target user group.

From Laura

As to the file folders, that symbol is used commonly to represent groups of items in a directory structure and to also represent data files. The original Kepler uses the data file folder so I saw no need to change that. In any re-design I always try to maintain some of the original symbology if it isn't problematic which helps to ease the transtion from old design to new design. I did alter the color of the data files on the canvas (to a darker gold rather than the traditional Windows yellow) and also the appearance is subtley different to the directory file folders -- there is no shadowing on the large data file symbols on the workflow canvas. If testing at a later time reveals any confusion, we could of course alter the data symbol or just the color of the data file folder to something that coordinated with the color scheme.

In terms of color and its usage, I've added color notes at the bottom of the Visual Re-Design page for anyone interested in more details about color usage that are based on human factors research. Topics include the use of saturated colors (bright), muted colors, number of colors etc. The choice of a particular hue (the muted teal) versus another was to choose something that remained in the blue family (blue is one of the most popular preferential colors) and that would coordinate well with grey and white and also contrast well with the emphasis colors of bright red, yellow and the orange highlight colors. White was chosen as the background color for the canvas because it provides good contrast with colored objects and provides the most contrast for black text in terms of readability.

On the subject of user groups, I agree that we have had some general confusion on our target user group(s). When I first arrived, my understanding was that scientists with little or no technical skills wanting to create scientific workflows in Kepler were the target group, with of course other users being people with more technical backgrounds ranging from a scientist with some technical skills (informatics person) to a full fledged programmer. We have informatics people and programmers represented on the team but we don't really have scientists with no technicals skills represented so I have made sure to advocate for them, but that is not to the pure exclusion of the other groups. If we make things easy to use for scientists (in terms of the tasks they are qualified to do), then those tasks (e.g., opening workflows, running workflows, mild modifications such as parameterizing things and then re-running or substituting different data files etc) will also be easy for the more technical people. As I mentioned on Kepler-dev recently, I've begun to think of things in terms of tasks the different user groups will perfrom in Kepler. To that end I've been developing some high level models and a user-task matrix which we will discuss at the Feb 2006 dev meeting. However, in the interim I have updated the section on who are our users and how we are involving them on the main Kepler usability page

Hope this helps to address any usability issues raised here.

Matthew Brooke added a description of the Halo Effect to his entry above - 16Jan06