the advents with nyxtom

    How many times have you suddenly "discovered" a feature about a certain software that could of possibly saved you hours of time had you known that feature before? It's all too typical to find hidden features in software these days. The problem isn't that designers intend to keep you from using such a feature, it's that the design limits them from "trying to put everything in front of the user". There's the first mistake - don't.

    There are some products that will put everything in front of the user while other products will only put a few things while hiding the rest from perspective. Users will either find themselves searching and searching for something that they need to get to or slow down the confusion and filter through all the unnecessary, even still - distracting - garbage in front of them.

    To avoid this scenario, designers can equip themselves with learning about what tasks are important to their users in addition to creating workflows. Most users can only get one thing done at a time. It's usually best to follow this idea of presenting things one at a time - wherever appropriate. For instance, instead of providing the textbox to post a new blog post, there is a Create button at the top of the page. I can see that when I need to accomplish that task, it's right there in front of me to get to it - without distractions.

    As a user we can be prone to wanting everything in front of us at every possible moment, but what we tend to forget is that we don't always need to get everything - everywhere - done at the same time. So, in supplement we complete tasks according to the context or point of focus we are in. At the same time, with respect to the designer, we need to understand that users need to be able to get out of context quickly - without seeking it out, which can lead to frustration. Simple things like - "I'm done", "Save", "Ready", "Back", "Previous" help users understand that they can navigate to other points of focus not only fast but very simply.

    There is an age-old saying that everything that can be thought of has already been created in some form or another. The problem that differs from every single scenario is not necessarily the practice that implements the solution but the entire product that shows itself through its main and completed interface. While the importance of lean and efficient code is and always will be there, there is of much greater importance to a product that can market itself. But let's take a step back at what great products entail in their user interfaces.

    There are a load of toolkits available to create graphical user interfaces today for the web, desktop and mobile but what most of these toolkits tend to do is supplement a key component in creating a product - showcasing originality. In fact, the greatest part about creating a new product is that you have full control over how your users are going to interact with it - you can choose to make task completion inherently difficult or inexplicably easy. In all of interaction design this is quite possibly the most important - work hardest on it over any other.

    The only successful product out of that market will be one that can differ itself in great interaction experience. Of course, creating that will not be easy and should not be taken lightly. Efficient code takes much thought into building algorithms that you can depend on. The same goes for interfaces in that successful products take much more thought, time and emotional presence into designing interfaces that you can depend on.

    Interaction design not only requires a bundle of testing but it requires a lot of personal experience. As a developer, it would be incredibly difficult to design a product without any familiarity to the end result. Without personal experience to the end product, emotional attachment will be bias in favor of ease of development. As an interaction designer it is important to remember that product experience to users, no matter what the product, count on tasks being obvious.

    Taking a quick glance at the two remotes above, what tasks can you determine will be obvious to complete. Let's suppose that the person will be watching TV in the dark. Without being able to look at the remote, will it be easy to figure out what buttons to press? The remote on the right uses differing shapes, placement and space around the buttons to distinguish tasks from one another. The user will be able to learn how to use the remote during daylight or under the light. Familiarity with the product soon begets the obvious nature to complete tasks.

    Of course, on the left, lights allow the user to see which button is which and how to complete a task like changing the channel. However, due to the number of buttons and the few spacing there is between them - the user will have to look at their remote every time they want to use it.

    Obvious interaction is not so obvious when it of course depends on perspective. Anyone on a team will have a differing perspective of obvious interaction when they are looking at the same product. However, the key point in making things obvious is about taking away prerequisites. So for instance, in the remote example lighting was taken away. Without looking at the remote which is easier? How often will the user need to relearn the interface? How long will it take to learn the interface the first time? These are a few important questions when thinking about obvious interaction.

    I decided to write a quick prose on interaction design and software. It's simple, but I think it gets the point across.

Since the dawn of time we have learned to progress by
connecting and building off of the world around us. We
have learned how to communicate, explore and create
through example, experimentation and evolution. Yet,
in a world becoming more and more dependent on IT,
we are only beginning to understand the many ways to
interact with the content around us.

This is our journey. Our passion is software. 

                                - Thomas Holloway

    People who create applications have a lot of power. As we all know, with great power comes great responsibility. But it really is true in the case of user experience. User experience is what defines how people really feel emotionally about your program. It tells them whether or not to use it again; whether to trust the people who created it; it expresses a deep connection that may live on or die at first glance. I would like to dispel a few myths that seem to come up time and time again when creating a so called standard application.

Myth 1. Installations: Accounting for custom options

The great myth of applications, at least those downloaded, are in installers. Installations allow the user to select where they want the program to be installed as well as custom options to enable or disable. I believe that this is simply flat out wrong, even insulting to the user. It's time we install it like it should be and provide practical solutions over customized choices. Removing programs should be as simple as deleting an icon. Using programs should be as simple as going to it.

The second myth of applications is that pictures speak louder than words. But the problem with that is almost all application icons have no meaning to us at all. A picture is worth a thousand words only if we create it as users. People understand words, much quicker than icons - so always provide that first.

Menus have been around since the beginning of GUI-based operating systems. But if we stop to think about how many times a user actually navigates to a menu we may realize that they provide an almost completely intolerable solution to making the program do what you want it to do.

Confirmation dialogs are another major myth in creating so-called standard applications. Confirmations not only insult the user's intelligence, but they indicate that once you've done it there's no going back. Always let your users undo and redo what they've done.

Our content is precious to us as users. We adore it because it's ours. But it's understandable to want to have a save feature because as users we're not ready to showcase it to the world. It's like a rough draft. But what happens when our computer crashes, something unexpected happens. Our content is at risk of being lost. Never ask the user to save when you mean to ask if they're done. Saving needs to be automatic Don't expose the user's content to everybody though; it's their content - they just simply aren't done with it yet.