rss or subscribe by email | follow us on Facebook | contact us


February 14, 2008 07:25


It is not often that I get to take part in a project this exciting. I've been talking of "extreme" UX and now I can finally start talking about it.

Today, we created a new team at nukeation that is in charge of nukeationFingertip - an initiative to create groundbreaking new user experiences for many common problems that lack a decent solution. We are fortunate to be working with some incredibly smart people who will add their expertise of their respective fields to our UX expertise and the result will be, as someone put it today, "really fun to play with".

Projects code named "Nukium", "Black Folder", and "Griffon" are part of the initial offerings. Stay tuned, as we'll be posting more information and screenshots soon.


Technorati Profile

Examples of Differentiated UX

February 7, 2008 01:31

With the undersea cable problems and my average net speed being about 15k/sec, I am presented with ample time to think and write about UX. Something I haven't been able to do for quite some time.

Last night, I had a short exchange in the private MVP discussion list about Differentiated UX. And more specifically, actual examples of differentiated UX's and the reasoning behind them. Below are some modified excerpts from my emails:

It is very easy to go overboard when creating a super cool UI. But to have a good UX and a differentiated UX, we don’t have to go recreating the wheel. We just need to identify as many areas of our own applications that can benefit from an enhanced UX. Not think of universal UX concepts that would benefit every application. That is what component vendors do and that ends up creating only a mediocre UX.

Think of this in terms of a website. Using a CMS like DotNetNuke is so easy and it lets you quickly get things done, but there is only so much customization possible because to benefit the most number of users, the creators must stick to a one-size-fits-all template. A custom CMS, while much harder to create in comparison would be built specifically for the site in question and therefore would have more originality and flexibility.

One aspect of DUX I’m messing with is windows. Mainly modal windows. If we compare more recent applications to something from the Windows 98 or 2000 era, the number of modal dialogs has gone down. SysTray popups have removed the need for so many message boxes and other modal dialog based notifications.  Often modal dialogs are not really needed. In many cases where files will be stored in only one place, the Open/Save dialogs can be removed completely. Windows Live Writer does a good job with that.


Taking again the Open/Save dialog example, see the image above. This is an in-page implementation of an open/save dialog. The design consideration here was to quickly identify the “slot” you want to save or open. Filenames were not a user-relevant element, so we did away with it completely. Extra info would be provided by a large Super Tooltip. We also use physical focus by blurring everything else so as to give this “dialog” total focus.

One thing I specifically mentioned was that blind usage of 3rd party components is more or less putting the UI and the UX in a box and limits creative UI. Take the DataGrid for example. In certain business scenarios, it makes perfect sense. But developers often become too eager to just slap a grid on the window and bind it to the data source. It’s so easy. But it is often unproductive for the end-user (even if they themselves don’t know it).


In this project, we were given an existing medical application front end and were asked to “idiot-proof” it. The app used DataGrids for a list of visits of the patient. No way would an inexperienced user – especially under stress or in emergency situations – be able to quickly navigate a grid and understand the data. So we implemented a customized DataBound template of the WPF ListBox (not even ListView).

This is a simple List, but look at the DUX/features:

  • Big icons (with totally different colors for each state) quickly relay the status of each item without needing textual data.
  • Large easy to click items.
  • Column Name is repeated in each item, so if the user is looking at an item at the bottom of the list, the eye doesn’t have to travel all the way up and see which column it is. It may seem like a very minor time saver, but when a single app is used all day it ends up saving a lot of time.

It was still just as easy to bind to the DataSource.


One last example: LogiDine. This is a restaurant reservation system app we did for ASPSOFT. And do note, this is Windows Forms (in .NET 2.0) not WPF! Just about everything uses OwnerDraw code. But the main DUX feature here are:

  • In-page “Add Customer” dialog, avoiding the modal dialog. Especially since this would be needed frequently.
  • A NumericUpDown control is nasty for quick input. So we added preset buttons next to them. Clicking a preset would quickly input the value in the spinner.


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 :)


Powered by the awesome BlogEngine.NET | Sign in