Brief about various Designs

Maybe just a shorter version:

·         Graphic/Visual Design: How it looks

·         Information Architecture/Design: How it's organized

·         UI Design: How it works before I touch it

·         Interaction Design: How it works after I touch it

·         Web Design: How it works in a browser

·         UX Design: How I feel about it

·         Development: Actual coding

first of all lets clarify design and development

design is a conceptual work, production of a concept for a solution, a process of elimination of things that you think, feel and believe do not fit as a solution to your intended goal

development is a production of finalized specification/idea (at least in theory) or something that makes sense and close to what you are looking for (although in many cases it is not like that), basically a conversion of your design/idea into working end product

note that both things can and do in most cases coexist side by side in production of the product

now that this is out of way, visual, web, ux, ui are just sub categories of a design notion, each although based on design principal also have their own sub universes and their own sub rules and sub practices that apply directly to their respective subcategories and in many cases can propagate seemingly from one sub category to another.

from my understanding and what i have learned over the years,
interaction design (none specific to field) - concept/understanding how one/individual interacts with an entity and how to design the process of interaction of that individual with the entity. that entity can be anything you pick it to be, for example your car, or your toaster, web browser and website that you view in a browser.
visual design (none specific to field) - concept/understanding of aesthetic appeal and impact of an entity with which individual interacts/looks at
web design (field specific) - concept/understanding of an idea that is a technology(s) specific and includes aspects of multiple design concepts such as but not limited to: interaction design, visual design, user experience design, user interface design and so on
user experience design (none specific to field) - concept of designing user experience, which in turn includes visual design and interaction design plus the limitations of the field in which such design work is happening
user interface (some what specific to field) - concept of designing an interface through which user can interact with the product, gui in soft/web app or an steering wheel in a car
user interface development (none specific to field) - is a process of converting user interface design concept into functioning interface that creates physical connection between individual and product.

Source: http://stackoverflow.com/questions/1654093/what-is-difference-between-interaction-design-visual-design-web-design-ux-des

Style a Select Box Using Only CSS

I often have to use a select box when I’m putting together a custom form that requires a drop down list. It took me a while to figure out how to easily style the select box using only CSS since certain parts are browser specific, such as the drop down arrow.

Here is how a select box will look by default:

Here is the first optionThe second option 

This is the HTML code:

<select>
   <option>Here is the first option</option>
   <option>The second option</option>
</select>

There are certain elements of a select box that we can style such as the font, border, color, padding and background color:

Here is the first optionThe second option 

But that annoying drop down arrow always stays the same. There is no direct way to do style it, but the workaround is pretty simple.

First we need to surround our select box element with a div container:

<div class="styled-select">
   <select>
      <option>Here is the first option</option>
      <option>The second option</option>
   </select>
</div>

Next we need to add a bit of CSS to make sure that the elements of the select box are styled a certain way:

.styled-select select {
   background: transparent;
   width: 268px;
   padding: 5px;
   font-size: 16px;
   line-height: 1;
   border: 0;
   border-radius: 0;
   height: 34px;
   -webkit-appearance: none;
   }

We need to make sure that our select box actually spans wider than the surrounding div container so that the default drop down arrow disappears.

This is the new drop down arrow I want to use:

Our div container needs to be styled like so in order for the new arrow to appear where we want it to:

.styled-select {
   width: 240px;
   height: 34px;
   overflow: hidden;
   background: url(new_arrow.png) no-repeat right #ddd;
   border: 1px solid #ccc;
   }

Our select box should now look like this:

Knowing this little workaround will make it a whole lot easier to style your select box exactly how you want it to be styled using nothing but CSS.

Sourece: http://bavotasan.com/2011/style-select-box-using-only-css/

IE Hacks

IE8 and Below

The key to targeting Internet Explorer 8 and below, with a hack, is to append “\9″ to the end of your style. For example:

 

body {

 color: red; /* all browsers, of course */

 color : green\9; /* IE8 and below */

}

It’s important to note that it must be “\9″. Unfortunately you can’t replace this with something along the lines of “\IE”, like I attempted to do so. Even “\8″ won’t work; it must be “\9″.

---

IE7 and Below

body {

 color: red; /* all browsers, of course */

 color : green\9; /* IE8 and below */

 *color : yellow; /* IE7 and below */

}

IE6

Lastly, we have the underscore hack, which most designers are familiar with by now. Rather than the * symbol, we use the underscore. This will target only Internet Explorer 6.

body {

 color: red; /* all browsers, of course */

 color : green\9; /* IE8 and below */

 *color : yellow; /* IE7 and below */

 _color : orange; /* IE6 */

}

How To Create an IE-Only Stylesheet

If you read this blog, there is a 99% chance you've had a hair-pulling experience with IE. But if you are worth your salt as a CSS coder, you should be able to deal with it. I am of the opinion that you can handle anything IE can throw at you without the use of hacks. Hacks are dangerous, since they are based on non-standard exploits, you can't predict how they are going to behave in future browsers. The tool of choice for fighting IE problems is the conditional stylesheet. IE provides comment tags, supported all the way up to the current IE 8 to target specific versions, as well as greater-than/less-than stuff for targeting multiple versions at once.

Why use conditional stylesheets?

·         You got problems, they need fixin'

·         Keeps your code hack-free and valid

·         Keeps your main stylesheet clean

·         Perfectly acceptable technique, sanctioned by Microsoft

And remember, these conditional tags don't have to be used only for CSS. You could load JavaScript, or even use them down in the content of your site to display special IE-specific messages.

The Code

This would go in your <head> with all the other regular CSS <link>ed CSS files. The opening and closing tags should be familiar, that's just regular ol' HTML comments. Then between the brackets, "IF" and "IE" should be fairly obvious. The syntax to note is "!" stand for "not", so !IE means "not IE". gt means "greater than", gte means "greater than or equal", lt means "less than", lte means "less than or equal."

Target ALL VERSIONS of IE

<!--[if IE]>

        <link rel="stylesheet" type="text/css" href="all-ie-only.css" />

<![endif]-->

Target everything EXCEPT IE

<!--[if !IE]><!-->

        <link rel="stylesheet" type="text/css" href="not-ie.css" />

 <!--<![endif]-->

Target IE 7 ONLY

<!--[if IE 7]>

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

<![endif]-->

Target IE 6 ONLY

<!--[if IE 6]>

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

<![endif]-->

Target IE 5 ONLY

<!--[if IE 5]>

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

<![endif]-->

Target IE 5.5 ONLY

<!--[if IE 5.5000]>

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

<![endif]-->

Target IE 6 and LOWER

<!--[if lt IE 7]>

        <link rel="stylesheet" type="text/css" href="ie6-and-down.css" />

<![endif]-->

<!--[if lte IE 6]>

        <link rel="stylesheet" type="text/css" href="ie6-and-down.css" />

<![endif]-->

Target IE 7 and LOWER

<!--[if lt IE 8]>

        <link rel="stylesheet" type="text/css" href="ie7-and-down.css" />

<![endif]-->

<!--[if lte IE 7]>

        <link rel="stylesheet" type="text/css" href="ie7-and-down.css" />

<![endif]-->

Target IE 8 and LOWER

<!--[if lt IE 9]>

        <link rel="stylesheet" type="text/css" href="ie8-and-down.css" />

<![endif]-->

<!--[if lte IE 8]>

        <link rel="stylesheet" type="text/css" href="ie8-and-down.css" />

<![endif]-->

Target IE 6 and HIGHER

<!--[if gt IE 5.5]>

        <link rel="stylesheet" type="text/css" href="ie6-and-up.css" />

<![endif]-->

<!--[if gte IE 6]>

        <link rel="stylesheet" type="text/css" href="ie6-and-up.css" />

<![endif]-->

Target IE 7 and HIGHER

<!--[if gt IE 6]>

        <link rel="stylesheet" type="text/css" href="ie7-and-up.css" />

<![endif]-->

<!--[if gte IE 7]>

        <link rel="stylesheet" type="text/css" href="ie7-and-up.css" />

<![endif]-->

Target IE 8 and HIGHER

<!--[if gt IE 7]>

        <link rel="stylesheet" type="text/css" href="ie8-and-up.css" />

<![endif]-->

<!--[if gte IE 8]>

        <link rel="stylesheet" type="text/css" href="ie8-and-up.css" />

<![endif]-->

Universal IE 6 CSS

Dealing with IE 6 and below is always an extra-special challenge. These days people are dropping support for it right and left, including major businesses, major web apps, and even governments. There is a better solution than just letting the site go to hell, and that is to server IE 6 and below a special stripped-down stylesheet, and then serve IE 7 and above (and all other browsers) the regular CSS. This is been coined the universal IE 6 CSS.

HTML

<!--[if !IE 6]><!-->

  <link rel="stylesheet" type="text/css" media="screen, projection" href="REGULAR-STYLESHEET.css" />

<!--<![endif]-->

 

<!--[if gte IE 7]>

  <link rel="stylesheet" type="text/css" media="screen, projection" href="REGULAR-STYLESHEET.css" />

<![endif]-->

 

<!--[if lte IE 6]>

  <link rel="stylesheet" type="text/css" media="screen, projection" href="http://universal-ie6-css.googlecode.com/files/ie6.0.3.css" />

<![endif]-->

 

Hacks

If you must...

IE-6 ONLY

* html #div { 

    height: 300px;

}

IE-7 ONLY

*+html #div { 

    height: 300px;

}

IE-8 ONLY

#div {

  height: 300px\0/;

}

IE-7 & IE-8

#div {

  height: 300px\9;

}

NON IE-7 ONLY:

#div {

   _height: 300px;

}

Hide from IE 6 and LOWER:

#div {

   height/**/: 300px;

}

html > body #div {

      height: 300px;

}

Credits

http://css-tricks.com/how-to-create-an-ie-only-stylesheet/

http://net.tutsplus.com/tutorials/html-css-techniques/quick-tip-how-to-target-ie6-ie7-and-ie8-uniquely-with-4-characters/

UI Design for Business Web Applications

This article covers the basics of user interface design for business Web applications. While one could apply many approaches, techniques and principles to UI design in general, our focus here will be on business Web applications.

Websites vs. Web Applications

A website is a collection of pages consisting mostly of static content, images and video, with limited interactive functionality (i.e. Except for the contact form and search functionality). The primary role of a website is to inform. Some websites use content management systems to render dynamic content, but their nature is still informative.


CampaignMonitor is powerful email marketing software, while Jeff Sarimento’s website is intended to inform readers about his life and work.

Web applications, on the other hand, are dynamic, interactive systems that help businesses perform business critical tasks and that increase and measure their productivity. Thus, the primary role of a Web application is to perform a function that serves the user’s tasks and according to defined business rules.

Web applications require a higher level of involvement and knowledge of the system on the part of the user. They don’t just stumble upon the application, do their work and bounce off. They use it as a tool to perform critical business tasks in their daily work. In the end, they cannot easily discontinue using the application and switch to another if they don’t like how it’s working, as is the case with websites.

DIFFERENT TYPES OF WEB APPLICATIONS

Business applications range in type from invoicing for freelancers to content management systems to document management systems to banking and financial systems.

We can distinguish between open and closed applications. Open systems are online applications that are easily accessible to anyone who opens an account. Users can access such applications via the Web and can open an account for free or by paying a fee. Closed systems (or line-of-business applications) are usually not accessible outside the company that uses it, and they can be considered “offline” applications (though many systems expose their functionality to business partners via other services or specialized interfaces). Such systems usually run on the company’s local network and are available only to employees.

First, Know Your Users

A successful user interface focuses on users and their tasks. This is key, and too many developers have failed to create a good user experience. As Steve Krug said, “Developers like complexity; they enjoy discovering how something works.”




When identifying your users, keep in mind that clients are not users, and you are not a user. 

HOW TO IDENTIFY USERS?

Identifying users can be done using several techniques, such as user interviews, business stakeholder interviews and the “shadowing” method of observation. Interviews can give you answers to questions about the users’ knowledge of the system and computers in general, while shadowing can yield more detailed information about how users perform tasks and what errors they make. The method is called shadowing because the observer is like a shadow, watching and noting the steps a user takes.

If you don’t have access to real users—either because you don’t have permission or are designed for open application—you can use personas, a tool to help identify users. Personas are a representation of real users, including their habits, goals and motivation. Because certain information about users is often identified through business analysis, you can make use of it to create personas. If you are not familiar with the tool, a comic by Brad Colbow will help.

Task analysis helps identify what tasks users perform in their jobs, how they do them, how long they take and what errors they make. Sometimes clients will be using an old version of the application that you are designing to replace. Make use of that old system and watch how users use it. Understanding their tasks and challenges will be easier that way.

Regardless of who your users are, one thing is certain: in most cases, you will have to consider both novices and experts. Novice users should be enabled to learn as fast as possible, while expert users should be enabled to perform their tasks extremely efficiently. This may mean creating separate interfaces. But in many cases you will be able to accommodate both types of users in the same interface through various techniques, such as progressive disclosure.

Such research is usually done by business analysts. But if no one else is responsible for it, you should do it. Once you have the necessary information, you can begin with design.

Design Process

You can follow one of any number of processes in designing the user interface. You might already have one. However, I would suggest that you consider the Agile approach. Why, you ask? Well, because for users (and clients), the user interface is the product. The bottom line is that they don’t care about your sketches or about fantastic back ends or powerful servers. All they want to see is the user interface.

So, how does Agile help? It helps through its key principle: the iterative approach. Each iteration consists of all of the phases defined by your process. This means that at the end of the first iteration, you will have a product that can be tested, a prototype.

SKETCHING

Sketching is a powerful way to explore ideas. The goal is to arrive at the solution by sketching out different concepts. In “Sketching User Experience” book, sketches are fast to create and easy to dispose of, which is why they are so powerful.

Are sketches the same as wireframes? Well, the differences can be blurry, but I would say no. Wireframes don’t capture rough ideas but rather develop them. 

Once you get the “right” sketches, or at least the one that you think are right, you can create more detailed wireframes or go straight to creating interactive prototypes.

PROTOTYPING

The next step in the process is to create prototypes that will simulate the real application. A prototype can contain one or more features (or all of them), but it actually does nothing. It merely simulates the behavior of a real application, and users will feel that they are actually doing something. Prototypes may contain some functionality if needed (such as complex calculations).

Because the nature of a prototype done in HTML is temporary—its purpose, after all, is to test ideas—don’t bother with the code; just make it work with minimal bugs. You will throw it away anyway. You can also use specialized prototyping software such as Axure. Some people even prototype in PowerPoint.

TESTING

Prototypes are useless unless you test them. This is not rocket science. People like Jakob Nielsen and Steve Krug support so-called “discount usability testing,” which is cheap and fast and yields valuable insight into your design decisions. You will use this information as the basis of another iteration of sketching, prototyping and testing. Do this at least until major issues have been fixed. We all know that software projects are tight on time and budget, so to be more efficient, test early and test often.

Design Principles

There are many design principles, but there doesn’t seem to be a general consensus on definitive ones. So, we’ll go through design principles more informally, leaving out strict definitions.

NO ONE LIKES SURPRISES

Probably the key factors in a good UI are consistency and familiarity. A user interface should be consistent across all parts of the application, from navigation to color to terminology. This is known as internal consistency. But a user interface should also be consistent within its context, such as the operating system or other applications in its group or family. A typical example is the applications in the Microsoft Office family. This is called external consistency.

A good approach to consistency is to define user interface guidelines for each project or for a group of projects. These should guide the decisions you make for all of the details. This will not only maintain consistency but also serve as documentation to help team members better understand your decisions.

Although a simple example, SprinklePenny achieves consistency and familiarity across the application.

Consistent user interfaces have a shorter learning curve, because users will recognize parts of the system and be able to fall back on prior experience. But familiarity is sometimes confused with consistency. Familiar user interfaces draw on concepts from the users’ previous experiences and use appropriate metaphors. Folders, for example, are a well-known metaphor for file organization, and they have replaced “directories,” which were used previously in command-line operating systems. In short, speak the language of your users.

A common belief among business owners is that a great user interface should look like a Microsoft Office product, especially Outlook. I won’t go into explaining how pointless this is. Rather, I will offer alternative advice: defend the user-centric approach, and explain why creating an application for employees, clients and partners (i.e. Their users) is so important.

All the same, most businesses are unique, as are their work processes. For example, two businesses from the same branch could have significantly different processes, forcing you to go beyond what is familiar and start to innovate. This part of the design process can be very interesting, although you have to be careful in how far you go with innovation.

USERS SHOULD BE ABLE TO BE EFFICIENT

Without a doubt, users should be able to be efficient when using business applications. This is what they are paid for, and this is what managers expect from the application. User interfaces should allow users to be efficient and should focus them on completing tasks in the easiest and fastest way. But this is not always the case. There is an opinion, or at least practice, among developers that says the user interface should be as complex as the back end system. No matter how ridiculous this sounds, the problem is real and might give you a headache. This is one reason why good communication and collaboration between developers is a must.

Users are efficient when they focus on a particular task. As mentioned, task analysis can help you identify tasks and determine how users perform them. If tasks are long, accelerate them by breaking them up into smaller units. You can also increase efficiency by providing keyboard support and shortcuts. Think how inefficient it is for a user to have to switch back and forth between mouse and keyboard. In some cases, you will be designing for users who are accustomed to working on command-line operating systems and the applications made for them. They will be keen to have keyboard support. One suggestion: when defining keyboard shortcuts, keep them consistent with those of common applications. For example, Ctrl + S should always save, and so on.

Efficiency can also be enhanced through personalization. Users who can personalize an environment will learn it faster and, more importantly, will be more confident using it. Personalization can be done in many ways: choosing widgets for the dashboard; defining shortcut options and favorites; changing the order of elements; etc.

Pay attention to accessibility. Although many assume that accessibility doesn’t matter in Web applications, it certainly does. Treat the application as if it was a public website.

A Web application also has to be efficient in the speed with which it processes information. So, consider heavy interactions that result from partial renderings and AJAX requests.

HELP!

An interface should provide meaningful feedback that describes the state of the system to users. If an error occurs, users should be notified and informed of ways to recover. If an operation is in progress, users should be notified about the progress.

We can go even further and declare that user interfaces should prevent users from making errors. This principle, called forgiveness, can be followed with confirmation dialogs, undo options, forgiving formats and more. Forgiveness makes it safe to explore the interface, decreases the learning curve and increases overall satisfaction.

Because of the complexity of business Web applications, you would also need to provide a comprehensive help system. This can be done with inline help, a support database, a knowledge base and guided tours (which mix video, images and text).

CAN’T GET NO SATISFACTION

Satisfaction is a subjective term that refers to how pleasant an interface is to use. Every design principle we have described here affects  satisfaction. And a few more principles are worth mentioning here.

Simplicity is a basic principle of UI design. The simpler a user interface, the easier it is to use. But keeping user interfaces for business applications simple is a challenge because the apps often have a lot of functionality. The key is to balance functionality and simplicity. Restraint is one of the most efficient ways to achieve this balance: i.e. Finding the simplest way to solve a problem.

BuildWith.me has a simple and effective user interface, without sacrificing aesthetics.

Aesthetics, though subjective and somewhat arbitrary, play an important role in overall satisfaction. Users respond positively to pleasing user interfaces, sometimes even overlooking missing functionality. But you’re not creating a work of art. One of the best articles that explains aesthetics is In Defense of Eye Candy.

In the end, users will be spending a lot of time in front of a business application, and no matter how usable, consistent or forgiving the interface is, satisfaction will be critical in determining how good the user interface is.

Essential Components Of Web Applications

Every Web application is unique, but many of them contain common features. Although the implementation of any one of these features will vary, let’s look at the basic concept of the three most common ones.

WEB FORMS

Forms in general are important to Web applications. But as Luke Wroblewski says in his Web Form Design book, “No one likes filling in forms.” That includes sign-up forms, including business applications with dozens of fields.

Minimize the frustration of filling in forms. Provide inline validation and good feedback. Use defaults when possible. Don’t forget about novice users. Use wizards to help them complete tasks faster, or use progressive disclosure to hide advanced (or infrequently used) features.

MASTER-DETAIL VIEWS

This is the technique of showing data in two separate but related views. One view shows a list of items, while the other shows details of the selected item. Master-detail views can be implemented across multiple pages or on individual ones.

DASHBOARDS

Many Web applications have dashboards. A dashboard is a view of the most important information needed to take action and make decisions. It is confined to a single page and is usually the starting point of an application. Dashboards are important because they enable users to access information and take action without having to dig through the application.

Xero shows a user’s most important financial information (e.g. bank accounts and credit cards) in its dashboard, making it easy for users to quickly see the status of their financial data.

HEAVY USE OF TABLES

Because Web applications typically deal with large quantities of data that are easily accessible and sortable, tables are unavoidable. But this is not a bad thing. In fact, tables were made for this purpose. Don’t confuse this with table-less layouts. Effective tables are easily readable. So, in most cases you will need a meaningful header, an optimal number of columns, pagination, alternating row colors, proper column alignment, sorting and filtering capabilities and much more.

Tables can also be interactive, meaning they can generate additional info and even modify the data they contain.

PulseApp is a good example of how tables can be used to efficiently present and manipulate complex data.

REPORTS

Most businesses work with some kind of reports. Printed reports are usually required, so pay attention to the design of reports. Printed (or exported) reports are usually simplified versions of online reports, optimized for monochrome printers.

FreshBooks has printing, PDF exporting and “Send to email” features. It also shows a print preview.

Don’t Forget UI Design Patterns

We’re so used to hearing and talking about UI design patterns that we sometimes forget about them! UI design patterns are helpful for designing user interfaces. The important thing is to consider them early on in the design process, ideally at the sketching stage. Because patterns often solve common problems, the right pattern can facilitate the user’s familiarity with an interface and increase the speed at which they learn it.

Case Study: Online Banking Application

To take an example from the real world, I will briefly explain the process of designing the user interface for one small bank’s online banking system. The team I worked with was hired to improve the system. The main reason for the redesign was that, according to management, “users complained and many stopped using it.”

After only a couple of hours spent with actual users, the main problems were uncovered. Information about accounts and credit cards was buried in poor navigation. Understanding how much money users were spending and the state of their accounts and credit cards was also hard. The application, however, was obvious to bank employees; they were familiar with the terminology and could interpret the numbers in the application perfectly well.

Give the tight deadlines, we followed the process I have described, and we partially succeeded. Despite the short time, the major problems were so obvious that we clearly understood our main task and how to go about it. We created a dashboard that provided clear information on the state of all accounts and credit cards. With this new navigation, finding information became easier. Reports were easier to understand, and several new features were implemented.

Although we made only a few changes, the changes affected critical user tasks and resulted in significant improvements to the overall experience.

Final Thoughts

Designing user interfaces for business Web applications is a challenging job that is full of compromises. You have to make compromises between client and user needs; business requirements and users; novice and expert users; functionality and simplicity. It requires a solid understanding of users and their tasks, as well as of UI design principles and patterns. Despite the difficulties, the job is interesting, and you learn many new things on each project that influence the way you design websites.

While this article reflects some well-known concepts and things I have learned from designing business applications over the years, I look forward to hearing your experiences and stories.

Author: Janko Jovanovic

Credits: http://uxdesign.smashingmagazine.com/2010/02/25/designing-user-interfaces-for-business-web-applications/