-
Get a monthly update on best practices for delivering successful software.
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
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 »
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
Design Documentation
A few years ago, I worked on a team that was trying to move the business side away from the waterfall method into more of an agile approach so there wouldn’t be such a disconnect between design and development. Since there was no blueprint on how design could be done in an agile fashion, resistance was very high. One of the major sticking points, however, was in documenting requirements. The business side controlled the process which meant no one could see or review the requirements until they were released by the analyst. In a world view of us vs. them, collaboration was not very high on their list.
Collaboration, however, is high on the list for agile development. So, how to resolve this conundrum and begin to merge the two teams. Continue reading »
Feature Fatigue
Your project is going along fine. After the initial bumps, the team has reached max velocity and is running through story points like there’s no tomorrow. The demos are a success, with the client loving how everything is coming together. Communication between the team members and the client is working well, with enough give and take that all sides feel like they have a genuine stake in the project. In fact, the goal posts are in sight and we’re already scheduling a release plan. And then the client asks for one more feature. Not a tweak of something already built, but a new feature that has to seamlessly incorporate into the application and not look like a last minute add-on.
The initial response? The team to comes to a screeching halt and devolves into something resembling the stages of grief. Continue reading »
Topics: project management
Death to IE6
“IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web.”
~ Jeff Zeldman, standards guru
Anyone who has worked with developing the presentation layer for web apps has become quite adept at creating workarounds in JS and CSS to try and give the user the same experience in IE6 that they’d have if they used an up-to-date browser. However, because of IE6's non-compliance with W3C Standards, a ridiculous amount of extra work (i.e., hacks) is needed in order to get the page to render correctly in this most outdated of browsers. And, as Dietrich mentioned in a previous post, the problem is that these deviations from the standard end up becoming the standard and increase the amount of time required to write and maintain code.
Continue reading »
Just mow the grass
Gauging a client’s wants and needs is as much an art as it is a science. Oh sure, establishing the requirements and needed features and potential limitations (hello legacy system) is pretty much a straightforward scenario. It’s when we get into the layout and behavior of the application that negotiating the waters can begin to get a little tricky. Bump it to the redesign of an existing application that users are accustomed to, and the trickiness factor is raised exponentially.
I’ve been lucky with Pathfinder in that my last couple of projects have been to design and develop new software. The clients come in with an idea for a better mousetrap and we build it. They’re excited, we’re excited and we get to build something shiny and new that gives the client a good experience and helps build their business. A win-win in my book.
Not all projects have such a glorious life. In a previous job, I was part of a team that was tasked with porting a legacy system over to a new framework. Naturally, there were the usual levels of complexity all projects of this type always seem to encounter. However, the most difficult obstacle to overcome was the inability of the decision maker to see anything beyond the existing user interface.
Topics: Prototype
Visual Heuristics
Heuristic reviews are a great tool for finding usability issues in any existing interface, from web-based to desktop. It's a quick and relatively inexpensive way to uncover, document and prioritize usability problems.
From usability.gov:
The goal of heuristic evaluation is to find usability problems early in the design of a Web site so that improvements can be made as part of the iterative design process … The result of this analysis is a list of potential usability issues or problems.
While I use heuristic reviews and find the results to be very helpful, I've never been too thrilled with the final documentation. Even when formatted nicely, they’re nothing more than a laundry list with a bunch of words and numbers and no hints or ideas on how that information can be grouped together and translated over to an application. Quite frankly, after the second page my eyes do tend to glaze over. And if my eyes glaze over, I can't even imaging how it affects the client. So I was challenged to come up with something better.
My co-worker, John McCaffrey, wanted to give his client some ideas on how to improve their site -- a heuristic review but with a sort-of Cliffs Notes component that could highlight the value of the review but not induce eye fatigue. He was also looking for something more visual to grab the interest of the client and keep them there long enough to start looking at the data. He mentioned that he really likes our annotated wireframes and an idea was born. Create a mashup of annotated wireframes and heuristic evaluation.
The Starting Line
'Fixin' the Start Line!' by UHLMAN
Companies (and people) new to software development tend to think that projects start with development, as in writing the actual code, as in here’s my idea … when can I see it and btw, why am I paying you for time that you’re not coding. Most are not aware of the upfront work needed to get to the point of coding or, perhaps, even the value of it. After all, they gave you the idea so let’s see less talk and more coding.
What is some of that necessary work that’ll drive us towards development? The upfront work definitely includes requirements — the details that allow us to start writing the code. But even before the requirements are started, long before diving into the wireframes and user modeling, features list or user stories, projects need to begin with a business problem and a blue-sky idea on how to solve that problem. In short, the product concept.
Continue reading »
Topics: project concept, Requirements, starting projects
Definition of a Feature (Given … When … Then)
At some point in their career, most everyone in software development has encountered the client who paints a very eloquent picture about their fantabulous idea that’s going to revolutionize the [insert industry vertical here]. However, as time goes on you realize the client’s staying at the 60,000 foot level, and while that may make for great conversation, it's less than ideal for actually developing something. The trick, then, is to get them to climb down into the trenches and define the details before you have to start writing the code.
At Pathfinder, we’ve been involving clients in creating business-driven scenarios to define a feature, i.e., what does ‘create accounts’ really mean. These scenarios walk through the different tasks of a feature and identify the expected behavior and outcome based on the user’s actions. Although they follow a specific format (context, events and outcomes), they are written in plain English that can be understood by all team members.
Continue reading »
Topics: Acceptance Tests, Requirements, Scenarios
What should our software do?
The most difficult part about designing software is, well, where to begin? You have the account manager on the one hand who gives you the laundry list of items her client has been screaming about for the last n years; the marketing person who has his stack of post-it-notes listing features by competitors; and the tech lead with an itemized list of underlying functionality that must be refactored if the system stands any chance of continuing to work in the future.
Some teams combine all the lists into one main Feature List, assign a priority and tackle them one by one until either (a) all the items are completed or (b) the CEO decrees the product must be launched. On small projects with a limited set of functionality this may not be a bad approach since the overall Feature List will never be ungainly. The downside is that what you produce may not be what the user necessarily wants to use.
Continue reading »
Design Thinking
Hmmm … is design thinking going mainstream? A recent article in the Harvard Business Review and now this from the New York Times:
So pervasive has design thinking become in the last five years that Stanford University has created an elective program it calls d.school — more formally known as the Hasso Plattner Institute of Design — that has proved wildly popular with budding entrepreneurs from all corners of the campus.
It is a time in the spotlight for a process that historically has been relegated to the end of the business planning line.
Those of us involved in design already know that design thinking is one of several tools we use to help our clients stay competitive. Nonetheless, it’s nice to see major publications picking up on not only what design thinking is, but the importance of joining it with business thinking. Read the full article for a review of how this partnership works to create new solutions.
Topics: design thinking
Bullseye Diagram
In most projects, it’s easy to come up with ideas but more difficult to give weight to their importance since the client (and sometimes the team) think they’re all important. So we move onto establishing a scale (1 = must have; 2 = nice to have, etc.) and then assigning values to each task/idea/feature. Generally some good discussions come out of this exercise in determining exactly what is important in creating a successful project, along with defining exactly what “success” is.
At the IDEA 2008 preconference workshop, Dave Bishop and Paul Gould from MAYA showed us another way to prioritize project tasks: a bullseye diagram. It’s still a ranking system, but done visually rather than numerically. The team first lists out all the project tasks. These are then placed in the bullseye based on where they fall in rank; the critical items are in the center and the less important items moving towards the outer rings. If this is done on a whiteboard with the tasks on Post-it-Notes, then information can be quickly be moved around in relation to new tasks that are added to the bullseye.
Once the tasks are prioritized and in the bullseye, you can organize, arrange and add structure. You can start to see relationships, which may indicate a different priority. You can start to see categories, which may affect iteration planning. You can begin to add structure. The outcome of this exercise is an easily understood diagram showing the project’s priorities. For teams that aren’t comfortable assigning a number to a task, this is a good alternative to try.
Topics: data visualization
IDEA – preconference workshop 06 Oct 08
The IDEA conference is being held in Chicago this year, and once again MAYA Design hosted the preconference workshop on Information Architecture. Some thoughts from the morning’s discussions.
- Why diagram? We diagram in order to depict the information space in such a manner that allows us to visually validate to the client that we understand their domain. So often as consultants, we’re thrown in to domains where we have no or very little prior knowledge and minimal time to come up to speed at the level we need to be at in order to understand the context of the problem. Diagrams are one artifact that we use to organize the information space and document the users’ mental model. They are an essential element in verifying that your direction and understanding are correct.
- Future proofing. Don’t just design for the here and now; don’t design a solution that locks you into one way of thinking; don’t create a solution that can easily be broken by another idea. As solution designers, we need to look at the larger picture and how the various pieces can fit into the whole, rather than at just one feature or one path. We need to allow for evolution so the solution can accommodate growth and expansion without extensive redesign. All of these are concepts we’ve heard before; but it's already good to get the reminder and hear them again.
- UCD - user centered design focuses specifically on making systems usable to people. It tames complexity. Having the user integrated into the design process brings a focus around which you can organize the solution and design a usable interface. The direct benefits are increased productivity, reduction in support costs, improved user satisfaction, etc. The usual suspects, but nonetheless important to bring up with your clients when you remind them why UCD is relevant.
For the remainder of the session, MAYA reviewed some diagrams they use in their IA practice, including some I hadn't seen before. I’ll have more on that later.
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
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