Yes...I blatantly used a G.I. Joe-ism in the title. Why? Perhaps just to reel you in from Planet Lotus ;-)
In my recent work with customers and all the hubbub around social networking and collaboration, it's quite evident that collaboration is cool again. I'd like to think that Lotus is playing no small part in this, as our offerings in this space are truly exciting. I'm more enthusiastic about Lotus than I have been in years and that's saying something since you know I'm a fanboy! :-)
But one concern I have is an issue that I encountered many times in my career as a consultant, and that is we are spending a lot of time driving home the technology component without a lot of emphasis on what I believe makes up the other half of a successful collaborative ecosystem: the culture.
If you are introducing the idea of collaboration for the first time or are trying to kickstart a stalled initiative, addressing the cultural component of collaboration is critical. It's not enough to have the best technology for supporting collaboration installed in your company...you must have people that will leverage that technology in the context of their business goals.
So what does a successful collaborative culture need to get started? Here are my ideas, but I'd like to hear yours as well.
*Collaboration Champions: Some folks that embrace the concepts right off the bat and serve as the "go to" people when other employees have questions and need assistance. These are usually the employees that "get it" immediately when a new collaborative technology is introduced and quickly become proficient in its use, both from a technical standpoint and from a business focused one.
*Provide Recognition: Many companies overlook the importance of praising a job well done. For many employees, helping others in a collaborative culture is an intrinsic reward unto itself, but they still value when their efforts are recognized. Rewards don't always need to be monetary in nature. In fact, the top providers in a social network or collaborative initiative often find the kudos to be the most rewarding aspect of participation.
*Proper Training: Argh...don't get me started about companies that don't train people on new technology. How often have we heard "Lotus Notes s*cks" because the users were unaware of how to successfully use the software. Yes, we wish all software could be so easy to use that you don't need any training, but with enterprise software we're not there yet. Thus, providing instruction is an important aspect of the collaborative culture.
*How Does This Help Me?: One of the most compelling arguments I've seen in a successful implementation of collaboration technologies is when the company can clearly articulate the vision to employees and answer the question "What's in it for me?". Let's be honest...while the recognition mentioned above certainly is a motivator for some, the majority of employees will just think that this is another one of those things management does to annoy us. ;-) If you can help employees see how this initiative will make their job easier, help them make more commission, not have to work overtime, etc., they'll buy into the movement much more quickly.
There's obviously a lot more to this subject and I've just scratched the surface here. I'll save more for another post, since I think a lot of you are sick of my long essays! :-) However, one point of note. Not many consulting organizations address culture as a significant part of a new customer collaboration engagement. I think there's some good business potential there. Who will tap into it?
By now many of you have probably seen the great little comic on the "It's Just a Bunch of Stuff That Happens" site about Simplicity, but if not follow the link then come right back...
Pretty true to life, eh? I recognized the bottom example in many, many (many, many, MANY) Notes applications I have seen through the years and I'm sure you did too, which is why we all thought it was so funny in a sad sort of way. But I tell you what my friends, the idea of simplicity is sorely lacking in the enterprise software world and this causes an undue amount of headaches for our customers, for our bosses and for ourselves. Is there something we can do about it? Absolutely. We can say no to complexity in the applications that we design.
To be fair, although the comic is funny, it's not really being equitable as it compares Google and Apple to an enterprise application, but the idea is not so bad. One of the tenants I've tried to instill in younger developers as I've mentored them is that complex business rules do not necessitate complex interfaces. In fact, I think the opposite is true. We need to work even harder to streamline and simplify the interface when the complexity of the business world rears its ugly head. We're all overwhelmed with the amount of data we have to deal with on a daily basis, so we appreciate (and even long for) those things that are easy to use. If we're trying to delight our customers and make their experience in our applications a pleasant one, what better way to achieve this than to employ our skills to craft a simple solution.
Here's an example from my own experience. Some of you have seen this in my talks at Lotusphere or the View conference, but it bears repeating. I worked for a few years for a "global tire manufacturer headquartered in Akron, OH". They had a pretty mature Notes infrastructure that had been around for quite a few years and some pretty complex systems were developed in Notes by IBM consultants there. One of these was a beast of an application called Vendor Billing, but I affectionately called it the Hellspawn. (OK...I didn't really call it that at the time, but in thinking back I should have!). The Hellspan was one of those systems that you dread to come across when you're a consultant. A multi-tentacled, multi-NSF monstrosity that had become more and more bloated over time, since developers just added new features without refactoring or thinking about what future consequences their design choices might make. I don't believe anyone did this out of lack of skill or with any ill will toward future developers, but rather the reality of a complex business process coupled with a desire to make changes quickly and cheaply provided the perfect environment for such a system to come into being.
Vendor Billing...excuse me...Hellspawn, was a system designed to gather up information about all the various IT services an employee at Great Big Tire Company made use of. This was managed through a series of documents that basically captured the services a given person was "subscribed" to. In addition, other databases in the Hellspawn suite stored employee department information, billing codes, rates, etc. It also interfaced with some of the company financial systems that were not in Notes. At the end of each month, some *really* nasty and complex agents gathered up the information from the various databases, determined how large each user's mail file was, spun around twice and sacrificed a chicken to the Gods of Complexity and spit out a document for each user that listed their costs for the various services. All of this was pretty much backend stuff and this far was hidden from the eyes of the users (thank goodness!). Unfortunately, the final result, that cost document, was used in a series of views that the end users would interact with.
For a good 29 or 30 days out of the month, the users were blissfully unaware of the evils that were going on within the Hellspawn, but when it came time to for managers to review their charges for that month, there was no escaping the task to be done. At this time, a manager would open the database and navigate to the main billing view. Within this huge, *horizontally-scrolling* view, the manager could see the totals for each subscription for each of his employees. On average, each manager spent about 30 minutes figuring out their IT charges and it certainly wasn't a fun or efficient way to spend half an hour.
I was first introduced to the Hellspawn shortly after I started at Great Big Tire Company and I'll admit that I was a bit scared of it at first. Certainly the idea of Simplicity was far from the minds of the people that developed it. I've no doubt that they were smart folks. There were custom LotusScript classes to perform operations on linked lists and the like. I'm quite convinced that some programmers make things more complex than they need to be simply to show off their "mad skilz". There's certainly a place for that, but in my opinion it's not in enterprise applications. Thus, my first thought as I looked at this beast was that it needed to be simplified...greatly!
I started, as I often do, by building some quick prototypes that distilled the basic essence of the application down to a single question: "What were the charges for my department?" Once I determined that this was what this system was really trying to tell the end user, the interface became quite obvious and instead of a massive view with the ability to navigate to other massive views, it was just a single field to enter the department number a la the Google search box. When a manager entered their department (which was of course remembered for the next time) and clicked the button, the new code I wrote went out and gathered up the required numbers and showed them on a new document which functioned as the "monthly report". This was formatted in a clean and simple way, such that they really needed to spend no more than 30 seconds checking their numbers. That's a pretty decent time savings per month per manager, eh?
As I worked on the new UI, I also spent a great deal of time under the hood, trimming things, refactoring code to make it easier to read and hopefully more efficient. Even though the business rules were still complex, I strove to make the managing of those business rules as simple as possible. This is our challenge as application developers and is as much an art as it is a science. Based on the hundreds of Notes apps I've seen in my career, here are some ideas to get you started:
1. Not every database needs a three pane UI. As Nathan is fond of saying, "It doesn't all have to look like mail!". Pick the UI layout that makes the most sense for the task at hand.
2. Skinny down your forms and pages. Most developers try to cram too much into a single screen. Instead of this approach, try a more fluid design that brings the most important information for the current task to the forefront of the user's attention.
3. Use views wisely. Not only are views one of the biggest performance hogs, but it's not necessarily efficient to use a view to find what you are looking for. Provide other mechanisms to getting at the data in your app, such as a document search like in my example above.
4. Examine other apps that you find easy to use and try to determine the reason why you like them. See if you can bring some of these themes into your own applications. A great example of this is an ajax-type ahead feature. It was immediately evident when we first saw examples of this technique that it would be useful, but I really feel now that it is almost a must have. It's such a great device for simplifying data entry in many situations and I try to incorporate it into my designs whenever I can.
5. Think outside the box. Yep, it's a cliché but it's still true. Sit down with a piece of paper and make your design as simple as you can, trying to forget the bounds of what you can do within the client. Then, once your design is done, jump in and figure out how the heck you are going to do it. For me, this has been a powerful technique, as I've come up with some great interface tricks by "drawing myself into a corner". :-)
As my life and work gets busier and busier by the day, I am more convinced than ever that simplicity is one of the greatest gifts a designer, engineer, boss or politician can give us. I'm sure many of you feel the same, so strive to make the idea of Simplicity an integral concept in all of your designs and save your users (and yourself) from the Hellspawn.
Hi Folks...Just a quick note to let you know that I'll be coordinating the Open Labs at the Lotusphere Comes To You event in Columbus, OH, next Thursday the 20th. If you have a chance to come by, please do and don't hesitate to introduce yourself!
The Open Labs give you a great opportunity to sit down and play with our new products, from Notes to Sametime, Quickr to Connections. Hope to see you there!
In my current role at IBM, I'm in technical sales for the Cleveland and Pittsburgh areas. Thus, it seems a little hard to justify that heading over to Dublin in June will help me sell Lotus software here at home. Then again, I would be "expanding my thought leadership". :-)
Hmmm...what do you guys think? Perhaps I could give out his address and we could all spam him! ;-D (Just kidding...I know he's started reading my blog now).
Well...either way, it's going to be one heck of a conference this year. Go if you can!
I got asked a question the other day that I didn't have a great answer to. A reader wanted to know of a way to limit the number of characters that could be typed into a field (e,g. restrict the user's entry to 30 characters). I don't remember having a business requirement like that in a Lotus Notes application for a long time, but in the past I'm sure I would have handled it with some form of input translation or validation formula using @Length. I'm vaguely aware of a script library I had at some point that probably included some code to do this, but it's long lost in the catacombs of old databases from past jobs. Regardless, I knew that any of those old solutions would be far from elegant in today's interface. Nope, what I needed was to whip up a fresh approach that presented a modern UI experience. Here are the characteristics I would want if I was implementing this feature:
-Immediate feedback about how many characters I have left -Automatic trimming of my text entry once I hit the maximum number of characters -Unobtrusive changes to the UI as I enter a length restricted field -A flexible and simple way to implement the functionality multiple times on the same form.
Click image for animated version
First, the code that does the checking. I tried to make it fairly generic.
The textLimiter function accepts the name of the field to be checked, the name of the field that serves as the counter and the maximum number of characters as arguments. In the If statement, we compare the number of characters (inputField.value.length) to the maximum allowed. If the string in the given field is longer than the max, we use the substring function to trim it to the appropriate length. If not, then we know we haven't reached the max length yet and the user can still type characters into the field. As they do so, the Else statement updates the value of the counter field by subtracting the length of the string in the given field from the maximum allowed number of characters. Pretty simple, no?
That's all that is housed in the JS Header of the Notes form. Now let's take a look at one of the fields that implements this code. For purposes of this example, I added the functionality to two fields. For each, I used the onFocus event of the field to initiate the call to the textLimiter function and used onBlur to clear the setInterval method. You can see how this appears in the "UserTitle" field below:
(Editor's Note: I used some creative editing to show the two events in the same screenshot)
As you can see in the onFocus event, I just set some variables for the given field then use setInterval to call the textLimiter function every 10ms. inputName is the name of the field you are limiting the characters in, counterName is the name of the field that is counting down the number of characters remaining and charLimit is the maximum number of characters allowed in the input field. The onBlur event includes the call to clearInterval, which means the client will stop invoking textLimiter as soon as we exit the field. (We'll skip the other stuff for now and come back to it later).
With just those few pieces in place, the functionality works quite nicely. As you type in the given field, the text underneath updates you with a message as to how many characters you have remaining. It's not enough to stop here, though. In order to keep the screen as streamlined as possible, I don't want any user input messages to be displayed except for when I need them. This speaks to the third point in my list of requirements. What I want to happen is for the helper text to appear as soon as I enter the field and disappear as soon as I leave it. That's where the rest of the code comes in.
I chose to implement the dynamic nature of this functionality with simple hide-when formulas. I placed the helper text on a separate line, then set it's hide when formula to hidden except when the "CheckField" counter was equal to the name of the counter's corresponding input field.
The first line sets the value of "CheckField" to the name of the input field that corresponds to this counter and the second line "clicks" the hidden button, refreshing the doc and showing the counter line. When the user exits the field, we just do the reverse, setting "CheckField" to null and refreshing the document again to hide the counter.
When you put all this stuff together, you get a nice little bit of functionality. It accomplishes the goal of restricting user input and does so in a fairly elegant way. You also get a handy little example database where you can try this out yourself.
Addendum: Well, what do you know. Had I not already done the work and typed up half of this post, I would have just quit this as it turns out that Mr. Robichaux has done something very similar. Our approaches were quite alike, but I think this one has at least one advantage in that it keeps the field trimmed at the set number of characters. In any case, if you'd like to see how he tackled the problem, check it out here.
It's a sad day for gamers around the world, as Gary Gygax, the creator of Dungeons and Dragons and the man considered the father of the role-playing game, passed away today. He was 69.
When I heard the news, I was surprised by how sad I felt. Although I haven't played the game in many years, it was a big part of my life when I was younger. I still remember the excitement when I saw that red box on the shelf at the toy store in the Foothills Mall. It had an epic picture of a fighter about to engage in a fierce battle with a dragon perched on huge pile of gold and it immediately captured my imagination. I'd heard of D&D before and knew a couple kids that played it, but I had not seen it in person until that moment. I learned from the box that it was a game played in your mind and that you became an active participant, like an actor in a story...AND it had these cool looking dice with all kinds of weird shapes. For a shy, bookworm-ish Junior High kid, this sounded perfect! I went home, scrounged together my money and rode my bike as fast as I could back to the store to buy that set. Little did I know then that it would be my introduction to the fabulous worlds of role-playing.
A short time later, I met some guys that played Advanced Dungeons and Dragons. Whoa...these were the cool kids (haha...pretty funny when you think back...they were of course the über-nerds to the rest of the school). When I saw the hardcover rulebooks, I was enthralled. There were tables galore and rules to govern every bit of action you could imagine. I was in geek heaven! From that point on I considered myself an AD&D player and spent a good amount of my money purchasing books, adventures, supplements and dice. Oh the dice...in so many cool colors and finishes!
I played Dungeons and Dragons with a core set of friends most of the way through high school (yeah...not a whole lot of dates among our group! :-) It was a great way to spend our spare time and kept us out of trouble. In addition, in my quest to learn as much as I could about the medieval period and to become a top-notch player and DM, I was exposed to a ton of great learning material. I'm convinced that I became a better writer, enjoyed history more and even loved my statistics classes (hmmm...I am a freak!) because of my involvement with the game.
Gary Gygax was the man that invented this craze that kept me penniless (and dateless) for so long, but when I think back to all those games, they were some of the most fun I've ever had. He was also a superbly imaginative writer and all around great person who continued contributing to the hobby all the way up to his death.
So...I failed my saving throw vs. sadness today when I heard about his passing. Here's to Gary. Thanks for all the good times!
Hey...Why Should I Care About The Interface? (Or...That's Just Touchy Feely Stuff, Isn't It?)
Because I'm a big fan of code reuse, I'm going to shamelessly copy and paste an essay I wrote when I first moderated a forum for LotusUserGroup. It's about why I think UI design in Lotus Notes is necessary and I believe it's an important talking point. I'm finding that as organizations are getting serious about deploying Notes 8, more developers than ever are interested in the concepts of usability and interface design. I've noticed an uptick in the amount of mail I'm getting from people who have just found my site, so this also serves as a good introduction to what this place is all about. Cheers!
If there is one question I have been asked most often by Notes developers, it is "Why do you spend so much time designing the interface for your applications?". The one line answer to this is "Because to the user...your interface IS the application". Because of the very nature of our jobs as developers, we tend to get wrapped up in the technical details. We love to come up with innovative new tricks, revel in writing a particularly efficient block of code and geek out when it comes to the latest and greatest technology. All of this, however, pretty much means squat to the guy or gal sitting in front of the screen trying to actually do something with your masterpiece. Users don´t really care about what´s behind the curtain. Rather, they are interested in one thing when they are using your application..."How can I get my job done quickly, efficiently and easily?!"
The goal of any good interface is that it should be unobtrusive. You´ll often hear designers talk about "getting the interface out of the way". This is your ideal to strive for. When your user can enter a flow state and accomplish the task he or she set out to do, WITHOUT having to think about how to USE the application, then your job as a designer has been highly successful. To put it another way, the developer is given the task to make the product transparent to the user. The goal isn´t to get people to like your application...it is to make it so that they don´t really notice the application at all. In the end, a clean, usable interface means happy users.
"OK...enough with the touchy, feely stuff", you say. "My users are business professionals...they don´t care what it looks like as long as it gets the job done!" Boy, have I heard this more than a few times. In a few special cases this might be true, but believe me, for the most part your users DO care. There are many benefits to designing a good interface. Although somewhat hard to put an ROI on, good UI design often saves money, since the users tend to request fewer changes. User acceptance of the applications is almost always higher than when the interface is ignored and users report greater satisfaction with the end result. Remember that it is human nature to want to use things that are functional and attractive. This fact is what makes the iPod such a spectacular hit. It´s just one of many MP3 players, so what makes it so great? The combination of aesthetics and usability (it´s so easy even grandma can use it) help it stand out in the crowd. To bring it closer to home, if you´ve ever had a user choose an inferior product over another more robust one simply because "it looks better", then you´ve experienced why interface matters. Perception plays a huge part in satisfaction.
So...if you are convinced that designing a good, usable interface is important, how do you go about accomplishing that task? There are many ways to start learning about usability. There are several great books on the subject and many websites that are great resources. I´ll post a listing of my favorites in a separate thread. My main point of advice for Notes developers would be to practice what I call an "interface first" design methodology. Basically, I use a pretty typical RAD approach to Notes development, but I have factored in UI design as a major component of that. The initial efforts that take place with an interface first design approach focus on determining what the user will see and do in the application. I am concerned at the very beginning with what the UI will actually look like because how the user will work with the interface elements usually has a direct impact on the code you have to write. As an example, I had a complex application in which multiple "child" documents had to be created for a given "parent" document. I could have simply used the standard Document and Response type forms with all the functionality that Notes provides for me, but in doing the initial UI design work, we came up with a much more elegant and simplified solution...at least simplified from the user´s perspective. In the end, the design used an embedded view/embedded editor model, which was harder to code but made the UI extremely easy for the end users, who were all new to Notes. Had we not focused on the interface in the beginning design stage, the application would not have been nearly as successful.
Employing an interface first approach takes a little getting used to in the beginning, but pays huge dividends in the end. How many times have you gathered specifications from a user, built the functionality and delivered it, only to have the user tell you that it´s not really what they wanted? Be honest...it´s probably more times than you´d like to admit. Have you ever thought up a cool design feature that you were sure they would LOVE, only to find out that they don´t use it, or worse, don´t LIKE it? I´m sure this has happened to the best of us. By using an interface first design method, you can avoid many of these problems. It´s not fool-proof, but it gets you a lot closer to the desired end result a lot faster than traditional methods.
So what does using an interface first approach actually mean? By using this method, you actually build the interface for your application BEFORE you write a lick of code. This can take many different forms, but essentially involves drawing out what all of the screens will look like as a first step. I use low-fidelity prototyping for all of my projects. This is just a fancy name for sketching out the interface on paper...using pencil, pen, crayons...whatever you have handy. Some people prefer to use HTML or a graphics program to design screen layouts. This is fine too, but takes more work. After I have gathered enough requirements so that I feel I have a good grasp of what the user is looking for, I grab a stack of fresh blank paper and jump into the design process. I draw out the fields, sections, graphics...everything that I expect will be a part of the application interface. This doesn´t have to look good. In fact, I encourage you to not spend a lot of time drawing these screens. They´re very likely to change and you might have to do this several times.
After your paper prototype is complete, schedule another meeting with your customer. Ask them to look at the screens and give you feedback. This can be formal (conducting a full-fledged usability testing session) or very informal...whatever you are more comfortable with. Take time to explore different scenarios. If your database is for entering customer complaints, ask the user to take the role of a customer service representative and have them walk through what they would do while looking at your paper prototype. Ask them to talk out loud as they do this, explaining each action. You´ll be amazed at the insight this gives you into the mind of the user. When you find something that doesn´t belong on the form, cross it out with a marker. Need to add some new fields? Just draw them in with a new color. See why it´s good not to spend a lot of time tweaking your prototype? You´ll end up changing them a lot.
When you come back from your initial paper prototype session you may be surprised at how much has changed. If you nailed it the first time, good for you! More often than not, however, you´ve got some changes to make. Quite literally, you should go back to the drawing board and build the next iteration. For a typical application, I will build about two or three paper prototypes. This may seem like a lot of work, but in reality doesn´t take too long.
So...you´ve built your paper prototypes, gone through some iterations with your users and have a pretty good feel for what the interface will look like and how the application will function. Now what? Now, go about your business...doing what you do best. Start slinging your code, basing it not only on the business requirements, but also on the interface requirements that you´ve collaboratively developed along with the user. By designing the interface first, you are already halfway to user acceptance and in my experience, have also made the users more passionate about the application. They feel invested in it much more than in traditional programming methods, where you may have only met with them once or twice. When you finally deliver that application, I guarantee it will be almost exactly what the customer asked for...and that, my friends, is exactly why we do this!
I've not read a lot of the "Dummies" series, but whenever I've picked one up, I've been impressed by the quality of the product. "Web Usability For Dummies" is no exception. In about 300 pages, the authors do a good job of laying the foundation for a solid understanding of the important aspects of usability. It looks like this book might be out of print now, but you can probably find a copy at your local library or via Amazon.com.
What I particularly liked about this book was the focus the authors give to the Usability Design Cycle. This is a process that helps answer questions about designing for usability and is broken into six steps that are performed in an iterative fashion. The usability design cycle starts with "Study the user", then leads to "Set goals", "Design", "Build", "Test" and finally "Deliver product". It's truly a cycle since the process should be iterative, each part building upon the previous step. As the authors state in the beginning of the first chapter, there are many good books out there that focus on the "build" part, but not nearly enough on setting goals, designing or testing, which arguably are the most important. Thus, they make this the thrust of the book and why I think it's worth picking up.
Chapter 1 begins the book with an overview of what web usability is all about. This leads into a discussion about studying your users (the first part of the usability design cycle) in Chapter 2. Sharp readers will remember that Mary Beth and her team kicked off the whole Notes 8 project by doing this very thing...studying what the users of Lotus Notes wanted, how they interacted with the software, etc. While the focus of this book is clearly on web design for external websites, there are enough nuggets of information that you can use for internally driven sites or application design in general. I liked the section in Chapter 2 that dealt with actual customer visits. I think this is something more developers need to do and this part of the book might help you become a little more comfortable with the process.
Chapter 3 looks into the whys and wherefores of setting goals for your website. This includes issues such as determining what needs of your users you really want to meet, creating actual business goals, using metrics and setting goals for the site's usability. This chapter rounds out the first part of the book.
Part II of "Web Usability for Dummies" (Chapters 4-6) is all about the design of usable sites and includes topics such as organization and site navigation. Part III (Chapters 7-9) explores the concepts involved in creating usable web pages. Since this book is several years old, there are bits and pieces which aren't really relevant anymore, but as a whole the ideas are still pretty solid. If you're a Notes developer who is just interested in usability in general, you can probably skip these parts of the book, as they are pretty specific to the web.
The final parts of the book deals with "Reaching a Broad Audience" (Part IV, Chapters 10-12) and "The Part of Tens" (Part V, Chapters 13-16). Subjects touched on include broadening the appeal of your site as well and several nice lists such as Do's & Don'ts, ten cool tools for usability, etc. Chapters 11 & 12 are my favorites since they deal with (surprise, surprise) usability testing! The authors feel that this subject is important enough to warrant two chapters and this book is probably worth tracking down just for their advice on the matter.
When all is said and done, "Web Usability For Dummies" is a fun, quick read presented in the standard Dummies fashion. Experienced designers may not find a lot of new material here, but this book would serve as a great introduction to many of the important concepts in the field of usability. With used copies available on Amazon for as little as $3.20, it wouldn't be a bad investment to add this to your reading pile. While certain chapters may not directly pertain to the work you are doing, the first part and last part of the book provide a very compelling case for usability and are certainly worth the cost of admission.
OK...well, I didn't really kill it, but I did do something I've been threatening to do for a couple of years. I cut the hardline. Yep, no more signal getting to any of the TVs in my house unless they are coming via DVD or a related component (I still have my LaserDisc player! :-) We're free of so much of the complete and utter crap being beamed into our house and I have to say it is one of the best things I've ever done. Let me explain.
I've never been a huge TV fan myself. There are certain shows that I think are great, but by and large I've managed to not get sucked into the routine of TV (you know...crashing on the couch and turning on the set to watch anything just because you're tired or bored). DVRs have certainly brought about a great revolution in how people watch TV. I've had one for several years and they've helped filter out a lot of the junk. Even so, in my mind, ever since the advent of the reality show and the preponderance of news programs that seem to focus on nothing but the worst in humanity, TV is like a portal to the land of stress and brain rot.
Don't get me wrong. I think there are some shows that have a lot of value. I always liked stuff on PBS, Discovery Channel, National Geographic, etc. Plus, there are excellent sci-fi shows ("Firefly", anyone?), dramas, and so forth. Hey, I'm far from a prude. I must confess a love for shows like "Family Guy", "South Park" and yes, even "Drawn Together" (oh man does that show try to offend every demographic possible! :-D
But...and this is a big but...I think the majority of what is on is just not worth my time to sit down and consume and this goes double for my kids. As parents, my wife and I never let the kids sit and veg for hours in front of the boob tube, but as they've gotten older, the shows that they want to watch have started straining the limits of what I want them to see. Reality shows are really what broke the camel's back for me. Most of these shows feature completely hollow, vacuous people that are held up as examples of celebrity and success. I am trying to raise intelligent, thoughtful and caring children and most reality shows glamorize the opposite of this. I have no illusions at this point that my influence as a parent is the main one in their lives. Basically, as soon as they hit school, their peers become a huge influence on them and I know this. It becomes my job then to counteract the negative stuff as much as possible and guide them in making appropriate choices. Having these crappy shows readily available at the flick of a switch (and let's face it...they seem to *always* be on) doesn't help, so one motivation for turning TV off is to remove the temptation. Another motivating factor is that TV is addicting (good article here). I started to see the kids want to switch on the box whenever they felt like there was nothing to do. Rather than cultivate this behavior, I wanted to teach them to find other ways of entertaining themselves.
Last summer, we did an experiment and disconnected the satellite box for three months. I told the kids that they weren't going to just sit around and watch TV all the time and that they needed to figure out other activities to occupy themselves. Honestly, the first four or five days were hard for them. They kept complaining about how bored they were. We soon started to see, however, a change in what they were doing. Once they realized I was resigned to carrying out my plan, they did start finding new forms of recreation. They started playing games together, they went outdoors a lot more ("I'm going outside to play"...wow, it was great to hear that so much), and they devoured even more books than usual (we're very happy to have instilled in them a love of reading since they were small). It was a great success to have them break the TV habit so quickly and we actually kept it off for longer than just the summer. Once the long, cold winter came, though, they all (my wife included) talked me into hooking it back up. I did so reluctantly, and with a promise that I would be returning to this experiment soon enough.
Unfortunately, I was under contract to Dish Network until the middle of January this year, so I resigned myself to waiting until the time expired. After returning from Lotusphere, I did the deed. A brief call to customer service and then a slightly longer call with the folks that try to retain you did not deter me and soon my goal was achieved...we were TV free!
As expected, there was some initial resistance on the kids' part, but we did avoid an all out mutiny. I do recall comments like "You've ruined my life. Now I can't talk about shows with my friends!", but otherwise it wasn't too bad. :-) We're now a little over a month in and I am very happy. My wife seems happier too. She watched a lot of news before, and like me, the general tone of the various news programs usually left her grumpy, if not all out pissed about a certain news item. We've been making frequent trips to the library to stockpile books and the kids have plenty of time to do homework, play their sports and participate in activities, all without feeling that they are really missing anything.
Oh yeah...one more great benefit. I'm saving about $70 a month not paying for cable or satellite service. Cha-ching!
Lest you think that giving up TV means giving up watching the shows you like, think again. Between internet downloads (iTunes and the like), services like Netflix and the general availability of so many TV programs on DVD, you can still get your fix of quality programming, all without the channel surfing (which tends to waste *a lot* of time) and the insidious commercials. We've been enjoying watching "Firefly", "Buffy", "The Profiler", etc. We also watch movies as a family, something we've always liked doing, especially since I built a home theater in the basement.
To recap...killing off the TV has been a huge success for my household. For those of you that like lists, here are the pros and cons in bullet form:
More time to spend on fulfilling activities with the family
Less stress from TV news and related programs
Immediate monetary savings
Less exposure to brain-dead, rich, silicon-enhanced bimbos (for the kids)
NO MORE COMMERCIALS!!!
NONE Less exposure to brain-dead, rich, silicon-enhanced bimbos (for me ;-)
(Editor's note: Before the advent of the Internet, I might have listed missing out on popular culture/being less aware of the zeitgeist as a con, but being connected in an always on world certainly negates this con).
Wow...I didn't intend to ramble on so much, but I wanted to write this as much to chronicle the experience for my future self as to perhaps inspire some other people to give it a try. It really does feel great to be free of TV and I don't think we'll ever go back!
Thoughts about Collaborative Technologies and User Interface Design...
By day, I work as a Collaborative Technologies
architect and champion the cause of usability and user interface design. But don't judge me
by my blog...I'm using a template. Cobbler's children and all... ;-)