My 10 Years in SharePoint

Robert Bogue December 24, 2011 No Comments

I vividly remember working in publishing in 2000. We had just survived what was supposed to be the cataclysmic events of the millennium. Of course, we were not plunged into some dark abyss where power plants stopped functioning and traffic lights started showing green in all directions. Microsoft was talking about moving Microsoft Office to the server. They wanted to play in the document management space. They also had a rag-tag group of folks from Vermeer Technologies who were demonstrating interactive web sites with FrontPage extensions. The result was Microsoft releasing SharePoint Team Services (STS) and Microsoft SharePoint Portal Server 2001 in relatively short succession.

The problem was that STS and Portal Server were as different as night and day. Portal server was built around the Exchange database engine and STS was built around SQL server. Portal server was focused on documents and had versions. STS was built around lists of items and didn’t have versions.

Ten years ago there were expensive document management systems were expensive. You only implemented them if you had a major process to automate. Lists were being created with Microsoft Access – or more commonly Microsoft Excel but sharing and managing that list data was difficult. Inside an organization the spreadsheets would fly back and forth. The lists were shared externally via email as well – sometimes unintentionally. Coordinating changes was a huge challenge.

I started building on SharePoint in 2001 with a project designed to improve the ability for a packaging company to communicate with its partners. It was innovative at the time – and it meant struggling through the development on a platform that wasn’t really ready for people to program on it. The version of the Exchange database engine that SharePoint used had issues – and it wasn’t really designed for what it was being used for so we found quirk after quirk. I vividly remember that none of the monitoring tools would tell us that SharePoint was down because deep in the core SharePoint would send an HTTP 100 Continue message if it ever couldn’t respond quick enough. That’s great if you’re waiting on the database to return a record but horrible if you’re in a deadlock situation where the resources are all consumed. It meant that we had to write custom tools to plug into the monitoring tools to detect if SharePoint was down.

The 2003 versions of the software moved Portal Server to a SQL database engine but lost versioning in the process. The net result was organizations that really couldn’t upgrade because they had built processes around the versioning – sure there were the backwards compatible document libraries in 2003 – but that was just the same as leaving 2001 around since they still ran on the Exchange database engine and had a completely different set of features which served to create confusion.

By about 2005 my entire world became SharePoint. Instead of doing ecommerce development I was building intranets and integrating systems into SharePoint. Mostly it was moving from a system designed to support external folks to supporting internal folks. The real benefit was that I was used to high-activity web development which most developers of the time weren’t used to – and in many ways high volume web sites is still a rarity.

In 2007 portal server was dropped from the name and Office was added. This reflected the much stronger integration to the Office client applications than had ever been possible – but the loss of the word Portal was the definite signal that the world had changed. It used to be that everyone wanted a portal, a place from which everyone would launch into the corporate resources. However, by 2007 it was clear that the word portal was too fuzzy and confusing to be useful. After all, we were in the age of search, not the age of portals. Yahoo had lost to Google.

In 2007 we were finally back where we started with versioning with a few enhanced features along the way, like our new workflow engine. However, the big change was less about SharePoint and more about the transformation SharePoint had caused – or at least participated in. By 2008 the document management market was starting to soften. People realized that the big systems for document management weren’t needed so much anymore. SharePoint 2007 might not handle large organization document management needs but most organizations could see value by using SharePoint.

By 2010 we finally had the set of tools in the product to support larger scale document management scenarios. Development tools were integrated into Visual Studio so we didn’t have so much heavy lifting. No longer were we hand-crafting XML, Text files and creating CAB files. Finally we can focus on getting things done rather than dealing with the mechanics of SharePoint development.

I had the honor of spending 10 months working on the Microsoft patterns and practices SharePoint Guidance – so we’ve finally got some good guidance for SharePoint development. In short, I believe we’ve finally got a platform for development.

Today, we’re thinking about enabling corporate developers to create solutions by developing code in the Sandbox. We’re looking at enabling organizations to have SharePoint hosted in the cloud. Strangely while I’m having conversations with clients about Sandboxed solutions and the cloud very little of what I do fits in either of these categories.

It’s a pretty different world than 10 years ago when I started – but I believe it is honestly a better one – at least when it comes to SharePoint.

Article: Strategies for Integrating SharePoint into Your Learning Strategy

Robert Bogue December 24, 2011 No Comments

Like it or not, 2 out of every 3 organizations are using SharePoint, Microsoft’s unstoppable platform for communications, collaboration and information management. SharePoint can be a great tool for learning organizations and it represents potential competition for a learning portal. The good news is that SharePoint’s array of options for integration that make it an ideal platform to marry up with an existing Learning Management System (LMS).

Without an LMS
Perhaps you’re just starting to get your programs off the ground and you don’t have an LMS in place. SharePoint has a series of options for you. You can start with the SharePoint Learning Kit (http://slk.codeplex.com ) which supports SCORM 1.2 and SCORM 2004. The basic features such as managing assignments, individual classes and training programs are supported. While there are certainly richer for-pay options which bolt on to SharePoint, you can get your feet wet with a SharePoint based LMS virtually for free. The SharePoint Learning Kit (SLK) is free and will even run on SharePoint Foundation so you don’t need a separate license to use it.

The for-fee SharePoint based LMS tools add more types of quizzes, surveys and better administration tools for a price. The good news is that from a price-perspective the SharePoint based LMS solutions tend to have lower costs because they do not have to make investments into basic document and list management, security or portal features – all that comes “for free” from the platform.

Pouring Concrete around Your Development in SharePoint

Robert Bogue December 24, 2011 No Comments

Several times over the last few weeks I’ve been confronted in one way or another with the need to protect coding from the interloping of the user and site administrator in SharePoint and conversely I’ve seen attempts to pour concrete around development that could be better left in sand so that it could be changed and moved. Through this I realized that there’s a need for better understanding around the model shift with SharePoint and its impact on software configuration management (SCM).

SharePoint’s a Different Kind of Animal

It’s often been said that SharePoint is a desert topping and a floor wax – paying homage to Shimmer a fictional product from Saturday Night Live. It’s also been said that SharePoint is like the proverbial elephant discovered by five blind men – each having a different perspective of what the animal is. Even within SharePoint you can see very different parts of the platform, however, some of the most interesting changes aren’t about the product itself but in the things that it enables organizations to do.

By removing the barriers to creation (what Microsoft calls composites) the tool allows business users to create solutions to their problems. They dynamically create storage for new kinds of information – which in the past required a database administrator to create a table or add a column. The business user can string together a list, a workflow, and some alerts and create a system for managing or supporting some business process. The agility afforded by this toolset means that changes can be made at any time. In SharePoint many of these changes are version controlled so if a mistake is made the user simply reverts to the previous version.

This agility is in stark contrast to the structure of a large scale development effort. Organizations spend an inordinate amount of time building structure around the software development process so that systems can be recovered and recreated. This effort is necessary in a world where specialized skills are necessary to create and maintain systems. You simply can’t have the payroll system changing everyday – and changing in ways where it’s difficult to explain to an employee – or the government – why a person was paid exactly what they were paid. So there are source control systems where code is maintained and controlled. There are configuration management practices which are used to govern changes to the system.

All of this leads to both repeatability – you can restore to any point in time and replicate it anywhere at any time – and control. This is desirable from a recovery perspective. These two outcomes are very desirable in a traditional system – and since traditional systems don’t allow users to create solutions on their own their relatively limited flexibility and need for coordinated activities is not a major barrier.

The real question comes when the rigidity of a SCM meets the agility of SharePoint and we have to answer hard questions about whether something should be treated as traditional code or whether it should live in the user world of agility.

Mapping the Extremes and the Middle

Even in SharePoint there’s some level of clarity that some things are software development and need SCM. If you’re deploying farm based solutions there’s a need to have a brief outage as the software is deployed – this is a clear reason to control the rate of deployments of solutions. Equally clearly if you are adding a contact to a contact list, you know that this is content and therefore should be handled like content – instead of being handled like code. That’s the easy part. Where it gets more difficult is when you look at items which are markup languages and non-compiled languages.

Consider that Cascading Style Sheets (CSS) controls the look and feel of the web site. It’s a language for expressing how the display should look. Most folks don’t consider CSS to be a programming language; it’s a markup language much like HTML. However, there is a sense that CSS should be protected like code because it has a great potential for causing issues on the site. Yet, many new web parts need their own snippet of CSS to work, sometimes overriding the behavior of the code CSS for the solution.

Like CSS, eXtensible Stylesheet Language Transformations (XSLT) isn’t a programming language. It’s a markup language with potentially huge power to change the appearance of the site. With that sort of power it “feels like” it should be a part of SCM and managed. But what about the XSLT used to format search results, or the results from a Really Simple Syndication (RSS)? It seems like our rules break down when the same technology is used for core system things and for user controlled formatting of resulting data.

JavaScript is the language for manipulating objects in HTML once it’s at the client. It’s a programming language, no question about it. This would lead you to believe that it should be a part of the SCM – but again with SharePoint we often have JavaScript that is a part of a web part that a user might add to a page. Do we restrict all JavaScript to being a part of the SCM process?

In SharePoint we also have the unique challenge of SharePoint features and the XML they contain. XML can tell SharePoint to create a content type, a list or even to create data. So does the XML that sets up your list and the sample data count as code – or content? Making the situation more challenging is the user code host – sandbox execution – which allows compiled code to run in a restrictive environment.

Does your head hurt yet?

Criteria for Decision Making

It used to be that we could make a simple decision. If it was compiled it was code – and if you didn’t have to compile it then it wasn’t “real” code. However, over the years the lines have blurred to the point where making the decision based on the file type doesn’t work. Instead we need to make decisions based on the intended use of the file.

Breaking down intended use a bit there are two key things to think about. First, what’s the worst that can happen? In other words, if the file gets modified, out-of-sync, or destroyed what’s the worst case? Second, how are changes going to be managed?

In the case of what’s the worst that can happen, you might have a style sheet that drives the rendering of the entire site. In this case the impact of the file being modified or deleted is pretty large. As a result you would want to protect against that. Conversely, if there’s a style sheet that is responsible for a minor part of the web site – it might be OK to treat that as content. SharePoint has built in version control and a recycle bin so recovery should be as simple as reverting to a previous version or recovering the file from the recycle bin.

The other side of the coin is how the changes are going to be managed. If you go the code approach to management you have to go through the configuration management process to deploy the code to controlled environments. This can add weeks and weeks of time to the deployment cycle. If there’s any need for agility you can’t treat it as code. Conversely, if the item never or rarely changes it might be acceptable to treat it as code. When making the decisions you should consider how many variations of the same thing that there may be – if there are many variations it’s harder to manage them as code.

Of course, some items, those items which are compiled code that can’t be deployed to the sandbox must be treated as code and managed through the software configuration management process so the decision has been made for you due to technical or design limitations. For everything else, the question is how you’re planning on using it.

Making it Concrete

Treating anything with a configuration management process is like pouring concrete around it. It’s certainly possible to remove something buried in concrete by breaking the concrete out and starting over – but it’s not nearly as easy as pulling up stakes and moving on. There are some things you need to pour concrete around. A backyard basketball goal needs concrete to steady it. However, Pouring concrete around the stakes of your tent may not be the best choice. Pour concrete when you need to – and avoid pouring concrete when you don’t need to.

Article: Four Tips for Engaging Your Executives in SharePoint

Robert Bogue December 23, 2011 No Comments

You may have snuck SharePoint Foundation 2010 under the radar, or it was an official but unfunded project. You’re trying to figure out how to get the support you need for the new intranet the organization needs or to extend it to the Internet so you can get partners engaged and get some real value from the platform.

However, you can’t seem to find an executive sponsor to drive the project forward.

All of the “experts” keep saying that you need to get executive sponsorship or executive buy-in, but they’re noticeably absent on how to make that happen. So here are four tips on how to get your executives to buy into SharePoint.

http://www.sharepointpromag.com/blog/sharepoint-pro-by-admins-devs–industry-observers-23/sharepoint/4-tips-engaging-executives-sharepoint-141690 [Article removed]

Guerilla Marketing: Easy and Inexpensive Strategies for Making Big Profits from Your Small Business

Book Review-Guerrilla Marketing: Easy and Inexpensive Strategies for Making Big Profits from Your Small Business

Robert Bogue December 18, 2011 No Comments

I don’t have a huge marketing budget. In some sense I don’t really have a marketing budget at all. That means that when I do marketing I’ve got to do it guerrilla style. I can’t fight the British in organized straight lines, I’ve got to use guerrilla tactics to succeed. (This is a reference to the American revolutionary war.) Jay Conrad Levinson’s book Guerrilla Marketing: Easy and Inexpensive Strategies for Making Big Profits from Your Small Business aims to show small business owners how they can do marketing without a lot of money.

A good place to start is what is marketing. Levinson says that it is “is the art of getting people to change their minds – or to maintain their mindsets if they’re already inclined to do business with you.” That’s a pretty good definition – if you’re sure that the market it is even aware that you exist and they’re making an informed decision between competitors. (See my review of Sources of Power for more on decision making.) I believe that there’s another option – the option that I find myself working with so my definition is “Creating awareness of your position and value in the market.”

Levinson follows up with “More than half your marketing time should be devoted to your existing customers. A cornerstone of guerrilla marketing is customer follow-up.” The problem with this is that in some cases, there’s little to sell to existing customers. In my case, I’ve got two worlds, my consulting world and my SharePoint Shepherd /intellectual property (content) world. In the consulting world you can always sell customers more time, however, on the SharePoint Shepherd side the product offerings are narrow enough that there’s not much to sell an existing customer. It’s more about finding new customers when it comes to marketing for the SharePoint Shepherd side of the business.

From here Levinson starts to align better with my needs and says “reminds you that the main number that merits your attention is the size of your profits.” That’s sage advice. Particularly when evaluated against the noise of web site hits, click throughs, and impressions. For me the only number that matters for the SharePoint Shepherd is bottom line profit. I don’t give a lick about click-through numbers if they don’t lead to sales.

Levinson is keenly aware and relates the best weapons for the small business is ingenuity and agility. There are numerous stories of organizations of all sizes doing the unexpected – paving a new path – and being effective at it. These are things that most large organizations simply can’t do.

Perhaps the hardest part of the book for me to read was the section on commitment – not because it was hard to read but rather because commitment is built on patience – and that’s not something that I have an abundance of – honestly, I don’t believe it’s something that most folks have an abundance of. One ray of hope for me was the ability to leverage measurement to focus on more effective strategies of marketing. I’ve placed several bets down on the roulette table of marketing with several sponsorships over the last few months. I’m tracking each one to see how many leads it’s generating. Further, I’m even starting to tag my BIOs in my public articles. If you look carefully you’ll see that they’re tagged with a specific tag that lets me know when someone clicks through. This ability to monitor what’s happening is helping me to keep myself occupied a bit while I’m waiting on my different marketing activities to take hold.

Levinson also is helping me to remember that what is crystal clear to me may not be in the mind of my buyer. It makes sense to me that if you’re offering your employees self-service help that your helpdesk calls will drop – however, that’s a connection that not everyone will make so I’m trying to get better about making my marketing messages very specific and to clearly articulate the business value of licensing the Shepherd’s Guide.

All-in-all, Levinson’s perspective is right. It will help you to think about how you can do marketing even if you don’t like it. (For what it’s worth I don’t like it.) Pick up Guerrilla Marketing and see if you can make a game out of getting more out of your marketing than you put into it.

Recovering Space on Development Servers through Shrinking Logs and Setting Recovery to Simple

Robert Bogue December 13, 2011 No Comments

One of the problems that happens when you put together a new virtual machine for development is you have to make a decision about how big you make the hard drive. Too big and you chew up space and too small and you’re constantly fighting for space. Invariably if I use a development machine for too long it starts to run out of space – no matter how big I made the drive in the beginning. However, a lot of that space is just log files for the database. Every change in the database gets logged and since it’s a development machine I’m not backing it up. In fact, I never backup the data in a development machine. So what I really need to do is set the recovery mode for the databases to SIMPLE so SQL won’t make log files and then shrink the log files I already have. This isn’t hard it’s just tedious for the 20 or so databases that make up a SharePoint installation. So I started making a script and ultimately found one at http://codesnippets.joyent.com/posts/show/665 that I could tweak quickly to get what I wanted. Basically it was resetting the recovery mode to whatever it was when it started – and I didn’t want that. I wanted to stay in SIMPLE recovery to prevent the logs from chewing up space again. Here’s the script (with modifications):

— From http://codesnippets.joyent.com/posts/show/665 w/ modifications
declare @ssql nvarchar(4000)
set @ssql= ‘
if ”?” not in (”tempdb”,”master”,”model”,”msdb”) begin
use [?]
declare @tsql nvarchar(4000) set @tsql = ””
declare @iLogFile int
declare @sLogFileName varchar(55)
declare @RecoveryModel nvarchar(10)
declare LogFiles cursor for
select fileid from sysfiles where status & 0x40 = 0x40
open LogFiles
fetch next from LogFiles into @iLogFile
while @@fetch_status = 0
begin
set @tsql = @tsql + ”DBCC SHRINKFILE(”+cast(@iLogFile as varchar(5))+”, 10) ”
fetch next from LogFiles into @iLogFile
end
set @tsql = ”USE [?]; ” + @tsql + ” ALTER DATABASE [?] SET RECOVERY SIMPLE ” + @tsql
set @tsql = @tsql + ”; ”
–print @tsql –for debugging
exec(@tsql)
close LogFiles
DEALLOCATE LogFiles
end’
exec sp_msforeachdb @ssql

The Elements of User Experience: User-Centered Design for the Web and Beyond

Book Review-The Elements of User Experience

Robert Bogue December 12, 2011 No Comments

Where does Information Architecture begin and end? It’s a question that I’ve been struggling with. There are so many impacts into user experience, visual design, navigation, etc. I tend to think of Information Architecture as the overall framework or structure. To me IA is the overarching thing under which many other disciplines fit. However, Jesse James Garrett sees the problem differently in The Elements of User Experience: User-Centered Design for the Web and Beyond. The book walks through his model for how he believes user centered design should work. The heart of this is a diagram showing five planes (or levels):

The book effectively walks through each of these levels and explains the relationship to the prior level – and the other concepts on the same level. So we move from a high-level strategy of what we want to scoping a project then defining its structure and so on. The book makes the point – effectively – that you need to focus on the bottom levels before moving up on the higher levels. This is pretty consistent with other things which build like change management. However, the good news here is that by exposing the linkages between the levels Garrett helps to provide arguments why the previous levels are important.

In general I struggle with user experience (UX) initiatives. Despite how much I know that a pretty interface is easier to use. (There’s research to support this.) I still struggle with the black and white definition of right and wrong that some visual designers try to use for things which aren’t quite so black and white and the insistence that an approach is right when there’s been no testing to support that perspective. So I was somewhat concerned about this book – however, I found that the book kept to the key goals of improving efficiency and allowing the users to get their job done and didn’t spend an inordinate amount of time about why changing from blue to purple would make people feel more powerful.

Because of the need to cover a breadth of topics the details can be a bit fuzzy at times. For instance, you’ll find much better coverage of wayfinding in Ambient Findability: What We Find Changes Who We Become and Information Architecture: Blueprints for the Web but the coverage here gets you the basic concept so you can dig into more later.

All-in-all, this is a good place to start to learn about Information Architecture – because it’s a good overview of Information Architecture and the related disciplines. Give The Elements of User Experience a read if you have time.

Article: 5 Tips for Measuring the Success of Your SharePoint Implementation

Robert Bogue December 9, 2011 No Comments

You’ve got a burning sense for the fact that your SharePoint project hasn’t gotten the adoption you want. Perhaps it’s your ears burning as others talk about the failure of the project to meet the adoption goals, or perhaps it’s just a fire in your belly that tells you there’s more to be had. Here are five tips to help you measure your success.

Information Architecture Resources and Questions

Robert Bogue November 28, 2011 No Comments

I’ve written two different course modules on Information Architecture. The first time was for Microsoft’s 10232 (Designing and Developing Microsoft SharePoint Server 2010 Applications) course and the second for the ECM Implementers Course. Each had a specific slant to IA to match the audience of the course. Honestly I wasn’t really all that happy with them because I felt like they were adaquate for their courses, they weren’t big enough to cover the entire IA problem. They were more of a survey of a few of the best practices you should consider.

Thus far I’ve done three web casts on Information Architecture which felt better. They weren’t long enough but the slant to match the rest of the content was removed and I had a chance to “stretch out” and talk about some of the framing issues. The most recent web cast was for Lightning Tools which is available from their webcast page. If you find that the session wasn’t enough to quench your thurst for knowledge about Information Architecture, I also did two web casts for Idera earlier in the year, Fundamentals of Information Architecture and SharePoint Information Architecture which are available for download as well.

[Update 2012-06-13: My Metaglogix Information Architecture Considerations for Upgrade web cast has posted.]

If you’ve gone to a conference with SharePoint coverage in the past year or two you may also be able to find a different Information Architecture presentation available for download from the conference web site. I’ve been talking about Information Architecture in the conference circuit for a few years now. (At least this time around.)

I’ve also read and reviewed several books:

For the record, I’m not done yet. I’ve got a reasonably long reading queue still and I’ve still got a ton of work to do before I’m done with what will become one of the next “The SharePoint Shepherd Presents” DVDs. I could, however, use your help. I’m looking for anything that you’ve found valuable in helping you how to create an effective information architecture and comments about the materials you’ve looked at which just weren’t helpful to you – and why.

As I’ve said a few times, I’m absolutely committed to making “The SharePoint Shepherd Presents” the best materials possible for SharePoint that are available. To that end I want to know what’s working and what’s not working for you. I want to know what you’re struggling with. Please email me with your comments about the IA materials you’ve seen – including mine. Thanks in advance.

Book Review-The Paradox of Choice

Robert Bogue November 26, 2011 1 Comment

I’m still preparing for the Information Architecture DVD that is forthcoming and I stumbled across a reference to the book The Paradox of Choice: Why Less is More by Barry Schwartz. Honestly, it felt like a reach when it came to preparing for Information Architecture. I didn’t know what to expect I’d learn, however, I was pleasntly surprised at the collection of research and conclusions that seemed to be both counter to general culture and equally aligned with previous reading.

Before I get too far I want to acknowledge that there are tones of Stumbling on Happiness in this book. In much of what The Paradox of Choice is talking about is our overall happiness with choice – and control.

I also wanted to relate a story for which the relevance will become apparent in a moment. Back in 1991, I was very early on in my career. I was going to probably my second conference ever. It was in Boston across the river charles from MIT. It was day three and I was not interested in what was being presented so I wandered for a short walk around the city. I hadn’t ever been to Boston so I figured I could look around, get some exercise, some fresh air, and return to the confernece. I started my walk and it wasn’t too long before I stumbled across a young woman with a clipboard. She asked if I would be willing to take a survey. As my mind was focused on MIT across the water, I thought sure. I’ll help out some college student, no problem. Once I agreed she walked me back about a half a block to the Church of Scientology building where they gave me a survey/test. This was at a relative high point in the amount of technical editing I was doing and I had a live-in girlfriend whom I was supporting while she was attending college. During the test I was actually noticing the bias in the questions. I would answer truthfully but I knew that the answers would send the wrong message. They were things like “Do you often criticize, or correct others?” being a technical editor that was part of my work. So I completed the survey in what they said was record time. They scanned in the results and led me to a little room to talk about the results.

One of the first questions was “Do you have any regrets?” The funny thing was, I didn’t and for the most part I don’t today. The thinking which I laid out for the interviewer was that I like who I am. If I like who I am and every experience positive and negative, every choice right or wrong, has made me the way I am. Regret means I would change something but I wouldn’t risk becoming someone I didn’t like to be. You could tell instantly that this put the interviewer off his game. To me at that time it seemed like the only conclusion to be reached but I’ve realized as I’ve grown older that this response is positively uncharacteristic of most people.

What’s the relevance of the story? Well much of the book speaks of our regrets – the opportunity costs of the decisions we make and the psychological impacts of those decisions. There are numerous factors that seem to be at play but how much we regret seems to be an indicator of how happy we’ll be – or not. Less regret = happier people, at least in the over simplified version of the story.

The key premise is built around maximizers and satisficers. Maximizers have to have the “best.” Satisficers have to have “good enough.” We’re all maximizers at times and satisficiers at times. We’ll lament for weeks over the purchase of a car but walk in and buy a computer in the matter of an hour – or vice versa. The key difference is that people who tend to be maximizers more often seem to be less happy – to the point of depression. Schwartz suggests that the opportunity costs – the costs for the decisions not taken – accumulate in our mind and become a burden that must be carried. Please don’t misunderstand. Satisficiers are not without standards it’s just that once those standards are met they make their choice and move on. They don’t have to have the “best” only what meets their standards.

The freedom to chose is also explorer in the book including the fact that most of us want a freedom to choose – that is until we’re actually in the situation. We want to choose as long as we don’t have to live with the consequences of those decisions – and particularly with the wonder about what might have happened if we had chosen the other path. In a world where we have more choice than any other time in history we’re also less happy. Choices can be a good thing – and they’re necessary – but only when they’re constrained in a certain bounds. Consider a post-it note. It has to be sticky enough to stick to the page (enough choices to feel like there are choices) but not so sticky that when removed it will rip off the page (so many choices that you feel burdened).

Choice is necessary so that we can feel some measure of control. If we don’t feel like we have control we may develop a learned helplessness. In the language of the book The Time Paradox this would be a fatalistic view of the world – one that’s learned by events. If we believe that we’re helpless we’ll stop taking responsibility for ourselves – and more importantly for making our condition better. The feeling of helplessness can not exist together with happiness.

I want to end by recounting the 10 steps at the end of the book intended to help you get more happiness out of your life. The parenthetical statements are mine:

Choose when to Choose
Be a Chooser, Not a Picker
Satisfice More and Maximize Less
Think About the Opportunity Costs of Opportunity Costs (realize you can’t have it all)
Make Your Decisions Nonreversable (to limit regret)
Practice an “Attitude of Grattitude”
Anticipate Adaptation (a thing will provide less value as you get more of it)
Control Expectations (the less you expect the better the experience will be)
Curtail Social Comparison (spend time with other people, don’t spend your time wanting to be other people)
Learn to Love Constraints (embrace the ability to not have to choose from everything all the time)

The Paradox of Choice is a great book – particularly if you want to figure out how to be happier in life. It’s also useful in understanding how to lay out choices for others as in the case of an information architecture.

Public Speaking

SharePoint’s a Different Kind of Animal

Mapping the Extremes and the Middle

Criteria for Decision Making

Making it Concrete

Recent Posts

Public Speaking