Blog

Themes Galore

Feb 28, 2008 by:   Tim Stanley

Web sites use templates called skins, themes, and styles to describe how web sites can be modified to change the look and layout of a web site without changing the content.  Wordpress, Blogspot, DotNetNuke and others all provide the ability to modify the color, layout and style with thousands of templates that are available.  Many are free, some cost only a small fee.  The ones that do cost something range from less than $50 to about $200 for a bundle.

One of the greatest sites to extol the virtues of using CSS to modify layout, colors, images, and style of a stie but using the the unchanged same content is the CSS Zen Garden.  A lot of significant design effort went into the styles used at the CSS Zen Garden, but they look great.

Predesigned themes can be invaluable for a small business or organization operating on a limited budget.  Something that would cost $3000 to $6000 or more to have a custom designer generate, can be obtained for less than $100.

There a new web site engine making headway in the market today called BlogEngine.NET.  It's been very popular as more and more new features become available.  One of the most interesting features is BlogEngine.Net's ability to support multiple themes.

Here's a list of current BlogEngine.Net Themes that are supported (with some custom ones added by me):

** - these are definately worth taking a look at.
* - you might be interested.
Several of the themes were created by Jesse Foster.  Jesse explains more about how the different layouts are accomplished in his post on Layout Gala.

Envision.1.0:

Discovery:

Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList

Focus Causes Change Blindness

Jan 25, 2008 by:   Tim Stanley

Focus or stress causes us to overlook things we would normally notice (inattentional blindness).  When people focus too much on one thing, people don't notice other changes.  Take the video example below that illustrates this example.  There are five changes that occur during this video.

[youtube:voAntzB7EwE]

What if you have a project, and you want to communicate a change. How can you be sure that people will correctly observe and act on the change accordingly? The first obvious answer is to have a change control process.  But even then, changes that are identified still get lost if the information is too much to process, or it it's not clearly presented. I've found the following techniques useful from my own personal experiences and projects.

  1. First, be aware that inattentional blindness or change blindness exists.
  2. Minimize other distractions when presenting information about changes.  If changes are presented when other priorities have focus, the changes will be lost.
  3. Minimize the quantity of changes presented at any given time.
  4. Provide breaks (hours, days) between blocks of changes.
  5. Give ample time between changes for people to evaluate the impact to other systems or processes.
  6. Clearly identify visually in distinct colors or blocks any changes.
  7. Break out specifically changes separate from the overall context of other documents, or e-mails. 

In software development projects, I have witnessed both within my own software development and within all software development teams a phenomenon I've not seen documented in any software development process. There is a period of time between when a development team has completed a release and when within days of not working on the code on a day to day basis, without performing any code reviews or other analysis, issues are identified that need to be further tested or changes made in code to resolve code or design issues.  The only thing I've been able to attribute this too is too much information during development which when removed allows the developer to focus on things more clearly and these things then come to light.  I now plan for these "aha" moments in my software development projects.

Any successful project has changes that occur from the begging to the end of a project.  Too many changes presented with other priorities will be lost and won't get successfully delivered.  Be aware of change blindness so your projects don't get caught blind.

Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList

Communication Illusions

Jan 23, 2008 by:   Tim Stanley

Every sense we use to communicate with can be tricked, or confused into perceiving things that don't exist and not perceiving things that do exist.  Our senses are good at what they do, but have limitations and adaptations that work for or against us in a certain way.  If we know the limitations, we can better compensate using other techniques.

Optical Illusions

Take the image above for example. Are the squares A and B the same color, or are they different colors?  They are the same color. Adelson of MIT explains the checker shadow illusion and why these appear to be different colors, but are in fact the same color.  Both colors are the hex color code #777777.  The visual system breaks down what it sees into components, allowing us to perceive the nature of what we see.  In this case, assumptions on physical space and light lead us to a false conclusion.

In one study, at the Visual Cognition Lab at the University of Illinois, individuals were asked to count how many passes of a basketball were made by a specific team.  Interestingly enough, about half failed to notice a gorilla that moves across the court and pounds it's chest.

Some key points on optical illusions (visual communication limitations):

  1. We see things that aren't there.
  2. We don't see things that are there.
  3. Focus or stress causes us to overlook things we would normally notice.

If our eyes can be deceived, then so can our other senses.  When we try to communicate, we use written, visual, verbal, and nonverbal means to convey our message.  Just like the optical illusion above, in every mode of communication there is the opportunity for illusions of communication to occur which can often lead to miscommunication.

Verbal Illusions

Speakers overestimate their effectiveness.  I've known this from personal experience, but I wasn't aware of the significant degree of miscommunication that occurs.  Experiments by Boaz Keysar and Anne Henly proved to me verbal illusions exist just as do optical illusions.

  1. Speakers are confident they are effective even if the information is ambiguous or unclear.
  2. Speakers are not understood as much as they think they are (less than ½ the time).
  3. Listeners are confident in understanding speakers
  4. Listeners do not understand as much as they think they do (less than ½ the time).
  5. Listeners are as confident when they are understanding correctly as when they misunderstand.
  6. Observers (not involved in the exchange) are more likely to identify potential misunderstandings.
  7. People that are anxious or depressed are more likely to incorrectly process ambiguous situations as threatening.

Written Illusions

Written communication can be even more prone to miscommunication.  Ambiguity in verbal communications is even more detrimental to miscommunication in written form (e-mail, documents, requirements, etc.). Communication that takes place in written form is devoid of explanation, original intent, body language and inflexion that come with communication in person.  Furthermore, most written communication tends to be viewed as more formal.

Think about it, if written communication were so easy and clear, why does the U.S. Constitution call for a panel of justices on the supreme Court to interpret the written laws?

Compensate for Illusions

We see things that aren't there, we don't see things that are.  We think we hear things, clearly, but don't.  No wonder software development projects fail.  If we want to communicate better, what can we do?

When I was the chairman of the ActiveStore committee, I worked with team members from multiple companies in Europe, Asia, the Middle East, and the US.  I learned that these senior people (presidents, vice presidents, directors)  were good at communicating, but not immune from these illusions of communication.  We would discuss a topic, come to a conclusion, reach an agreement, and then write it down.  We found that only by using multiple avenues of communication (white boards, verbal, in-person meetings, and written summaries), did we actually agree on what we were trying to communicate. 

I've since then worked with development and customer teams in four or five different physical locations, anywhere from 700 to 7000 miles apart.  The problem only gets more complicated and complex the further the distance is involved.  I've used the following points to help me communicate clearly.

  1. The burden of communication falls on the communicator.
  2. Assume only ½ of what is communicated is understood.
  3. Repeat important communication points multiple times in different ways.
  4. Don't be ambiguous, be specific.
  5. Have the recipient repeat what is understood.
  6. If something can be interpreted in multiple ways, clarify the original intent.
  7. Have the recipient state assumptions that are made.

Every instance that I have seen where there were significant gaps in what was expected versus what's been delivered in a software development project have all been preceded by  little explanation, and large assumptions that were not clearly communicated.  I've seen the above techniques clearing up communicating help improve understandings significantly.

References

Technorati Tags:

Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList

Software Is Not Done

Jan 21, 2008 by:   Tim Stanley
Puzzle
photo: Willi Heidelbach stock xchng

It's not that software is never finished.  It's just that done is not a good description to describe the status of software.

What's the status of the "Buy 12 get one free promotion?"

It's done!

What's done for one particular team isn't done for another.  Done for the business analyst isn't done for the the person doing deployment.  It leads to a lot of confusion among teams, particularly when teams are in multiple physical locations.

What's needed to help communicate the status is a common set of terms used by the teams in all locations to consistently indicate status.  I use the following terms with my teams.  This not only helps identify the status of a particular feature, it takes the emphasis off a particular phase and helps the team realize that one shot isn't the game.  Half time isn't done.  The goal of a software service or product is to rollout the features desired by the business, not to just complete one particular phase.

  1. Business requirements complete
  2. Graphical User Interface (GUI) requirements complete
  3. System requirements complete
  4. Technical design complete
  5. Code construction complete
  6. Code review complete
  7. Code review changes complete
  8. Unit test complete
  9. Unit test issues changes complete
  10. First pass system test complete
  11. System test issues complete
  12. Final system test complete
  13. Customer acceptance test complete
  14. Customer acceptance issues complete
  15. Deployment complete
  16. Pilot complete
  17. Rollout complete
Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList

What Is Heard Is Not What Is Said

Dec 29, 2007 by:   Tim Stanley

In the days of global development teams, communication can be difficult.  It's what the recipient hears that is more important than what the communicator says.

What was said:

I believe in you. Love, Mose

What was heard:

I be leaving you. Love, Mose.

The next time you communicate with your team members, get them to repeat what they understood in their words.  It's better to straighten out any misunderstandings up front than to let things go misunderstood.

The full entry from December 2007 Reader's Digest:

My wife struggled with a career crisis: Should she quit her job? Knowing how panicked she was, I called our florist and sent her a bouquet with a card saying "I believe in you. Love Mose." Later she called to thank me. "But I'm confused by the card," she said. "Really? Why?" "Because it reads 'I be leaving you. Love, Mose.'"

Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList

ASP.NET 3.5 Extensions CTP Preview Released

Dec 10, 2007 by:   Tim Stanley

On Dec 9, Microsoft released the ASP.NET 3.5 Extensions CTP Preview for Visual Studio 2008.  Scott Guthrie outlines some  ASP.NET 3.5 Extensions CTP Preview key features this preview release provides.

These include:

  • ASP.NET Ajax Improvements
  • ASP.NET MVC
  • ASP.NET Dynamic Data Support
  • ASP.NET Silverlight Support
  • ADO.NET Data Services

A set of ASP.NET 3.5 quickstart samples are also available. 

A quick take:

Q: Should I use this for production development?
A: No, this is a CTP Preivew.  See the ASP.NET Product Roadmap for more information.

Q: If I shouldn't use this for production development, what good is this release?
A: It provides the ASP.NET MVC which if your requirements need it provide the ability for enhanced URL control for your ASP.NET applications.  Previously, the only ways to do a very complex URL structure was a painstaking folder path, or installing an Isapi extension.

Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList

Visual Studio 2008 Express Free

Nov 30, 2007 by:   Tim Stanley

Microsoft announced on Nov 19, 2007 the availability of Visual Studio 2008.  It also made available to the public a free version of the developer tools.  Check out the following links to obtain your free copy of these tools.

The Visual Web Developer version includes a significantly improved HTML web designer also used in Visual Studio 2008 and Microsoft Expression Web.

Add to favorites Send to a friend Digg It! DZone It! StumbleUpon Technorati Reddit Del.icio.us NewsVine Furl BlinkList