- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Fresh paint or new drywall? The cost of changing IA or design mid-project
We software engineers - and our clients - tend to think of visual design as a coat of paint. The arrangement of elements on a screen seems like a purely decorative concern, something that can be applied to the bare walls of an otherwise functional application at the very end of the development process. Anybody who's ever spent much time coding at the view layer knows differently. If effective visual design planning doesn't occur early in a project, there's often a hidden cost. Reskinning an application is more like installing new drywall than applying fresh paint.
The PR wizards who launched the web standards movement have propagated the idea that if you just mark up your content and code semantically, then it's a trivial concern to alter its appearance. This is true up to a point, but most sites have a large number of person-hours invested in their stylesheets, images and other purely "decorative" assets. Because browser vendors haven't consistently implemented existing web standards, even the most well-meaning programmers must litter their code with hacks, filters and nested containers to achieve visual fidelity. The hooks for achieving a given look-and-feel often penetrate deep into the view-layer code. Altering that look-and-feel often requires changes to those hooks, which adds risk to a project and almost always breaks lots of tests.
Use a Task Flow to Show “How do I ___?”
Although task flow diagrams (sometimes referred to as interaction flows, process flows or work flows) are a standard in most IA’s toolkits, it can be confusing for those unfamiliar with this particular tool to know when to start diagramming. When in the process is it started? How much information is needed before diagramming? How much detail should be added? When is it considered complete?
The short answer is to start diagramming once the task is identified because it’ll help in flushing out the requirements. The diagram starts to identify what the user and the system need to do. It delineates a repeatable pattern of activity. It answers the question: “How do I _____________”.
After you have an identified task (I like to use Use Case Diagrams to call out the high-level tasks), the start point and end point need to be established. For example, let’s say your business requirements state that the web application is only accessible by authenticated users; therefore, a user needs to successfully login in order to see the home page. The initial diagram has the user starting on the login page, submitting their information and viewing the home page after the system logs them in.
But wait … I did say *successfully* login, didn’t I. O.k., so we add a decision point to the diagram to show that only successful logins allow a user to access the web application. Don’t worry just yet what the details are for the system to successfully authenticate a user. The purpose of the diagram is to identify the process, not to define it. For now, all that's needed is to show that the login information must be vetted before the system allows access.
Granted, the previous examples are simplistic, but simple is where task flow diagrams start. This basic statement “How do I ____________” turns into an initial task flow, delineating the steps needed to complete the task from start to finish based on the information known at that time. The first iteration is generally the ‘happy path’ and identifies the main flow of a task. As more steps are uncovered through requirements, the flow is updated and modified to accommodate the new information and show the various decision points and/or alternative paths as they become known. The end result is a flow diagram that conveys both the overall structure of the main user tasks and the sequencing of activities to be programmed into a repeatable activity.
Topics: Best Practices, Information Architecture, Task Flows
Site Maps — Still Needed for Web Apps?
In a previous post, I talked about creating a Use Case Diagram as a means to moving the 60,000’ concept to a level of detail that’ll allow us to begin development. Since that diagram identifies the overall functionality, the team can use that to start designing the data model, writing user stories and generally working towards a more detail view of what we’ll eventually need to develop.
The site map is another diagram I’ve found helpful to bring further definition to the concept.
On some projects, usually those that were understaffed, the site map was typically drawn up after the project was in the end stages of development and only because someone in marketing asked for it. Oh, everyone on the team knew what was being built and the relationship between the areas, but it was all verbal -- no one had taken the time to set it down on paper.
At Pathfinder, we sketch out a site map early in the process to give a physical representation to the verbal concepts floating around the team. The ‘we should separate this’, and ‘let the user skip from here to there’ and ‘oh yeah, both these areas relate to each other’ kind of ideas that float around before requirements are actually written.
The very act of documenting work to further define the concepts and gives the team a visual artifact for future decisions. The site map, no matter how rudimentary, begins to identify and categorize the user activities into a relational hierarchy and provide a framework for the application. It helps in project scoping and planning because it begins to further identify the details of a project, which can then open a conversation as to what is needed now and what can be postponed to later. It is a concrete drawing that you can show the client and ask, do you agree? Is this what you want?
As with Use Case Diagrams, a Site Map gives you an overall view of a project -- not necessarily all the details but a high level view of the end goal. Both documents are relevant because both give you a checkpoint to refer back to once you’re in the details of a project to make sure that you’re still on track to meet the project objectives.
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
It Starts with the User Story
Having recently been asked about the difference between a use case and a user story, I came up with this explanation:
Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.
A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.
For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:
As a [role]
I want [feature]
so that [benefit]
From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.
Design Pattern 1 - faded breadcrumbs
Preface: in my travels around the interwebs I often encounter a neat interaction design that I use my handy Skitch tool to capture. As of now, they sit there until I encounter a project to use them in. To make them more accessible I'm going to post them here, please add comments, since many times I'm not sure how to actually implement these!
Apple's faded breadcrumbs
In (Leopard OS?) search windows, when a list is presented and an item is selected, the path to that item is shown as breadcrumbs in the footer. Because these items can be anywhere, the structure can be very deep, when horizontal room is at a premium, and folder names are long the display truncates the display to a fixed width and fades out the name to white. On mouseover, the title stretches open to show the entire label.
What can it be used for?>
Windows offers the ability to "ellipses" a label that gets too big for it's container. On mouseover, a 'tooltip" window pops up showing the entire label. The fade approach is more elegant, and the animation is actually useful since you don't obscure the other information like popup tooltips do. Websites hopefully have flatter navigation structures nowadays, but horizontal space is always an issue, as it is always finite. Techniques to maximize horizontal space are welcome.
How to do it?
Apple.com is showing this behavior on their footers, go to any page and look at the footer breadcrumbs, click on one and you get the animation effect. However, the fade is not possible in HTML. Also, apple seems to use some 'safari' behavior in their page I don't see in IE 6. Any ideas or libraries? Post below.
IA and agility
A friend of mine recently left a position at a supposedly Agile shop where developers wrote code based on raw requirements rather than formal IA. When he described their process to me, I really felt his pain. I can't imagine trying to capture the complex requirements of Ajax applications without the tools of modern IA.
Good information architecture provides not only detailed blueprints for developers, but also the raw material for test cases. If your only documentation of a component is just a high-level business document or a working example of that component, then it's difficult to identify deviations from the spec or prove that an unexpected behavior is a bug. Sure, on Agile projects the first-round IA sometimes gets reverse-engineered from working demo code. But IA and UxD should be a central component of Agile development.
Technorati Tags
IA in the age of Ajax
On Monday, Richard F. Cecil of UX Matters published an interesting piece titled Documenting the Design of Rich Internet Applications: A Visual Language for State. In it, he discusses the challenges facing information architects in the Ajax era. Full of practical, how-to advice for IAs and developers, it's already prompted some interesting comments. I'd recommend it to anyone interested in the process of developing RIA specs.
A few months back, some former colleagues of mine - both of them top-notch IAs - approached me about putting together a panel discussion about just this topic. The panel never happened, but our initial discussions got me thinking about the role of IA in RIAs. As web-based user interfaces grow more complex and modular, many of the traditional approaches to IA fall by the wayside. Steve Hansen, a commentator on Cecil's piece, nails the problem:
As someone who designs and builds complex RIAs, with complex non-linear work flows, I have been struggling to find the ideal modeling vocabulary. Things get even more interesting when you have complex server back-end functions. I currently use a hodge podge (technical term) of wireframes, UML activity, sequence, and communication diagrams and whatever else seems to fit the bill. This is surely an area ripe for discussion and exploration.
It's clear to anyone who's ever worked on even a moderately complex Ajax application that screen-based specs don't cut it. Unless documentation breaks things down into individual components, controls and user actions, it will fail to capture all of the possible conditions. Even a component as commonplace as an image carousel or a rich-text editor includes more discrete points of user interaction than an entire webapp did five years ago. Throw in something like keyboard commands - a topic Cecil's piece doesn't broach - and the complexity multiplies. And let's not even talk about the need to document accessibility modes.
I'd be interested to hear from people with more of a desktop software background - the same folks who are flocking to GWT - about their approach. I don't know much about IA in the desktop world, but I imagine that webapp IAs will be looking there for inspiration. Desktop GUI frameworks don't offer the free-for-all that HTML, CSS and JavaScript do. There's less freedom, but there's less of a burden to reinvent the world over and over.
That's why the GWT or Ext model offers productivity gains not just for developers, but also for IAs and designers. If your interface is built out of standardized widgets rather than build-your-own components, much of the documentation can live at the widget level. Application IA then benefits from a shared vocabulary in which common interactions have already been described and it's only corner cases and the interplay between components that need individual documentation. Users win, too, because they don't have to figure out how, for example, your date-picker works; it's just an instance of the same date-picker widget they've used in other applications on the same platform.
As Ajax UI toolkits mature, it will be interesting to see how their authors balance the desire for completely customizable interface components with the productivity and usability gains of componentization. At what point do bells and whistles cost more in complexity than they deliver in novelty?
Technorati Tags
Topics: Ajax Development, GWT, Information Architecture
On the Benefits and Pitfalls of Competitive Research
Competitive research is part of the design process at Pathfinder. By competitive research, I mean spending time getting to know how others have solved the problems you are confronted with. We do this type of research separately to start both the Information Architecture and the Visual Design phases of our process.
Recently, though, I’ve been thinking about the net effect of the importance that it plays in the Visual Design process. Specifically, to what extent does it help, and when does it hinder.
One the one hand, it can be really dumb to start designing something without knowing what has already been done in that space. Starting from scratch can be a real time waster. It pays to take advantage of other’s successful design thinking as it relates to the problems you have to solve, because they might have been solved already.
However the more immersed one becomes in a particular domain--the more exposure one has to the state of the art--the more boxed in one can get. You become accustomed to seeing problems not as challenges in need of creative thinking, but as patterns that conform to some already defined problem/solution set. Then all you have to do as a designer is simply find that matching set. It may sometimes be easy, even more often than not, and there may be projects when doing this is the best you can hope for under the current constraints, but eventually it’ll hurt you as a designer, because you can get to used to searching for patterns. Cliché as it may be, your creativity is like a muscle. You have to exercise it daily for it to grow. And not all problems have a matching solution yet. There will always be unique problems that will require you to solve them on your own, and you’ll be caught off guard if you haven’t practiced using your own design skills.
I would say that for competitive research to be an effective, and positive experience in the long run, it has to be balanced with a healthy dose of skepticism. As a designer you should open yourself up to what others have done, and in fact realize that it’s very important not to design in a vacuum. But as you explore those designs that came before you, keep in mind that it’s up to you to use your creative skills to come up with a solution. You can’t let your skills sit in the dark, while you let others do the hard work. Eventually it’ll come back to bit you. Take what works. There’s no reason not to. But even then, don’t just consume it, deconstruct it. Take a designers critical eye to it, so you can learn from it and grow as a designer.
Powered by ScribeFire.
Topics: Information Architecture, User Experience
Waiting for 5.0
I want to thank my colleague Brian for posting in our sister blog (or the main blog, whichever way you look at it) about HTML 5.0 article in a list apart. I have been working on an entry about some persona work we did at World Usabilty Day a few weeks back and have been stuck coming up with something profound, so stay tuned. As it so happened a part of that article also caught my eye and caused me to flare up a bit in disbelief, and it was a different part, so thus my impetus to get this out, since rash reactions make for the best blog posts anyway. Here is the offending statement:
<header> <h1>A Preview of HTML 5</h1> <p class="byline">By Lachlan Hunt</p> </header>
<header> <h1>Example Blog</h1> <h2>Insert tag line here.</h2> </header>
When I first read the article that IBM put out on HTML 5, I was smiling for the semantic goodness of all these new elements. Somehow, I imagined this was a way to clear up one of the biggest problems in semantic design, naming conventions and inheritance. In one swoop you could get rid of the scourge of 'classitis, and add a whole level of drop and drag functionality without the baggage of a proprietary solution ala scriptaculous (class='draggable'). I was hoping that you could just create rulesets like;
header {
the box looks like this
}
header h1 {
the logo/branding looks like
}
header ul li {
the 'utility' navigation looks like
}
menu {
the box is like
}
menu ul li {
main navigation looks like
}
Semantically I would then have places on an interface that revolve around specific purposes, and have the alphabet soup of tags (h1, p, ul) which when put in those buckets pick up a purpose and display. Then we need no classes, since you should be able to stick to just the tags that brung you. The descriptive simplicity of not having to worry about #nav p and .nav li but you have menu container, fully ready to accept things that make menuing possible. Anyway, this was the illusion, after reading the example passage in the article I thought:
What? There are two headers? Now how do you manage a header (display:none) situation for a print style? Would it be header class=realheader and header class='subheader? Doesn't that defeat the purpose?
Then of course the p class=byline bit - can't any p within the header be considered a paragraph, why call a byline a paragraph? Why invent a subsidary element, could it be made into a <span> just to keep it clear?
So, I somehow thought that HTML 5 would eliminate the need for custom naming conventions, and perhaps classes and ID's were a thing of the past. Then, the article this made me realize that the tags are not necessarily unique in a page, and therefore the 'hook' quality of: getelementbyID finding a single instance is out the window. Then I wept, as this trashes some of my imagined utility of this addition to the language.
I wanted this because my experience is that XHTML and CSS are not well and truly separated. CSS makes little sense on it's own, and reading someone else's CSS while not impossible, is not ideal. You have to find instances of each element in the production code and piece together the puzzle of how things are used and why. Some programs like CSSedit make it a bit simpler, but since XHTML doesn't enforce good practices, and with little effort, you can 'break' the stylesheet by adding elements without definition, or that inherit unwanted or unintended styles. In your own work, this makes things confusing, in trying to understand others work, it becomes a real pain.
<div id="header"> <ul class="nav"> <li><a href="here.html">Go here</a></li> <li><a href="there.html">Go there</a></li> </ul> </div> <div id="content"> <div id="nav"> <ul class="sidenav"> <li><a href="here.html">Go here</a></li> <li><a href="there.html">Go there</a></li> </ul> <div class="content"> <p>stuff is here</p> </div> </div> </pre>
an example of a screwy, yet valid page markup
So HTML 5 gives the addition of a few new tags, and the appearance of some semantic 'hooks' that could lead to a better standard (video is welcome), not to mention search engines can spider and parse our sites more effectively. I think Google is already hip to the id='nav' convention - see an earlier post on my site for this. I am confused and somewhat disappointed by the lack of uniqueness to these elements. While I don't understand the DOM hook thing completely, this seems to make things tougher by having to deal with arrays, but perhaps Brian can explain it to me (or us) if it is a good thing after all.
I started this blog with a long history of HTML and the 22 original elements and their morphing into the however many there are in use today. I dumped that part since explaining the history of why text markup and navigational markup are two different beasts so why expect Berners-Lee or any standards body to tackle all the desires we have for the language. My own goal is to have some level of semantic abstraction so I can classify the user experience in words and elements that everyone can agree upon so we can focus on our unique or non standard elements, for the maximum value add. Messing with navigation techniques for the past 10 years seems a bit of a futile endeavor (could they have come up with a <tabs> tag?), and I'm certain not to have contributed as much as some to new ways to interact with a set of information. I suppose along with classes, ID's and the tags we have we are doing pretty well, and my paradise may be your nightmare, so best leave it up to the browser makers. But thats another post.
Topics: Information Architecture
Writemaps: A web based site map generating tool
Came across an interesting web tool today...Writemaps: A site map generating tool that allows you to build, edit and share site maps.
It's got limited features, but it has two big things going for it:
1 - It's web based, and you can share your files via url. So anyone with a web connection can view and edit what you've created.
2 - It creates presentable sitemaps. The page representations (nodes in the site map tree) have subtle gradients and drop shadows, and the tree diagram contains only right angles, giving your sitemap a polished professional touch.
A few other notes about this tool:
Can't print or save as image, but you can save as XML.
It's got an undo button! (how many web apps do that?)
You can zoom in/out on your map views.
It's dead easy to get started.
In summary, there's a lot of potential here, and I think I might give it a try on my next project.
Powered by ScribeFire.
Topics: Information Architecture, Task Flows, Web 2.0
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
Get in the Flow (Task Flow that is)
Call them what you like (task flows, work flows, process flows), flow diagrams are an important part of any software project. As a developer, you may be more familiar with sequence diagrams, a nifty way to visualize an exchange of messages between different processes and the order in which they occur.
Well another useful diagram is the end-to-end task flow. This handy dandy diagram shows all the steps necessary for a user to accomplish a task. Buy a pair of shoes? Select shoes, select size, add to cart, go through checkout process. Simple and easy.
And yet, what is it really telling you? Well, a flow diagram gives you an overview of the end-to-end process, the start to finish if you will. It lets you know what the user needs to do in order to start a task (select those really cool shoes) and what defines that the task is completed (display order confirmation). In between those two points are all the necessary steps to go from start to finish.
Initially, the in betweens are very high level (as evidenced by the above diagram). As more information becomes available, the flow is modified, added to, subtracted from and generally redrawn to show not only the user tasks, but also the system tasks (return error message, validate and continue), alternative routes (continue shopping, display upsell message) and decision points.
I've found flow diagrams to be very helpful because they let team members know how their stuff fits into the big picture. Let’s face it, on most projects the end-to-end flow is never developed lineally by one developer. Instead, it’s broken down into pieces and parts and assigned to various people. Seeing the end-to-end diagram up front gives you the overall picture of how an entire feature will play out and, more importantly, shows you how and where your piece fits into the whole. It'll get you thinking about potential points where code can be reused (sweet!) or better ways the data can be used at the presentation layer.
End-to-end diagrams let you see that what you're working on is no longer a lonely story in isolation, but rather something that’s part of a defined sequence that contains a beginning and middle and end. It ties what you're doing into the whole and brings a coherency to the process. This is especially valuable for large features that are spread out across teams and even iterations.
Technorati Tags: task flows, information architecture, diagrams
What is UxD?
A couple of weeks ago a sales presentation was being prepared in our New York office; it was primarily focussed on the problem at hand, but the presenter wanted to include a single slide as a cue to talk about User Experience Design [UxD]. He emailed me and a couple of the principles asking for a description in a single frame.
I wrote something, designed two slides because I could not shoehorn it into one, various documents were thrown into the air, then we were all consumed by other work as the train moved on.
Now I am rethinking it. UxD is a fairly complex set of activities to describe, and there is no shortage of areas claimed by related disciplines. All of them are occurring in an area of rapid market development that happens to be highly valued by the societies we are in. Which is a recipe to attract passionate debate driven by financial rewards.
So is there a good way to describe it, or state it's value to a potential client in a single powerpoint slide? Assuming that no fly-ins, starbursts or windowshade rolls may be used in place of meaning, we will start with those old standbys - words:
________________________________________
Concise version:
User Experience Designers create structures for understanding and manipulating information, designing consistent contexts which encourage cumulative learning. In doing so they raise the bar from "being able to do something" to "being able to do something easily".
Their solutions go beyond code to model the most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________
Verbose version:
User Experience Designers are typically employed on applications or sites with large amounts of features, complexity or information.
They create structures for understanding and manipulating information or parameters, designing consistent contexts which encourage cumulative learning.
They raise the bar from "being able to do something" to "being able to do something easily". As a starting point they conduct research to find:
_Who are the users?
_What are their goals?
_In what context will they use the product?
Then they use any modeling technique available to propose solutions that go beyond code to model the most most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________
And this is just a starting point for discussion, and the slide itself is TBD. The concise version is hardly meant to be all encompassing, but it focuses on Pathfinders particular business goals. These are concentrated in application work, either in or out of a browser, and our communications tend to be directed toward fairly tech savvy folks. Interested in your comments.
Charles
About Pathfinder
Recent
- Dealing With A Legacy
- Big Changes Underway at LinkedIn for Groups
- Four blatant iPhone usability blunders (and one constant annoyance)
- Flash/Flex physics engines and examples
- A Rails Story, Or An Engine That Really Could
- Data visualization and the art of conveying information
- What’s In Your Junk Drawer?
- Selling Git on the Business End
- IE8 Beta 2 Released
- Faster JavaScript for Firefox 3.1 Thru JIT
Archives
- 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
Accessibility
actionscript
activerecord
Add new tag
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Frameworks
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
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 Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
Chicago
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
Echo2
Echo3
Editorial
ERP
Ethnographic Research
Ext JS
Facebook
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player 10
Flex
flexunit
Flow
Frameworks
front end
front end development
Games
Gauge Component
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
Gwittir
GWT
Healthcare
Hibernate
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
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
Mozilla
Music
MVC
MySql
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
ORM
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
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
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
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
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
Video
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
XML
XML Metadata
XUL
Yahoo Map AS3 API
Zeigarnik
Zeigarnik Effect
ZK