I was recently posed the question about showing icons in both the headers and in the sub-sets of data for activities like; printing, exporting, changing views etc. He had made it so that this subset of activities were hidden until an activity was spawned. IE a cell of data was clicked or hovered over, then the print, export, etc icons were shown. His question was if it should be made to be shown all the time and what other applications were doing. Looking at other data heavy applications (Google Marketplace, iTunes, other Accounting Type Applications) I found that these icons were indeed hidden quite a bit to draw the eye to the data set the user is looking for. The user understands they have an activity to perform, but paramount to the task is first identifying the data set they need to work with, and a lot of clutter in the data for "activities" didn't help facilitate the user finding the data set they wanted.

There is some level of intuition and things that can be assumed and hidden like this example on Facebook, that once a user clicks on an icon the menu is opened and a new activity is spawned.

It appears that data driven applications opt for a cleaner appearance putting icons and setting widgets or icons only in a mouse over state to keep the user’s focus on the data and less on the activities that can be spawned in viewing the data. Once an activity is decided as an action the user is clicking on the data set (or row) and then it is best to show the activity or icons that necessitate the activity going forward.

There seemed to be quite a debate over what activities could be deemed "resources" or "activities". For instance it was believed that "Print Page" and, "Help" were considered "resources" but activities in workflows were indeed "activities" it's hard to make this association, as all seem to be activities, but are they inherent activities that are expected functionality that every application provides in similar manner in a similar position on each and every page? Some would argue to follow that paradyme and keep those icons in the same place and provide similar functionality. But us UX Designers of the world feel that if everyone is seeing them there, they have been sufficiently informed to mouse over the selected set of data to make those icons appear for a new function, to print that cell's specific information, not a whole page of high level information, but more specifically the focused (targeted), intended critical piece of information that user wants to print. That's us saving the world, and trees, if your going to print, make it count!  If you are going to click, make that action be valid and not clutter the interface with unused and some would say "task based iconography" that isn't helping you to make a decision on the data set you want to work with.  We would argue that data sets should spawn the activity and we can derive a whole new set of assumptions on what that data set is possibly narrowing the tasks down that much farther, and making a more friendly user interface.

The Model View ViewModel (MVVM) is an architectural pattern used in software engineering that originated from Microsoft as a specialization of the Presentation Model design pattern introduced by Martin Fowler.^[1] Largely based on the Model-view-controller pattern (MVC), MVVM is targeted at modern UI development platforms (Windows Presentation Foundation, or WPF, and Silverlight) in which there is a user experience (i.e., user interface) (UXi) developer who has requirements different from those of a more "traditional" developer (e.g. oriented toward business logic and back end development). The View-Model of MVVM is "basically a value converter on steroids"^[2] meaning that the View-Model is responsible for exposing the data objects from the Model in such a way that those objects are easily managed and consumed. In this respect, the View-Model is more Model than View, and handles most if not all of the View's display logic (though the demarcation between what functions are handled by which layer is a subject of ongoing discussion^[3] and exploration).

MVVM was designed to make use of specific functions in WPF to better facilitate the separation of View layer development from the rest of the pattern by removing virtually all "code-behind" from the View layer.^[4] Instead of requiring Interactive Designers to write View code, they can use the native WPF markup language XAML and create bindings to the ViewModel, which is written and maintained by application developers. This separation of roles allows Interactive Designers to focus on UX needs rather than programming or business logic, allowing for the layers of an application to be developed in multiple work streams.

Target Audience Personas
	Guide the design of the site architecture, as well as the creative approach and execution. A persona represents a group of target audience members who visit a site and identifies their interests and abilities.

Answers the following questions: Exactly who visits the client's site? What are the interests, capabilities, and limitations of the Target Audience? What are the personality profiles of the different audiences?		Provides the following benefits: Ensures a clear understanding of who we are "talking to" via the site. Ensures the focus of the navigation, structure, labeling, and creative treatment is on target throughout the project.
Target Audience Personas (PDF)  Target Audience Personas (WORD)

Personas represent the various user types that are expected as the intended users of a system. They are useful for keeping stakeholders and project developers focused on the intended user as they make design decisions.

Personas consist of at least three primary elements:

1. Name: This is usually a real name, like “Bob” or “Lisa,” and may include the role of the individual as well. Roles should communicate something about the user’s perspective or motives. Examples of roles are, “Early Adopter,” “Conservative Shopper,” “Worrier,” “Care-giver,” “Parent,” and so on. Include a photograph that represents the individual’s general character to create a more vivid and realistic example for project stakeholders.
2. Motivations, Needs, and Preferences: Based on user research, each persona’s motivations, needs, and preferences should be expressed in a concise statement, such as, “John wants to compare mobile phones and calling plans to sign up for new cellular service. He is particularly interested in finding a phone that will support worldwide travel, without expensive roaming fees.”
3. Scenarios: Personas help project members better understand the personalities of a system’s intended users by describing a potential task or goal that the system will support in terms of how a person will react to it. For instance, a “Worrier” may be hesitant to complete a shopping purchase, fearing that his credit card information will not be secure. A parent may wish to control the experience of her young child while he explores a video gaming website that advertises violent games.

Although personas are abstractions of actual users, they should be developed based on actual data found in user research. To introduce personas to a project team, print them out and post them around the office. Bring personas to meetings to make more informed development decisions that will affect the user experience. For example, you may want to know, “Which area of the website would Chris, an Early Adopter, explore first before deciding to make a purchase?” During a meeting, attendees may role-play the various personas to ensure that the website will be designed to meet their needs and preferences according to their persona descriptions. Furthermore, to encourage project team members to maintain their focus on the intended audience of personas outside of meetings, create email addresses for each persona and assign team members to assume the role of each persona. When a stakeholder or project member has a design decision to make, he can send an email to the personas, who will respond to their question from the perspective of their needs and preferences.

Style Guide
	Provides a summary of the product or web standards that guide the User Experience team during development, including site design standards and page styles.

Answers the following questions: How can the client ensure online branding reflects offline standards? How will the client's company preferences for content be followed? How will the team document the standards developed and agreed upon?		Provides the following benefits: Sets specific standards aimed at supporting the client's brand and mission Provides a comprehensive documentation of standards for the client's site up front and throughout the process Promotes consistency, which in turn promotes quality, usability, and accessibility

This gude works as a foundation for all future development and ongoing efforts to unify the look and feel of applications that are in a future state of release or additional products or functions that may be added at a later date. By providing documented guidelines you can insure that your intranet, extranet, and corporate websites share a unilateral look and feel and any applications that your IT department adds can seamlessly blend into your enterprise.