Q&A with Trace Johnson of Chicago-based mobile-payment start-up Mpayy
Chicago isn't Silicon Valley, so it's always interesting to see tech start-ups putting down roots in Midwestern soil. Last night I hit the launch party for Mpayy, a mobile payment start-up that launched just last week. Over a hundred prospective customers, potential investors, and tech and banking professionals hit Fulton Lounge for cocktails, networking and, of course, a product demonstration. Afterwards, I chatted via email with Trace Johnson, Mpayy's product VP, about the launch, the company's future, and the state of Chicago's entrepreneurial culture. (Full disclosure: Johnson and I were once colleagues at Orbitz, one of the Windy City's big tech start-up success stories.)
Agile Ajax: First off, can you tell me the basics about Mpayy? What's the one-minute pitch?
Trace Johnson: Sure, but there are different pitches for consumers, online merchants and mobile merchants:
- Consumers get online and mobile payment processing. Shop online or send money to your friends from your checking account for free and get cash back when you buy.
- eCommerce companies get a secure payment solution with 0% fraud liability and they save 40-50% vs. credit card processing.
- Mobile merchants - taxis, fruit vendors at a farmer's market, Avon ladies, shirt vendors at a concert - get turn their mobile web enabled cell phone into a retail point of sale system.
101 Ideas for JSONP - Idea #4: Scraping XML with XPath, Part 1
It's been a while since the last installment of JSONP. Lots of good stuff has happened in the meantime to make our lives easier, but some things are still brutish, ugly and complex. One of the nice things in the more recent version of the JDK is the ever improving support for XML processing. Long gone are the days when you had to hunt around for libraries and hope that your version of the JDK worked with your third party libs. There are still reasons, like performance and extended features, that would cause you to pick an alternate library, but if you just want to add a little bit of XML processing into your apps, things couldn't be easier.
GWT Widget: Rolodex
Chris Jones of YesMail has written a pretty slick rolodex widget (see the Google groups thread about it).

Right now the animation images are generated by hand, but with a little bit of Java 2D, this can happen at compile time. You can kind of see some of the issues here of Flash v.s. DHTML. Flash has all sorts of image transformation goodness, while DHTML is a little handicapped here. You could use something like Reflex instead of compile time image transformation, though I haven't tried out how well it performs when animating.
Anyhow, nice work Chris. It's nice to see folks pushing the boundaries of what one can do with DHTML widgets.
Technorati Tags: ajax, gwt, yesmail, widgets
Topics: Ajax Widgets, GWT, Widgets
Agile User Experience: If you have a silo, knock it down

In many development processes, team members are organized by functional group. A project might have a team of developers building the code, and then down the hall or across the globe, a separate team of designers working on the visual and usability aspects of the application. The two sub-teams are walled off in their own silos, and communication between the two sides is minimal.
This structure is not compatible with an Agile software process -- it's too hard to get rapid feedback between the teams that make a process truly Agile. Worse, if the two teams are separated, the odds that they will have a common conception of the project, or even a common set of terms for discussing the project.
The most important step in tearing down the silos in your project is just switching your mindset from function-based teams to project-based teams. Continuous integration spreads from being just something the developers do to a way of making sure that all aspects of the project are in synch.
At the most basic logistical point, the designers and developers should share a common code repository. There's a certain amount of overlap in the tools used for web applications on both sides. If designers can see the latest version of the application when making CSS or HTML changes, then developers can see those changes and work with the most current design as quickly as possible.
In order for this structure to work well, each side needs to move out of its silo and toward the other. Developers need to have an awareness of usability and design issues, and be able to discuss potential problems with the designers. Developers also need to be willing to do any rework that will be needed as the design changes.
Designers need to be willing to work at least some of the time in the developer toolkit, working with source control, able to make CSS or HTML changes directly in the code files (even better if the designers and developers can make it easy to make tweaks at the JSP or ERB level). Not everything that a designer does can be captured this way, but using common tools and files where available increases the team's ability to work together. Sharing knowledge makes the team more able to notice potential problems, and makes teams more stable over time.
Last week, I wrote about how a user proxy can help integrate Agile and User Experience Design.
Once again, let me mention the upcoming book Professional Ruby on Rails. Available mid-February.
Topics: Agile Development, Ruby on Rails, User Experience
Ajax security surprises: web-aggregators, offline applications and frameworks

I'm still absorbing the densely packed information from "Ajax Security," the first-rate book by Billy Hoffman and Bryan Sullivan that I recently recommended in these pages. Here, in no particular order, are three of the most surprising lessons imparted by Messrs. Sullivan and Hoffman:
Web aggregators and SSL
This is probably a great big "duh" to some developers, but web aggregators such as iGoogle and NetVibes often compromise the security of otherwise SSL-encrypted web applications when funneling content from them to your personalized homepage:
Now, consider what happens when you use a Gmail widget on an aggregate site like NetVibes. Sharp-eyed readers will notice the URL for NetVibes ... is http://www.netvibes.com. This is not an encrypted connection! NetVibes sends user data in the clear from the aggregate to the user.... NetVibes makes an SSL connection to Gmail, and then NetVibes degrades the level of security by transmitting the data over an unencrypted connection. Our attacker ... can steal the data much more easily now. NetVibes is not providing the same level of security that a user would receive if he accessed Gmail directly. This situation is not unique to NetVibes and Gmail.... At the time of publication, every major aggregate Web site the authors examined downgraded security on data from secure sources. [emphasis theirs]
Topics: Best Practices, Books, Review, Security
Songbird powers label-approved P2P download service Qtrax
Last week I posted my interview with Stephen Lau, developer evangelist for the Songbird open-source music player. Afterward, I had some follow-up questions, which appear at the bottom of this post.
During my conversation with Lau, he tipped me off to the imminent launch of a new music service that would be white-labelling the Songbird core. The accouncement came this weekend from new peer-to-peer download service Qtrax, which promises major label-approved P2P access to a music catalog of 25 million tracks. The Wired News report on Qtrax provides plenty of interesting background information. But now UK newspaper the Guardian is reporting that Qtrax's music-label support is far from final.
As the music labels continue their quest to usurp the iTunes monopoly, it seems like Qtrax would have as much leverage as any other alternative distribution channel. It'll be interesting to see how this plays out. In the meantime, here are our follow-up questions to the original interview with Stephen Lau
Agnostic lightboxing
The memo may not have gone out yet, but for a year or so now the scourge of popup windows has been erased from the user experience. I know that it has been blocked by browsers for quite a while but UXD designers once and a while need this modal stalwart, the dialog box to get their business done without distractions. Thanks to great coders out there, we have a replacement we call "lightbox" which you experience probably daily as the darkening out of the screen and the overlay of that modal box. Its very quick to implement, easy to code, and with some variations, can hold music, slideshows and other nifty content types. I use it constantly, but it has one drawback, the reliance on either prototype or jquery as a backbone to do it's magic.
While I put myself kind of in the prototype + scriptaculous crowd, the battle between these libraries makes it hard since you can only include one of them. Thus someone writes some "perfect for your audience" lightbox effect, but you need to change to jquery to use it. This happened on my own site where some lightboxes needed to play mp3's and others needed to show image slideshows, I had to make compromises and change from page to page, which was extra work, and kind of weird.
No more, thanks to Mr. Jackson, we have a new lightbox (that uses the correct attribute 'rel') that can take advantage or either library, or even mootools or YUI, neato! Look forward to delving into it, check out the download at http://mjijackson.com/shadowbox/ and cheers for choice!
Topics: Design Patterns
New Years Resolution
I had a recent experience which helped emphasize how important it is to see things within the context of the user's environment. In this instance, I'm speaking of buying a new TV. Our "old" TV had served us well, was a high-def projection model, but with prices falling and screens getting brighter and flatter, I was able to convince the wife it was a fairly cheap midlife crisis purchase after all. But which to buy? Brand and reputation aside, the differentiating factor between sets were size, display type and resolution. If you haven't been pouring over spec sheets lately, the main idea is that there are two display types - Plasma and LCD and two main resolutions 720p and 1080p. For size, I wanted bigger or same as my other model so I wanted 47", 50" or 52". In my usually thorough fashion, I poured over different websites and user opinions and ended up buying the cheapest one that fit the bill... a 47 inch 1080p LCD.
The reality of setting this thing up turned out to be a fairly educational experience, all my time staring at rows of displays at Best Buy or Costco or reading Consumer Reports gave me a vague idea what were some good qualities to look for. But much like talking about what a user wants it didn't prepare me for what the real user experience difference there was between the resolutions and sizes. I really ended up finding out what all the jargon meant only when presented with the device in my own environment. It reminded me of a project where all the developers had 1680x1050 resolution monitors and the users had 1020x800 laptops. It was too tough to get the developers to realize that the way they displayed the app was removing some of the problems like cropping of text, the addition of scrolling to content, and other display problems they just weren't seeing because of their screen size. The solution I presented was to open the application in the specified fixed resolution (1000x780 or so). My point being that if they shared the pain with the users, we could build a better app, but high resolution is hard to give up, and they secretly went back to opening it full screen.
Setting up the TV I was unprepared for how vibrant the colors, and how sharp the picture, especially the high definition picture broadcast here in Chicago. There are definite advantages to higher resolution that 1080p provides (near 2 million pixels), but I noticed that as I moved backward, the screen became 'smaller' and the higher pixel count less noticeable. In all the reviews I had read, they focused mostly on comparing black levels and picture contrast, but never talked about how distance really effects the way you perceive detail, this article at cartonbale.com describes it well. 
As I sat further back I became more and more convinced that a bigger TV was necessary, I just wasn't seeing the benefits, so I traded it in for a lower resolution 720p model at 50" for the same price.
The new model was certainly the right size, but now all I could see was the lack of fine detail, of course as I moved back, it looked fine, even better than before since the TV was noticeably larger. But I couldn't get over the feeling of something missing. A decent relationship with the pythagorean theorem helped (TV's are measured diagonally for some reason) determine mathematically what I was perceiving but couldn't find on spec sheets or by comparing screens next to each other at Best Buy. For purposes of this article I found this calculator will help you out with the math.
The iphone has a great screen - 160 pixels per inch and distance between dots is .15 mm which means it really goes right up to inches from your eye.
Display monitors like the 22 inch that we use on our computer - 90 pixels per inch - distance between dots .28mm - we can determine that closeup viewing within 1 foot looks good.
The first set - 1080p 47" set was 46 pixels per inchand a whopping .54mm between dots, still, closeup viewing even within 5 feet doesn't reveal the gaps.
The 720p 50 inch plasma set was 29 pixels per inch with a chasm of .86 mm between the dots, still, I don't know if it's the dots or the gaps or what, but with this display showing a mere 1 million pixels, it certainly seemed less detailed.
Or to put it more succinctly (courtesy of some forum post found at avsforum.com:
The human eye can resolve 300 dots per inch at 1 foot. The value is linearly scaleable. In other word 30 dots per inch at 10 feet. A 50 inch diagonal tv has a Horizontal width of 50 x .87= 43.5 inches. 1080 displays have 1920 horizontal pixels. 1920/43.5= 44.37 pixels per inch a 720 display would have 1280 /43.5=29.42 pixels per inch. A person with 20:20 vision can only resolve 30 dots per inch at 10 feet. Thus at 10 feet both 720 and 1080 displays should look identical . However as we get closer to the screen the 1080 display would start to look sharper. At about 8 feet the 1080 would really start to shine.
Removing all the picky bits about LCD vs plasma, setup, color temperatures and such, the lesson learned was even with the science involved, the main way to pick a TV is where you are going to put it and watch it. While a little part of me wants to upgrade to the 1080p set at 50inches, the extra money may not be that well spent considering my distance from the screen. So next time you're at the showroom, ask them what their return policy is, trying it at home is the only way to find out.
Topics: User Research
Agile Development, Documentation and Bringing Projects back from the Dead

One of the things that comes up quite frequently when talking about Agile development with newcomers to the topic, is the subject of documentation. They hear about "just enough" documentation, "low ceremony" process, and Wikis. To many it seems like "not enough" documentation.
When pressed on what they mean by documentation, they usually respond that what they want is a document that represents all of the specifications and decisions about specifications, the architecture, the design, and the tests that completely describe the system being developed. That may seem like a reasonable request, and I think that a typical agile project, with it's User Stories and various other Wiki artifacts that are produced in each sprint, constitute just such a record.
Topics: Agile Development
A New ZK Tutorial
There are already quite a few tutorials and mini talks on the ZK site, but one more never hurt. Over at Dr. Dobb's, Andrzej Sekula guides you through "Hello, World!" with ZK, while explaining architecture, features and few other things. Worth a look.
Technorati Tags: ajax, zk, tutorial
Topics: Ajax Frameworks, Server Side, Tutorials, ZK
Agile User Experience: If you don’t have a user, invent one of those too…
Following up on Brian's point...
A customer proxy of one kind or another is also important in integrating Agile practices with User Eexperience Design.
One of the long standing issues in combine Agile development with User Experience Design is just the differing time cycles between Agile developers, who are running on a test, develop, refactor cycle that could be mere minutes long, and the UXD designer, who is working on a longer, perhaps more traditional, cycle.

The problem comes in when the developers start making coding decisions for the interface. Without immediate feedback from the UXD designers, the developers are often left to their own devices for the initial versions, with revised designs coming weeks or months later.
Our goal is to keep the development team moving forward with current feedback from the design team. For exactly this reason, the original XP book listed Onsite Customer as a core XP practice. However, that's not always feasible, and in any case for User design you want the user's feedback, which may not be the same as the customer's.
What we try to do is use the idea of a customer or user proxy to allow us to have incremental refinement of design, and allow the development team to get quick feedback and continue with the next fine-grained task.
When a developer has a usability question, the developer asks a team member acting as a user proxy. This is either an analyst on the project or one of the designers. The user proxy makes a decision on the question -- if not a final decision on all details of the problem, at the very least a consensus on some aspect of the problem that the developer can do next. While the developer does that task, the user proxy goes off and consults with the design team and the customer.
Ideally, by the time the developer is ready for the rest of the task, the user proxy has more detailed requirements and design for the developer. The key is making sure the developer's next step is always covered.
This does require some effort from your team -- the developers have have awareness of usability issues and concerns and the design team has to have the ability to respond to developer concerns quickly. Again, though, the design team doesn't need to have all the answers at once, they just need to be able to give incremental details to the developer.
(The image of the floor appearing directly underfoot is from the ad campaign for Gatorade G2)
Have I mentioned my upcoming book Professional Ruby on Rails, yet? Available mid-February wherever fine computing books are sold.
GWT Image.prefetch memory leak and suggestions for improvement
In answering a question over at the GWT google group, I came across what I think is a misfeature with Image.prefetch. The code for prefetch looks like this:
public static void prefetch(String url) { Element img = DOM.createImg(); DOM.setImgSrc(img, url); prefetchImages.put(url, img);}
The reason that the images are stored in a static hash is because in some browsers, under some circumstances, the image DOM element is garbage collected before it is loaded. That's great. But there is a problem here: these prefetched images are now not garbage collected at all. If you prefetch 1024 images of 1M each, you will have 1G of images in your browser. In some browsers, prefetching the same image several times will apparently create lots of copies, each chewing up more memory. (I haven't seen this in IE7 and FF2 in my brief testing.)
So, what to do? For starters, I'd suggest testing to see if we've already loaded an image. Second, I'd add the ability to unfetch or release a resource:
public static void prefetch(String url) { if (!prefetchImages.containsKey(url)) { Element img = DOM.createImg(); DOM.setImgSrc(img, url); prefetchImages.put(url, img); }}
public static void release(String url) { prefetchImages.remove(url);}
You could do something with an onLoad event or automatically kick out earliest image from a FIFO queue when prefetching a new image, but I'm not sure that gives you enough control. Anyhow, the above gives you enough control to be useful.
Technorati Tags: ajax, gwt, prefetching images, memory leak
Topics: GWT
Microsoft Eats Its Young: AjaxPro is no more

Back when .NET didn't have an Ajax pot to piss in, I voraciously read Michael Schwarz's blog and followed his Ajax.NET framework. He eventually released a companion "Pro" version. Now, several Microsoft MVP awards later, he is packing it in. I, for one, will miss the competition in the .NET world. That leaves two major alternatives that I'm aware of:
Since the concepts around how Ajax apps should be built are still in flux, it would be nice to have a few alternatives in the .NET world (especially ones that don't produce the XHR salad that ASP.NET Ajax does).
Technorati Tags: ajax, .net, ajaxpro.net, gaia widgets, anthem.net
Topics: .NET, Ajax Frameworks, ASP.NET, C#, Microsoft
Agile R&D: If you don’t have a client, invent one
I'm working on an internal project at Pathfinder: a cool little Rails app originally developed by one team and now being dusted off and extended by another team. Because this is an R&D project, specifications are a little vague. My colleagues and I spent several hours talking about which direction we should take the app we'd inherited. Each person's idea, of course, was subtly different from everybody else's. By the time we were done, we had a backlog the size of the monster from "Cloverfield" and no clear idea how to turn it into actionable user stories for our first iteration.
Then our CEO stepped in to act as a proxy client. At our iteration kickoff, we briefly summarized all of the directions in which we thought the application could be taken. He immediately reframed the discussion for us, prioritizing one particular feature that would differentiate our project from other applications in the market we're targeting. Suddenly, it was glaringly obvious what needed to be done first and what could wait until later - or never. Within an hour, we had a wall full of assigned and estimated user stories.
The obvious lesson here is that client engagement is central to the agile method of software development. You can have all of the great ideas in the world, but without somebody to cut through the jumble, you'll end up paralyzed. The less obvious lesson is that minimalism is the key to successful iteration planning. Once you're focused on a specific feature set, pare away anything that's not absolutely essential to getting that feature set out the door. Don't focus on the platonic ideal of your application, but rather on the concrete version of your application that you plan to deliver in the current iteration. You'll probably discover that seemingly essential functionality is actually low-priority - or totally unnecessary.
Topics: Agile Development
Interview: Songbird developer evangelist Stephen Lau

After my enthusiastic support for the open-source Songbird media browser, I recently got the chance to sit down (virtually) with Stephen Lau, Songbird's developer evangelist. Stephen was full of thorough, informative answers about Songbird's technical underpinnings, business model, development methodology and roadmap to version 1.0.
Agile Ajax: For software that's still pretty far from a polished, commercial 1.0 version, Songbird has attracted a devoted following and an active user base. How and why do you think that's happened?
Stephen Lau: We owe it all to our fans! The users that have adopted Songbird have definitely put up with some growing pains as we get closer to our consumer 1.0 release, but they've done so because they see the value in having a completely open platform as a media player. They are the type of users who are early adopters, music geeks, tech geeks, etc. and as near as we can tell, Songbird's following has grown via word of mouth (blogs, reviews, etc.) from our users.
Topics: Music, Open Source, Songbird
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- 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
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue



