rss or subscribe by email

nukeation.com | follow us on Facebook | contact us

The Designer Role - Part 2 (Official Expression Newsletter)

February 25, 2008 23:13


The Microsoft Expression Newsletter's Feb issue just got published today. You can read Part 2 of my article here.

The previous part can be found here.


  Share

Differentiated UX

February 1, 2008 05:29


Last night, Brian Noyes pointed me to his blog post about Differentiated UX and asked my thoughts about it. This post is derived from my reply to him.

From Brian's post:

A new buzzword that I hear more and more these days, particularly from Microsoft evangelists, is "differentiated user experience" or "differentiated UI". I'm even guilty of using this occasionally myself. And yet, it is one of those terms that often makes people cock their head like a dog that heard a human-inaudible screech.

In an effort to save my dying keyboard, I'll call it DUX or DUI here. And trust me, the effort needed to make a DUI can actually cause a DUI.

As Brian mentions, there is no clear concept of a differentiated UX or UI, but we agree on the basic definition.

From my reply:

I totally agree that a good – differentiated – UX would use a new way of doing the same tasks.

To clarify, task oriented means creating a UI that makes sense for a particular task rather than commonly used UI patterns. Let me give you a very simple example: if you are creating a graphical application and need a button that activates the Pencil tool, it would make more sense to use a pencil icon on a button rather than a button with the text "Pencil" on it. If you want a more complex example, check out my post about Rethinking the Button.

So yes, I'd say DUX is almost the same as task-oriented UX design.

From my reply:

I totally agree that a good – differentiated – UX would use a new way of doing the same tasks. This was something Kai Krause did magnificently and why he is my hero. We – the developers – are so caught up with all the hundreds of new technologies and trying to make them all work that there is no time to do UX, just a simple UI that is quick and easy for the developer.

I may not have been programming for as long as many of you, but from what I remember there weren't as many new technologies and 3rd party material in 1998 as we do now. Right now, we have LINQ and soon SQL 2008, the whole new way of handling WPF in the code layer, new strict UAC-oriented security guidelines, WCF, and what not. It really isn't the developers fault (or job, come to think of it) that he or she can't focus much on UX. And when there is no designer at hand to do this, the only fallback option is a quickly thrown together UI that more often than not (from a designer's and UX point-of-view) sucks.

From my reply:

In my opinion and experience, the biggest problem with bad UX is the old menu/toolbar/grid recipe (like mentioned in your post). Most regular developers I’ve seen are using that same method (and I forgot to mention the Outlook style sidebar) for their business apps. And in fact, a common rant of mine is that the Grid is making developers lazy. So often do they quickly bind a grid instead of using a more graphical and comprehensible. These controls are good for many situations but not for all. From what I’ve seen, a developer will use a Grid where a ListView can be used because it can be directly bound and does not require much code.

Brian's reply to this:

I shudder to think how many times I’ve gone in to help a customer put together a system and the developers insist “no, really, we HAVE to take this table with 57 columns and bind it to a grid with all columns in it… that is what our users want”. After I choke down the bile, I try to explain that they probably don’t really understand what their users want at all. :)

I don't care if you hate me. STOP USING THE GRID, people! Really, it is time to kill the grid. It is making developers lazy and end-users unproductive at best. And I promise to punch the next person to say "It's easy to bind the grid, nothing else is as easy". Wrong, wrong, wrong. Go watch episodes one (Intro) and three (DataBinding) of revoluxions that Andy and I did a long, long time back. It is SO darned easy to bind data to the ListBox (not even the ListView!!) in WPF.

If you're saying my <insert favorite 3rd party vendor's name here> Grid is super awesome and let's me add cool things like dropdowns and checkboxes and ink. Again, go see the DataBinding episode. A ListBox in WPF can accept anything - and I mean anything - including custom controls!!

From my reply:

The second biggest problem for bad UX are cookie-cutter 3rd party controls. Again, if you look at all the offerings from 3rd party vendors - it’s all grid essentially. The newer WPF ones maybe look hip and act cool, but they’re still just the same old controls with a bit of new functionality and eye candy. And these controls are keeping developers from adding a good UX. And custom work is always a requirement for a REALLY good UX. The Ribbon UI was a very innovative breakthrough for the Office apps. But now everyone is just aping it, not building on top of it. They just want their app to look like Office.

What more can I say? Trust me - not every app should be like Office. The Ribbon is cool but not useful everywhere. Custom controls from all those vendors are really good and useful, I don't deny that - but don't let them become the app itself. Add some customization that is focused on the task your user will be doing.

From my reply:

The software world can learn a LOT about this – especially differentiated UX – from the game industry. Check out control panels (on game objects, as well as the actual UI) in Doom3 or Quake 4 or Crysis or Republic Commando. While it is nothing that would be found in the real world (except some in Doom and Quake) they still speak of task oriented UI design, not common design oriented UI forced for that task.

Here are two simple examples. They seem simple enough, but we rarely do this in our applications.

crysisUX1  doomUX1

From my reply:

Of course, the root of the problem is that developers should not be doing the UI any longer. A designer has to be involved if good UX is a target. Someone who thinks exclusively about the end-user experience. Additionally, it has to be a hands-on designer, not someone who will provide JPEGs and then a developer does the XAML. Many unspoken ideas are lost in that process and tradeoffs are made in the moment and end up being a mediocre UX.

It has happened so many times to me personally. Over a dozen times, I've handed complete graphical assets (CSS, JPEGs, etc.) for a website design, along with complete JPEG mockups of how it should look when built. But for reasons I will apparently never completely comprehend, the developer(s) somehow mess up the design. The most basic thing I can think of is that they're not trained for putting together a design - they're trained for making it work.

Even after I've done the actual website - code and all - and published it, the client (a developer) will go in himself a month later to add a bunch of text. Wouldn't be more than 2 lines - a heading and a line of text. But he would use a non-pro tool like Notepad++ or something else instead of Visual Studio or Expression Web - or worse - try to hand code it in HTML. Now these alternatives are not bad - but only if you KNOW what you're doing. A lot of my designs are currently flying mutilated on the web.

If you're saying "So what? It may not look perfect - only a slightly different - as long as it works, what's wrong?" you're probably a developer and need a LOT of help with UX. Because the end user notices these things. It lowers the professionalism of the application, and in turn, of the developer that made it.

In Brian's post, he writes:

While a lot of this may seem like just eye-candy, one has to be always cognizant of the impact a simple visceral coolness to an application compared to its competitors may have. I frequently work with customers ranging from internal corporate applications; to ISVs for major industry software including financial, insurance, and medical; to government contractors developing specialized applications for defense and management purposes. In all these arenas, there is always an aspect of sales to the success of the project. If the funding source (the VP of X in the corporate environment, the purchasing bank or insurance company in the ISV scenario, or the General with the budget to give the green light in the government arena) can look at an application for which they have no expertise to judge themselves, but immediately feel like it is impressive in some way (which usually manifests itself graphically first), then they are likely to chose that as the way forward.

In a totally separate conversation regarding my product reuxables, Andy Eick writes:

I wish I would have learned earlier in my career how important the UX is -- when you are briefing the boss, they need to see a good looking UI, or you won't get your next funding cycle.

This is a fact. Apple has understood this for a long time. It's their aesthetics that sell their products more than anything else, IMHO.

From my reply:

And we come to the core of the thing – there aren’t enough designers out there. Not for this kind of work. A good majority of them are trained for eye candy – not usability. Designers also need to understand some basic precepts of software development so as not make the developers’ job too hard because of their designs. Again something to learn from the game developers. There is no common term for the role, but often there is a sort of interpreter in game dev teams. Someone who knows the basics of graphics and software and helps the design and development teams understand each other.

Unfortunately, we don't have an immediate solution for this problem. We can only wait for more designers to start learning about real UX (not the buzzword it has become) and provide their services. In the meantime, I humbly point you to www.nukeation.com :)


  Share

Egos in WPF: Designer vs. Developer (AngryCoder)

February 1, 2008 04:13


My new article is featured on front page of the newly relaunched angryCoder.com.

But like developers, designers also have healthy egos measured in tons. Stick a single developer in a team of designers and he or she will be chewed to death in a matter of minutes. Black shirts hide bloodstains easily - why do you think designers wear only black?

Read the entire article at angryCoder.com


  Share

The Designer Role - Part 1 (Official Expression Newsletter)

February 1, 2008 04:11


Microsoft just published my article titled "The Designer Role" (Part 1 of 2) in the official Expression Newsletter.

You can read it here.


  Share

UX Concepts - Rethinking the Button

February 1, 2008 03:43


We have UX technologies like WPF and Silverlight (and of course, Flex/Air/Flash/etc.) that can really push beyond the existing User Interface and Experience with enough flexibility and ease of creation. So as I've said before, it is high time that we start rethinking of the most basic elements of the UI and UX.

Now only a small fraction of this can be wrapped up into a component you can buy from a vendor. No, this has to be done more or less on a case-by-case basis. 3rd party controls can go only so far. Of course, this is why you need a good designer on your team. Sure they are very few right now, especially with WPF, but there are a few good ones. :)

So what am I exactly talking about? Here are a few examples. And while I am aiming for a WPF/XAML implementation, they are more or less platform independent concepts and can be implemented on almost any platform worth its salt.

Don't forget - what I talk about here is only a single angle of looking at things - there are many and the more you explore them, the more customized and more powerful UX you can create for your users.

  • Rethinking the Button
  • Super Shadow and Physical Focus
  • Non-Modal, Connected Status Display
  • Real World Simulation

For this part, let's talk about...

 

Rethinking the Button

The essence of the button has remained the same since way before we had graphical user interfaces. In DOS it was a flat colored rectangle with text on it, in Windows 1.0 it was a rectangle with text on it, in Windows 3.1 it was a beveled rectangle with text on it, in Windows XP it was a nicely shaded rectangle with text on it, and now in Windows Vista it is an animated rectangle with text on it. And this applies to other operating systems as well. Sure, there are small variations here and there - and skinners go far in making unique buttons - but the basic paradigm remains the same.

Few people have been able to come up with new ideas for the button. Many of them failed. But one of the shining examples of such advanced User Experience has been Kai Krause. I’m going to show you a new method of creating buttons that I’ve come to call “Menu Killers”. These are based on some of his philosophies.

For our example, the basic premise is a Product menu system. The required commands are: Open Product Dialog, Add New Product, Add Note, and Configure. These are some of the most typical commands you see in daily programming. Most of the time, these are a row of buttons or a menu. Sometimes even an Outlook-style vertical command bar. But we’re going to do it a bit more graphically.


First we get a designer to come up with icons for each command.

The icon that represents the overall category of these commands, Product in this case, is kept bigger than the rest. The other three icons are about ¼ of that one, and are laid around in a semi-circle on the right hand side (or the left hand side, depending on the language/culture requirements, not to mention Tablet PC's right-handed/left-handed settings!)

The box represents the products and OnClick will bring up the main product dialog (or page, if you’re using a page navigation structure). The plus sign, the note icon, and the tools sign are common and clearly recognizable icons that represent the other three commands. Picking out the most recognizable icons is the important part.

But sometimes visuals are not enough. You can use the tried and trusted tooltip for each button. Or if you want to have something a bit more unique, you could place a label or textblock right under the main icon (the box). The label would, when idle, display the name of the section - “Products” in our case. But when you hover the cursor over any of the other icons the label text changes to show that particular command’s name. The figure below shows the Add Product command being highlighted.

Visual feedback is very important. The user should immediately know what control he or she is targeting. To provide good visual feedback the Opacity of all controls should be dialed down to 60% or 70%. On mouse hover, it should animate (or simply pop) to 100%. Coupled with the text label, it would be ample visual feedback.

This is just one example of using the Menu Killers. If you have more commands, you could form an entire circle of icons around a main icon. If you require a shallow hierarchy, you could have a secondary level of sub-commands as shown in the figure below.

Adding a third level is not recommended. You will also notice that the top level commands are dropped down to 40% opacity when a secondary level appears. This helps identify the hierarchy in a very visual, non-textual way. To add some extra coolness, you could have the secondary level crawl out of the parent icon one by one.

TIP: Always keep your animations quick. Slow animations look cool at first, but in regular usage these lengthy animations become cumbersome. Movement and fade animations should be between 0.25 and 0.5 seconds. Fade out animations can be kept up to 1 second, but no longer than that.

I leave you with a few more examples of how this design pattern can be used in other scenarios. Experiment and you will find many uses for it.

Back / Next

A very simple back next design. The back button is bigger as it is more commonly used.

Locked Network

A network has been locked. The lock icon can be used to unlock it with a password dialog, while the info icon provides more information about the situation. This design demonstrates an overlapped grouping.

WPF CODE

The code used in the "Menu Killer" buttons can be found here.

TO BE CONTINUED...


  Share


Powered by the awesome BlogEngine.NET 1.6.1.0 | Sign in