This article describes methods for designing screens in a user interface and the technology frameworks that support screen design.
Ambrose Little, Charles B. Kreitzberg
MSDN Magazine September 2009
View Complete Post
As devices converge, user experience design needs to change, too.
Dr. Charles B. Kreitzberg
MSDN Magazine April 2010
While style and slick visuals are important in Web site design, they shouldn't detract from a site's usability and functionality. Here are some hands-on tips for look and feel, readability, discovery of affordances, and more, with plenty of examples of good and bad design.
MSDN Magazine December 2009
In this column, Ambrose Little and Charlie Kreitzberg discuss best practices, design patterns, and other considerations related to implementing a search feature.
MSDN Magazine November 2009
This article explores techniques developers can use to gather information about and incorporate their users' mental models in their software designs.
Ambrose Little, Dr. Charles B. Kreitzberg
MSDN Magazine October 2009
The end goal of software projects is to deliver value to the customer. Software design is a major factor in how successfully a team can deliver that value. The best designs are a product of continuous design rather than the result of an effort that tries to get the entire design right up front. This approach lets you strive to apply lessons learned from the project to continuously improve the design, instead of becoming locked into an erroneous design developed too early in the project.
MSDN Magazine August 2009
This month's column describes the benefits and methodologies of usability testing.
Dr. Charles B. Kreitzberg and Ambrose Little
MSDN Magazine July 2009
This month the authors show you how to treat the user experience as an essential dimension of the development process while retaining the advantages of Agile.
MSDN Magazine June 2009
In this month's installment, learn how to achieve the most important outcome of all UI design: ensuring that your software is useful, useable, and desirable.
MSDN Magazine May 2009
A persona is a description of a fictional person representing an amalgamation of traits found in a segment of your users. Emplolying personas arms you with a powerful foundation on which to base design decisions.
MSDN Magazine April 2009
Good navigation makes for happy users, and happy users are good for your business. See what makes users happy this month.
MSDN Magazine March 2009
We give you a gentle introduction to designing and evolving rich domain models as part of integrating Domain-Driven Design (DDD) into your coding efforts.
MSDN Magazine February 2009
This month our usability experts explain what it takes to create informative, useful error messages.
Dr. Charles Kreitzberg and Ambrose Little
MSDN Magazine January 2009
Designing testability into your app means smaller tests that are cheaper to create, easier to understand, faster to run, and much simpler to debug.
MSDN Magazine December 2008
A great user experience is more than just a pretty face. In this new column we'll look at some of the subtleties of building great user experiences.
MSDN Magazine March 2000
I'm looking more for SSAS 2008 best practice design advice, rather than for an answer to a specific question (although I have a specifc set of examples).
First issue: Creating a non-additive measure group and an additive measure group. We have some fact data in our current cube that is additive, and some fact data that is non-additive; all stored in the same fact table. We do not currently
have measures implemented that reflect this aggregation distinction. Question: Is it considered good practice to segregate additive and non-additive fact data into a) different fact tables and/or b) different measure groups? My thought is
that it would be an acceptable design approach, but am looking for feedback.
Second issue: Non-additive fact data is only available at a non-leaf grain. The example here is that we have non-additive fact data which is only available for the 4th or 5th levels of our 6-level geography dimension. Our solution has been
to create a custom geography branch, which now essentially serves as our 'aggregation treatment' for non-additive fact data. I don't believe it's a good practice to have the geography dimension serve this function because we end up having to create a
custom geo member for each non-additive fact data element. Question: What is considered best practice