Are you designing for engineers or customers?

I attended a meeting & demo recently which started with the developers telling me the software wasn't really designed for users, it was for engineers.  It was built though with a customer in mind.  They work for a for-profit company.

Let that sink in for a moment...

How many times have you heard "well, it may be too complicated for a user", or "the users really could bind up the system if they don't know what they are doing"?

Let's consider these comments.  Has no one learned that complicated software is crap?  Has no one learned that complicated software has a slim chance of success?  Complicated equals crap.  Plain and simple truth.

Consider the below photo.

Although, this was built with a user in mind, it was most certainly built from the engineer's perspective, by a person who really understood the usability (um, yea...right).  How many users could intuitively begin using this remote out of the box without help?  A small percentage.  Notice there is a help button on this remote!  The design team knew they were delivering a crappy product!

Now consider the photo below.

This was built with users in mind.  Most users are able to figure out how to use it right out of the box, with no help.  That's a big difference from the first approach.

It takes a lot of patience to have a team work with a user community when developing a product.  However, it makes no sense to ignore the very users you want to buy your product.  Yet, we see it happen repeatedly, again, and again, and again.

Don't be like the Time Warner remote design team and proudly add a help button to your product.  The only help your customer will be looking for is how to return your product and rant about it to their friends and the other 5 zillion people online. 

Transparent System Migrations

System migration to follow-on target architectures usually occurs near the end-of-life of an existing system.  A slow approach is much more effective with simultaneous deployment of both legacy and target systems.  Sure, there are those that believe a slow approach is wrong, but much like ripping a Band-Aid off there will be a lot of initial pain.  A “gateway”, or bridge, can be implemented which becomes the bridge to enable legacy and the new systems to co-exist in the same environment.  The bridge allows users access to data that exists on the legacy and the new systems in a transparent manner. 

Again, transparency is important, as it allows the architecture to migrated so as not to interfere with the business.  Some scoff at the notion of transparency, but why shouldn’t that be the goal?  The ideal situation is for your user community to tag along with you as you transform your system to the shiny new system you so desire to deliver.  Not going in thinking of transparency may mean your user community will fight against the new changes.  A bridging approach is one way to help your users make the leap from legacy to future systems.

Engage your users so you can help them help you migrate to a new system with minimal issues.  Just like our desire for a transparent government, so, too, should be your system development plan and implementation.

SOA Best Practices can evolve

A well thought out, planned SOA approach should place business practices first, instead of the software.  Piecing together functionality and data from almost any application to help automate business processes, one can break the restrictions imposed by current legacy components.  SOA encourages the reuse of those Services by ensuring a greater consistency across an organization’s processes and practices.

Best practices define what a system is all about.  As part of the SOA evolution, best practices must be standardized to help to reduce costs and provide immediate flexibility.  Standardized practices and processes not only allow for plug and play software and Services, but it also lessens the reliance on specific developers (and that’s good news).  Having standardized business practices helps lower application support and maintenance costs, as well as reduces the need for customized software. 

Best practices leads to Next practices.  Next practices will come from your user community, as the software users discover news ways the new Services can be used (and that’s more good news).  This will likely require more work from you and your development team, but, hopefully, the work will remain at the updating level, not patching; however, if you’ve followed my first sentence’s guide of a “well thought out plan”, then you will be less likely to enter the patching revolution, and can instead stay in the software evolution phase.  The cost for implementing follow-on or supporting Services lowers each time a new Service is deployed.  This can be achieved through Best practices, not by using the gunslinger approach of shooting from the hip and not ever planning what your desired final system to be. 

Does your organization use Best practices?  Have you engaged your user community to adopt a Next practices thought process?  If not, you are missing a great opportunity to learn how your software is really used and to win over support for that next impossible idea!

Lego blocks approach to building SOA

To better understand SOA, imagine that the Services are Lego blocks.  Each Lego block has the identical bumps on top and holes on the bottom so the Lego’s always fit when positioned together.  To build an SOA, one must piece together their desired Lego blocks with other Services.  Once the first Lego has been built, piecing together new and existing Services provides the ability to build on top of existing Services.  

Re-usability can easily be addressed with this Lego example.  If a Service becomes outdated, remove the Service pieces and reconfigure them, or add new Services to build what the new users now need.  That is the beauty of Lego blocks and SOA - you are only constrained by your ability to build your idea! 

This, in itself, lowers the development cost as it does not require a complete overhaul of a system or software application; Services and their supporting applications are built with the understanding they will eventually need to change as the business changes.  Let me know what you think of this analogy using the comment box.  Do you agree or have I oversimplified the challenge?  

Just a few thoughts on SOA

Service Oriented Architectures enables an organization to build applications by assembling discrete application components and coordinate reusable business Services to increase productivity, agility, and flexibility.  SOA provides business agility by providing the tools to respond quickly and efficiently to changes in the business and to leverage those changes for efficiency and competitive advantages.  Service Orientation, as a business approach considers processes as resources the business can create, discover, combine, and access as needed.  The concept of loose coupling, standards, and metadata provides a foundation for taking tightly coupled legacy components and transforming them into loosely coupled Services that enable SOA.

SOA is also a set of best practices, a discipline to follow.  SOA is not about new technologies; it is about creating, managing, sharing, and securing applications.  The most important part of adopting SOA is how to implement it to enable adaptation of future business opportunities.  SOA is also attractive because it offers greater flexibility, lower integration costs, lower development costs, less development time, and less maintenance time.

 

Adapting a SOA-based philosophy provides a loosely coupled infrastructure that is open to change and flexibility, providing the ability to integrate new capabilities and requirements.  To satisfy this, organizations must implement a philosophy of software reuse in all functional areas.

The SOA approach of breaking applications into discrete Services means a SOA effort can be incremental by gradually replacing legacy applications.  This approach allows existing legacy applications, new applications and Web Services to work together.  One must also consider that automation of business Services breaks system boundaries that accompany legacy applications; this encourages the reuse of those Services, reduces development timelines and ensures a greater consistency across all segment processes.

There should be a separation of architecture requirements vs. operational requirements.  One must identify the architecture requirements first, and then overlay the operational requirements onto the architectural roadmap.  The architecture requirements must be clearly articulated to the development teams to ensure all development is aligned with the future, ideal system.  Technology is changing, but architecture changes will not evolve substantially over the next 15 years; therefore, focus should be on ensuring the architecture can support an extended deployment timeframe. 

Culture changes are required in the defense acquisition process

It is clear that policy and cultural problems “interfere” with the acquisition cycle.  The US Government has finally begun working to reduce the acquisition cycle from years to months and, quite possibly, weeks.  Currently in the US defense department, two years is considered “rapid development”; however, the military cannot wait that long.  Short-term goal is to move to an 18-month acquisition cycle (from RFP to delivery).  

Adopting agile development will certainly support this change.  It will mean moving away from a heavy document centric mindset.   HOORAY!   Requirements documents will become a living, continuously changing document.  Collaboration must occur between the Government and industry.  Within industry, system engineers and integrators, developers and testers all must work as one cohesive team.  There must be a continuous development and testing cycle with the goal of delivering change resilient software and systems; system silos can no longer be allowed!

There must be a fundamentally different requirements process.  Requirements must be developed with the user community.  Requirements will likely not be satisfied at the initial delivery, as one should expect that new requirements will develop as new functionality is delivered.  Obviously, new functionality will be developed with sprint Cycles using the backlog approach which means requirement priorities can change based on a list of the functionality that remains to be added to the product.  This approach is supposed to be focused on the priority needs of the system operator, not the satisfaction of some arcane acquisition guidance.

The upfront requirements methodology will also need to change to support this new acquisition approach.  One possible method is to use Model Driven Architecture (MDA) which is system platform agnostic that use models, templates, and pseudo code.  The MDA mindset is that paper requirements are too ambiguous; MDA will help to remove the ambiguity.

The budgetary constrained environment we are in will probably drive thinking that is even more inventive and tinkering with the military’s acquisition lifecycle.  It is certainly welcomed, as we’ve seen the commercial world make great strides in new ways of working and building systems.  It is a great time to be part of this change.  Technically, this will be easy as demonstrated by many commercial endeavors.  Culturally, it will be akin to moving a mountain.  It will be an interesting ride.

Honesty can be a yellow brick road to customer happiness

Years ago when I was young Navy sailor stationed at the Little Creek Amphibious Base in Norfolk, VA, I worked for an officer who seemed to take me to task for each and everything I did.  I seemed to always carry a bulk of the load for presentations, white papers, etc.  I assumed it was because I had gone cross ways with him at a point early in my tour assignment and he intended to show me who was in charge.  Shortly before he rotated to a new assignment, I was called to his office for what I was thought was going to be preparation for a meeting.  I was wrong about that meeting's topic, and I had wrongly assumed why he rode me so hard the past two years.  He started off thanking me for always being honest.  I was told very few people that worked for him in his Navy career was honest even when it meant it could possibly cause problems.

The commander recalled the time we were in the Arabian Gulf a few months after Iraq had invaded Kuwait.  He had presented information to the admiral which was wrong and he was called out on it.  the commander was obviously embarrassed and came back into the work space and let me have it in front of everyone.  When finished, he asked me what I had to say for myself.  I calmly told him that what he briefed is not what I had given him in preparation for his meeting.  I showed him my notes, and the printouts to back up my claim.  He then asked me, "Are you telling me that I was not listening to you?".  Simple answer, but not so simple implications.  After a pause, I told him, "Yes, that is exactly what I'm telling you.".  He stormed out of the office, but he overheard the conversations that followed between his young officers and me, which was me being told I cannot talk to an officer that way.  My response was, "People's lives are at stake.  I will not put someone's life in jeopardy just because feelings will be hurt or they are senior to me!"  Flash forward to me standing in his office two years later, and I was dumbfounded I was being thanked for efforts when all along I thought I was in the doghouse.

I took that day in his office to heart, and I have continued to always* give honest answers.  It has, obviously, caused some heated conversations over the years as I have hurt feelings and have caused an uproar or two when I've told the emperor he has no clothes on.  I believe it has served me well both personally and professionally over the years.  How about you?  Does my story invoke fond or painful memories?  

My yellow brick road analogy for this is that I know I've done my job when I give my honest opinion, even when it goes against the grain of others, be they my peers or my customer.  And honesty is how I help my customers see the yellow brick road, or the gold standard for customer care.

* = sometimes, honesty just doesn't work.  Such as the time your young son or daughter cooks their first meal for the family for the very first time...or the inevitable question from your spouse that goes something like "does this make me look....?"

Beer Bourbon Chili

Today's blog is completely different than my normal technology focus.  Someone asked me just how killer is my chili, and the best way to respond is to provide my recipe and let you decide for yourself.

This is my favorite chili to make on cold days and for special events.  After about five weekends of making chili, the family finally all agreed this was best tasting.  I placed third at the local volunteer fire department my wife and I support.  We do not think it's too spicy.  My spicy gauge is my five year old son.  If he eats, it's not too spicy.

I hope you enjoy it as much as we do!

Ingredients -
3 lbs meat loaf mixture (beef, pork, lamb)
1 medium onion, chopped
1 4 ounce can chopped chiles
2 14 ounce cans of petite diced tomatoes (do not drain)
2 16 ounce cans of pinto beans (drained and rinsed)
1 6 ounce can of tomato paste
1/3 cup, plus 2 teaspoons cocoa chili powder
2 & 1/2 teaspoons Mexican Oregano
2 & 1/2 teaspoons Cilantro
2 & 1/2 teaspoons ground Smoked Cumin
1/3 cup Smoked Paprika
3 teaspoons Garlic Powder
1 & 1/2 bottles of your favorite Porter
1 shot of Makers Mark bourbon

1. Place meat in large pan over medium heat.  It is important to break the meat down into small pieces, as ground meat sometimes doesn't separate.  A trick I use is once the meat is about 50% browned, I use a potato masher to ensure the meat can get into the smallest size possible.  The smaller the size, the better the flavor!
2. Combine all a spices and mix until everything has had a chance to say hello.
3. Once the meat is browned, add the onions and mix well.
4. Add the chili spice mix and stir until the meat looks chocolaty & cook for another couple minutes.
5. Add the beans, tomatoes, and tomato paste & stir thoroughly.
6. Add the Porter and Makers Mark & stir.

Bring the chili to a boil and then turn to simmer and lid it.  I usually let mine cook at least three hours.

A couple of tablespoons of sharp cheddar cheese and a dollop of sour cream & freshly baked bread makes for a fantastic meal.  Oh and a double IPA goes nicely with the chili's smoky flavor.

Not the best photo, but I never claimed to be photogenic or a great photographer ;-)

Apple vs Microsoft...Apple vs Google

This week I've been trying to get a friend's Toshiba laptop resuscitated.  It is an older computer, but still very usable.  The problem I've run into with it is that the Toshiba bloatware is causing a crash each time the OS restore disc is used - XP restores fine, but the system starts dropping errors everywhere.  After many Google searches of the interwebs, the consensus seems to point to something on the Toshiba disc.  How does this relate to my topic today?  Steve Jobs' decision to not allow others to play in his sandbox was a brilliant decision; it remains so even today.

Microsoft's OS is a good product, but how much of the user experience is hurt by the crapware the vendors throw on top of the OS?  Take a look at the status tray on your computer.  Beyond the anti-virus software, do you really need all of those applications running?  Why does a computer vendor believe I need their software?  I don't buy a Dell laptop because I believe they are going to provide software I cannot live without!  I bought it because I want the computer...not the bloatware.

The same argument applies to Google and the Android operating system.  How is it that a company that takes pride in the fact that their interface is minimal, yet allow mobile phone vendors to install crappy applications and widgets over the top of an operating system that works fine without.  Samsung's TouchWiz is a perfect example.  The company has acknowledged that one year old phones cannot be upgraded to the new Android ICS version, as the phones cannot handle the ICS upgrade and TouchWiz; however, they refuse to release a version without TouchWiz which can be installed on the phones.

I'm sure when Steve Jobs was still alive, he smiled broadly at Microsoft and Google stumbling in their attempt to deliver a better product.  I'm sure he's still smiling, as he seems to be the only one that understood that a great user experience is what brings customers back.  The USER EXPERIENCE is what counts, and it is what makes customers want to return.  There is no software that a Toshiba or Samsung installs onto a product that makes me WANT their product.  These companies should stick to hardware, and leave the software to those that know what they are doing.

So, Apple wins.

What is an intuitive user interface?

There was a time we believed that a command line interface was the only way to operate.  Yes, I’ve been around that many computer generations!  Computer user interfaces have come a long ways from that simple DOS interface (Though I do still use it occasionally).  Debates seem inevitable when discussing the ease of use of the user interface.  There is no reason to drag out all of the different views, but it is intriguing how so many people in this world use one of either three product lines - Linux, Apple and Windows, yet, there is always a struggle to gain a consensus on what is the right approach when it comes to the UI.

The first question that must be asked is, “What information will need to be presented, and how will it need to be presented?”  Too many times, we will find a team that believes they know exactly how the UI should be used and is unbending in the design; they’ve taken ownership of the software which is a great thing, but it makes for hurt feelings, and less profit, when the users don’t like it. 

UI usability and ease of use will and should be a top priority when designing an interface.  I’m sure a “DUH!” was uttered by someone just now.  Are they not the same?  Of, course….maybe…maybe not.  Think about Windows Vista and its usability.  It had a level of usability, but it will never be considered for the “Software ease of use Hall of Fame”.  Therefore, I argue that usability and ease of use are not the same.

One must know who the users are - consumers or enterprise.  There is certainly a different approach for each audience.  Beyond productivity software like word processors and tax software, consumer applications lean more toward the consumption aspect, while enterprise software will be more production oriented.  Knowing this going in will make a huge difference.  Know your audience, or be destined to ask for a do-over when you get it wrong.

However, none of this matters if your user base does not like the product.  To garner their support, include them in early design mock-ups, prototype reviews, and beta reviews.  I've seen success by hosting very early user tests (sometimes referred to as usability test).  The user tests are scheduled before the final code cutoff (yes, a waterfall development effort).  This has paid in dividends!  When a problem is found, and there will be problems, we can bring in the software engineer responsible for that piece of the code and she hears first hand from the users why they want it changed and what their expectations are of the UI.  Too often management teams will push back on user events as being too costly.  This approach is counterintuitive.  Spending a small amount of money early in the design (that means user input is required) saves a considerable amount of money after the software is delivered to fix the software problems.  The importance of engaging your user community early and often has two very real positive results – your customers have a feeling of ownership, and delivering software that is usable out of the box.  Here’s hoping your software is in the hall of fame, and not on the wall of shame.

Kid's books and business presentations

Raising four children means I've spent some quality time with Curious George, Five little monkeys, the Lady with the alligator purse, and many others.  The thing that is interesting is when watching them when I'm reading, they are not so much listening to what I'm saying as they are looking at the illustrations and connecting them to words I'm reading.

In other words, it seems my voice is used only to help guide their eyes through the book's illustrations.  When we're done with a book, they can recall nearly everything from the story.  There's a simple answer - we, humans, are visual by nature.  Isn't this visual nature part of how we develop as kids?  Doesn't this visualization drive our imaginations as kids?

So, why is it people feel the need to have fewer illustrations and more words in their presentations?  I know I groan every time I hear a presenter say, "I apologize for the eye chart"!  If they know it sucks, then why do they feel the need to have us agree with them that it sucks?  I can only assume it is because in our society, an inferred rule was mandated that graphs are bad, and words are great.

 Aren't slides considered visual aids?  If the person presenting knows her business, the slides will truly be there to support her as she speaks.  If, on the other hand, if she continues to refer to her slides for what it is she's trying to sell - show no mercy.  If my five year old son can grasp a story just from illustrations and no more than 10 words per page, so, too, can a decision maker.

The knowledge worker of the future

There is a rising generation. A generation that does not remember not being connected to a computer, a gaming console, a mobile phone, you name it. My son, John, who is almost 18 is that generation. I'm sure someone has already tagged this group similarly to the Y, X, and so on generations, and I've no intention of doing that here. This generation has been immersed in digital consumption daily, they've seen computers transform from the ugly beige boxes, to laptops, net books, and now tablets and smart phones. They've adopted early and they've easily adapted as the computer world changes.

My son plays World of Warcraft, Star Wars The Old Republic, Call of Duty, and occasionally plays me in Quake when I'm up to being schooled in gaming. Why does this gaming matter? It removes some of the anxiety of meeting new people. Because they are always connected, there is a feeling of familiarity with the larger world. They know and understand each other and they know and understand their world - which is going to be the "new world" in just a few short years. This emboldens them to do things that other generations may have thought twice about. They are not alone and unafraid. They are a generation and unafraid.

They have grown up with the interwebs which has enabled the game play and familiarity with society (their society), and certainly their love for gaming and computers.

Why is all of this important?

It is important because this coming generation is the new knowledge worker. Be it salesman, tech, inventor, or more likely all three. As in every generation, it takes the right personality to make great things happen. Think Steve Jobs. With my son's generation, the right personality matched with the understanding of technology will kill two jobs - business analyst and IT. Heck, you may even be able to roll the sales position under him, too!

This generation never looks at gaming instructions...they throw them away with the plastic shrink wrap. There is no such thing as intuitive software (another blog topic for another day), but there is an intuition for how one expects software to react. "At the lowest cognitive level, they are processes of experiencing, or, to speak more generally, processes of intuiting that grasp the object in the original" - Edmund Husserl

Cognition? You betcha - having that level of understanding does already make for a great geek. But, only if one knows how to listen and observe as to how a system is actually used, which means moving away from the mindset of thinking one knows how the customer uses a system to one that knows how to use software/systems.

At what point will we see the merging of business analyst / salesman / IT? That's the funny part, it's already happening now. You might want to slip on the sunglasses that Nada wore in the movie They Live. :-)

Google Ari Weinstein (twitter @AriX) and you'll find a 17 year old iOS developer, or Nick D'Aloisio, the developer of the Summly app. This generation is out there doing great things already.

My son's generation is the future "knowledge worker", we just need to figure out how to help them live up to that label.

Focus on User Interface design or the workspace environment?

I was recently working on a program in which one system was having an issue in which the operators were becoming confused when using the system.  Steps were taken to attempt to fix the UI issues; perhaps the approach was wrong?  While it is obvious that the KISS (Keep It Simple Stupid) approach oversimplifies the problem, right or wrong, there is a belief that a UI-wizard is the right approach.

Let us use a golf analogy I heard some time ago.  Using the wizard approach on an 18 hole golf course assumes the user knows what he's doing and would have only 18 steps.  However, my golf game is quite different, so there are things that must be accounted for such as my bad form, water hazards, sand traps, lost balls, etc.  So the wizard has to account for a minimum of 72 steps (for someone who is good), to seven steps (because I quit after the first hole), to as many as 180 steps because I trudged through to the end.

Is this a training issue?  Probably...maybe.  One must step back from the problem and assess whether it is UI-based or environmental.  What are the potential detractors in both the computer-space and the workspace?  As more and more automated system processes are introduced, the importance of the operator interaction becomes increasingly more important.  In the computer automated environment, the point where an operator interacts with the software is crucial to be successful.  Why then, is the focus solely on the user interface?  The collaboration tools (emails, chat, text messages, documents, etc) are possibly distracting the operator from her job.  Certainly, those tools are there to support the business, but, perhaps, those tools and their presentation methods are cause for operator confusion.

Stepping back from the computer, one can imagine the workspace does impact the operator effectiveness. How is the workspace designed.  Is it conducive to the computer operators or is the furniture laid out at the whim of someone who "knows" design?  Is it loud when it would be better having a mute button on conversations?  Lots of questions that should be answered before deciding a wholesale redesign is required.

Sometimes it's not just a poorly designed user interface.

Information Management

Key to the successful SOA delivery model is Information Management. Information Management supports SOA in that it deals with one of the most important corporate assets - information in both structured and unstructured formats. Information architecture, a key part of information management, makes SOA more intelligent and manageable. Ultimately, without a solid and robust information management environment, SOA is limited and presents fewer opportunities for end-to-end business integration and transformation.

Information management, in SOA, places a strong emphasis on technology that integrates structured and unstructured information sources as if they were a single source. Structured information typically includes relational, XML (Extensible Markup Language), or tabular data (such as spreadsheets). Traditionally, management of structured information falls under the label of data management. Unstructured information, in contrast, involves free text reports, documents, web pages, audio, video, etc. The management of unstructured information is often categorized as content management. A unified view of data and content will provide a simplified representation of and access to underlying information services.

Information management in SOA also encompasses data placement and data retrieval. Information Management is central to a successful SOA and support the required SOA governance.

Without a clear understanding of the information’s intent and value, one could easily make the wrong choices in information management and architecture. Therefore, there must be a proactive plan to incorporate information management to help remove common problems such as data silos, data inconsistencies, and untapped information assets.

Handheld gaming systems are dead

Even though Nintendo is claiming to have sold over 4 million 3DS units in just the US in 2011, the handheld gaming system market is dead.

Santa, like the good saint he is, delivered a shiny new blue 3DS unit to my youngest daughter this year - exactly what she asked for.  Oops, maybe he should have asked her why she wanted the game player.  It's simple really, since Christmas she's spent more time on the Android tablet we have.  The tablet is the Nook Color, rooted running the CyanogenMod which is slightly larger than the 3DS unit.

About the same price, right?

Wrong.

That's only considering the initial cost.  It does not include the games or apps which can be purchased...

Nintendo games seem to be no cheaper than $20.00

Android games are either free or no more than $2-3.00.

Do the math, from an economic perspective, there is huge benefit to not support the gaming system pyramid scheme.

But, I should refocus on why my daughter is playing more on the tablet than the game system.  Simply, there is more to keep her entertained.  She can jump from games to movies, back to games, watch her favorite Justin Bieber video on YouTube, read books, or when she's just a little older there will be email, Skype, FaceBook, and Twitter.  My kids (two boys & two girls - ages 5 - 17) use the interwebs daily for homework, keeping up with friends, playing games, and watching TV and movies.  Using a tablet is like second nature to them.  It is an extension of their already daily routines.

As she becomes bored with a game on the Android platform, which can be as soon as days or weeks, I have no problem shelling out a few bucks for a new game.  I am quite a bit more hesitant to spend another $20-30 for a Nintendo game.  Consider this - if a new game is purchased monthly for a Nintendo, one will easily spend what it cost to make the initial purchase for the game system.  With a tablet, maybe I'll spend $50.  Seems like a fairly compelling argument.

Damn, okay, I lost track again...

So, a couple of days ago I asked her to provide me the pros & cons of the Nintendo and the Tablet.  The following is in her words.
Pros
Nook -

1. You can search for games to play
2. You can read books
3. You can watch movies
4. You have a bunch of games and stuff
5. You can play games against friends

Nintendo 3DS - 

1. You don't have to connect to the internet
2. There are cards that came with it so you can make the characters do different things in 3D
3. You can make it 2D or 3D
4. You can play games against friends if they have a 3DS

I'd list the Cons, but she lost interest in helping me....

Another telling story the handheld gaming market is dead.  My five year old has not asked one time to play on the 3DS.  He goes to the tablet each time.  His games are available on the tablet at home, on my phone at soccer games and swim meets and long car drives (long equals anything more than 20 minutes).

So, I'm going to follow the tech tradition of what gadgets or businesses will be gone before the year is up.  2011 will be the last year the handheld game platform will see the numbers it has seen.  It will follow Pong to the tech grave as being overcome by new and more engaging games technologies.  Those technologies are already here and the death has been accelerated by Amazon's new tablet.  Content is king and Nintendo does not have it.  Hey Nintendo, maybe you should reconsider those apps that found their way onto the Android Market.  License fees, man, licensing fees.