Month: February 2007

Jobs on Entrepreneurship

And a few words from Jobs on the hardcore challenges of being an entrepreneur, also circa 1995:

I get asked this a lot and I have a pretty standard answer which is, a lot of people come to me and say “I want to be an entrepreneur”. And I go “Oh that’s great, what’s your idea?”. And they say “I don’t have one yet”. And I say “I think you should go get a job as a busboy or something until you find something you’re really passionate about because it’s a lot of work”. I’m convinced that about half of what separates the successful entrepreneurs from the non-successful ones is pure perseverance. It is so hard. You put so much of your life into this thing. There are such rough moments in time that I think most people give up. I don’t blame them. Its really tough and it consumes your life. If you’ve got a family and you’re in the early days of a company, I can’t imagine how one could do it. I’m sure its been done but its rough. Its pretty much an eighteen hour day job, seven days a week for awhile. Unless you have a lot of passion about this, you’re not going to survive. You’re going to give it up. So you’ve got to have an idea, or a problem or a wrong that you want to right that you’re passionate about otherwise you’re not going to have the perseverance to stick it through. I think that’s half the battle right there.

Blogged with Flock

Steve Jobs on Organizations

A small departure from studio-based lessons from Andrei…now let’s hear what Jobs says about organizations vs. start-ups, circa 1995:

One of the things that happens in organizations as well as with people is that they settle into ways of looking at the world and become satisfied with things and the world changes and keeps evolving and new potential arises but these people who are settled in don’t see it. That’s what gives start-up companies their greatest advantage. The sedentary point of view is that of most large companies. In addition to that, large companies do not usually have efficient communication paths from the people closest to some of these changes at the bottom of the company to the top of the company which are the people making the big decisions. There may be people at lower levels of the company that see these changes coming but by the time the word ripples up to the highest levels where they can do something about it, it sometimes takes ten years. Even in the case where part of the company does the right thing at the lower levels, usually the upper levels screw it up somehow. I mean IBM and the personal computer business is a good example of that. I think as long as humans don’t solve this human nature trait of sort of settling into a world view after a while, there will always be opportunity for young companies, young people to innovate. As it should be.

Blogged with Flock

Consistency vs. context

It’s vital for UI elements to be consistent across different parts of an application, so as to improve learning curves, encourage familiarity, ease of use and recall of how to use. However, if a particular part of the application requires a different visual treatment or UI element or behavior due to the nature of the context (a form layout vs. a table or tree), then by all means just do what makes sense for that context–do the right thing! Forcing consistency for the sake of consistency isn’t the best prescription if it conflicts with the needs of a certain context/situation.

The box exercise

Not to be confused with the “box model” of CSS layouts, but somewhat indirectly connected later on in the UI process, the box exercise is foremost a collaborative method of organizing information into potential layouts that can serve as a baseline for photoshop-level comps/explorations. The method connects two traditional but typically separate activities that seemingly have nothing in common: card sorting and magazine layouts. To make this method work, you gotta have a) key members of the team participating (marketing, engineering, design, etc.) b) tons of post-it notes and c) a huge whiteboard to stick and re-stick those post-its.

Basically the process goes like this (block out a few hours, too):

1. Unpack all the contents of the UI to be designed and write them down on post-it notes (one concept per note). For example, if re-vamping a navigation bar, write down all the menu items, tabs, search fields, etc. that constitute that navigation area. Having the product team domain experts (from mkting, engin, QA, etc.) is crucial for this to work well.

2. Gather those notes into groupings that seem to make sense in a semantic way (caution: semantic is a hugely loaded word so please use this term lightly in this case; ie, i’m not referring to XML semantic validity, etc.)

3. Iterate successively on those groupings, constantly questioning why the clumps are what they are, why can’t this item go over there, etc. Move towards smaller, meaningful groups of notes. This is why you want folks from dev and PM–starts to force questions about assumptions, functions, relationships, etc. and lots of “why do we have this anyway?” kind of thinking…

4. While grouping, assign a simple, meaningful label for each group that captures the gist of what that group is about. Naturally there will be changes and debates but pick something and move on. Avoid marketing terms, just get to the heart of what it’s about functionally or semantically. Use the domain jargon if appropriate for the user audience.

5. List out the groups on the side, giving an approximate percentage of importance for each group. For example, File Exchange functions might be 75% of the navigation bar because it’s for a data transfer application, while User Prefs would be only 5% since it’s done once and typically not re-visited after that. These percentages will be useful for the next step.

— So that is basically the card sorting portion of the exercise. Usability purists will note that a true card sort activity can last for days, usually involving hours spent with one domain expert at a time, not multiple folks simultaneously. And of course a detailed report suggesting recommendations emerges from the activity. The goal here is expediency and getting to action/decisions to move the process forward in a real-world product development situation. Remember, real artists ship! —-

5. Now we get into the magazine layout part of the process. Mindful of the group labels and their respective percentages, draw on the whiteboard some boxes for the groups–they’re just layouts. NOT UI controls or widgets! That’s later on… You want to do this fairly quickly, no more than 2 minutes per layout drawing, generating 3-4 per person (yes, force those PM’s and developers to draw!). Helpful to use different colored markers for each person.

6. Now step back and discuss each layout, the rationale and issues (but not getting into UI widget stuff or style ideas yet) and vote successively on a) which one approximates the ultimate ideal b) which layout is most like today’s and c) which layout is a good transition from today to the ideal.

7. Based upon these drawings and groupings, the team is ready to proceed to the next phase: visual mockups and explorations, including UI controls and styles…

To summarize, the benefits of the box exercise include:
– Cross-disciplinary collaboration in a) understanding the functions and b) generating improved alternatives
– Connecting a common usability activity with designing, “making something” that moves the overall UI design forward
– Involves non-design members to contribute ideas
– Leverages a simple drawing scheme: boxes! anybody can draw a box.
– Encourages critical thinking about the content and functionality, before entering the UI widget/style stage

What is a pixel anyway?

An abbreviation of “picture element” but so much more! Basically it’s a mathematical abstraction, not simply a “dot on the screen”, as one may mistakenly presume. Nor does it have a physically determinate size, since it’s size is dependent upon many factors, including screen resolution of the display device. This can become very metaphysical very quickly, but essentially as an abstraction that is processed electrically via “computer parts” (extreme layman’s terms) and represented on the display via RGB color values, pixels are in effect not “real” but simulations/representations of mathematically defined logical structures/units. Sounds like the matrix, doesn’t it???

More to it than this…trying to find papers/books that refer to this deeper view of pixels and will update shortly.