Jacob Barnard - Alpha

Current working build is here:

http://jmbarnard.iweb.bsu.edu/BarnardDevTest/

I will be doing the "paint-job" for my site as I get the functionality near completion.  For some general design tutorials, here is a site I was introduced to the other day.  Just another tool to consider:

http://tutsplus.com/

Jacob Barnard - Proposal

(Site Preview Through Its Development)

http://jmbarnard.iweb.bsu.edu/BarnardDevTest/

(Pre-Alpha Design Specs)
http://docs.google.com/Doc?id=dcv8sm7j_49gbqmjjhb&hl=en

Jacob_9_I

The part about this chapter that really interested me was the discussion of spimes.

According to Bruce Sterling, quoted by Saffer:

A SPIME is an entity that is aware of

SP: space

+

IME: time,

...and it documents everything about itself and those things affecting it from the beginning of its life until the end of its life.

...sounds kind of like a human?

The plural of SPIME is SPIMES, which in reverse is SEMIPS.

Interesting to notice here is the acronym MIPS, which is already known as "millions of instructions per second," the predicate behind a some modern CPU logic.  And, imposing my own thinking here, we could let the first two letters SE be "social entity"... well, maybe we should make it "social entities" to keep the plurality.

... so, we have "Social Entities [that can process] Millions of Instructions Per Second."

...sounds about right... and scary.

Jacob_7_I

I think one thing we need to notice from this chapter is how Saffer defines smart applications and clever devices.  These devices talk with one another (i.e. the laptop feature that talks with a traffic server about your car's speed, etc.) and are able to relate to each other.

This goes back to a concept mentioned at the beginning of class.  That is: the devices and systems we design are really in the end meant to facilitate communication among humans.  It is interesting to see that when we apply this same concept to inter-machine/software communications, we call those machines and software clever or smart.

Heh... I guess this would be a inner-relation (I hesitate to say metarelation): e.g. machines and software designed to relate to each other in order to ultimately facilitate human relation.  I wouldn't say that it is a metarelation because it is not a relation of a relation.

i.e.   H - D - D - H is what I am talking about...

where H = human

and D = some designed entity (software, hardware, etc.)

and the dashes are a line of connection

... essentially, this observation is my big idea.

Jacob_6_Q

This chapter didn't seem to lend itself to any big ideas or big questions in my opinion, but I'm still not ruling them out.

This chapter seemed to focus primarily on the tools of interface design.  Yes, Saffer touched on some theory and quoted other professionals, but I think for a big idea or big question here, we may need to deduce something from all the practical advice Saffer gives.

I think here we need to notice the trend in quantity of elements used in interface design.  The trend is change.  More and more we see new elements of interfaces becoming staples of interface design.  Each somehow fits the bill of the principles outlined in chapter 3, but each is different from its peers and predecessors in some way (hence the word 'new').

I believe that there are infinitely many possibilities for interface elements; it just depends on the context on when and how to use them, which leads to my big question: If we have total creative power over the context, could we not implement new and bizarre interface elements that still make sense to the user?

Jacob_5_I

I am pretty familiar with task flows.  They work well to convey the logical connections between actions and states in a design.  However, what I was not aware of before reading this book is what Saffer calls Use Cases (Saffer 107). I thought it was pretty interesting, and it actually parallels something else I am familiar with called notecarding from a book called Big Java (3rd Edtion) by Cay Horstmann.

The idea of notecarding is to identify the verbs and nouns inside the system you need to design.  Once you do this, you can group nouns inside of other nouns (where it makes sense to do so) and then associate all actions with the appropriately corresponding nouns.  (You can also put actions inside of other actions: i.e. the action of running may require the action of moveLegs.)

The Use Cases idea seems a little more focussed than note carding, or rather more structured.  Where the notecarding is very general, the notion of Use Cases seems to mimic the task flow - it sort of plugs the designer into any given point in the design and says "what happens here?"

The other nice thing is that a use case seems to be generalizeable.  In other words, I can talk about a very specific use case or a very broad use case (i.e. the entire use of the system from beginning to end),  albeit I think in the broader use of the notion of use case one might run into some problems with Poka-Yoke, but I think that's the fun of design.  E.g. You might say that "At the beginning, the user sees the Web site and can access all of his tax information.  At the end, he has filed his taxes."  This is an informative use case to me; it describes in general what the design should accomplish.  But for more complex Websites with many possible beginnings and ends, it gets a little fuzzy.

So, I think it just depends on your style and how you want to approach designing the "hows" of the design.

Jacob_4_I

A little background first...

After this semester, I'll have taken all the required undergraduate courses to apply for graduate school to pursue an M.S. of Computer Science. Having taken several TCOM, CS, and MATHS courses, I've noticed a very interesting correlation between the high-level and low-level material I've studied:

Many theories that apply to low-level material are applicable to high-level material as well.

Take Saffer's hunt statement (Saffer 76).

It is the statement: H(x, y) = "I am going to do x so that I can do y." This type of statement is similar to one found in a particular component of discrete (or finite) mathematics called propositional calculus.

Usually these statements (or propositions) have truth value -e.g. H(x, y) can be logically TRUE or FALSE. Unfortunately, unless we can predict the future, we can't really determine the truth value of H(x, y) as we see it above.

But, if H(x, y) were something like "x allows me to y," then we could more accurately evaluate the truth of H(x, y) - i.e. if we had H(Starting my car, drive my car), that would be equal to "Starting my car allows me to drive my car." Generally, this is a true statement because you can't drive a car that has not been started (unless you get friends to come and push!).

How might this kind of basic statement-analysis apply at the high-level? Well, take a more complicated hunt statement like "I am going to talk to the client so I can get an idea of what he or she wants." It's an extremely abstract, future based statement - it is high-level. It's not really a statement that we can manipulate with the rules of logic, but we can break it down... so, let's do that:

I can infer from this new hunt statement that I need to set a date to meet with the client or at least talk with them. I also need to determine some parameters for the part that reads "get an idea of what he or she wants." What are some certainties and what are some variables hidden inside that last half of the hunt statement?


Examples of Certainties:

These things are not set in stone... but man, if they fluxuated all the time, the project would be REALLY difficult... so these are some high level, assumed constants or certainties I think a client is obliged to relay:

Let P(x) = "I am designing for the platform, x." If x = the Web, the iPhone, ... etc., then we suddenly have a lot more information and our design goals become more narrow and thus easier to envision. It may be the case that you are, in fact, designing the platform. So, that might change this P(x) a bit.

Let D(x) = "The client would like the application to feel x1, x2, x3, ... , xn." Here the client can give you any number of different feelings. Again, with more concrete information, your goal for a design comes more into focus.


Example of a Variable:

Let $(x) = "The client will pay x for the finished product." This is something that may change if things are added/subtracted from the project mid-stream.

So, what's the big idea?

Well, this might be overkill on common sense, but sometimes we get the dreaded designer's block... NOT GOOD!

So, if you can't think of something snazzy when urgency is suddenly forced to be your best friend, I think it's a good idea to break things down into smaller, more manageable questions and just see what you can accomplish that is practical.

Maybe after reading this book, perhaps if we follow this ideology, we might find some more fundamental truths about interaction design in addition to those Saffer relays.

Jacob__3__Q

I thought it was interesting that Saffer introduced rhythm as one of the elements of interaction design.  As a musician I've noticed several designs whose responses were very rhythmic - e.g. there exists a definite time it takes to complete a "feedback" (or perhaps even the time it takes to complete a "feedforward") on any member of a set of similar objects within some designed system.

Dr. Dailey noted the "genie" effect that the Mac OS X employs through Quartz to "minimize" and "maximize" windows.  That time is always the same (unless you hold certain keys to change it) for every window you "minimize."

Similarly, when one clicks on an icon on the dock and the application doesn't open immediately, the icon bounces up and down rhythmically to let the user know "Hey, I'm working on opening this up for you."  While each bounce is rhythmically timed, each bounce may have no indication of how much of the program is loaded; yet, this might make the user feel as though the computer is processing the load in an ordered manner, as opposed to some loading bar which may suddenly jump a little and then wait to progress for a good deal of time.

Here is a site whose menu responses are quick, but because each response is timed, one can have fun just messing around with the menu.  (Notice that large menus pop up with the same time that the smaller menus do):

http://www.sony.com

The big question:

Do you think rhythm is appropriately used in most interaction design on the Web?

Jacob__2__I

Apple had to consider a vast audience when designing the Mac OS X operating system user interface. Having said that, there is a lot about the interface that is very intuitive: the dock and its icons, the icons and their reactions to the mouse, notifications occurring on the desktop upon the detection of new drives rather than off-screen (and many more features that were or were not mentioned last week in class). Simple concepts, yet very powerful.

I think "Genius-Design" favors the simple, direct approach. What do I mean by that? I think that "Genius-Design" is maximized when the design lends itself to little effort on the part of the human yet yields robust results on the part of the designed entity. Take the iPhone or iPod Touch for example. Simply by tapping one of the many, glossy buttons in the main applications menu, I have access to a massive amount of content - some might argue a virtually infinite amount of content (because anyone can write an application for the iPhone now provided that they have the proper resources). And, if I don't have something I want, I can tap a button on that same menu to search for an application. Once I've found the application, I download it by pressing a similar, glossy button. Another glossy button appears on that same main menu; then, I have what I want. It is all in one place, and it is all activated the same way: tapping an easily recognized button with my finger! Again: simple, yet powerful.

Jacob__1__ Q

Saffer talks about interaction design as being "about behavior." He premises this by saying that two systems can look alike yet "feel" different. I can understand this feeling; it is almost tangible in a way. I'm sure many others understand this feeling also (page 4, Saffer).

So, now I have a premise: what if some (or many) humans feel as though the machines we use are designed by people who are trying to play on our senses and feelings. Maybe we should not buy into those more "feely" products. On the other hand, maybe we shouldn't worry about it and just embrace it.

The big question I have is this: as Americans become more and more technologically savvy, do you think we might steer away from a feeling driven sense of interactivity and perhaps toward a more logic or efficiency driven sense of interactivity? And to follow that up: is one better than the other in your opinion?