Mike Kelly posted to the IWST news group about two upcoming group meetings that are taking place in Indianapolis. I listed them in order of perceived relevance. The first one is free, and is a day long, similar to the excellent IWST that I attended in September. The second one is not free, and lasts two three days. The first one seems particularly useful, although the second might be as well.
I've edited liberally, so here goes…
May 15, 2009
Title: The Drunkard's Walk: How Randomness Rules Our Lives Authors: Leonard Mlodinow Published: May 2008 Length: 272 pages
After taking two quarters of statistics and two of probability, I wasn't sure that I would learn much by reading The Drunkard's Walk. Fortunately, the history of the evolution of thought regarding chance and the ramifications of randomness on everyday life were explained to the point where I gained new insights into this area. It reinforced and clarified existing views that I had as well.
The most important point that was made is that there are a large class of things that humans typically see as being based on skill but are more likely based a great deal on luck. While CEOs and Hollywood film producers are paid top dollar for their skills, there seems to be little correlation with actual skill for their positions. Many events that involve human decision are unpredictable to the point that they can be considered random. I enjoyed the discussion of reversion to the mean presented throughout the book. Essentially, we tend to praise someone and see them as smart or skilled when they succeed, and then tend to disparage the same person when they do not appear to succeed. Mlodinow explains that our approval or disapproval often has little to do with someone's next attempt because often the performance in the event is somewhat random. When I yell at someone, it is likely that they will do better than before. When I praise someone, it is likely that they will do poorer than before. Likewise, a mutual fund manager is likely to be lauded when she does well, and given the boot when she does poorly, even though picking stocks is a mostly random process.
The first breakout session I attended was the most interesting. It was titled "iPhone User Interface Design."
The first point the presenter made was that the percentage of time that you spend on portions of the development cycle is quite a bit different for a successful iPhone app than most software applications. He showed a diagram that looked way cooler than this:
What this means is that you need to spend a lot more time in the design aspects of your app throughout the life cycle than you normally would. This set the tone for the rest of the presentation.
He defined "design" as mapping out requirements, doing the art and layout, and figuring out how core features and navigation are going to work. The cycle for developing a new product should typically go: familiarize, conceptualize, realize, finalize. Executing these well will take your application from average to excellent.
One solid suggestion was to read through Apple's Human Interface Guide. Apple has spent a lot of time thinking about how people will interact with the iPhone and iPod Touch, so you don't need to duplicate their work. What's more, there are many conventions that you will be unaware of and unwittingly break. For example, Apple intends all buttons to have rounded corners, so if you have something that's not a button, don't make it rounded. Likewise, buttons should look like buttons because users have a model of what a button looks like and what it does.
The presenter reiterated considerations voiced in the general session, such as thinking about where the user will use the application and considering general properties of the iPhone and how it differs from the web and from a desktop computer.
One significant suggestion was to design for the thirty-second use case. You need to consider that the user wants to open your app and get what they need within thirty seconds. If your app has a bunch of meaningless screens or has poor performance, it will significantly hinder your ability to help them. If it takes twenty seconds to navigate where they need to go, you only have ten seconds to please them. If you can save any time by remembering or determining data (zip code for searching for restaurants, for instance), you should do that. It takes a lot of time and mental effort to type things in on the iPhone, and it would be very annoying if the user has to type something in multiple times.
Last Wednesday, I went to a one-day session in Chicago titled iPhone Tech Talks. I am currently taking the Cocoa Academy course, and thought that this would be a nice way to get some additional information. The conference had probably about 400 people or so. I was a bit worried because I have neither an iPhone nor a Mac, so I thought that I might have been out-teched. :) However, it seemed like most people did not bring their laptops, and some of the people that I talked to had as much or less experience developing for Apple platforms.
I took like fourteen pages of notes, so I will probably break it up into a few posts. This one, which gives an overview, one about usability (I was writing the entire hour and a quarter session) and one about performance and using different libraries.
Hmm… Well, maybe you are doing or planning on doing some kind of iPhone development. That would be nice.
But I was talking with someone who has the G1, and the features are pretty much the same aside from native multi-touch, so most of the design principles and considerations will be present there. Indeed, any mobile device has at least some of the constraints that you need to think about when creating an iPhone app: usability, market reach, battery life, screen real estate, interrupts, performance, and more.
I would say that this was my first foray into mobile development, so it was definitely an eye-opener. If you have developed for a mobile platform before, then some of these comments will be old hat, but there still might be some gems in there.
Title: The Little Book of Bull Moves in Bear Markets: How to Keep Your Portfolio Up When the Market Is Down Author: Peter D. Schiff Published: 2008 Length: 263 pages
With the current state of the financial system, I was looking for a book to make sense of it all. I had been reading about the decline of the dollar, the poor state of the financial sector, and the huge deficit the United States is running, and thinking that there were still some people out there who thought that things were going to get better in the very near future. Although I don't have all that much in long-term savings yet, I was wondering how to keep what I had in there and what markets might be nice to invest in given the current state of the US economy. In the introduction, Schiff states: "The goal [of this book] is to help you preserve and enhance wealth that can be reinvested in America after fundamental economic reform takes place."
The book was written in early to mid-2008 after Schiff's book Crash Proof. That book accurately predicted what happened in the last year or so, even though various pundits scoffed at his work. I was excited to read something that contained timely information. One thing that Schiff did not talk about was a potential government bailout plan, although that is probably a subtext with inflation and other government manipulation. He does talk about the 2008 elections and how they might influence policy, and plugs Ron Paul because of his Austrian economic roots and the desire to return the gold standard. He correctly observed that the "smart money" was on Obama, and he indeed won.