4 - Immanuel Kottlowski

    The user has needs and the user knows how to satisfy those needs. Much like the fast food selection analogy made in the book. This fits because the user knows whats best, but doesn't always do the best thing, like removing a flash drive via device removal ("Ain't no one got time fo' dat."). So in essence the user is always correct, but the habits that they have do not always reflect their knowing the correct answer. So if you build something that they think they need they won't use it the way they think thought were going to use it. So the user is correct in knowing the right way to do things but is wrong in actual execution.

    The user wants a feature that makes a puppy, well that would be cool but who's going to take care of the puppy? The point is that users want a lot of things, but the things that they want don't always make a lot of sense for the given activity. To add a feature on the mere whim of a user isn't always the best way to do things, because the feature might take away from the main activity. Somethings are nice to have but most users are only going to use 20% of what you develop so why make more than you need too. Make a few nice to haves but keep it simple and focus on the activity. I feel as though Hoekman is advocating a balance between user needs and the activity at hand. The main question is does the wanted feature take away from the main activity? If it does then that feature is removed, or minimized so that it doesn't clutter up the interface. Hoekman mentions the 80/20 rule, and that is what he is advocating.
    In project two for the design, all the features that I added could have been re evaluated to the 20/80 rule. Put the more advanced settings off in the corner and had only the main "quick start" option in the fore front. because most people that use the machines at the gym are only worried about the quick start option which would have accounted for about 20% of the interface anyway.