- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Upcoming Conference: FITC Chicago 2008, June 22-23
Another Chicago area conference coming up: FITC Chicago 2008, from June 22-23 at the Chicago City Centre Hotel & Sports Club, 300 E. Ohio. We're even supporters. 
So what is it beyond the platitudinous "design and technology" event?
Obviously there's going to be lots of talk about how to develop Flex and Flash applications. Also how to develop online/offline apps with Adobe Air. Heck you'd think Adobe was a sponsor. 
If designing RIA's with Flash/Flex/Air is your thing, you want to be here. It's not free, but based on last year's event, well worth the $125-$250 (depending on which sessions you go to).
Update: If you sign up here with our special ninja supporter code of PATH15, you get 15% off.
Topics: Adobe, Adobe AIR, Announcement, Conference, Design, Flash, Flex, Web/Tech
Pixel by Pixel…Or how I spent my last 2 weeks designing a few icons
"Our product is shipping globally, and we're not going to customize each device to the language of it's destination country. So we need you to design a set of icons that will be used in place of textual messages."
Challenging, but simple enough, right? Immerse yourself in the product, do some user research, brainstorm designs that are meaningful, descriptive and culture neutral, and there you go. Oh, and one more thing...the device's display is 128 x 64 pixels with 1 bit color depth.
Such was the nature of the project I recently worked on, and it was a challenge of a very different kind then I had faced in a while. With either greater resolution or more color depth, It's relatively easy to depict pretty much anything with a high degree of recognizability. Shading, perspective, non-linear surfaces are all time consuming but doable with one or the other. Yet with only 2 colors and not many more pixels at your disposal, your so much more limited in what you can do. Take a look at some early GUI icons to see what I mean...
Since I couldn't use more than 2 colors, I couldn't anti-alias, so I was basically confined to horizontal, vertical and 45 degree diagonal lines. Forget about perspective. Since true perspective doesn't involve straight lines, depicting a product from an angle on such a small scale is out of the question. And shading--which is essential in illustrating that a surface displayed head on is curved--is just a matter of starting on the darker side with a high frequency of black, and then lessening the frequency as you move to the 'lit' side of the surface (Take a magnifying glass to a newspaper add to see what I mean). Again, not an option here due to the small screen size, there just want enough room to do that. I felt a lot like a writer being asked to weigh in on a complicated subject using 50 words or less. They say brevity is the soul of wit. I had to be clear and concise if I had any chance of success.
At 128 x 64, every pixel matters. And at 1 bit color depth, rotating, scaling or otherwise transforming anything in Photoshop is useless because the software automatically anti-aliases, creating shades of grey that were forbidden. So I had to design pixel by pixel--make a 1 x 1 selection, put my hands on the keyboard cursors and get to work. See Wikipedia's entry on Pixel Art for a good reference.
As it turns out, I was more at home on this project than i though I would be when found out the requirements. You see back when I was a kid, the first computer graphics program I ever used was on my father's DOS machine. The program itself wouldn't fit on the computer's hard drive, so it had to be loaded via floppy disk--the old 5 1/4" ones. The computer didn't have a mouse, so almost everything I created had to be tediously drawn pixel by pixel using the cursor keys. It took me months working 2-3 hours a night, but I created some pretty good stuff. In particular, I remember drawing a hockey rink, with players, stands and all, which I'm pretty proud of. Using Photoshop/Illustrator now, with the capabilities so far advanced over what I had to work with at that time, It's hard to see how I did what I did, or for that matter why I spent months doing it. But there's something about taking time to do something right, struggling through the frustration that comes with the absence of 'Undo', picking yourself back up after making a mistake that renders 10 hours of work useless. Creating art is a sprint. Back then it was a marathon.
So I forgot about my mouse, left the color picker behind, and zoomed in at 1600%. I soon found the hang of it again, and I got in the groove I remembered from way back. After a lot more time than I though it would take, I had a set of icons that worked...and that's the key. And in the end, I feel a little more satisfaction than I would have if I was allowed to let Photoshop do it's magic.
Topics: Design
Use Case Diagrams
Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.
For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.
The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.
Topics: Best Practices, Design, Information Architecture
The Curse of Knowledge
You can never know too much about something, right? Wrong, at least according to a December 30th article in the New York Times. As we become experts in a particular domain, our ability to innovate diminishes.
"Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself."
Reading the article, I couldn't help but think back to my own experiences with this same sort of issue. I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers--when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.
Now I see that it's part of a larger problem of expertise and creativity. The more expertise one exhibits in a particular field, the harder it is to think creatively--to so called think 'outside the box', and the harder it is to imagine not knowing what you do. The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape. The article cites the example of Eveready, the flashlight maker, who's powers-that-be couldn't imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.
According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking. Bringing the so called novices--the non expert users--into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.
Powered by ScribeFire.
Topics: Best Practices, Design, Design Patterns, Domain Knowledge, Ideation, Story Telling
Design can be Used for Good and Bad
Every so often I'm rudely reminded that much of the information I get comes from a source who's goal is to sell rather than inform. It is those times that I'm also reminded of the critical role that design plays in supporting the goals of the organization (wether they be to inform or to sell) by shaping user behavior.
Case in point. I use Yahoo Finance to track my stock portfolio and stay financially abreast of the day. I choose Yahoo over the many others out there because I'm used to it. It has a simple interface and I know where everything is located. It also has great tools, and it aggregates information from many many other sources in one place, which I find invaluable. However I just recently noticed that Yahoo Finance is serving some text ads on the site now. I wouldn't otherwise be too bothered by them, but they've been designed for the express purpose of looking like real (un-sponsored) content. They're right up there on the right hand side of the page, occupying the top of one column in a three column layout. The ad titles are just about the same color as the headlines and links on the rest of the site. And while the other section titles are all orange and bold--designed to give structure to the page and let you know what section your in-- the only way you can tell that your reading ads is from the truly inconspicuous (light-grey on light blue, thin, all caps) 'Advertisement' header.
This really infuriates me, especially because it's a finance site, and I can't help but notice the content of the ads. For instance, right now I'm looking at the front page, from left to right I see a snapshot of the Dow's performance today, a headline saying 'Stocks mixed ahead of jobs report' and a couple of blurbs on 'Hottest China Stock' and '16 Hot Dividend Stocks'. Now I'm sure you can guess which ones are ads. And yet I can't help but see the ads and incorporate them into my understanding of the days financial news. They were designed to be scanned, and that's exactly the kind of information I need to be able to filter out when I'm scanning a page like this.
The fact that these ads persist is a clear indication that Yahoo is concerned less about an informed public and more about using its real estate to extract as much equity as possible.
Powered by ScribeFire.
Dasher - A new way to write
I simply love finding these little gems on my weekly web excursions. This time it's a fascinating new piece of software out there called Dasher, and it allows you to write without typing or scripting. What's that you say? How else can you write? Well...The basic idea is that current methods of typing are inefficient, because they don't learn. Let me explain. Although there are x number of letters in the alphabet, every pressed key reduces the number of available choices for the next key press, and increases the odds that other specific keys are pressed next. For instance, 'E' is much more likely to be pressed after 'H' than 'B' is, and 'O' more likely after 'G' than 'C'. On current writing technologies it's up to the user to learn to be more efficient at writing He than Hb or Go than Gc. But that doesn't need to be the case. By taking advantage of the learning and memorization power of the computer, it's possible to create writing interfaces that guide you through the process rather than just recording what you type. If you'll indulge me in some metaphor, imagine rowing down a river. Dasher is the river with a strong current to wherever your going, and existing typewriting technology is the river with no current whatsoever.
What Dasher does is use language patterns to present likely letters and words to the user based on the letters or words they have already written. The goal is to make writing more efficient by reducing work. There are no keys to press using dasher. In fact the mouse is never clicked. The interface allows one to write by simply navigating the mouse down a path--or tree--through the alphabet. The start screen displays all 26 letters of the English alphabet. You select a letter by moving your mouse next to it. As letters are selected, Dasher displays all available letters again, but this time those more likely to be chosen are larger and therefore easier to select. As you write, you move forward through the tree, and entire words and phrases are displayed in order of likeliness.
Dasher needs some work before I start using it instead of my keypad, but the idea has real merit, and it deserves to be explored more. As an interface designer I see at this tool as a great example of how simple interactions, when thought about creatively, with nothing held sacred, can have potentially revolutionary effects on the way we interact with technology.
Powered by ScribeFire.
Topics: Design, Flow, Interaction Design, Rich Interactions, User Experience
DUX2007 - Ubiquitous Computing
Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.
Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service
Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.
As designers, then, our challenge is to design for these product/service ecologies.
Back to the Nike+: although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.
Some final thoughts from Greenfield:
- As designers, we can no longer assume that the product we design will be a standalone product.
- Everything that can be networked, will be.
A final thought from me: it's an exciting time to be designing.
Technorati Tags: Design, User Experience, Usability, DUX07
Topics: Best Practices, Design, Ideation, User Experience
DUX2007 - Data Visualization
Data visualization was touched upon a number of times throughout the DUX07 conference.
In David Pescovitz’ keynote address on Monday, he mentioned that since the 1980s we’ve seen three waves of technology: PC Computing, communicating, and sensing. We’re now in the fourth wave which is sense making -- how do we make sense of all the data that’s out there. How do we deal with search queries that return hundreds of thousand of lines of results. How do we start to make connections between the data.
One way we deal with sense making is through data visualization -- a concept which is starting to filter out beyond the research labs into the commercial space. Through data visualization, we can take huge sets of information and present them in such a way that it:
- allows us to immediately see how items are related to one another;
- gives us a more immediate way to see patterns;
- becomes a default to try and understand huge amounts of information.
In addition to visualization, Pescovitz touched a bit on how we're using collective filtering to try and make sense of all this data. We turn to social networks we may trust, such as Digg, to take advantage of the filtering layer created by that network’s society. Anything to help us get a head start on parsing the data.
Later on in the conference, Nick Cawthon talked about aesthetics and efficiency in visualization of data. His talk referenced research he had done using different types of data visualization in order to determine what participants thought of the graphic (pretty or ugly) and whether or not it worked (they could complete a task such as finding a file). An interesting outcome was that the higher the user-rated aesthetic, the more reluctant the user was to abandon that particular data visualization. At a basic level, if the interactive graphic was perceived as “pretty”, the user was willing to spend a bit more time trying to learn how to use it.
Fascinating ideas and I know we're just scratching the surface of its potential.
Technorati Tags: Design, Information Architecture, Usability, DUX07
Topics: Design, Design Patterns, Information Architecture
DUX2007 - Simplicity
Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.
At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?
To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:
- time - can I spend the time learning to use a new product? no? then it's not simple
- money - can I spend money on a new product?
- physical effort - does it require exertion beyond my usual effort?
- brain cycles - do I have to think for a long time?
- social deviance - does it go against the social norm?
- non-routine - does it break my routine?
These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.
Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.
Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.
Technorati Tags: Design, Information Architecture, Usability
Personas and Football
This year I’m once again in the Pick a Loser football pool*. Each week, I pick an NFL team that I believe will lose and if they don’t lose, I’m out of the pool. So, for example, the first week I selected my team, the Chicago Bears, to lose (so much for fan support). They complied so I'm still in play. I can only select a team once; therefore, da Bears are off limits for the rest of the season (even though I’m fairly confident they’ll lose another game or two).
My point here is not to kvetch about our quarterback (don’t get me started) or our running back (oy), but to mention that once you Pick a Loser, you start experiencing the NFL games a bit differently. It’s not that you’re actually outright rooting for them to lose (poor sportsmanship, old bean, not at all done), but you begin to look at which team excels in mishaps, penalties, and/or position weakness, or which team is thrown off stride by an unexpected change in personnel, and how you can exploit that to ‘win’ that week.
In other words, when picking a loser I am adopting a different persona than when I pick a team to win. I have different goals and objectives, looking at the stats (data) differently and end up going down a different path (workflow) to make my selection.
This, my friend, is the point of having personas on a project. You use them to identify the different ways a user needs to interact with your product -- their point of view determines the different paths and interactions they need to take in order to achieve their goals and objectives. Once you know the different points of view, it’s a lot easier to design a flexible workflow that accommodates your users. A win-win for all.
As for me, I survived week 2 (the Chiefs in case you're interested) and now need to figure out my week 3 loser.
*disclaimer: naturally for all the kiddies out there, you should never try this at home because gambling causes your hair to fall out
Technorati Tags: personas, user experience, design
Powered by ScribeFire.
Chaos and Order
The process of designing (guis/websites/apps what have you) can be very exciting, and ultimately, when a design goes well and achieves its purpose, it can be highly rewarding. But it's also a challenge. Every designer has their own set of struggles that they go through during the design process.
One of the things I struggle with most as a designer is the urge I have to make things consistent, or symmetrical. I prefer order over chaos, I'll admit. I constantly have to catch myself from spending too much physical and mental energy on removing what I see as chaos, and replacing it with structure, consistency, balance and symmetry. It's not that these aren't worthy goals, but my experience is that sometimes those characteristics aren't the key, or even an important element on a particular interface screen or widget. In fact, in many instances I have found that what I consider order is quite an undesirable solution, or at least, not what the doctor ordered.
By instinct I look at my work through a designer’s lens. It is a macro view. I see the overall structure of the interface. I slave over task flows and wireframes, structuring them and fine tuning them so they please my aesthetic and philosophical sensibilities. I judge them by their adherence to my design rules-symmetry, balance, structure, consistency.
But for the judges that matter, the users, the interface is simply a tool that they will use to accomplish a task (or set of tasks). They will judge its success not by any theoretical characteristics, but by how well it allows them to accomplish those tasks. They won’t look at the blue prints. They’ll never get a look at the task flows generated in the design process, nor would they have any desire to.
Internalizing this distinction--the difference between my view, and the user’s view--and embedding it into my design process is one of the challenges I face, and one of the determinants of a successful design.
Powered by ScribeFire.
Topics: Design, Design Patterns, User Research
Design Doesn’t Just Mean Color
In discussing our SDLC process with some colleagues, I pushed for having a separate phase between Discovery and Development; a phase where we can take the knowledge gained from Discovery and begin sketching out high-level solutions in order to get a handle on the scope before going into iteration planning. In other words, a Design Phase.
I quickly discovered that some people hear the word ‘design’ and automatically associate it with the look and feel of the GUI, regardless of what else is being said. Until I understood that, their argument that there was no need to call out an entire phase for design made absolutely no sense. To me, using design in this context means to figure out how to do something at all levels, i.e., taking the requirements (Discovery Phase) into high-level schematics (Design Phase) to better understand their relationships, dependencies and impact in the end-to-end process. Obviously, I hadn’t explained that well.
Much conversation ensued, including the standard weeping and wailing and clutching of the pearls when passionate people get together. Amazing how we were all speaking English and yet totally missing what was being said. Until someone (the former English major, of course) effectively put us back on track by saying “Ok, but what do you mean by ....”
Ah-ha! Define the terms. With a BA, IA, and Tech Arch conversing, we found we were using the same terms to mean different things and different terms to mean the same thing. Well once we started speaking the same language, we agreed there is merit in having a separate phase specifically for design and revised the diagram accordingly. As a team, we were then able to define what that means to our process.
I could say that as a team we designed our SDLC process, but I’m not even going to go there.
Technorati Tags: SDLC, Application Design, Design Phase
Topics: Best Practices, Design, SDLC
Color for Developers, part 3
Through a glass badly
"This is not a pipe." R. Magritte
You are reading this on screen. It is not what I expected.
One of the biggest problems for any on-screen designer is the weird backlit medium we fish swim in. This is true if you are creating interfaces for browsers or desktop applications.
By now you are asking why, why does he continue to torture us with these vague allusions and puzzling suppositions. Well it is just my sick idea of fun, really, but here is a simple test. Make a pdf of your favorite picture of a human. Put it on a flash drive and walk around to a few of your colleagues computers and compare the different displays. Extra points can be scored in two ways:
1] try a PC and any other platform, Mac, SGI, Treo
2] try laptop, lcd and CRT screens. If you can still find a CRT screen, they are fading into the dust of time or the junkyards of third world countries as we speak.
Of course you will find that the image of Britney Spears moments after the haircut discloses an array of skull colors limited only by the number of screens it is displayed on.
Individual hairs may or may not resolve, and the level of contrast will have a happy variety as well. This is where you work. Every one of your users sees this differently.
So great, isn't that a big mess, can we please just ignore it? Well no, that isn't really playing well with others. What we need is a basic strategy for accommodating this tragic reality.
There are commercial solutions to calibration available, or most Adobe programs ship with basic calibration tools. These will help... but only you. There is no way of knowing if your users ever did this, and we know that asking is not a scalable strategy.
Unless you are in a highly controlled situation, in an industry where there is a financial benefit directly tied to color fidelity, you can bet that no one really cares.
So what is the solution?
1] Design it a bit crude. Don't expect someone's screen to display a reliable difference between zero, 10 and 20 percent black, that is too subtle. Try 0, 15 and 30
2] Test it. Test it some more. Don't beat it to death, but it can definitely be too subtle.
There we go. In a few short blogs the secrets of your universe revealed. You have grasped the remote from my hand, grasshopper, do not watch Jerry Springer with the powerful tools you have been given.
Color for Developers, part 2
Color in context
Many moons have swung by since our last talk, grasshopper, and by now you have had those tattoos revised and replaced more times than Angelina Jolie. I can only hope you have been as politically corrupt and personally shocking, really, she is a role model to so many.
Today we will talk about color and perception, then later we will do the sacrifice part... Right, let's start with Kasimir Malevich, who had strong opinions about color or the lack thereof and put his money, [or the people's money] where his brush was. Painted such fashion nuggets as "White on white" and "Black square". If you imagine what they look like in your mind, you will be darn close.
So what was on his mind? Why bother? There are a couple of reasons:
1] Cultural
He was a Supremacist in Russia in the early part of the last century and thought that painting couches and side-tables was hopelessly bourgeois.
2] Psychological
He wanted to defeat his own preconceptions and create something new; a kind of meta painting that was both free of objects and depicting pure emotion.
Well can color or it's absence do that? What strange and magical powers does it have? Vassily Kandinsky, one of Kasimirs drinking buddies, associated some very specific things with color - he claimed that certain colors elicited thoughts/memories/feelings of particular sounds and feelings and made them into a handy grid.
Most people make some basic and reliable associations with colors; black associates with night, death and designers clothing. Red means fire engines and radio flyer wagons. These are cultural associations, that effect how we perceive and interpret our world. A blue light on your dashboard is understood as a fairly passive status light. A yellow light, blinking rapidly, means the engine is probably about to seize.
When we use these colors in an interface, all of those associations are carried along with it. A complicating factor is the cultural context it is being read in. Many cultures have very different tolerances and preferences for color that western europeans; any short description of these differences will be reductive, but think of these references: Jamaican villages houses, Bollywood movies, Japanese packaging... Would those local tastes effect the design of an interface for those groups? I look forward to your comments. Leave a donation for the gods by the planter.
Design? Meet Research.
A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.
But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it? A valid point. She is accustomed to a landline -- you pick up the handset and there’s a dial tone (no, don’t even start -- she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call -- it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.
Topics: Accessibility, Design, Usability, User Research
About Pathfinder
Recent
- Roles Testing For Security
- Blackbird takes the pain out of JavaScript logging
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
Archives
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
AS3
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
chess
Chicago
Cloud Computing
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player
flash player 10
Flex
flexunit
Flock
Flow
Frameworks
front end
front end development
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
Healthcare
Hibernate
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
JsUnit
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
Restlet
RETE
Review
Rich Interactions
ruby
rubyamf
Ruby on Rails
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
The Ajax Experience
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Venture Capital
Video
Vision
Visualization
VLC
Volta
Web/Tech
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
work life balance
XML
XML Metadata
XUL
Yahoo Map AS3 API
YUI
Zeigarnik
Zeigarnik Effect
ZK