Michael Gaigg: Über UI/UX Design

27Oct0

How to Disable Button on form submit in .NET

Posted by Michael Gaigg

This problem seems to be almost too obvious to be posted here but it took me quite some time to actually figure it out how to do it correctly - so I'd might just share it with you.

Disabling the submit button helps users comprehend that their action is in process and waiting for a response can be expected. It also prevents them from clicking the same action more than once which could lead to serious troubles (duplicate entries, application exceptions, etc.)

Problem

How do I disable a form submit button on a .NET page that does client-side validation?
The problem is that the button cannot simply be disabled because it would not be enabled again if the client-side validation prevents the form from being submitted.

Solution

.NET

<asp:Button runat="server" ID="btnSubmit" Text="Submit" OnClientClick="SubmitForm(this);" />

JavaScript:

function SubmitForm(source) {
ret = true;
if (typeof (Page_ClientValidate) == 'function') {
Page_ClientValidate();
ret = Page_IsValid;
}
if (ret) {
source.value = "Processing...";
source.disabled = true;
__doPostBack(source.name, "");
}
return ret;
}

14Oct0

5 Usability Newsletters to Follow

Posted by Michael Gaigg


Yes, you heard right, "Newsletter", this old-fashioned, 'traditional' thing that pollutes our mailboxes. Well, at least according to Jakob Nielsen email newsletters are more powerful than stream-based media (RSS or other social media feeds) in terms of maintaining a customer relationship, i.e. because newsletters need to be deleted manually versus 'dropping off' the users' main page.

5 Newsletters well worth following

Alertbox

Jakob's column on Web usability is probably the most prominent and longest running newsletter out there. Jakob has been publishing his research results and findings in his bi-weekly 'Alertbox' since 1995.

Subscribe to Alertbox

UIEtips

Jared M. Spool and his team publish their high-quality research, interviews with grands like Luke Wroblewski, Donna Spencer, Dana Chisnell et al and special offers on User Interface Engineering. Like Nielsen he's been around for ages and their conference is on sequel 14 this year.

Subscribe to UIEtips

SURL

The Software Usability Research Laboratory (SURL) was initiated in the Fall 1998 under the direction of Barbara S. Chaparro who has over 19 years of experience designing and evaluating user interfaces and conducting research in human-computer interaction (HCI). The goal of the lab is to provide usability services and research to the software development community and to train students on HCI with real-world projects.

Subscribe to SURL

Measuring Usability

Jeff Sauro maintains a very interesting site & newsletter at Measuring Usability. He has been pushing the limits of usability engineering for a few years now in the hopes of moving toward more objective implementations of user data. His articles are published irregularly but when they are, they deliver.

Subscribe to Measuring Usability

UI Design Newsletter

Every month Human Factors International (HFI) reviews the most useful developments in user interface research from major conferences and publications. Their UI Design Newsletter covers the full range of human-computer interaction, including development, HCI issues, I/O devices, multimedia, documentation, and training.

Subscribe to UI Design Newsletter

You know another Newsletter?

Have I missed something? Post it in the comments section.

12Oct0

Remote User Testing – A Comprehensive Guide

Posted by Michael Gaigg

No doubt, user testing increases the usability and acceptance of your website and can/should be done as early as possible, preferably during Prototyping.

The following blog entry discusses the advantages & disadvantages of remote user testing, describes time estimates & costs and explains how a session looks like using Techsmith's UserVue.

General Discussion

Advantages

  • Reduced (or no) travel time and expenses.
  • Higher exposure through easy screen sharing (managers can sneak in easily).
  • Actual user environment, familiar and comfortable.
  • Possibly fewer drop-outs.

Disadvantages

  • Facilitator not physically present (degree of separation can be challenging).
  • Can't see facial expressions or non-verbal cues.
  • Difficult to build rapport and trust.
  • Difficult to control environment.
  • Possibly technical difficulties (firewall, etc.).
  • Setup and use of software or usability lab might be challenging and requires a liaison.

Time estimates & Costs

Task Breakdown

The following time estimates are to be taken with a grain of salt, they can change significantly up or down depending on the project size, experience of the team and infrastructure.

  • Preparation (18 hours)
    • User screening: 8 hours
    • Task creation: 8 hours
    • Environment: 2 hours
  • User testing (10 hours)
    • 2 hours per user
    • 5 users per round
  • Post-test (32 hours)
    • Test report: 16 hours
    • Implementation: 12 hours
    • Communication: 4 hours

Summary: Our Time

1 Round = 60 hours
2 Rounds = 110 hrs.
3 Rounds = 160 hrs.

+ User comps
+ Time additional observers

How it works

Software

UserVue

UserVue is a Remote user testing software that enables a Facilitator to remotely observe a Participant using a phone line for communication. Multiple Observers can passively join the Session and share their observations with the Facilitator.

Morae Manager

Morae Manager uses the collected data (observation markers and notes, video, keyboard and mouse inputs) to analyze and calculate task times, error quotes and other common measurements.

Session

A Session is initiated by the Facilitator. Invitation emails are being sent to the Participant and Observer(s).

At the announced time all the involved parties need to download a small software bundle that allows them to connect to the UserVue software. The Facilitator then calls the Participant and gives instructions on how to start the Session.

After the session has ended the installed software bundle will be removed from computers of the involved parties.

Participant Requirements

Operating System

Microsoft Windows 2000 and Windows XP or later version of Windows.

Web Browser

Internet Explorer 5.0 or later, Firefox 1.0 or later.

JavaScript

Enabling JavaScript is recommended.

Security?

All communication with the UserVue Web site is performed over an encrypted Secure Sockets Layer transport mechanism (HTTPS). All session data is encrypted with a 128-bit Blowfish cipher as it is sent over the network.

Can anyone "eavesdrop" on my session?

All session data (including audio, video, chat data, etc.) is encrypted with a 128-bit Blowfish cipher as it is sent over the network. This makes it exceedingly difficult for anyone to intercept and observe session data.

Are copies of my session data stored anywhere?

No copies of session data are stored on any server. The only recording happens directly on the facilitator's computer. Session data may pass through TechSmith's servers to facilitate firewall and NAT traversal. However, this data is never stored. Also, this data is undecipherable as it is in an encrypted form as it passes through TechSmith's servers.

What are your experiences with Remote User Testing?

References

5Oct0

Happy 1st Anniversary!

Posted by Michael Gaigg

Thank You!

It's been one year since I started sharing my experience about User-centered Design on this blog. I want to take this opportunity and thank you all for reading my thoughts and insights - you give meaning to my work!

More important, I want to hear from you

  • what you liked,
  • what you didn't like and
  • especially what you would like to hear more about.

What's coming next?

Here is a sampling of what I'm currently working on or what I have planned to write about next:

  • Effective Web Design Critique
  • Code samples: jQuery, .NET, CSS
  • How Can I Evaluate the Quality of My Website?
  • More 'Design Guidelines'
  • More 'Best Practices' (including spreadsheets)
  • Some funny 'Lessons learned'
  • ...whatever else I learn every day

A look back

Popular Posts

Google street view sighting

Lessons learned...

My Personal Favorites

Your typical user captured on photo

Your typical User

Summary: Best Practices

Summary: Design Guidelines

Breadcrumbs

Breadcrumbs

30Sep0

Integrating Prototyping Into Your Projects

Posted by Michael Gaigg

This article was inspired by Integrating Prototyping Into Your Design Process - Using appropriate fidelity for the situation by Fred Beecher which I extend by the following:

Prototyping needs to be iterative throughout the project!

Goal of Prototyping

Prototyping is not only a design tool but a research and communication tool as well.

  • It should assist in optimizing the main task (top tasks) and validating its/their efficiency.
  • Furthermore this should not add cost to the project but reduce project expenses while increasing ROI.

So the goal is to use different levels of prototype fidelity to incrementally identify and enhance the user's task(s).

Ideally this happens linear (increase visual fidelity as you add functional fidelity) but typically it is bent to either side (see Figure 1) where more emphasize on

  • visual fidelity can be beneficial for marketing purposes or
  • functional fidelity can assist earlier user feedback trough user testing.
Prototyping in the context of your project

Figure 1: Prototyping in the context of your project.

Integration into your project

Regardless of the project approach you take it will boil down into the fundamental project management phases of Requirements, Design, Implementation (and possibly others). Prototyping should not be solely perceived as a method useful during Design, it is essential during all 3 (or more) phases starting as early as Requirements phase.

I suggest the following approach:

  1. Low-fidelity prototyping (paper / digital sketch)

    1. Create paper prototypes or digital sketches
    2. Design navigation architecture (workflow)
      1. Review with client
      2. User testing (optional)
      3. Iterate (until happy)
      4. Revise into 2
  2. Medium-fidelity prototyping (simple HTML)

    1. Simple HTML prototyping (maybe even black and white)
    2. Proof basic workflow and important interactions
      1. Review with client
      2. Iterate
      3. Revise into 3
  3. High-fidelity prototyping (Enhanced HTML)
    1. Enhance HTML prototype (links and basic functionality)
    2. Settle on design (including corporate design, basic artwork)
      1. Review with client
      2. Iterate
      3. Revise into 4
  4. Start 'real' implementation

Implementation Effort

Each prototype (digital sketch, simple HTML, advanced HTML based on simple) should not take more than 40 hours of pure development (not calculating initial meetings and communication and possible variations based on project size) plus 80 hours reviews and iterating with client. Sounds impossible? Think twice. It is so much easier to modify a sketch than programming HTML. The 'real' implementation will be built upon a solid code foundation with a grown-up design already - voila!

Can I skip a prototype?

Yes, obviously you can. But it comes with a cost later on because you miss crucial information from the earlier phase and it is more expensive to implement modifications.

Technical considerations

The argument I hear most often is that 'prototypes' are wasted time/money because they get trashed anyway. This is absolutely not true! Identifying problems early almost always saves money later on, you don't find anything out until you start showing it to people, enhancing the quality of the product will help money flow into your pocket once deployed and most important, prototypes don't necessarily need to and should not be trashed.

Low fidelity prototypes can be more than just ‘paper’, this could be digital wireframes that look like sketches, e.g. Microsoft offers software that tie sketches (SketchFlow) directly into UI design (Expression Blend) and subsequently into development (Visual Studio) - check out the WebsiteSpark Program for almost free licenses.

Don't bend too much!

Danger! Don't bend the curve from Figure 1 too much otherwise you end up with

  • a highly functional 'prototype' but without design, i.e. without visual clues whether your client/users will like it (buy it) and without validation that you got your information architecture right OR
  • a highly visual 'prototype' that looks sharp, sexy and slick but cannot be used and lack usability ("we just installed the app and now our users complain they [...]" - substitute the appropriate phrase for yourself 😉

Proof-of-concept

Creating medium- to high-fidelity prototypes can be considered proof-of-concept and can be beneficial to or sometimes even required by your project. Looking at Figure 1 that would mean to move their respective dots from Design/Implementation to an earlier phase.

What are your experiences?

Do you use / re-use multiple prototypes within your projects? Do your project structures support prototyping? To which extent?

18Sep0

15 Outstanding Examples of Braille in our World

Posted by Michael Gaigg

Braille can be found everywhere. Some findings are real gems, love the McDonalds braille lunch menu which is even advertised on drive-through windows in corporate locations - yes, exactly, didn't know they had driving test in braille yet. I'd actually opt for scratch and smell menus at McDonalds - ok, that's just me 😉

Love the braille bikini as well. Enjoy!

Hong Kong Disneyland (by tandaleo)

Hong Kong Disneyland (by tandaleo)

Wine label (by adactio)

Wine label (by adactio)

Japanese beer (by preetamrai)

Japanese beer (by preetamrai)

Medication (by Thijs van Exel)

Medication (by Thijs van Exel)

Graffiti (by John Kannenberg)

Graffiti (by John Kannenberg)

Monopoly (by Tostie14)

Monopoly (by Tostie14)

Google (by johnbullas)

Google (by johnbullas)

McDonalds braille menu in drive through (by John C Abell)

McDonalds drive through (by John C Abell)

McDonalds lunch menu (by nothingedifying)

McDonalds lunch menu (by nothingedifying)

Bike racks (by alex_lee2001)

Bike racks (by alex_lee2001)

Cake to celebrate the bicentenary of louis braille (by moirabot)

Cake to celebrate the bicentenary of louis braille (by moirabot)

Playboy (by 1980Andrew)

Playboy (by 1980Andrew)

Playing cards (by beerboxerboy)

Playing cards (by beerboxerboy)

Map of Cambridge (by DrNick3)

Map of Cambridge (by DrNick3)

Don't touch (by mako)

Don't touch (by mako)

Bikini (by tussenpozen)

14Sep0

Go figure: Hierarchy of Digital Distractions

Posted by Michael Gaigg

I'm still smiling about David McCandless's Hierarchy of Digital Distractions, a visual representation of digital things that matter to us. Well, some of them more than others.

In the shape of a pyramid the illustration reminds us of the order of importance model as suggested by Maslow's hierarchy of needs where the most fundamental need - earning our bread and butter (any kind of actual work) - is at base. Activities higher in the pyramid require more of our attention and 'trump' the activities below. Moving up in the pyramid means re-prioritizing activities by focusing on lesser important but subjectively more fulfilling needs.

The Hierarchy of Digital Distractions

The Hierarchy of Digital Distractions

So, if you in the midst of a phone call on one of those ancient Landlines, a New Voicemail will catch your attention which in turn will be trumped by a Mobile Phone call in silent vibrating only before the next Text Message comes in which obviously is not as important as a Mobile Phone call. Beware of buying an iPhone though because anything happening on your iPhone will overpower the before mentioned.

An email from a romantic partner will always rule over any skype call and a new message from your online dating service which is in return more important than an @message on twitter, a message on facebook or a new contact on flickr. All this happens is fine until one of your devices crash or your partner shuts the lid of your laptop on your fingers.

What's your funny interpretation?

8Sep0

Design Guidelines: Print Stylesheet

Posted by Michael Gaigg

One of the most elegant techniques in web design is the use of a print stylesheet to control the style of a webpage on a hardcopy. Being so easy and cheap it is by far the most undervalued technique out there.
Often overseen bonuses are

  • adding copyright statements or thank you notes,
  • controlling which elements should not be seen (remove menu, commercials,...) and
  • in general ensure that the printed page is legible (contrast especially for links, fonts, ...).
Results of applying a print stylesheet to the page

Results of applying a print stylesheet to the page

Design Guideline for a Print Stylesheet

  1. Make page legible
    • Use serif font family (e.g. Georgia)
    • Use points (e.g. 12pt)
    • Ensure good contrast (e.g. color: #000; background: #FFF)
  2. Maximize paper use (e.g. width: 100%)
  3. Hide elements not relevant to print (e.g. display: none)
  4. Add content relevant to print (e.g. spell out links, thank you note)
  5. Use correct markup to reduce amount of styling (e.g. h1, h2,...)

How it works

Embed an extra stylesheet designed for print media into the page.

<link rel="stylesheet" type="text/css" media="print" href="print.css" />

This stylesheet takes effect when a user invokes the print function of the browser and overrules style elements in other stylesheets on the page.

Then either provide a button or link that triggers a javascript function to print the page or have the user go through the browser's menu, even print preview would show you the expected layout already.

<a href="#" onclick="window.print();return false;">Print page</a>

I know, evil javascript, but hey, if turned on it works cross-browser (except IE6 with multiple IE versions installed).

Code sample

I recognize that many samples can be found on the web but I also found them incomplete in many cases. I don't claim to be compete myself, but I really like with what I came up with and most of all would like to hear your comments and feedback or even better references or links where you applied it to.

Download sample code

index.htm

<html>
<head>
<style type="text/css" media="all">
@import "main.css";
</style>
<link rel="stylesheet" type="text/css" media="print" href="print.css" />
</head>
<body>
<div id="wrapper">
<div id="statement">Legal statement and thank you note.</div>
<div id="header">Header</div>
<div id="content">Content plus <a href="http://link.com/">Link</a></div>
<div id="footer">Footer</div>
</div>
</body>
</html>

main.css


/**
Elements
*/
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
body {
line-height: 1;
color: black;
background: white;
font-family: Arial, Helvetica, sans-serif;
}
ol, ul {
list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: separate;
border-spacing: 0;
}
caption, th, td {
text-align: left;
font-weight: normal;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: "";
}
blockquote, q {
quotes: "" "";
}
/**
Classes
*/
/**
IDs
*/
#wrapper {
background: #FFFFFF none repeat scroll 0%;
margin: 0pt auto;
width: 600px;
}
#header {
border: 1px solid #CCC;
margin: 5px;
padding: 5px;
}
#content {
border: 1px solid #CCC;
background: #EEE;
margin: 5px;
padding: 5px;
height: 200px;
}
#footer {
border: 1px solid #CCC;
margin: 5px;
padding: 5px;
}
a:link, a:visited {
border-bottom:1px dotted;
color:#AE4F0C;
font-weight:bold;
text-decoration:none;
}
a:visited {
color:#333333;
}
a:hover, a:focus {
border-bottom-style:solid;
color:#D03900;
}
a:focus {
/*background:#FFFFCC none repeat scroll 0%;*/
}
#statement {
display: none;
}

print.css


body {
font-family: Georgia, serif;
background: #FFF;
color: #000;
font-size: 12pt;
}
#wrapper, #content {
width: auto;
height: auto;
margin: 0 5%;
padding: 0;
border: 0;
float: none !important;
color: #000;
background: transparent none;
}
#content {
margin: 10px;
}
#header, #menu, #sidebar, #footer, .noprint {
display: none;
}
#statement {
display: block;
border: 1px solid #666;
padding: 10px;
}
a:link, a:visited {
color: #781351;
background: transparent;
text-decoration: underline;
}
a:link:after, a:visited:after {
content: " [" attr(href) "] ";
}

References:

3Sep0

Free book online: The Principles of Successful Freelancing

Posted by Michael Gaigg

I know this might be a little off-topic but nevertheless useful to many of us. The book 'The Principles of Successful Freelancing' of Miles Burke is available for free to download (only valid for the next 10 days starting today), so get it now!

Contents

  1. Considering Freelancing?
  2. Prepare for the Transition
  3. Manage Your Money
  4. Set Yourself Up
  5. Win the Work
  6. Give Great Service
  7. Achieve Work–Life Balance
  8. Where to from Here?

About the author

Miles Burke has been creating web sites since 1994. In 2002, Miles founded Bam Creative, an award-winning Western Australian web company. Miles serves as Chairperson of the Australian Web Industry Association, and has been awarded for his entrepreneurship in recent years; he’s a recipient of the Contribution to the Web Industry award in 2005, winner of the WA Business News’ 40under40 award in 2007, and appears in the 2008 edition of Who’s Who in Western Australia. Miles can also be found writing at Miles’ Blog.

Links for freelancers

Have more useful links? Post them in the comments section.

Suggested reading:
28Aug0

Presentation: Wiki – the right tool for my organization?

Posted by Michael Gaigg

Finally I got my head around posting a presentation I gave last March. The title is "Wiki - the right tool for my organization?" and had the purpose of introducing the concept of a wiki to a group that was about to install a wiki within their department.

Background: About three years ago I went through the effort of evaluating existing wiki platforms, installing/hosting it for our department and keeping it alive for the next two years before it got sacked. I'm here to tell you why it didn't work out in the end.

Characteristics

I jump right into the characteristics (the slide "Characteristics" is duplicated in the presentation on purpose) because I found understanding them key to a successful implementation. That's why once more I want to emphasize on the issues that need to be met in order to successfully implement a wiki, for example if your company has no culture of sharing content or employees are reluctant to give up ownership of their code, a wiki is most likely not the ideal collaboration tool.

These are the characteristics of a wiki:

  • Perpetual work in progress
  • No one owns the content
  • No specific organization (hyperlinks)
  • Anyone can edit other people’s work
  • Discussion area for each page
  • Version control: list of all changes made to a page

Critical Success Factors (aka truth about a wiki)

Only implement a wiki if you feel comfortable you can meet the following critical success factors:

  • Only 10% contribute; only 1% on a regular basis.
  • Obey the characteristics of a wiki
  • Power to the people
    • Trust the user
    • Authority to change something
    • Refuse defined structures

My previous experience taught me that implementing a wiki into your organization is doomed to fail if one is not aware of their importance and therefore

  • overestimates the reach and participation,
  • neglects the characteristics of a wiki,
  • or doesn't want or cannot give power to the people.

The truth is, only 10% of users contribute to a wiki and only 1% on a regular basis. If you have 100 employees you can expect between 1 to 10 of them to contribute and the rest to consume - which in turn will lead to lesser contribution and lesser consumption over time. Wikipedia works well because there are millions of users where 1% is still significant number to keep up quality content.
The argument of mandatory (or even monitored) participation runs directly against the characteristics of a wiki, is counter-productive and will result in your wiki failing.

Choosing a wiki: What to consider

Obviously there are many criteria and features that will directly affect your choice. I recommend Comparison of wiki software as a starting point for finding the right software but I wouldn't be surprised if you ended up with MediaWiki which is the used by wikipedia for one simple reason (besides its free usage under the GPL license and its huge community): the MediaWiki syntax is widely used and makes actually sense to learn - because it is wikipedia 😉

Criteria

  • Cost (open source license)
  • Programming language (PHP, C#, Java)
  • Data backend (File system or DB)
  • Extensibility & user community

Features

  • WYSIWYG editing & Syntax
  • Version control & Discussions
  • Permissions & Security

Keys to get a wiki going

Once you've decided to go ahead and install a wiki, what can be done to make it successful?

  • Find dedicated helpers
  • Partner with groups/people related to your mission
  • Offer structural templates for new pages
  • Add some content to major categories
  • Do lots of marketing
  • If possible, offer training

Do you work with wikis?

What are your experiences? Do you use a wiki in your company? How do you use it?

Page 19 of 24« First...10...1718192021...Last »