Blog

Free 30-day trial Free Trial

ProtoShare Sponsors Video to Underscore Importance of User Experience

Animated Video uses chicken and egg conundrum to explain the relationship of UX and UI

Portland, Ore. – July 27, 2010 – Site9, Inc., developer of the industry’s fastest growing collaborative prototyping tool for websites and web applications, ProtoShare, today announced the company's sponsorship of The Chicken & Egg video. Created by user experience consultant, Kai Brunner, the video explains how UX (user experience) design is structurally connected to the UI (user interface) in interactive design.

To effectively explain the relationship between user experience and user interface to clients, family, and friends, Brunner looked to the age-old chicken and egg relationship of which came first – the chicken or the egg. Using the analogy in his animated video, Brunner illustrates how user experience design affects the user interface, and how a user interface improves from feedback gathered during evaluations of the user experience. Eventually, a clear and enjoyable user experience results from a superior user interface, which was refined and improved with usability testing and feedback.

Brunner has also entered The Chicken & Egg video, with ProtoShare as the sponsor, into the 2010 Viral Video Awards at the 26th International Short Film Festival Berlin. “I produced the Chicken & Egg video to raise general awareness and appreciation for the role User Experience Designers play in making the web better for us all,” said Brunner.

"People are confused about what UX and UI are. When Kai showed us his video we found it informative and entertaining, while also illustrating the need for tools like ProtoShare. We decided to sponsor him in his quest to educate people about the need for good user experiences, and how they are derived," said Blake Johnson, Founder and VP of Marketing at Site9.

“When it comes to advancing ProtoShare, we listen to the needs of our customers,” said Site9 CEO Andrew Mottaz. “The updates in ProtoShare 3.9 were popular requests so we knew we had to make them happen. The improvements really do enhance workflow for developers and project engagement for reviewers. Together they result in a better and faster prototyping and collaboration process, and that makes our customers happy.”

Brunner's video can also be viewed online at Vimeo:http://www.vimeo.com/12871218.

About Kai Brunner 
Brunner is an independent UX and UI consultant. He has been analyzing and designing memorable interactive user experiences for over 15 years. In 2010, Brunner was honored with an MEX Award for a cutting edge mobile user experience for his prototype touchscreen tablet application, BlazeBroker. For more information on Kai Brunner, visit his website at www.KaiBrunner.com.

Happy Birthday, ProtoShare!

Happy 2nd Birthday, ProtoShare!

This week marks ProtoShare's second year out of beta.

When ProtoShare 1.0 launched it was the first wireframing and prototyping application available as a web-based solution. It opened the door for development teams to collaborate with stakeholders on website and web application projects to gain better feedback in a timely manner.

Now, thousands of users and interactive development projects later, ProtoShare continues to help shape the wireframing and prototyping industry with version 3.9. For this accomplishment, we say "Thank you!" to all our users for your continued support and feedback over these past two years.

We look forward to celebrating more birthdays with you.

Best,
The ProtoShare Team

Avoiding Failed Projects: What's a Project Manager to do?

According to the 2009 Standish Chaos Report, 68% of IT projects fail, miss the deadline, are over budget, and/or missing key elements. New Bamboo reports that at least 30% of all website projects fall victim to the same issues. Even the most seasoned development teams and project managers experience project setbacks.

From a Project Manager's point-of-view, what can be done to combat these pitfalls and help your team deliver better projects on time and on budget? In this post, I'll cover some of the common causes of interactive project setbacks as well as how to avoid them. My findings stem from my own experience as a project manager (PM), as well as anecdotes compiled from other colleagues' experiences.

7 Common Causes of Project Setbacks

  1. Lack of Information – from the client and from you
  2. Multiple Decision Makers
  3. Scope Creep
  4. Loss of Feedback for Requirements
  5. An Undocumented Process
  6. Project is Rushed to the Final Build
  7. Use of Incompatible Technologies
How to Avoid Project Setbacks

As a project manager, you should know what's going on with your project at all times: where it is, how each stage affects it, and how to mitigate any foreseeable risks before they happen. At the same time you must also manage relationships with your client and your internal team. (Note: In some companies, the Account Manager and Project Manager are two separate roles, in which case, you should learn to work together and communicate often to collectively avoid these problems.)

Lack of Information

Many clients you will work with are unaware of how much requirements analysis and work is involved in the process of creating websites and web applications. As the PM, part of your job is to help educate the client on how much information you need from them throughout the process, how last-minute decisions or changes affect the budget and timeline, and to understand his role in the process.

When a project begins, you will need to gather as much information as you can about your new client/project. Sit down with the salesperson that sold the project to find out how the process went and if the salesperson promised any features or functionality not in a "typical" project.

Next, sit down with the client and introduce him to your process and needs. This can also be done through a conference call. I've also sent out an orientation survey in advance to learn more about the client, the problem he wants to solve, project goals, the audience, future plans, etc. Find out what he expects of you and tell him what you expect from him during the process, like how often and through what methods he wants to be contacted.

Multiple Decision Makers

Unless you are working with a small company, it is not often that you get to work directly with the head decision maker (DM). Ask who the main DM is and what role your contact plays. A former colleague of mine once worked with a client that said he was the one to be working with him on the website project. After the entire website was completed and ready for delivery, the client showed it to the real DMs and they hated it. Needless to say, the blame fell on our company to salvage the relationship and their budget was blown out of the water for re-work. My colleague's contact was the liaison to the real DMs, but failed to inform the PM of his role. The PM also failed to ask.

Another scenario of multiple decision makers is when your contact is working with a committee of DMs. Be sure your client contact understands he is to facilitate and manage this committee so you are not bombarded with requests from multiple people that all want different things. They should vote by consensus or have one overriding DM.

Scope Creep

Scope (or feature) creep happens with most projects. Some teams prepare for a little scope creep by building in budget and timeline buffers, but you should minimize scope creep as much as possible. Communication, as with any of these setbacks, is the most important aspect to avoiding scope creep.

If a client asks for an unplanned feature, ask him why he wants to incorporate it. Uncovering the motivation for a request will help you target the real issue. If it's an extraneous request, simply discuss the (lack of) ROI that it involves and that it doesn’t address the target goal. If it's a reasonable request and a benefit to the project, inform the client you need to speak with the development team about creating a new use case. You also need to learn how long this new feature would take and that you will contact the client with an estimate since it is outside the original scope.

Loss of Feedback for Requirements

In some way or another, it has happened to me and my colleagues: losing an email with a client request or answer or forgetting to write down important information in the project documentation after a phone call.

When you misplace or forget information important to a project, the client feels unimportant. If it's a question that needed to be answered and you forgot the answer, you have to call the client back to get that answer. It could also be a request that you missed entirely and the client notices it is missing in the prototype or the final product, so your team has to make adjustments after the fact.

You should have a single location to post client or other stakeholder feedback regarding a project (ProtoShare is a good tool for this). This way, the information is immediately shared with stakeholders and reflected in the requirements documentation. Stakeholders input their feedback directly into the application so you cannot lose it. You can also directly type in feedback while on the phone with the client, so he can verify you have captured his feedback accurately.

An Undocumented Process

If your team does not follow the same process for each project you undertake, you will miss information that is important to the successful completion of the project. I find it helpful to create a checklist for each step in my company's development process to ensure that no steps are skipped.

This checklist may physically follow the project from one department to another or be tracked in your PM software. Be sure task owners mark off their items when completed and that they don't try to cut corners. Good organizational skills are very helpful to making sure you can manage multiple projects successfully.

If you currently do not have a process documented for creating websites or applications, sit down with your team and create one.

Project is Rushed to Final Build

An anxious client, tight deadline, and not following a process (as listed above) can all contribute to a project being rushed to final build before it is ready. Be sure to set expectations with your client, understand all the elements the project is to address, and share this information with your client.

Also, stepping through your documented process is important; that's why you have a process. For many development teams, these steps tend to include Research, Project Objectives, Personas & Use Cases, Requirements, Site Map, Sketch, Wireframe, Design, Prototype, Test, and Build. The client may not be involved in each step, but he should know why you conduct each step thoroughly. If any one is missed or rushed, then the project will be off target and require expensive re-work.

Use of Incompatible Technologies

This issue is related to Lack of Information. You will need to learn who the client's end users are and what systems or technologies they use so you can ensure what your team creates will work on their systems. You don't want your team to use coding techniques that don't render well in browsers used by the client's audience.

There's also nothing worse than writing an application in a way that does not integrate with a key system the client uses at his company. Ask him what systems they use and if they plan on changing systems in the near future.

In Summary

There are many reasons why website and application projects fail. However, with the right planning, good processes, good tools, and constant, open communication, you can effectively manage a project to its completion and make your clients happy.

Here are some other resources you may find helpful:

In Loving Memory of Tom Holce

We at Site9 are deeply saddened that today we lost a board member, investor, and, most importantly, a genuinely good friend to all of us. Tom Holce, an entrepreneurial legend throughout the Pacific Northwest, passed away this morning. Tom was one of those people whose legend was a reality: a genuine, insightful, smart, inspiring, and kind person. There will be a lot written about Tom over the next few weeks, most detailing his philanthropic activities and business successes. For us, we'd just like to say thanks for your belief and support in making Site9 a reality. We’ll deeply miss you.

Tom Holce, 1929-2010

Jason Fried of 37signals on Managing Conflict

37signals co-founder Jason Fried published an article in INC. titled Managing Conflict. It's a good look at conflict and how it can be beneficial if managed properly. He also gives a few examples of how they actually handle conflict management. One thing that stood out for me was:

...we try to get real with things as quickly as possible. For us, real means something we can all look at -- a picture, a sketch, something visual. Until everyone's looking at the same thing, it can be hard to reach actual agreement. Five people may read the same paragraph, but they often interpret the words differently. But when you look at a picture, a mockup, people are more likely to reach agreement -- or valid disagreement. Whichever way they go, at least we know where they actually stand, not where we think they stand. Pointing at something real cuts through to the truth.

I agree with this wholeheartedly. At Site9, one of our mantras is: "prototype early, prototype often." It can be more beneficial to quickly build small sections of a larger prototype in order to answer questions as they arise rather than hold all questions till the complete prototype is finished. Some ideas need a lot of structure in order to make decisions, but a lot of ideas don't. If you want to show what a nav bar will look like, or some logo treatments, you don't need the whole page. Better to get the ideas out and in front of people and make decisions.

I recommend reading the whole article as it has a some great advice on how to handle the times when you can't avoid conflict and you have to choose one side or the other.

Enhancing Prototype Fidelity with Styles

Introduction

When creating prototypes, one of your primary considerations is their level of fidelity. As described in a previous blog post, there are three dimensions of fidelity: visual fidelity, functional fidelity, and content fidelity. And for each dimension, your prototypes can be low fidelity, high fidelity, or something in between. For example, you might create gray-screen prototypes with minimal interactivity and placeholder text, or highly interactive prototypes that use a precise color palette and production-ready images and text. The best solution for you depends on your prototyping goals and your audience.

One way to enhance visual fidelity is with styles. Because ProtoShare generates prototypes using HTML and CSS, you have complete control over their colors, fonts, and other visual aspects.

I've had the opportunity to put the visual fidelity capabilities available in ProtoShare to the test for several Professional Services clients. Working from detailed design specifications, I could easily include their corporate colors, background images, and fonts, and create complex navigation with a completely customized look and feel. Several of the CSS techniques I used are described in the case studies below.

How to Include Styles in ProtoShare

All components use pre-built styles by default. You can modify existing styles and add custom styles by configuring component properties or by using the Styles screen. For the Rich Text component, you have the additional option of creating inline styles using its HTML editor.

Component Properties

While working in the Editor, you can apply a few basic styles to components. The styles are available in the Appearance group of the Properties tab, and are meant to take your design to the next level of visual fidelity beyond simple boxes. The available properties depend on the specific component, but generally include opacity, border style, fill color, and stroke color. Anybody comfortable with using the Editor can apply these styles, and knowledge of CSS is not required.

The Properties tab for the Rich Text component is shown below.

The Styles Screen

If you want to create custom styles, use the Styles screen. The Styles screen contains the global style sheet for your project, and styles created here are available for all components within a project. The exception is the HTML Sandbox component. In this case, you must define inline styles using the component's content editor.

The Styles screen is shown below.

You specify the styles using the standard CSS syntax. Precede class names with a . (dot) and IDs with a # (pound). All components have at least one default class name. You can use that class name to define CSS rules for all components of a given kind. You can also define additional class names or an ID for each component in the Mark-up group of the Properties tab in the Editor.

Some components, especially those in the Page Navigation group, make extensive use of pre-built styles. To modify these existing styles, you can use third-party browser add-ons (such as Firebug for Firefox) to discover the CSS rule of interest, and then include your modifications in the Styles screen. You can also display the ProtoShare default style sheets using your browser's View Source command while viewing a design. You can find most of the relevant styles in viewer.css.

Case Studies

Changing the Default Rich Text Property Values

All components have a collection of properties that are configurable through the Properties tab in the Editor. The properties are organized into groups, and the Appearance group includes the main properties related to component styles such as opacity, border thickness, and stroke and fill color. Configure these properties to suit your design goals. If you want to make more extensive changes, use the Styles screen.

For example, I want to configure a Rich Text component that's part of a footer clipping. The design goals for the footer state that its constituent components will not include borders or padding, and that the footer will include a background image.

The property configuration is shown below. Note that the fill is transparent so that the background image can be seen through the component.

Overriding Rich Text Heading and Link Styles

With the Rich Text component, you can format text, create links, include images, create tables, and more. The component uses the popular TinyMCE WYSIWYG editor. This editor supports a wide range of formatting options such as headings, font type and size, text and background color, and lists. The default formatting is specified by pre-built ProtoShare styles. For example, headings and paragraphs use sans-serif fonts, and links are rendered in the prototype using bold, gray text.

I want to modify the heading font size and render links using different colors for all Rich Text components in my project. I can do this by adding CSS rules to the Styles screen. Because this is a change that will be applied to all Rich Text components, I'll use the default class name, which is available in the Mark-up group of the Properties tab.

The CSS rules are shown below.

h1 {font-size: 2.4em;}
h2 {font-size: 1.5em;}
h3 {font-size: 1.2em;}
.RichText a {color: blue;}
.RichText a:visited {color: purple;}
.RichText a:hover {color: blue;}
.RichText a:active {color: black;}

If instead, I wanted to change the styles for a single Rich text component, I'd define an ID, a unique class name, or specify inline styles using the Rich Text HTML editor.

Changing Button Font Styles

The Button component is part of the Form Elements group. You can specify the text that's displayed in the button using the component properties, but you cannot modify the font properties using the Editor. Instead, you must use the Styles screen.

I want to change the font properties for a single Button component. To do this, I'll define the ID formSubmit in the Mark-up group of the Properties tab, and then specify the CSS rule in the Styles screen.

If you use just the ID selector when creating the CSS rule, it will not be applied. This is because ProtoShare defines Button component styles using the button HTML element. You wouldn't necessarily know this without examining the appropriate pre-built style sheet, which is viewer.css in this case. When you encounter a situation like this, and you're sure the CSS syntax is correct, you should determine how the the pre-built style is defined.

The CSS rule is shown below.

#formSubmit button {
     font-family: "Courier New", "Lucida Console", Courier, monospace;
     font-weight: bold;
     font-size: 1.5em;
}
Assigning Images to Navigation Styles

One of the most powerful features in ProtoShare is the ability to quickly build clickable prototypes. Using purpose-built components, you can display Site Map pages as breadcrumbs, jump menus, header navigation, subnavigation, and more. In particular, the horizontal and vertical navigation components provide you with tremendous flexibility. These two components are highly configurable and allow you to create just the right navigation experience. However, with this power comes complexity, and changing the pre-built styles can require a little extra effort depending on the task.

As you might expect, the navigation is rendered as an unordered list. Each list element contains a blockquote element, each blockquote contains a table, and each navigation link is contained within a table cell. Including links in a table is somewhat unusual, but is necessary to make the navigation work in all supported browsers and in the application. Also, each link state has an associated class in ProtoShare. For example, a normal, unvisited link has class x_inactive, while a visited link has class x_active.

The following CSS rules assign an image to the link, the link hover state, and the active link, respectively. You can use these rules to create an icon menu, for example.

#NAV.subNav ul li td {
     background: transparent url(/Assets/bgArrow.gif) no-repeat scroll 10px 12px; 
     width:150px; 
}
#NAV.subNav ul li td a:hover {
     background: transparent url(/Assets/bgTriangle.gif) no-repeat scroll right center; 
     color:#fff; 
}
#NAV.subNav ul li blockquote.x_active td {
     background: #A79E8C  url(/Assets/bgArrowOpen.gif) no-repeat scroll 10px 12px; 
     color:#fff; 
}
Targeting ProtoShare Page Content

Sometimes, the easiest way to define project-wide styles for page content such as text, hyperlinks, images, tables, and lists is with the tag. However, if you use the tag in the Styles screen, you might change the styles used by the application as well as your page content. To avoid this problem, ProtoShare includes a special class and ID protoshare-body, which allows you to access only the ProtoShare page content.

For example, to change the font family used in your designs (including table data), while leaving the application's font unchanged, you can create the following CSS rules.

.protoshare-body, .protoshare-body td {
     font-family: "Trebuchet MS", Helvetica, Jamrul, sans-serif !important; 
}
Using the Latest and Greatest with CSS3

With the introduction of CSS3, features such as round corners and drop shadows are now easy to create for developers targeting Mozilla and Webkit browsers.

You can incorporate these styles into your designs using the Styles screen. For example, the following CSS rules allow you to add round corners and drop shadows to components.

#roundCorners {
     border: 1px solid #666;
     -moz-border-radius: 1.5em;
     -webkit-border-radius: 1.5em;
}

#dropShadow {
     -moz-box-shadow: black 0.5em 0.5em 0.3em;
     -webkit-box-shadow: black 0.5em 0.5em 0.3em;
}

Summary

By including the appropriate level of visual fidelity in your prototypes, you can deliver just the right experience, and get answers to questions more quickly.

Because ProtoShare generates prototypes using HTML and CSS, you have complete control over their visual fidelity. If you're comfortable using the Editor, you can evolve your prototype beyond simple boxes by configuring component properties. If you have CSS knowledge, you can use the Styles screen to create custom styles.

The best solution for you depends on your prototyping goals and your audience. Using ProtoShare, it's easy to produce the desired look and feel from gray-screen prototypes, to visually stunning designs.

About the Founders
administrator login