http://tc.eserver.org/publisher/Particletree A listing of works published by Particletree in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Particletree http://tc.eserver.org/35638.html http://tc.eserver.org/35638.html Using color and color alone as a visual cue is appealing because it’s usually an aesthetically pleasing and a minimalist design technique. Calls to action and visual cues are critical to interface designers because users, especially on the web, have limited patience and are looking to process information and make decisions quickly. Since the brain recognizes and forms an emotional bond with colors almost immediately, colors are a natural choice for visual cues. Unfortunately, it’s easy to alienate or confuse some of your users when some of those aesthetically pleasing colors look very similar. To point out a few interfaces that use hard to differentiate colors as visual cues, here are a few examples that have given me some trouble. http://tc.eserver.org/27693.html http://tc.eserver.org/27693.html Jeffery Zeldman wrote earlier this year in his essay about Web 3.0 that 'Wireframing AJAX is a bitch.' And while I can't deny the statement, I do think there are steps we can take to alleviate the pain. The problem is static XHTML/CSS wireframes are woefully inefficient at the task of communicating and documenting the features available to the new crop of Ajax web sites. Because we've been working on a rather intense Ajax project for the last few months, we've been developing and refining a number of techniques and guidelines to help our team design for Ajax by moving beyond the traditional forms of functional specs and wireframes to something a bit more appropriate for the dynamic medium'rapid prototyping. http://tc.eserver.org/27688.html http://tc.eserver.org/27688.html I know there are a good number of designers out there afraid of anything that smells of programming (basically, if it's not plug and play, it's not being used). I completely understand. Dealing with CSS rending across browsers is bad enough already. Because prototypes are all about making an interface 'look' like it works, the dabbling we're going to go over here is actually a process that's amenable to designers (especially those with programming skills that started off as just rudimentary hacking skills). CSS is the domain that most of the new crop of web designers are most comfortable with and so the functions we're going to go over are ones that manipulate, for the most part, the styles of our elements. http://tc.eserver.org/27684.html http://tc.eserver.org/27684.html Goes over a few techniques and approaches we use to create the foundation of every prototype--wireframes. In addition to serving as documentation for those working with the markup, wireframes are a great way to create screenshots and debug rendering problems that are happening during DOM manipulation. Whenever we find something looking funny during the development process, we always refer back to our wireframes to see if it’s a markup / presentation problem. If it renders right in the browser statically, then we know to look for the problem in the JavaScript or server side programming. http://tc.eserver.org/27682.html http://tc.eserver.org/27682.html The most monotonous entities in the known universe, forms, are a staple of every web programmer's balanced diet. Whether we like them or not, forms are the gatekeepers to our site’s goodies and often their design alone determines whether a user will try what you’re selling or simply walk away. Without pomp or circumstance, here are ten tips to transform your plain vanilla into double chocolate chunk with marshmallows.