Thursday, February 12, 2009

we're done here

plain and simple... dfarkasdesign.blogspot.com is now moving to a new home at brainfarks.wordpress.com

I thought (not so) long and hard about it and i like the wordpress interface more... its easier to edit. I also contribute to other wordpress blogs so its easier on my brainspace.

Friday, February 6, 2009

Nothing stays asynchronous

To quote fight club, "on a long enough timeline, everyone's lifespan is zero".

To translate this to technology, "on a long enough timeline, all communication vehicles are immediate". Meaning, there is no permanently asynchronous communication service.

Take the phone for instance. In it's initial form one individual would call an operator and leave a message for another. This asynchronous messaging service provided a catalog of calls over a long duration of time. Enter the answering machine and messages can be left directly for a specific user. Enter the cell phone and you are reachable anytime, anywhere.

Take the pager. Before an asynchronous method to ping an individual, text messaging has filled the gap and is much more immediate.

Take mail. We have come a long way from horse delivered mail to overnight delivery. Enter email and we have instantaneous communication. Enter smart phones, PDAs, and laptops and we have near zero latency to what was previously a weeks-long endeavor.

So nothing stays asynchronous for ever. Technology is constantly decreasing latency and making it easier to be reached. As appliations like google's latitude saturate the market meeting locations will be replaced with spontaneous 'run ins' thanks to big brother type trackings.

To reiterate an overused question, when do we give up too much freedom in exchange for immediate access to all of our communiation devices?

Monday, January 26, 2009

My center click gripe

A simple gripe about web browsers and navigation.

When searching through the Internet, I often come across links to pages I want to further investigate. This is, of course the intent of the Internet. My typical interaction is to cnter click a link to open it in a new tab. This solves a variety of browser based issues. It minimizes the number of windows open. It loads data I want while reading the current page. It is a single action.

Now enter javascript. Many sites use javascript to open links in new widows or tabs (browser specific). This is great in the case of FAQ pages and third party sites. In fact, one could argue it negates my need to center click.

That is the problem though. It does not negate it. Instead of opening my new tab, I am directed to a tab with a single line of jss and no actual content. Why does the hack provided by developers negate the hack I have taught myself? Shouldn't center click still work, especially if my hack and the jss solve the same interaction dilemma? Users should not learn a hack because of an application's shortcomings only to have a workaround sparingly implemented come along and cause that solution unhelpful. There needs to be more standardization across development and, perhaps more importantly, more acceptance from the system to a variety of inputs that aide the same result.

Wednesday, January 21, 2009

MVC and alan cooper's inmates

MVC stands for model, view, controller and is the idea of separating Interface from functioning code to interactive elements. That is a blanket statement with many gaps but let us assume it is true. With that in mind, code and user interface happen in separate places, completely unique from eachother. In the web world, this means you may change the layout without consulting the owner of the content.

Now take into consideration alan cooper's book "the inmates are running the asylum". Again to paraphrase, cooper suggests that developers and designers need to work hand in hand from the beginning for a sucessful product. All stakeholders involved in development need to have a mutual understanding of eachothers needs and motivations and willingness to find solutions. So how does that model, that I agree with, compare to MVC?

If the design and the code are fundamentally separate, what is instigating their interaction? I do not think a new model has to be made for code. Instead, there needs to be a change to how the mental model of development is taught to parties involved. This happens in some academic program such as Carnegie Mellon's HCI program that I am a product of. Still, the majority of design and computer science education lives remote of the other fields involved. Until joint education is widespread the inmates issue cooper described by cooper will continue to exist and design, marketing, and developers will continue to struggle in the attempt to find a cohesive product.

Monday, January 19, 2009

Design persepecive

This does not warrant a long post. Nor can I write much on the topic considering my recent perspective is and will always change.

Still, an interesting experience today as I interviewed a potential Carnegie Mellon design student. I was able to see my views about design in his responses and compare them to what I know now and there was a lot of interesting and surprising differences.

Thursday, January 15, 2009

Smart phones that aren't

I have decided that society as a whole has settled for mediocracy in the department of mobile devices. We have the term 'smart phone' and believe our devices are augmenting our lives. True they keep calendars and contacts in order, let us check our email, and even write this blog. That does not make them smart. It does make them feature ridden.

I believe smart phones are more like trained dogs. Teach a dog a command and he responds. Sit and he sits. Speak, paw, roll over. Alarm, schedule, call. Are smart phones really that advanced? I see them as conditioned beings.

To side with Alan Cooper, I am the sole user of my iPhone. It should know I always want the device to turn on to the homescreen and should load the highest level of a feature upon load. That is what a smart phone would do. Instead I find myself following a series of actions to go back in hierarchy followed by hitting the home button so that the device is ready for my next encounter. That is not a smart phone. My need to take these steps are the same as needing to clean a dogs paws after taking him for a walk. The only difference is the dog might learn to expect this and wait while you put the leash up before tending to the animal. Smart phones have no memory of past events and dart into the house first chance they get, tracking mud for the owner and user to clean up.

There has to be a fundamental change in what users expect before technology will be updated. There has to be a movement for device names to accurately reflect their abilities. This change will not come from developers as it requires coding and learning on the devices part. Users don't know to ask or what doesn't exist. Which leaves the void to be filled by interaction designers. The only problem there is how to speculate on what should and should not be learned in a polite, wizard free manner?

I am open to ideas as technology becomes more pervasive innour lives.

Wednesday, January 14, 2009

The answer is right in front of you

Users are conditioned through little or poor design, unforgiving code, and a time before usability was a popular term to believe that systems and devices are inherently difficult to use. Show a user a new product and they will be hesitant to use it expecting the experience to be unpleasant. Similarly, provide a user with a simple task and they will search high and low for the answer expecting it to be hidden in some lost corner.

I have witnessed this most recently not with software, but with elevators. Waiting in the lobby of my office building an individual saw the elevator call button turn out. The user looked all around them to five of the six machines to see which had arrived. Not discovering the answer, she reluctantly turned around and sighed in frustration as she realized the available elevator was the unit she was staring at while waiting.

I see this incident as being very similar to the question "where are my glasses?" where a user will wander around searching for something to find that is on top of their head. Users have been presented with so much inept software that we no longer accept a simple solution. If an application doesn't require 20 steps to load a new document we don't trust it. That's not to say we won't complain about 19 of those steps, but we as users have become conditioned to poor interactions.

Users no longer look in the box labeled batteries for a fresh set of AAs for the flashlight. We expect the linen box to have our answer. It is the role of interaction designers to regain the trust of users in systems that they can be useful, usable, desirable, and polite.