-
Get a monthly update on best practices for delivering successful software.
How Would Steve Jobs Pitch YOUR Product?
It's no accident that Steve Jobs is arguably the ultimate technology pitch-man. He's worked with some of the best designers, ad agencies and creative people on the planet even since the early days of Apple. But how would he pitch your idea? It's a fun question to ask and I found a book that just might have the answer. While browsing in a discount brick-and-mortar bookstore I came across "The Presentation Secrets of Steve Jobs" by Carmine Gallo of Businessweek.com. There was one copy on the shelf and it immediately caught my attention. As I flipped through the pages, I was impressed with the many "how-to" pieces of wisdom. For example, you'll see how answering four simple questions can yield a powerful elevator speech. You'll see how to use high impact words, tight headlines and key numbers to get your point across in a way that seems effortless. While I think the book is a "must have on your desk" for product managers and marketers, I also think it's a great reference for designers to think about what makes a design more marketable and enticing to the customer.
Topics: apple, keynote, marketing, presentation, product manager, Steve Jobs
User Driven Product Development
This morning I sat through two pitches by two startups looking for funding. I won't get into the details, but they both had clever ideas at their root. But while one company was attractive and poised for success, the other was mediocre and not getting much traction. Why was that? They both had clever ideas, no?
Over the years I've looked at a lot of business plans for Venture Funds. The first lesson that I learned was that cool ideas didn't equal successful companies. While I would get all hot and bothered by a particularly elegant software solution, the VC's I was consulting to preferred the plans that understood the market and the customers in it (and had a kick ass management team, natch).
Continue reading »
Topics: User Modeling, Venture Capital
Why would you use a tablet instead of a laptop? (In Pictures)
As an answer to those asking why we need a tablet anyway, there's a very funny set of pictures and comments at WTF Is Wrong with Laptop Users in the Media. The author went through the first 400 images (out of 28,886) he got on a search at Getty Images of "Using a laptop" and compiled the highlights. My favorites:
Now ask yourself, in which of those pictures would (a sealed, always on, always connected) tablet make more sense?
In all of them (although the beach one still seems like a bad idea.)
Topics: apple tablet, laptop, tablet
Trading Away Technical Complexities for Vastly Increased Simplicity and Ease of Use
... it's hard not to think about how much easier some people's lives would be (hi Mom and Dad) if they could trade technical complexities they don't care about for vastly increased simplicity and ease of use.
My parents were technically savvy enough (with a little help from their sons) to start using Skype video in their mid seventies, prompted by the arrival of grandkids halfway across the country. But for them, it was always a cumbersome affair:
1. Arrange a time to have the video call.
2. Move the laptop to the dining room.
3. Call on the telephone to tell me that they're using Skype on the computer.
4. Initiate the Skype phone call.
Needless to say, this did not happen all that often.
This past Christmas my brother got them a Skype Video Phone. They set it up with a little help from us, and when we told them to just treat it like the telephone, they got the idea. Now, they are making video calls much more frequently - not just to the grandkids, but to our cousins in Switzerland and South Africa.
They traded complexity for simplicity and ease of use, and though the skype video phone will not end up being a success on the level of the iPhone, it's already brought my parents a lot of joy, and is part of a trend towards more simplicity and ease of use. It's one major reason the iPhone is as successful as it is.
Now imagine that simplicity and ease of use in a multipurpose, always on device with a bigger screen. My parents wouldn't need the skype video phone, they'd just have that as an app on their tablet.
Prediction: The Teens will be the Decade of Mobile
I've made my fair share of predictions, and this may seem to be a layup, but I think it's a prediction worth making anyway: mobile devices and applications will transform business and every day life in the next decade.
Why does this seem like such a layup? Well, look at the iPhone and the ecosystem of applications and companies springing up around it. Android and Blackberry are trying to jump in on the business and everybody and their brother is cooking up a connected mobile device. And yes, that's obvious. Mobile devices are going to increase in importance in 2010 and if you don't already have an iPhone app cooking to complement your other online channels, you're behind the times.
But if you're just thinking that more iPhone applications are going to be the end of it, you're in for a rude awakening. Businesses have just started consolidating after the disruptive years of the 90's and aught's, with the transformative effects of the web largely digested by the marketplace (the newspaper industry is still thrashing but will soon succumb). A new disruptive decade is dawning that may see the passing or fundamental transformation of industries as varied as telecom, credit card and broadcast television/cable. Prepare to take your business through a roller coaster ride every bit as challenging as the web revolution. Continue reading »
Topics: iPhone, Mobile, Predictions
Your SDLC or Your Product – You Decide
…or the telephone game
Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.
The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:
A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.
In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.
Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”
Art vs. Design, the Art of Design, or the Design of Art
A couple of days ago I happened upon an interesting article about the difference between art and design. The author makes a lot of interesting points, and whether you agree or not with the statements he makes, the article does make for a great conversation starter.
Art and design are two different words, and some say two different worlds as well. The use of each often comes with a distinct connotation. I could go on about how design's goal is to solve a problem, whereas art doesn't necessarily always have a problem to solve. I could talk about how art doesn't necessarily require a common user experience, whereas design more often than not does. I could expand upon that by discussing how art doesn't require that a thing be usable, whereas design is often judged in part or whole by its level of usability. I could even discuss how art can be effective whether done collaboratively or not, and contrast that with numerous examples of how here in our agile software development environment at Pathfinder we find collaboration inseparable from our design process.
But I could also talk about how much art and design overlap and blend, so much so that it becomes difficult to make concrete distinctions. And how, sure, software design is about solving a problem, but it's also about solving a problem beautifully. Continue reading »
Software Development: Importance Doesn’t Always Equal Effort
I've worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That's where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance -- however that is defined -- is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.
To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990's money. The part of the system that resolved the transactions was really really "important," but the part of the system that allowed an application helpdesk to support users by seeing what their user's saw cost 60% more to develop. That's right, an "unimportant" helpdesk module was more expensive and took more effort and cost more than the "important" backend that handled billions of dollars a day.
User Centric Design – the Who, What, Why and How of a Feature
At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.
We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.
We move onto user stories, all of which are written from the point of view of the personas: Continue reading »
Topics: user centric design
Wireframing with incomplete requirements
The value of wireframing even with incomplete information
The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered. But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements? What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do? Is wireframing at this juncture useful? I say yes. With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.
The key to a wireframe's usefulness is that it is a visual document. Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment. Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications. A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation. "Where is the Cancel button? Oh...not in the requirements? Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."
In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation. Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).
Error Messages & Usability
I was starting up one of the Adobe apps the other day when this somewhat troublesome message was displayed:
Ack! On the one hand, good for them for alerting me that an error had occurred. On the other hand, what's up with that message? I had no idea what I could do beyond clicking ok (and after reading the message I wasn't sure all was ok). A bit unnerving, but it did get me thinking about how applications deal with error messages.
The idea that non-technical users will be viewing error messages is one of those things that tends to be overlooked. You’re so focused on getting all the features up and working that dealing with errors on the presentation layer are often left out of both design and implementation.
Even if time is crunched on a project, however, here are three scenarios you should always cover in a user-friendly fashion: Continue reading »
Bridging the Gap Between Rails Developers and HTML Designers
To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.
Designers and developers obviously have different goals for their HTML -- developers have issues of reducing duplication, organization, and performance that are largely not the designer's concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.
Topics: Ruby on Rails, uxd
Developing Good Wireframes Ahead of Visual Design
In the design process, the wireframes focus on the structure/layout of elements on the screen, and the interaction that the screens will provide. The visual design focuses on aspects of design such as colors, graphics, branding and mood.
Design encompasses both of these, and both are equally important. But by first addressing the software's information design & interaction needs, wireframes help you make sure the user experience makes sense, including that the workflows are natural and intuitive for users, and that the interactions are easy and clear. Without these, a site may not be very usable. Developing good skeletal wireframes before fleshing out the visual design is important for several reasons.
Focuses the Conversation
Visual designs tend to elicit more of an emotional response than wireframes. Hence, putting a fleshed out visual design in front of a client can divert attention from the structure and interaction of the page, and tilt the conversation more towards the color and graphic choices. Skeletal wireframes help you and your client focus the conversation on the business goals and the needs of the user. Continue reading »
Software Development and the Construction Analogy
Dan Vanderboom has a thoughtful post up about software development methods. I especially like his takedown of the building construction analogy that is overused and abused in the world of software development:
[...] this is completely at odds with how homes are normally built. People typically choose a previously-implemented design, and only customize superficial features like countertops, cabinets, floors, and railings. Houses from this plan have been built before, and the labor and materials cost are known from previous experience.
Building software is usually more like constructing something that’s never been built before: the first sky scraper, the Golden Gate Bridge, or the Hoover Dam. The requirements are unique, the pieces have never been assembled in such a way before, and there’s an inherent level of risk in creating something new. When this is the case, the Customer needs the services of an Architect, not just a Builder who stamps out deliverables in a cookie-cutter style.
I would add two points to his post:
- One additional reason that building construction is not a good metaphor for software construction is that it breaks down along scale. You can construct a scale model of a house to validate the concept, but a scale model of the software is the same as the software itself. An application's size is measured in features, not feet. That's why agile development seeks to deliver a minimal set of features as quickly as possible.
- We've folded User Experience Design (UXD) into our agile process as a way of getting to value more quickly. Feedback in agile is important, but if you can improve the quality of that feedback, you converge on good features more quickly.
Related Services: Custom Software Development, Agile Development
Exactly What are Wireframes?
Wireframes are the bare-bones schematic of the presentation layer for an application or web site. They are the visual interpretation of the user and business needs for any given feature. At a basic level, they show the page layout and placement of various elements on the page. At a more detailed level, they identify user interactions and the expected behavior.
Why use them?
Wireframes are a great communication tool for all members of a project team. Instead of an abstract list of requirements or a verbal description of a concept, the visual nature of a wireframe allows everyone to see exactly what it is they’re discussing. They are usually black and white (sometimes with shades of gray) schematics because we want to get feedback on the page structure and behavior, not the visual design. However, wireframes created for mature applications can readily incorporate existing visual design since that language is already defined and shouldn’t divert focus from the reason we’re looking at wireframes.
Annotated Wireframe
Although a picture is worth a thousand words, adding annotations to a wireframe lets the viewer immediately know the expected user behavior of various elements on the page. While a more detailed explanation of the behavior is generally contained in the design specs, adding a shorter version here is extremely helpful.
Here's an example of what an annotated wireframe can look like:
Who uses them?
All team members. Because they are a visual artifact of what is proposed to be built, they are an easy and cost-effective way to get the stakeholders to sign-off on how their business requirements will be translated to software, before any code is written. They also give development a heads up on what the page will look like and how it’s expected to behave; which means they also let QA know what to expect once the feature is ready for testing.
While I sometimes have to educate clients new to software development on the benefits of wireframes, once they see them within the context of a project, they're sold on the benefits and understand their usefulness.
Related Services: User Experience Design, Custom Software Development
Launch: Pathfinder Newsletter
Subscribe via RSS
Categories
Topics
.NET
.NET Browser Control
.Net Development
2d cad
2d physics
3d
3D GPS
3d mapping
3D physics
37signals
Acceptance Tests
Accessibility
ActionMailer
actionscript
activerecord
acts_as_ferret
Add new tag
Adium
ADO.NET Entity Framework
Adobe
adobe acrobat
Adobe AIR
adobe flex
Adobe Illustrator
Advertising
aggregation
agile
Agile Development
agile iteration
agile thinking
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
Ajax library
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax toolkit
Ajax Tools
Ajax Widgets
A list apart
Amazon
Amazon CDN
Amazon Web Services
amf
Analysis
Android
animation
annotation
Announcement
Announcements
antennae
Antipatterns
Apache
Apollo
App Engine SDK
apple
apple tablet
Application Architecture
Application Development
ap store
architecture
art
AS3
ask a UI guy
ASP.NET
ASP.NET
assembla
asterisk
Asynchronous Processing
authorization
awards
axiis
Azure
Back Button
backups
bandwidth
bandwidth profiling
Barnes & Noble
Barriers to Entry
Beans
beer
Benchmarking
Best Practices
BitmapData.draw
BJAX
blackberry
Blaze Advisor
blender
blog
blogging
blog widgets
book review
Books
Borders
braindump
browser
Browsers
Bugs
Business
Business Concepts
Business Reasons for Ajax
Business Rules Engines
C#
c# documentation ndoc sandcastle
caching
campfire
Canvas
capistrano
career
Case Studies
CFO
change management
Charles
charting
checklist
chess
Chesspresso
Chicago
chicagoruby
chirb windycityrails
Chrome
Chrome OS
CI
CIO
Closure Tools
Cloud Computing
CloudFront
CMS
COBOL
Cocoa
code
code art
Code Generation
code generator
Code Style
Color
COMET
Competitive Strategy
Compilers
Compressor
Computer Science
Conference
Confluence
Consistency
Content Management
continuous integration
converget appliances
core animation
CRM
cruise
CruiseControl
CSS
cucumber
Custom Application Development
Custom Flex Component
dashboard
Data Mapper
data services integration
data visualization
date
datetime
Davlik
Degrafa
deployment
deprec
Design
design documentation
Design Patterns
design thinking
Desktop
desktop application development
Desktop RIA
Desktop Software
developer
Developer's Notebook
development
DHTML
Diagnose
Divide and Conquer
documentation
Dojo
Domain Knowledge
don norman
Drawing
Drools
drupal
dynamic languages
ease of use
EC2
Echo2
Echo3
Editorial
elections
enterprise iphone development
Entrepreneur
erb
ERP
error handling
Estimating
estimation
Ethnographic Research
events
everyblock
Evolution
Excel
externalinterface
Ext JS
Extreme Programming
eye tracking
Facebook
factory
failure
Fake Agile
Feedback Loop
ferret
FileReference
Firebug
Firefox
Firefox Extensions
fixed bid
fixturereplacement
fixture replacement
fixtures
Flare
Flash
Flash and Air
flash awards
Flash Catalyst
flash player
flash player 10
Flash Player optimization
Flash Remoting
Flex
Flex, Flash and Air
flex 3
Flex3
flex code generator
flex css
flex development
flexmock
Flex optimization
flex skins
flexunit
flex widgets
Flickr
Flock
Flow
Fluent
forms
Frameworks
FriendFeed
front end
front end development
fulltext search
functional
functional specs
Games
Gang of Four
Gauge Component
GDI+
gem
getting things done
ghost
GigaOm
GIS applications
Git
github
gitignore
Golf
Google
Google Analytics
Google Analytics for Flash
Google Analytics for Flex
google android
Google App Engine
Google calendar
Google Closure Tools
google docs
Google Gadgets
Google Gears
google maps
Google Web Toolkit
Google X Prize
GORM
government
g phone
Grails
Graphics
graphing
Greasemonkey
Griffon
Griffon Plugin Development
Groovy
GStreamer
GTD
Gwittir
GWT
GWT 2.0
GWT Layouts
GWT Rich Internet Apps
h.264
haml
hardware
Healthcare
heuristic evaluation
Hibernate
high-performance teams
hosting
HTML
Hudson
Hype
IBM
IDE
Ideation
IE
IE6
IE7
IE8
IE detection
iGoogle
Illustrator
illustrator cs3
ILog
ILOG JRules
imacros
importing graphics to flex
Information Architecture
information visualization
infrastructure
Innovation
Instructional Design
Interaction Design
interaction patterns design
Internship
Interview
iPad
iPhone
iPhone Development
iPhone SDK
iPod
ipod touch
irb
iteration
IT M
IT Mill Toolkit
iTunes
jakob nielson
Java
javafx
Javascript
JavaScript frameworks
Javascript Libraries
Java Web Start
JBoss Rules
Jess
Jetty
JIT
jmeter
jnlp
job
Jobs
jQuery
JSF
JSON
JSP
JSR-94
JsUnit
JVM
JWS
Kanban
keynote
Kindle
kiosk
laptop
Lazlo
Lean
Legacy Systems
leopard
lightweight
LinkedIn
LINQ
LINUX
log4j
logging
Logical Model and Conceptual Model
Low Pro
Mac
Maintainability
Malware
Manufacturing
mapping
marketing
Marketplace
Mash Note
Mashups
math
measurement
Meebo
metal
metaprogramming
MetaWidget
Methodology
Microformats
microsite
Microsoft
migrations
minimalism
Mobile
mobile platform
Mocha
Mock
mocking
mock objects
modeling
mod_rails
monitoring
Mootools
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
natural key
neal ford
Netbook
NetNewsWire
networking
NewNet
news
newspapers
new york times
nfjs
NHibernate
nokia
notebook
NSURLProtocol
obj-c
Object-Oriented
Objective-C
Object Relation Mapping (ORM)
ocmock
Office
Om Malik
OmniGraffle
online spreadsheets
OOAD
OOP
opengl
Open Screen
OpenSocial
Open Source
opensource
Opera
Oracle
OReilly
origami
ORM
os
osx
OS X
Packer
pagination
pairing
Pair Programming
palm
papervision3d
Pathfinder Development
Pathfinder General
Patterns
pdf
pdf application development
Peer Creation
Performance
Personas
PGN
Photoshop
PHP
Phusion Passenger
physics
physics engines
planning
play at work
plugin
plugins
portableapps
pragmatic
prawn
Predictions
preloader
presentation
primary key
privacy
process Web/Tech
Product Definition
Product Design
production environments
Production Support
productive programer
productivity
product launch
product manager
Product Strategy
Progressive Enhancement
project concept
Project Manage
project management
Project Website
Prototype
Prototyping
PureMVC
Pure MVC
purpose built devices
PV3D
pyro
QA
qooxdoo
Radiant CMS
rails
railscasts
rails controllers
rails development
Rails Environment Tests
rails polymorphic
railsrx
rails testing
randori
Really Simple History
Refactor
refactoring
References
regex
regular expressions
reporting
Requirements
Requirements
Alice Toth
requirements definition
Requirements Visualization
resesign
Restlet
RETE
Review
rfp
ria
Rich Interactions
rich internet applicaiton
rich internet applications
risk management
Robert Fogel
ROI
rspec
ruby
rubyamf
Ruby on Rails
Ruby on Rails Internship
Ruby on Rails testing role
ruport
S3
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
Scrum
SDLC
Search
Secretariat
Security
Selenium
SeleniumIDE
Semantic web
SEO
Server Side
service oriented architecture
shoulda
Silverlight
simplicity
Sketch
skins
SOA
soapUI
Social Networking
Software
software arhcitecture
software design
software develoment
Software Development Best Practices
Software Engineering
Software Maintenance
Software Processes
software product strategy
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Spring Framework
StageScaleMode
Standards
standish
starting projects
Startups
static typing
Stencils
Steve Jobs
STI
Story Telling
Stress
Structured Design
Struts
Subclassing
sun
surrogate key
Susan Boyle
Swing
tablet
tabs
tag
taglib
Tamarin
Tank Engine
Task Flows
Task Switching
tdd
teams
teamwork
telephony
Tellurium
Test
test::unit
Test Driven Development
Testing
tether
textmate
The Ajax Experience
throttling
Tilt Component
time
timezone
Tools
touch
touch screen
touch screen kiosk
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Twitter
ubuntu
UI
UIViewController
uml
unit testing
Unit Tests
unity3d
Upgrade
Usability
Usability Testing
user centric design
user driven agile
User Experience Design
user experience design
user groups
user interface
User Interface Standards
User Modeling
User Research
uxd
Vaadin
value
velocity
Venture Capital
Video
viral marketing
Vision
visual analytics
visual design
visual documentation
Visualization
VLC
VML
vmware
Volta
Waaler Surfaces
wapcaplet
waterfall
watij
watir
web
Web/Tech
Web 2.0
web app
Web Applications
Web Design
Web Development
web forms
web hosting
Web Infrastructure
Webkit
Weblogs
Web Services
WebSockets
Web Standards
WebTest
Widgets
will_paginate
Window Forms Development
Windows
windows development
windows mobile
WinForms
Wireframes
WordPress
workflow
work life balance
xcode
XML
XML Metadata
xp
XUL
Yahoo Map AS3 API
YUI
Zeigarnik
Zeigarnik Effect
ZendAMF
ZK
Archives
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- 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
Blogroll
Recent
- Single Purpose Devices vs. Flexible Platforms and Functional Cases
- Tiling a 2-D Polygon using C# GDI+
- Architectural Anxiety and the Waterfall Approach
- Unit Testing Sphinx
- Flashback: The iPhone and the Early Days of the Web
- To the Moon: an iPhone with Wheels
- How Would Steve Jobs Pitch YOUR Product?
- iPad: How big is the space between laptops and iPhones?
- A Slight Correction to using PureMVC with Vaadin
- iPad: Instant Reaction to Apple’s Tablet Event