Tag: ux

Posted on

Why I Love UX (or How to Piss Off an Entire Department!)

Last Friday, I tweeted something which was badly worded, and managed to piss off much of our UX team (not to mention a few UX people far and wide):

Pissing off UX

Now I ask you, how could that post possibly offend anyone (note sarcasm)?

So, I would like to clarify what I was thinking when I posted that (and again ran into the problem that most of my thoughts do not fit into 140 characters).

First, I had been reading a number of posts and other articles by so-called UX experts, thought leaders, and others (all off whom shall go nameless, as I do not need anymore flames – well, actually I enjoy flames, but am full at the moment). Like many fanatics, they have (in my humble opinion) some fairly radical beliefs that are not well grounded in the real world. These are the “UX people” to whom I was referring in my post. Yes, my choice of words was bad.

Secondly, I have a great deal of respect for the UX process. I even have a lot of respect for most of the UX people I know (even the ones with whom I disagree). Frequently it is the UX department with whom I have an issue. I have the same issue with Marketing (the department) versus Marketing (the process), and with Architecture (the department) versus Architecture (the process).

The comparison with architecture is particularly relevant, as I have had many arguments over the years in software organizations as to whether “architect” is a role or a job title – should there be an “architecture group” separate from the development team. My belief is a resounding NO! I tend to believe that “architect” is a role which and individual with the appropriate skills and training assumes on a specific project. On another project, that same person may be a senior developer. My concern with architects in a group by them selves is that I have frequently seen these groups (a) become extremely elitist; and (b) become too far removed from the reality of implementation, leading to architectures which are elegant, beautiful, and difficult to impossible to build on-time and on-budget. Often, the 99% philosophically correct, current-best-practice architecture is not necessary, when the 80% solution can actually be implemented on-time and on-budget.

I find that UX groups is some organizations, and UX thought-leaders in the world at large, are falling victim to much the same challenges I described for architecture. Too much separation between UX and implementation creates certain challenges.  And, there is often little willingness to deviate from the “philosophically correct vision” in favour of practical reality.

And as a final thought, I definitely do not have all the answers in these areas – I just have some very definite questions about how we (in the global sense) do things.

Advertisement
Posted on

Windows 8 is for the Right Handed?

As I have played with Windows 8 (both the Developer Preview and the Consumer Preview), I have gotten the distinct feeling that it has been developed assuming a right-handed user. For example, access the system charms works much more consistently with my right thumb as opposed to reaching across with my left hand.

Tonight, while reading through some of the developer documentation for the consumer preview, I came across the following statement:

Untitled

Apparently it is ok to ignore 10% of the population when designing your user experience.

Posted on

First Thoughts on Microsoft Surface Development

A brand new Microsoft Surface development unit arrived this week in the Moncton T4G office. As I start to develop some prototypes, I will be doing some related posts, but I wanted to start by talking about the platform a little, and the development environment.

For anyone who has no idea what the surface is, it is a multi-user, multi-touch platform released by Microsoft a couple of years ago. Have a look at this video to see what it can do.

Other the last few weeks, before the unit arrived, I have learned quite a bit about the Surface. The first interesting thing I learned was the the surface is not a touch screen in the sense that your iPhone or multi-touch laptop are. The surface of the Surface is just glass – it is not a capacitative or pressure sensitive material at all. All of the touch behaviours and interactions are based instead on a computer vision system. Inside the box there is a fairly standard PC running Windows Vista, with an DLP projector pushing the image up to the table top. There are also 5 cameras inside the box which perform the actual "vision". These feed into a custom DSP board which analyses the camera feeds into something a little more manageable for the PC. The fact that it is a vision-based system leads to some interesting capabilities, as well as some idiosyncrasies.

When the Surface is running in user mode, the Windows Vista UI is completely suppressed. There are no menus, no windows, and no UAC dialogs – nothing that would indicate it is even running Windows. There is also an Administrator mode which shows a standard Vista UI for administrative functions or for development.   

As far as development goes, the good news is that it is all pretty standard stuff. There are two approaches to programming for the Surface. The first is to use the Microsoft XNA Studio platform, the other is to use Windows Presentation Foundation (WPF). Using XNA gives you a little bit more power, as well as access to more of the "lower level" information like raw images from the video feed. Using WPF is a higher-level programming model, and comes with a set of controls specific to the Surface UI model. The nice thing is that all you know about .NET and WPF programming applies to the surface. And from a larger architectural perspective, Surface can tie into any infrastructure accessible to any other .NET-based model. It is just a different .NET UI layer.

The bigger challenge in developing for the Surface is changing the way we think about the UI, and selecting the right solutions. First and foremost, Surface applications are not just a port of a standard Windows UI. Stop thinking about Windows, Icons, Menus and Pointers (WIMP). The surface calls for a completely different models, one that I am just learning. One of the interesting statement I have read describing the Surface model is "the content is the application."
The Surface is more than just a multi-touch platform. Sure, you could implement a multi-touch solution on the Surface exactly the same as a Windows 7 multi-touch solution, but that is only using a subset of the Surface capabilities. The key characteristics of Surface interaction are:

  • multi-user, multi-touch (up to 52 simultaneous touch points)

  • social interaction – multiple simultaneous users, collaborating or working independently

  • 360 degree user interface – users on all sides of Surface at the same time, with UI oriented to support all of them

  • Natural and immersive – like the physical world, only better

  • Support for physical objects integrated into the experience (tokens, cards, game pieces, merchandise)

When it comes to selecting a solution to deploy on the Surface, the two most important keywords are "social" and "immersive". Social, because the best Surface applications are those in which the computer is not replacing human interaction, it is enhancing it. Immersive, because you want the user(s) to forget that they are using a computer, and to only be thinking about what they want to accomplish. The how should be transparent.

Over the coming days and weeks, I will post more about the Surface and what we are doing with it. Hopefully next week I will be able to post a short video. If you have any thoughts or suggestions, I would love to hear them.

%d bloggers like this: