The Least I Can Do: Designing Applications People Can Actually Use

dont-make-me-think If you design applications that anyone in the world, other then yourself, will use then you really need to be thinking about usability during the entire development process.Some of you (hopefully) have heard of Steve Krug, the author of Don’t Make Me Think.

This is a great video of a talk Steve gave at Joel Spolsky’s Business of Software conference which covers The Least We Can Do to create usuable software.

Silverlight Straight Talk: The Awesomeness, Disadvantages, and Difficulties in Silverlight

Building Silverlight application takes time, effort, patients, and tools (yes, you have to have some tools). In this post we will cover: where to get the necessities and some useful additional tools, as well as straight talk about the awesomeness, disadvantages, and difficulties of building Silverlight applications.  We will also cover the basics of XAML, referencing and using related assemblies, and the how Expression Blend and Visual Studio make it all happen.

filetypeicon_PDF

PowerPoint-Icon

Where to Get the Necessities

http://silverlight.net/GetStarted/

Must Have tools

  • Visual Studio.NET 2008 or 2010 (available from the link above)
  • Expression Blend 3 (available from the link above)
  • Silverlight Spy
  • Fiddler Debugging Tool
  • FireFox with FireBug(Tools àAdd-ons àGet Add-ons)

Useful Additions

Straight Talk: the Awesomeness, Disadvantages, and Difficulties in Silverlight

  1. You, as a developer, now can and should learn how to developer professional grade User Interfaces that offer end users an engaging and user friendly experience. You will take on both the role of Designer and Developer.
  2. The things that you wished you could do in C# instead of JavaScript can now be done, this frees you from the limitations of the typical web application.
  3. The learning curve: its steep (but not mount Everest)
  4. XAML, it’s a whole new world.
    • Its an unfamiliar landscape that takes time getting used to (remember the first time you ever worked with HTML and CSS, its just like that)
    • Its very picky and unforgiving, one wrong move and you get an very unhelpful BAD PARSER error forcing you to literally dig through all of your code to try and figure out what the problem it.
    • Blend, it’s a whole new tool (even if you already know Adobe Photoshop)
    • You have to find your way around the tool, its not obvious how to do a lot of things , expect to spend lots of time and energy getting used to it
  5. Visual Studio and Blend: it takes two to tango
    • You really must have Blend in order to develop complex (or even average) Silverlight applications
    • Animation and themes are pretty much done exclusively in Blend.
    • All your C# coding is done in Visual Studio
    • Reliable Error message don’t exist, this increases the time and difficulty in tracking down issues.
  6. Gotcha’s that will drive you nuts
    • If you don’t explicitly set the Forecolor (a.k.a the font color) on your TextBlock then your text wont show up (even though it looks fine in Blend)
    • Your project can get out of synch when working in both Blend and Visual Studio, if your not careful you can end up undoing a lot of your code
    • The Design View in Blend can screw you! Don’t rely on it exclusively, instead always be looking at the Code Window (Split View) when working with the designer
    • No Project Refresh in Blend: After adding items to your project through visual studio you have to trick Blend into reloading the project in order to work with the additions.
    • Bland fails to apply namespace properly when using it to add new User Controls
    • Selecting an Image source through the designer copies the image to the Silverlight Application Root
    • Blend doesn’t recognize Web Service References and will indicate that you have errors when you really don’t
    • Error Message are worthless.

Understanding the basics

  1. UI layout
    • Grids: they are very much like HTML Tables
    • Stack panels: this is like an HTML Div where you set the “orientation” of its contents to one of two setting, either Horizontal (default) or Vertical
    • Canvases: just like it sounds, it’s basically a container where you position its content using Canvas.Top=“x” and Canvas.Left=“x”. Very similar to using a Top and Left in HTML/CSS
    • Margins: allow you to add spacing between items (left, top, right, bottom) in order to control its position relative to other objects. Just like Margin/Padding in HTML/CSS
  2. Animations
    • Visual State Manager: this is the build in “animation” that is applied to object. Is usually developed using Blend because it can be a nasty little bugger to work with by hand.
    • Animation using Blend: similar to how you animate object in Flash (“Tween” like features as well as Easing)
    • Behaviors: these are “In-Code” animations (basically taking an animation that Blend creates and writing it in C#). Can be reused through your project as well as other projects (by adding references to the DLL its contained within). Not easy to create because currently there isn’t any automation tools to write the C# code (you will be doing by hand, not fun).
  3. Events and Data-Binding
    • Getting a grip on Asynchronous Data Exchange: timing is everything, your data may take a long time to return (if it returns at all) and you need to let people know what’s happening during this time. Data returned is not guaranteed to be returned on the User Interface Thread, meaning it may be there but not show up in the UI
    • Data-Binding and why it’s so awesome in Silverlight: Binding objects to data is INSANELY easy. Objects look for data that it should bind to first in its own DataContext, then its Parent, then its parents parent, etc… until it finds (or doesn’t) what its looking for. Handles “not found” very graciously.
    • Accessing your web services: set-up to easily handle moving from Dev to Test and then into the Production Environment
    • Wiring events to User Controls: very similar to how you define it in ASP.NET web applications.

References assemblies & debugging your project

  1. Accessing and Using Shared Components
    • Using Blend’s Control Library to access items in referenced libraries. In Blend you can access controls that exist in references library (DLL’s).
      Blend
    • Extending existing controls in order to customize them: accomplished in the same way as ASP.NET, simply create a Class file that inherits from the base control (i.e. the Textbox control) and add custom properties and methods to it. Then use these in your project in order to take advantage of the added functionality.
    • DLL’s as well as “Behavior” classes (just C# class files), many available for Free on the Web (visit http://gallery.expression.microsoft.com/en-us/  )
  2. Testing and Debugging your application
    • Using Fiddler to intercept web service requests (very useful to debug web-service requests and responses)
    • Using Silverlight Spy to identify User Interface elements (a must-have tool to drill down on the Silverlight objects displayed on the screen)
    • Unit Testing your Web Services and Business Logic

Learning Fatigue, Sustainable Pace, and a Programmers Death March

Have you ever been at the gym, running on a treadmill, while the guy next to you (who is in much better shape I might add) is not only running faster than you but appears to be doing it with ease. You adjust your speed trying keep up, it works for awhile and you feel good about it, but eventually fatigue sets in and you find it increasingly more difficult to stay on pace. Eventually you have to slow down to something thats “sustainable”, something you can keep up for your entire workout.

Learning (and working) can, and often is, just like this.  In the sequel to Alice’s Adventures In Wonderland, Through the Looking-Glass by Lewis Carroll, the Red Queen says “it takes all the running you can do, to keep in the same place”, eventually becoming known as The Red Queen’s Hypothesis

An excellent article written by 37 Signals entitled Sleep deprivation is not a badge of honor offers some great insight into this analogy.

Learning Fatigue

In the software development world learning is something we as programmers/geeks are, or at lease should be, constantly doing. I read articles/blog posts/chapters in books on a daily basis and still find it nearly impossible to keep up with the ever increasing complexities of our industry.

This can feel very much like being on the treadmill, trying to keep up with that guy next to you. Now don’t get me wrong, I love to learn new things and am constantly fascinated by all the incredibly cool stuff thats coming out these days, but I do need to have balance, one that is “sustainable” (a.k.a Sustainable Pace) otherwise I will suffer from Learning Fatigue.

In a very interesting article written by Dr. Bruce D. Perry, MD. Ph. D. entitled How the Brain Learns Best he discusses Learning Fatigue (what is referred to as Neural System Fatigue).

Through the process of education, we are trying literally to change the brain…Learning requires attention. And attention is mediated by specific parts of the brain. Yet, neural systems fatigue quickly, actually within minutes.

With three to five minutes of sustained activity, neurons become “less responsive”; they need a rest (not unlike your muscles when you lift weights). They can recover within minutes too, but when they are stimulated in a sustained way, they just are not as efficient.

Sustainable Pace

To combat Learning Fatigue, and the guy next to us on the treadmill, we can use the wisdom found in the old parable The Toroise and the Hare:

Slow and Steady Wins the Race

We need to be learning daily, in small consumable chunks, in order to prevent burn-out while maximizing our retention of the ever-increasing complex topics we study and grow to love. This is called Sustainable Pace and its something I believe in, preach about, and practice religiously.

A Programmers Death March

So lets jump back to the Treadmill example at the beginning of this article and make some small changes. The story starts the same way, you’re on the treadmill with Mr. America next to you and you’re trying to keep up. But this time it’s different, this time your boss is standing behind you telling you that you need to “get it done” because his boss put a finger on a day in his calendar and said “it HAS to be done by this day” (with little or no understanding of what it will really take to make that deadline).

So there you are, trying to keep up, knowing that you might not be able to and even thinking that you’re just going to turn around and tell your boss to go screw himself because you have decided to quit your career and sell hot dogs out of a buggy downtown. Sure this example is goofy, but while we chuckle nearly all of us are saying to ourselves “i’ve been there”. This is the “Programmers Death March”, it’s the exact opposite of Sustainable Pace, and it will lead you to either having a heart attack or quitting your career (or both).

So what do we do to avoid the Death March? We have to be realistic about what we can achive in a given time span. In software development we often don’t know how close to finishing a project we really are: the requirements change, the technology available to us changes, and our skills change. The answer is tocommunicate with stakeholders openly, honestly, and most important REGULARLY. This last piece, the part about regular communication, is an Agile Development pholosophy cornerstone. If you aren’t familiar with Agile then definetely take a look, much of it is about how to make your work and ultimately your career more productive and enjoyable.

In addition we cannot forget that ultimately we are the ones in charge, while this may seem rediculous it is actually true. If you slowed down the treadmill and then told your boss that it was necessary in order to be able to complete the project at all, much less on time, there isn’t much he could or would do about it. I strongly encourage you to read the book The Inmates are Running the Asylm by Alan Cooper, its a book about Software Developers taking charge and it will change you’re perspective in many ways.

When ORM becomes a problem

ORM (Object Relational Mapping) systems are useful in getting you started with a project. They help you to quickly create objects that model your Data Source, letting you interact with the data in a simple and intuative manner.

While ORM is extremely useful, especially in smaller projects, this usefulness comes at a price. ORM becomes a problem in long-term maintenance as you are committed to the ORM you initially select, whether its Entity Framework, LINQ2SQL, SubSonic, NHibernate, or any other ORM Software Factory system that generates class based on the targeted data source you will need to select one and, in most cases, will be married to it throughout the development (and product) life cycle.

While this may not seem to be a deal breaker it is not until later, during the longer-term maintenance phase, that the price is paid. Developers who inherit the project from you will be forced to continue to use the ORM you selected, even if its no longer available. And if the ORM system is open-source, with its source code available for you to modify, upgrades (or downgrades) to a different version can cause major headaches which often result in the development team refusing to make changes to the ORM for fear of crashing the application (or even worse would be to cause lots of runtime errors that are only discovered after the upgrade).

Another disadvantage is that if the data source schema is changed the application is not shieldedfrom the change. The relational schema of the data is hard coded into the application via the generated classes. If the data model changes the ORM object won’t know until they are regenerated by the ORM software.
The moral of this story is to use caution when working with ORM systems. Anticipating and addressing these kinds of issues beforehand can help to avoid having your hands tied later down the line.

Making your website project a success

Finding a talented, reliable, and responsive development firm that has the skills you need can be an enormous challenge. Understanding what you need can be just as difficult, here are a few things that will help you get started in the right direction.

Know your target audience:

Who are you creating the website for: the general public, your company’s employees, or existing clients? While this may seem silly it is one of the most overlooked items in nearly all projects. Identifying who the site is for, how they will use it, and what the most important parts are is critical to the success of any website project. Take the time to really think about your target audience, what they need, and how you are going to provide it to them. Write this information down in an outline form and regularly refer back to it during and after the development process, asking each time if you have given your target audience what they need.

Identify a budget:

It is difficult (if not impossible) to know how much a project will really cost, often you are identifying your needs during (and even after) the project is being developed. Even if you have no idea what your project may cost to produce you need to set limits on how much you are willing to spend. Think if your project as if it where the purchase of a new car; you don’t want to go to the Porsche dealership when you can only afford a Yugo and you don’t want to be looking at Yugo’s when you really need a heavy duty truck. Your project is an investment that needs to bring a return, identify how much money you are willing to spend and what your project needs to do for you in order to justify the expenditure.

Ask for a development timeline and make sure everyone can stick to it, including you:

It is important for all parties involved that an estimated development schedule be created and agreed upon by everyone. Your development firm must balance your project with others that it may be involved in; you will need to balance the needs of your project with your current work load. No one party can do it all, realizing that your website development project will require both time and effort from you and setting aside the necessary time to stay on track is one of the most important practices to follow. Making sure you follow up with your development team, getting them the feedback and materials they need when they need them can mean the difference between the success and failure, not to mention reducing a great deal of stress for both sides.

Focus on what’s important:

It’s easy to get carried away with your project, spending time and money on things that don’t achieve the bottom line. Work with your development company to create a “Critical Path”, a set of absolute “must have’s” that represent the bare minimum needed to make your project a success. Before, during, and after the project focus on the Critical Path first leaving the extra’s for later if time permits.

Communicate:

Communication with your development firm makes or breaks a project.
Be responsive: Return phone calls and emails promptly. Keep your development firm informed:if you don’t have time to get them something then let them know, set up regular scheduled meetings/calls to discuss the status of your project and any decisions/changes that may need to be made.

Don’t make assumptions:

Don’t assume others understand what you meant, instead ask them to repeat it to you in their own words. Miscommunication costs time and money, taking a few moments to ensure everyone is on the same page can make your development experience much more pleasant.

Stay involved:

Your development firm cannot do it without you, just as you cannot do it without them. If you haven’t heard from them in awhile give them a call and ask for an update

Get things in writing:

keep a record of your email conversations and follow up any calls with an email that recaps what was discussed.

Normalized vs. Denormalized

What is the difference between Normalized & denormalized, and when do you use which?

When most of us design our databases we tend to think of them as related (and un-related) tables that contain data. It is common to normalize our tables in order to create a cleaner, more manageable, and intuative Database design. Normalized means separate tables via foreign key relationship, there are however things that we should consider before we normalize our system.

Historical Data:

One of the most important is historical data. When we normalize our system we open the door for historically inaccuracy. What’s that mean? It means that we can change the data in the related table, causing us to lose the accuracy of the data thats related to it.

What do you mean “lose the accuracy”? Lets look at an example: We have a Member table which holds a foreign key referrence to the States table. If we change the data in States table, which is referrenced by the Member table, we have no way of knowing what that the Member record originally contained (like change Republic of Congo to Republic of China).
So why should we care, isn’t this the whole reason why we normalize our database? Yes and No.

If we know that we will never have the need to keep an audit trail or report on the data then surely normalizing it is perfectly suitable. However we all know that software requirment change, and there may come a time when the Marketing Department wants to know the history of how its members data has changed over time, normalization would destroy this historical record (unless we some how dig it out of a backup, which would be a major pain in the rear), denormalized does not.

Reporting:

If you think that you will ever have to do any kind of Data Mining or Reporting on your data then avoiding over-normalization is important. Reporting on, or performing calculations on, large amounts of data requires that you denormalize your database. Anticipating this during the design phases can save you a lot of time and grief later on.