General
Waxing Speculative about Amazon’s Business Model
1 Comment
From Jeremy Keith's notes on Jared Spool's AEA Boston talk:
You can buy an iPod nano on Apple, Best Buy, etc. for about $149. Amazon sells it for $134. That’s probably cost price. It turns out that Amazon can sell almost everything at cost price and still make a product because of volume. It’s all down to the Negative Operating Cycle. Amazon turns over its inventory every 20 days whereas Best Buy takes 74 days. Standard retail term payments take 45 days. So Best Buy is in debt between day 45 and day 74. Amazon, on the other hand, are sitting on cash between day 20 and day 45. In that time, they can invest that money. That’s where their profit comes from.
Holy smokes. Maybe I'm dense or out of the loop on these things, but while I figured there was a volume advantage to Amazon, I didn't realize that this cycle-based plan was the key to their profits.
Barn and I were talking about this a little over IM today, and this gives a lot of fun fuel with which to speculate about all things Amazon...
Continue reading "Waxing Speculative about Amazon’s Business Model"
Confirming Passwords Is Annoying: Is There a Better Way?
28 Comments
The defining characteristic of a password field is that it abstracts text as dots. While the intention of this behavior is understandable (it makes users feel secure and protects from prying eyes), the unintended effect is that it creates a usability problem. Users can't tell if they've entered a password incorrectly until after the site's validation informs them. It's like typing with your eyes closed.
The most common solution for the password field problem on registration pages is to require people to confirm their password in a second field. Again, the intention is understandable (it cuts down on mistakes), but the reality is that sites are requiring people to deal with two password fields. Here's an example of the common solution with some JavaScript validation:
Demo
While this isn't a terrible experience, I think there are a few other ways to handle this problem worth exploring. With some inspiration from a post on IxDA.org, I've created three below. Of note, all of these proposed solutions load a password field when the page is generated, so the browser will initially treat them as regular password fields.
Solution #1: Users click a checkbox to show characters
Demo
Pros: The decision to show or not show characters is fully at the discretion of the user. Passwords can be edited while characters are displayed.
Cons: It doesn't automatically switch back to a password field. People could accidentally keep it checked while they're filling out the rest of the form, leaving the password susceptible to prying eyes.
Solution #2: Users hold down a button to temporarily show characters
Demo
Pros: Users are able to see their password characters if they'd like and cannot accidentally leave the field in the show character state. This solution potentially feels more secure to users than solution #1.
Cons: The downside is that users cannot leave the field in "Show characters" mode while they're editing the field. They can only see what they've entered when the button is pressed down.
Solution #3: The password field automatically changes to show characters
Demo
Pros: As a user, this approach would be my personal favorite because it's the easiest option, and you always see your password as you're typing it in. I don't really care about other people seeing what I type, since I rarely find myself in situations where I notice or would expect people to leer at my screen.
Cons: When users first select the field and start typing, it will look and behave like a regular text field -- which may be startling to some. Users will not see that it switches to a password field until after they've entered something and clicked off of it.
Conclusion
None of the solutions presented here are the silver bullet for how to handle password fields in all situations. Depending on your users, your goals for the form, and your willingness to try something a little extraordinary, one of these options may make sense for your site. If anyone has any other ideas for how to handle password fields, I'd love to hear about it in the comments.
Update! April 16, 2009
In response to this post, Stephen Lewis from Experience Internet put together a writeup and demo for another alternative to password confirmation. His works very similarly to the iPhone password input field where the last character is momentarily a character before automatically switching to password "bullet".
Google Gives Back - Services and Grants for Nonprofits
1 Comment
Aside from its standard bevy of free tools and services, Google has several grants and premium services available to nonprofits:
1) Google AdWords Grants
Certain nonprofits are eligible for free pay-per-click (PPC) advertising through Google AdWords (up to $10,000/month). Organizations are able to target keywords and craft appropriate ads within Google's guidelines.
Ads are each given a cost-per-click (CPC) value of $1, so they're not going to rise to the top as often for common keywords that others may spend more money on. Once you get a grant, it's important to carefully select and monitor your keywords to make sure they will actually show up on relevant searches within your niche.
The grant amount will vary based on how much you are able to use in a given month. The monthly cap is $10,000, but because you only spend $1 if your ad is shown AND someone clicks on it, it's rare that you'll actually be able to spend the full amount in a given month. Still, you'll be able to tweak your campaigns and keywords at any time to try to maximize your grant.
- Check your eligibility - Basically, you should be a nonprofit organization that is not political, fee-based, or religious. Organizations in several countries are eligible.
- Apply for the grant
Continue reading "Google Gives Back - Services and Grants for Nonprofits"
Exploring Project Management Tasking Tools
0 Comments
Since starting at Viget in February 2007, I've received a few requests from friends and clients who want to know what project management tools we use for tasking our teams. Also during that time frame, I've auditioned three different platforms, including Fog Creek Software's FogBugz, Thoughtworks' Mingle, and now Unfuddle, whose features and flexibility seem most promising for our particular needs.
I should note that, before my time, we tried and abandoned XPlanner; same with Mantis. Later, we even built our own tasking tool, Viget Labs Project Management (VLPM). Ultimately, though, we learned that maintaining and building upon internal applications is unrealistic when paying clients have deadlines and expectations; so the search began for an external product that could support us (and, ideally, be customized as we grew and our needs changed).
Of course, each product we've tried has its pros and cons, which I describe here in my personal reviews (that's a disclaimer!).
Continue reading "Exploring Project Management Tasking Tools"
Hello, World!
1 Comment
As Viget Labs’ newest Project Manager, I’ve been learning the ropes here for the past couple of weeks. I spent my first week at HQ in Falls Church, Va., discussing Viget’s constantly evolving project processes and learning the finer points of Viget culture from my new team members. (It’s perfectly acceptable to make peanut butter sandwiches at your desk. I’m going to fit right in!)
After that initial week of guided training, I returned to Viget South in Durham, N.C., and continued learning on my own, reviewing successful web projects my colleagues have managed, asking questions about their experiences with different types of client engagements, and taking notes about techniques I admire or helpful tips they’ve given me. One of the things that impressed me was just how easy it was to go back and review those completed projects, even without the guidance of the project managers who saw them through to completion. Each past engagement was clearly documented with a set of deliverables, making it simple to follow the decisions the project team made at each stage of a web site’s life cycle.
One of the required reads for all Viget project managers is Dan M. Brown’s Communicating Design, which I’ve begun to read this week. Brown’s book encourages communication about web site planning and development using effective documentation. Since I’ve worked in user experience design for several years, none of the deliverables he describes are unfamiliar to me; but, it’s been interesting to compare some of his document creation and presentation techniques with Viget’s real-life examples.
Although Viget’s documentation varies based on the requirements, scope, and timeline for each web site, it’s always created for the same purpose: keeping all project team members focused on the same goal. By clearly expressing user needs, site design, and strategy decisions made over the course of a project, good web site documentation also allows even uninvolved observers to understand the motivations for designing a site in a particular way, including or excluding features, or writing copy with a certain audience in mind.

Recent Comments