What are those buttons doing in my class?

The discussion between Martin Fowler and Elliotte Rusty Harold on Humane vs. Minimalist approach for collection interfaces has already spawned sufficient debate over all the factors.  However, Elliotte used a bizarre analogy between remote controls and class interfaces and for some reason this comparison bothered me. Then, I thought "Hey, there might be something to learn from the remote control".  So, here is yet another perspective on the issue:

OK, first a quick review of my history of media center remotes:

• First there was the remote - cool
• Then came the the features with buttons - I started making purchase decisions based on which remote had the most buttons - ahhhhh
• Then came the multi-purpose buttons with special modes - more features!?
• Then came the other components w/ more remotes - hmmm??
• Then I could  not find the remotes - Oh, I can tape them all together!?
• Then I noticed  that the controls all had different shapes of buttons with different layouts and different functionality - hmmm?? 
• Then I realized that I didn't understand most  of the buttons - what language were these guys speaking - not mine???
• Then I eventually remembered only the buttons I use - I still can't find the stupid remotes.
• Then Apple introduces front row that provides a new construct (easily accessable menus) for finding features -  now they are talking my language
  
• Then I got rid of most of my remotes - they are reduced, but I would prefer having just one!
   

Note: This may not directly reflect my own or any actual history or occurences. 

Lessons learned:

• I hate searching for remotes - I can never remember where I put it or what I called it - they should always be where I want them
• Lots of remotes are not good - one remote is better
• I don't have a real issue with buttons as long as their behavior is predictable and work similar to other buttons
• I hate having to press different buttons to achieve my goal - I confuse easily and have a poor memory
  
• The laguage should be mine (the guy who wants to be entertained) - not the feature happy designer who wants me to press each and every button
  
• I mostly like  to be ignorant of the small details of how the remote/component works - details should not be in my face every time I use it
• Remote should not require large context switch - it should just do what I need

Overall Lesson:
Really creative products, that make my life better, seem to ignore old rules and boil the design essence down to the consumers ultimate goals. 

Conclusion:
I guess I prefer minimal controls/classes with intuitive interfaces that don't distract me from what I am doing.

 

Comments

[krishna]

You made some really good points, but the conclusion.
All the lessons learned are true with how classes are in ruby (humame or whatever).
* I hate searching for remotes - I can never remember where I put it or what I called it - they should always be where I want them
N/A in this context.
* Lots of remotes are not good - one remote is better
N/A in this context
* I don't have a real issue with buttons as long as their behavior is predictable and work similar to other buttons
this is one of the core principle of ruby.
* I hate having to press different buttons to achieve my goal - I confuse easily and have a poor memory
you will have to do this in java, ruby reduces most of it.
* The laguage should be mine (the guy who wants to be entertained) - not the feature happy designer who wants me to press each and every button
N/A
* I mostly like to be ignorant of the small details of how the remote/component works - details should not be in my face every time I use it
thats one of the bad points about java, i have to remember where the array index starts from. but first and last methods does do it in ruby.
* Remote should not require large context switch - it should just do what I need

[Richard Cowin]

Krishna,
I agree that Ruby does meet many of these goals.

However I am not sure I agree with your N/A conclusions.
I might say that if you have too many classes in too many packages, things get easier to lose.
I might also say that a language that has customizable DSL support would be nicer than having to use several different languages, each with its own environment.
I also think that interfaces should be geared towards the consumer of the interface and not have the details of the design leaking through the interface.

However, If I were to actually say those things, it may make me sound biased.

And, I did this small detour/exploration to get around the language biases and back to the underlying design concerns. Sometimes we get caught up in all the rules have ben created for historic reasons and may or may not even still apply. But, I mostly did it for fun.

doh! I should have added the enjoyment factor somewhere in the conclusions.

[Kevin]

Sony RMAV 1000 :)